5.7.40

Enhanced Status Code 5.7.40: DMARC Record Missing or Invalid

Permanent failure Critical severity Authentication RFC 7489
What it means

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.

At a glance
Code5.7.40
Bounce typeHard (permanent)
SeverityCritical
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7489
What it looks like in your mail logs
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

Your server attempts delivery
The recipient server returns a permanent 5.7.40 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.40 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
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.

Gmail Message blocked because the DMARC record or policy is missing or invalid Reference
Gmail The same code is also returned with a 504 reply for an unrecognized authentication type Reference

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

Frequently asked questions

What does 550 5.7.40 mean from Gmail?
It means Gmail blocked the message because your sending domain has no DMARC record, or has one it cannot parse. Since February 2024 Google requires bulk senders to publish DMARC, and a record with a syntax error counts as absent. This is a permanent rejection, so the mail will not deliver until the record is corrected.
What is the minimum DMARC record that satisfies Google?
A record at _dmarc.yourdomain.com containing v=DMARC1; p=none; rua=mailto:[email protected] meets the requirement. p=none means take no enforcement action, so it changes nothing about how your mail is handled while satisfying the rule and starting the flow of aggregate reports you need before tightening the policy.
I published DMARC but still get 5.7.40. Why?
Check the record name first: DMARC lives at _dmarc.yourdomain.com, and a record at the apex will not be found. Then check the tag order, because v=DMARC1 must come first and a record beginning with p= is invalid. Finally check for duplicates, since two records at _dmarc make the policy indeterminate and the receiver treats that as none at all.
Does my subdomain need its own DMARC record?
Not necessarily. If a subdomain publishes no record, receivers fall back to the organisational domain policy, so an apex record covers it. The danger is the reverse: a subdomain that publishes its own broken record overrides the working apex policy and breaks a path that would otherwise have been fine. If you publish per subdomain, validate each one.
Is 5.7.40 the same as a DMARC policy rejection?
No, and the difference is important. 5.7.40 means the record is missing or unreadable. 5.7.26 means the record was read fine and your message failed the policy it sets. The first is a DNS problem, the second is an authentication problem. Fixing the record does nothing for a message that still fails SPF and DKIM alignment.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes