Enhanced Status Code 5.7.40: DMARC Record Missing or Invalid
Enhanced Status Code 5.7.40 means “DMARC Record Missing or Invalid.” Google rejected the message because the sending domain publishes no DMARC record, or publishes one it cannot parse. Since February 2024 a valid DMARC policy is a requirement for bulk senders, not a recommendation.
550 5.7.40 Message blocked. The sending domain has a missing or invalid DMARC record or policy
What does 5.7.40 mean?
Google returns 5.7.40 when a message is blocked because the sending domain has a missing or invalid DMARC record or policy. It is not an IANA-registered code; it belongs to the block of codes Google introduced alongside its February 2024 sender requirements, and it exists because publishing DMARC moved from best practice to entry requirement.
The requirement itself is modest. Bulk senders must publish a DMARC record, and a policy of p=none satisfies it. What fails is not usually a refusal to publish but a record that does not parse: a policy tag that is not the first tag, a missing v=DMARC1 version, a record published at the domain apex instead of at _dmarc, or several DMARC records published at the same name. Any of those reads as absent.
The subtlety that catches people is where the record must live. DMARC is looked up at _dmarc.yourdomain.com, and for a subdomain the receiver falls back to the organisational domain policy only if the subdomain has none of its own. Senders who publish at the apex and then send from a subdomain often believe they are covered when they are, but senders who publish a subdomain record with a syntax error break a path that the apex would otherwise have rescued.
How 5.7.40 plays out
5.7.40 rejectionWhere 5.7.40 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.7.40 is | ✓ this code |
What each provider means by 5.7.40
A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.
Common causes of 5.7.40
- No DMARC record is published for the sending domain at all
- The record is published at the domain apex rather than at the _dmarc subdomain
- The v=DMARC1 version tag is missing or is not the first tag in the record
- The p= policy tag is missing, misspelled, or set to an unrecognised value
- More than one DMARC record exists at _dmarc, which makes the policy indeterminate
- The record contains a stray character, smart quote, or line break introduced by a DNS editor
How to fix 5.7.40
- Publish a TXT record at _dmarc.yourdomain.com, not at the apex
- Start with v=DMARC1; p=none; rua=mailto:[email protected], which satisfies the requirement
- Confirm v=DMARC1 is the first tag and p= is the second, since order is significant
- Verify with DMARC Record Checker that exactly one valid record resolves
- Check any subdomain you send from, because its own broken record overrides the apex
- Read the aggregate reports for a few weeks before moving to quarantine or reject