Delivery Status Notification Failure: Gmail's bounce notice

Will the message arrive later? No. The sending server has stopped trying for the addresses in the notice.

Reading the notice

1. Read the address next to Final-Recipient. It also appears in the readable part at the top. The notice shows it exactly as your mail app sent it, so an autocomplete mistake shows up here.
2. Find the reply from the receiving server. Gmail puts it in Diagnostic-Code. Microsoft prints it under Diagnostic information for administrators, beside the name of the server that rejected the message.
3. Check the status code in that reply, leading digit first. A 5 means the message as sent fails again, and a 4 means the receiving server called the problem temporary. Email bounced back has the RFC 3463 definitions and sorts bounces by reply code.
4. Fix the cause in the reply, then resend. A failure notice covers only the addresses it lists, so a message to 6 people can fail for one of them and arrive for the other 5.

The Mail Delivery Subsystem page explains each field, and what to do when a batch of notices arrives at once.

The Action field

Google's help page tells you to look for mail from "Mail Delivery Subsystem (mailer-daemon@googlemail.com)". It says "The subject line is often 'Delivery Status Notification (Failure).'" A notice from Outlook.com or from a self-hosted server uses different wording in that subject line, but it carries the same fields underneath.

A retry notice looks almost the same in your inbox, but it reports a delay. Its subject is only a summary, so check the Action line. Every per-recipient block in the notice has one. RFC 3464 defines Action: delayed as more attempts to come, and Action: failed as an address the server has abandoned. Google documents only the failure wording, so trust the field over the subject.

A delayed message can still end as a failure days later, when the queue runs out. RFC 5321 tells a sender to wait at least 30 minutes between attempts on one destination. It says the give-up time "generally needs to be at least 4-5 days". Each provider sets its own timers inside that range. Exchange Online retries a temporary error over 24 hours, then returns the message to the sender:

Exchange Server on your own hardware mails the delay warning after 4 hours by default and expires the message after 2 days. Act on a delay notice before the queue expires. After that, you'd be resending a message that's days old.

Fixes, by reply

The reply gives the cause, and often someone else has to fix it.

• No such address. This one is yours to fix. Check the spelling on both sides of the @, then ask the person for a current address.
• Mailbox full, or the far server busy. The recipient has to fix it. Reach them another way and let them clear it.
• Refused as spam. Whoever runs the sending server has to fix it. Gmail reports that refusal as Message blocked. When Gmail throttles instead of refusing, the reply says 421 4.7.28, and the message stays queued.
• SPF, DKIM or DMARC in the reply. Send it to the person who runs DNS for the sending domain. 550-5.7.26 is Gmail's version of that rejection.
• A sending limit. Google blocks a personal Gmail account that sends more than 500 emails in a day, or one email to more than 500 recipients. Google says you can send again within 24 hours.

Bounce, DSN and NDR

Microsoft and Postfix notices use other wording. Bounce, DSN and NDR are all names for the same message. Microsoft calls it a nondelivery report and treats the NDR as the most common type of delivery status notification. The user section of an Exchange NDR opens "Delivery has failed to these recipients or groups:". Postfix is the open-source mail server behind a lot of self-hosted domains. Its built-in failure template reads "Undelivered Mail Returned to Sender", and its delay template reads "Delayed Mail (still being retried)". The delay message then says you don't need to resend.

Underneath, RFC 3464 makes all of them the same object: a multipart/report message whose report type is delivery-status. A human-readable explanation comes first, then a message/delivery-status block of per-recipient fields. The third part carries your own message or its headers, when the reporting server can return them.

Microsoft's own worked example ends like this:

In Microsoft's explanation, the server mail.contoso.com rejected the message, 530 5.7.1 Client was not authenticated is its reply, and the admins at contoso.com have to fix it. The server that wrote the notice and the server that refused the message are often two different machines.

Fake failure notices

Phishers copy delivery notices because everyone has seen a real one. SANS wrote up a phishing run that copied an Office 365 non-delivery notification. The mail offered a link to resend the failed message. The page behind that link asked for the address and the mailbox password.

Before you trust a notice, check these:

• No sign-in. A real notice reports the fate of one message. It never puts your mail behind a release button or a login page on a website.
• Action and the reply text. Read both without opening a link or an attachment. Most real notices also return your message or its headers. Under RFC 3464 a reporting server can leave that part out, so a missing copy proves nothing.
• mailer-daemon@googlemail.com on a Gmail notice. That domain publishes p=quarantine, so a receiver applying the policy files a forged copy in spam. Check it yourself with dig +short TXT _dmarc.googlemail.com. DMARC covers the domain in the visible From address. The display name printed in front of it can say anything.

Bounces for mail you didn't send

RFC 3464 requires a reporting server to send the notice to the transport envelope's return address. That's a different address from the one in the visible From header. Spammers forge that envelope address, so the failure notices for a spam run land on a stranger.

The same RFC requires a DSN to travel with an empty envelope sender, MAIL FROM:<>. Because of the empty sender, no server sends a notice about a notice. It is also why an SPF check on a bounce falls back to the sending server's HELO name.

Search your Sent folder for the message the notice quotes. If it isn't in that folder or your app logs, a spammer forged the envelope address. They didn't need access to your mailbox to do it. The Mail Delivery Subsystem page has the tracing steps for a run of these, and the limits of p=reject against a forged envelope.

Authentication errors

When the reply mentions authentication, the notice covers one message and one receiver. RFC 3464 says a DSN describes the delivery status for exactly one message. The other systems sending as your domain do not appear in it, and you hear about each one only when a receiver bounces its mail.

Run the domain that bounced through our DMARC checker, free and with no signup. Then run it through the SPF checker, which resolves the includes and counts your record's lookups against the limit of 10. A DKIM error needs the selector from a message the same system sent, and our DKIM checker looks up the key published under that selector. Our combined checker checks SPF, DKIM and DMARC for one domain at once.

Some rejections cite reputation instead. Google Postmaster Tools shows the spam rate and the authentication rates for the mail you send to Gmail. Google notes that data can be missing for a day when the message count is too low, to protect users' privacy. Verify the domain now, so the numbers are there the next time a bounce cites your sending reputation.

Receivers already write DMARC aggregate reports about your domain, and two outside tools read those reports at no cost. Postmark's DMARC Digests send one summary a week once you point a rua= tag at the address they give you. The free tier kept 7 days of history when I last checked, and the paid plan cost $14 a month per domain. Cloudflare's DMARC Management charts the same reports on every Cloudflare plan, and it needs the domain to use Cloudflare DNS.

One bounce covers one message, and the sender behind it is rarely the only one on your domain that fails. On the Starter plan, at $19 a month, we alert you the day a report first shows a new source failing DMARC on one of your domains, instead of the following Monday. We keep daily totals per source for the life of the account on every plan, so you can check whether this sender ever passed. The first domain is free, and alerts come with the paid plan for when one email a week isn't enough. A receiver's report counts messages by source IP and contains none of them, so we can't read the notice in your inbox.