Bounce and error codes

Mail Delivery Subsystem: check whether your message arrived

Last updated 2026-08-18

Mail Delivery Subsystem is the From name Gmail puts on a delivery notice. Action says whether Gmail planned more attempts or stopped. The Final-Recipient block names the address, and Diagnostic-Code explains the cause when the remote server includes it.

Message count chooses the path

One message came back. That path answers whether the recipient got it and who owns the fix.

Domain-wide bounces are arriving for several users or from an app. That path groups the replies and traces the largest group to its source.

Gmail's bounce address

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. The visible From header alone does not authenticate a message.

Action decides delivery

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

• Final-Recipient names the address covered by this block. Read it for typos.
• Action states the outcome. failed ends delivery attempts for that copy; delayed means Gmail queued more attempts.
• Status is the enhanced status code. In these notices, 4 is a temporary failure and 5 is a permanent one. The next digit names the subject; the last 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 retries, 5xx stops

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-message bounce

1. Original message: use the recipient and subject in Sent to identify the send. 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: a missing letter is the whole story. Correct it before resending.
4. Diagnostic-Code: a nonexistent mailbox calls for a corrected or alternate address. For a full mailbox, wait or contact the person another way. An error naming email authentication belongs to the sending setup; the code list below points to the matching fix.
5. Links and attachments: leave them closed. The delivery-status fields and surrounding explanation let you assess delivery without opening them. A familiar display name or From address does not 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. For a personal Gmail send whose error names Gmail's authentication, contact the recipient another way; their mail admin may need to inspect 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. Named failure: apply only that fix. Authentication errors lead to DNS and sender configuration. The code pages below cover rate limits and address failures.

Trace an unsolicited notice as one of 2 cases:

• 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. A policy of p=reject asks participating receivers to reject forgeries that also put your domain in the visible From. Envelope-only forgery falls outside DMARC. After SPF covers every legitimate source, an ending of -all tells receivers that other IPs fail, though each receiver decides whether to reject them.

A batch can contain several failures. Treat each group as its own incident. The first bounce may not represent the queue.

When a group names DMARC or authentication, check the domain named in the error:

The result needs 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 incidents, aggregate reports group the source IPs and authentication results that participating receivers observed. They do not identify a particular bounce or account for 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.

DomainCanary is our product, so read this paragraph knowing that. It parses the aggregate reports and mails a weekly digest, free for the first domain. It does not read the bounce you have open, and forensic reports are not in the product.

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 naming 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 names the cause when the remote server supplied one.