550 5.7.40: No DMARC policy for a bulk sender (Gmail)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.40: not in the IANA registry; the group is security or policy status (RFC 3463 §3.8).
• Who uses it: Google (Gmail): the sending domain has no DMARC policy.

A 5.7.40 bounce from Gmail means your sending domain has no DMARC record, and Gmail requires one from bulk senders. Publishing a basic DMARC policy is enough to clear this particular error.

What it means

This is Google's code, and its meaning comes from Google. Google's SMTP error reference lists it in two forms:

• 421 4.7.40: the domain has no DMARC policy, and Gmail rate limits your mail. Your server will retry, but deferrals continue until the record exists.
• 550 5.7.40: the same reason, and the message is refused.

DMARC is a DNS record on your From: domain. It tells receivers what to do with mail that fails SPF and DKIM alignment, and where to send reports.

What Gmail requires

Google's sender guidelines split senders in two:

• All senders: SPF or DKIM, valid forward and reverse DNS, and TLS.
• Bulk senders (around 5,000 or more messages a day to personal Gmail accounts): SPF, DKIM and DMARC. The DMARC policy may be p=none. The From: domain must align with SPF or DKIM, and marketing and subscribed messages need one-click unsubscribe.

So the policy does not have to block anything. It only has to exist.

Common causes

• The domain never had a DMARC record.
• The record sits at the wrong host name, or has a syntax error, so receivers do not find a valid policy.
• You started sending from a new domain (a second brand, say) that was never given a record.
• A DNS change removed the record.

Google also lists 504 5.7.40 for an unrecognized authentication type when a client signs in: that is an SMTP AUTH problem, covered under 530 5.7.0 and 535 5.7.8, not DMARC.

How to fix it

1. Look up your From: domain with the DMARC checker.
2. If there is no valid record, build one with the DMARC generator. Start with p=none and an address to receive aggregate reports.
3. Publish it in your DNS, then run the checker again.
4. Make sure SPF or DKIM passes for your From: domain, or DMARC will fail even with a record: see 5.7.32 for alignment and the SPF checker and DKIM checker.
5. Read the reports for a few weeks. When every legitimate source passes, you can move to a stricter policy.
6. Resend, or let your queue retry the deferred mail.

What to do with the address

Keep it. A 5.7.40 refusal is about your domain's DNS, never about the recipient's mailbox.

Related codes

• 5.7.32: From: domain not aligned with SPF or DKIM (Gmail)
• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it
• 550 5.7.27: SPF failed for a bulk sender (Gmail), or the sender has a null MX

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.