Bounce and error codes

Delivery Status Notification Failure: what stopped your message

Last updated 2026-08-24

Failed or delayed: read 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. It names a delay rather than a failure. The subject is a summary, so check it against the field: every per-recipient block in the notice holds an Action line. RFC 3464 defines Action: delayed as more attempts to come, and Action: failed as an address the server has abandoned. Google documents the failure wording and not the delay 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 puts the give-up time at "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 while it is still a delay. Once the queue expires, you resend a message that is already days old.

Read the address, then the reply

1. Read the address next to Final-Recipient. It also sits in the readable part at the top. The notice quotes it as your mail app sent it, autocomplete slip included.
2. Find the reply from the far server. Gmail carries 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 far server called the problem temporary. Email bounced back has the RFC 3463 definitions and sorts bounces by reply code.
4. Fix the one thing the reply names, 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 takes the fields one by one, and covers a batch of notices arriving at once.

Who fixes it, by reply

The reply names the cause, and often the person who has to act is not you.

• No such address. You own this one. 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 owns it. Reach them another way and let them clear it.
• Refused as spam. The sending side owns it. Gmail wraps that refusal in Message blocked. When Gmail throttles instead of refusing, the reply reads 421 4.7.28, and the message stays queued rather than failing.
• 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.

Gmail, Microsoft and Postfix name it differently

Your notice may never use the phrase Delivery Status Notification at all. Bounce, DSN and NDR all name 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 body then tells the reader that no resend is needed.

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:

Microsoft's own reading of that line: 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 own the fix. The server that wrote the notice and the server that refused the message are often two different machines.

Fake failure notices ask for a password

Delivery notices make a good disguise, since everyone has seen a real one. SANS's writeup of a phishing run dressed as an Office 365 non-delivery notification walks through one of them. The mail offered a link to resend the failed message. The page behind that link asked for the address and the mailbox password.

Check three things before you trust a notice:

• 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. RFC 3464 lets a reporting server omit that part, so a missing copy is not evidence either way.
• 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. A display name proves nothing on its own. DMARC covers the domain in the visible From address, not the name printed in front of it.

Notices for mail you never sent

A reporting server sends the notice to the transport envelope's return address, not to the address in the visible From header, and RFC 3464 requires that. 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:<>. That empty sender stops a notice from earning a notice of its own. 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 neither that folder nor your app logs holds it, a spammer forged the envelope address. That forgery needs no access to your mailbox. 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 need the reports

When the reply names authentication, the notice has told you about one message and one receiver. RFC 3464 puts it plainly: 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 says how much of the 10-lookup budget your record spends. A DKIM error needs the selector from a message the same system sent, and our DKIM checker reads the key that selector publishes. The combined checker takes one domain and returns all three verdicts.

Some rejections name reputation rather than authentication, and Google Postmaster Tools shows the spam rate and the authentication rates for the mail you send to Gmail. Google's own note on the tool: data can be missing for a day when the message count is too low, to protect users' privacy. Verify the domain now, and the numbers are there the next time a bounce blames your sending.

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 hand 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. If your nameservers are already at Cloudflare, start there and stop reading.

DomainCanary is our product, so weigh this paragraph against the two tools above. One bounce covers one message, and the sender behind it is rarely the last on your domain to break. On Pro, at $19 a month, an alert reaches you the day a report first shows a new source failing DMARC on one of your domains, rather than on the following Monday. We keep at least 12 months of source-level detail on every plan, so the question of whether this sender ever passed has an answer. The first domain is free, and the paid plan adds the alerts whenever one email a week stops being enough. A receiver's report totals messages by source IP without carrying any of them, so we cannot read the notice sitting in your inbox.