Mail Delivery Subsystem: Gmail is reporting a failed or delayed message

Mail Delivery Subsystem is the From name Gmail puts on a delivery notice, and the notice says whether your message failed or is still queued. Action: failed means Gmail stopped trying, and Action: delayed means more attempts are coming. Diagnostic-Code holds the remote server's reply, which says what to fix.

Did the recipient get your message? Not if Action says failed. Fix the cause and send it again.

One bounce or many

One message came back. That section shows whether the recipient got it and who has to fix it.

Domain-wide bounces are arriving for several users or from an app. That section shows how to group the replies and trace the largest group to its source.

The From and Subject lines

The Subject reads Delivery Status Notification (Failure) for a failed copy. Gmail uses Delivery Status Notification (Delay) while it keeps retrying.

Other mail systems use similar From names. googlemail.com is Gmail's normal bounce domain, and mailer-daemon is the automated sender mail servers use for delivery notices. Anyone can forge the visible From header, so it doesn't prove a notice is real.

The Action field

The machine-readable part has one block for each affected recipient:

• Final-Recipient is the address this block covers. Read it for typos.
• Action is the outcome. failed means Gmail stopped trying that copy, and delayed means it queued more attempts.
• Status is the enhanced status code. In these notices, 4 is a temporary failure and 5 is a permanent one. The middle digit gives the subject, and the last one adds detail.
• Diagnostic-Code, when present, preserves the remote server's SMTP reply and explanation.

SMTP multi-line replies put a hyphen after the code on continuation lines. 550-5.7.26 and 550 5.7.26 are the same rejection.

4xx and 5xx replies

A 4xx SMTP reply tells Gmail to queue the message and retry. A delay can still end with a later failure notice when the queue expires. Gmail's rate-limit form is 421-4.7.28.

A 5xx SMTP reply tells Gmail to stop for that recipient. The notice then says Action: failed. Fix the cause before sending a new copy.

One bounce

1. Original message: find it in Sent by recipient and subject. No match can mean a forged return-path or an app that does not save mail in Sent.
2. Action: for delayed, wait for a newer notice or ask the recipient before resending. For failed, keep reading.
3. Final-Recipient: check the address for a missing letter, and correct it before resending.
4. Diagnostic-Code: if the mailbox doesn't exist, get a corrected or alternate address. If it's full, wait or contact the person another way. If the error mentions email authentication, the fix is in the sending setup. The code list below links to each fix.
5. Links and attachments: leave them closed. You can judge delivery from the delivery-status fields and the explanation around them. A familiar display name or From address doesn't prove who sent a message.

If Sent contains mail you did not write, run Google's Security Checkup and inspect Gmail's forwarding rules. If Sent has no matching message, a forged return-path can send the notice to you without touching your account. Repeated notices alone do not prove a mailbox breach.

Give an authentication failure from a work account to your mail admin. If you sent from personal Gmail and the error mentions Gmail's authentication, contact the recipient another way. Their mail admin may need to check the receiving rule.

Domain-wide bounces

Delivery notices go to the envelope sender. An app can use a bounce mailbox configured in the platform rather than the address in the visible From header.

1. Action and Status: separate delayed mail from copies Gmail has stopped trying.
2. Diagnostic-Code and recipient domain: count the distinct replies, then start with the largest group.
3. Message-ID and Date: use them from the attached original to search the application logs.
4. The cause: apply only the fix for it. Authentication errors lead to DNS and sender configuration. The code pages below cover rate limits and address failures.

A notice for mail you didn't send comes from one of these:

• Your sending system used the return-path. The attached original and application logs identify the job or account.
• A forged return-path produced backscatter, which alone does not show a mailbox breach. If you publish p=reject, participating receivers reject forgeries that also put your domain in the visible From. DMARC doesn't cover forgery of the envelope alone. Once SPF lists every legitimate source, ending it with -all marks every other IP as a fail. Each receiver still chooses whether to reject them.

A batch can contain several different failures. Treat each group as its own incident, because the first bounce you open may not match the rest of the queue.

When a group's replies mention DMARC or authentication, check the domain in the error:

You want one DMARC TXT record whose first tag is v=DMARC1. Long TXT records can appear as adjacent quoted chunks on one line. Run the visible From domain through the DMARC checker. Check the envelope sender domain with the SPF checker, which follows every include and counts the lookups. For a DKIM error, take s= from a message sent by the same system and use the DKIM checker.

For authentication problems, aggregate reports group the source IPs and the authentication results that participating receivers saw. They don't point to a particular bounce, and they don't cover every message. Reading a report by hand shows how to separate a legitimate sender from a spoof.

For reputation errors returned by Gmail, Google's free Postmaster Tools shows domain reputation when the domain sends enough traffic for Google to display data.

For ongoing authentication failures, use Cloudflare's DMARC Management if your DNS is already there. It charts aggregate reports for free. Postmark's DMARC Digests mail a weekly summary. When I last checked, free monitoring shows the top 10 sources over 7 days.

We read your aggregate reports and mail you a weekly digest, free for the first domain. We can't see the bounce you have open, and the product doesn't include forensic reports.

Common bounce codes

• 550-5.7.26: Gmail refused the message for authentication, or applied a DMARC reject.
• 421-4.7.28: Gmail deferred the message and retries from its queue.
• 550 5.7.1 mentioning DMARC: a receiver applied your policy.
• 550 5.7.515: Microsoft refused a bulk sender that is missing authentication.
• 550 5.7.509: Microsoft applied your own p=reject.
• 550 5.7.23: Microsoft failed SPF for the connecting IP.

Start with Action and Status for the outcome. Diagnostic-Code gives the cause when the remote server supplied one.