Email bounce codes explained: SMTP and enhanced codes

A bounce is the receiving mail server’s “no”, relayed back to you. Most rejections carry two codes and a sentence of text, like this one from Gmail:

550 5.1.1 The email account that you tried to reach does not exist.

550 is the SMTP reply code, 5.1.1 is the enhanced status code, and the rest is the receiving provider’s explanation. Read all three, the text most carefully.

Two codes from two standards

The SMTP reply code (RFC 5321, section 4.2) has three digits. The first decides what happens next:

First digit	Meaning	What the sending server does
2	Success	Done
3	Intermediate, e.g. 354 after DATA	Continues the dialogue
4	Transient failure	Keeps the message and retries later
5	Permanent failure	Doesn’t repeat the request; returns a bounce

The second digit is a rough category (x0z syntax, x2z connections, x5z mail system) and the third a finer grade. RFC 5321 advises clients to rely on the first digit when possible.

The enhanced status code (RFC 3463) has the form class.subject.detail. Servers that advertise the ENHANCEDSTATUSCODES extension (RFC 2034) put it right after the reply code, and its class must match the first digit: a 5xx reply carries a 5.x.x code. The subject says where the problem is:

Subject	Area	Example
x.0.x	Other or undefined	5.0.0
x.1.x	Addressing	5.1.1 bad destination mailbox address
x.2.x	Mailbox	4.2.2 mailbox full
x.3.x	Mail system	5.3.4 message too big for system
x.4.x	Network and routing	4.4.7 delivery time expired
x.5.x	Mail delivery protocol	5.5.2 syntax error
x.6.x	Message content or media	5.6.0 other or undefined media error
x.7.x	Security or policy	5.7.1 delivery not authorized

IANA keeps the registry of codes; later RFCs added more, such as the authentication codes in RFC 7372.

The text is free-form, and this is where providers explain themselves. One code can cover very different situations: Gmail uses 550 5.7.1 for more than a dozen reasons. Providers also use some numbers differently from the registry: Gmail’s 5.7.27 means “SPF didn’t pass”, while the registry defines X.7.27 as “sender address has null MX” (RFC 7505). Treat the number as a category and the text as the diagnosis.

4xx or 5xx: retry, or change something

4xx means temporary. Your mail server keeps the message and tries again; RFC 5321 recommends a retry interval of at least 30 minutes and a give-up time of at least 4–5 days. Meanwhile you may get a delayed notice. That isn’t a bounce, and RFC 3464 says list software shouldn’t remove subscribers because of it.

If one provider keeps answering 4xx for days, the cause is usually reputation, volume or authentication. Gmail, for example, uses 4.7.x codes for temporary rate limiting and 5.7.x codes for blocks. Slow down and fix the cause named in the text; retrying faster makes it worse.

5xx means permanent. Don’t send the same message again unchanged. RFC 5321 says the client should not repeat the exact request, Microsoft’s Outlook.com policies say senders must not retransmit after a 5xx, and Yahoo says not to retry 5xx errors. First change the address, your DNS or the message.

Even a 5xx can come from a temporary condition, so RFC 3464 recommends removing subscribers only after persistent failure, not after a single report. A clear “mailbox does not exist” from the recipient’s provider is the exception most senders act on at once; Yahoo says to remove such addresses.

Common codes and what to do

550 5.1.1 — the mailbox doesn’t exist

RFC 3463: bad destination mailbox address, meaning the part left of the @ is invalid. Gmail: “The email account that you tried to reach does not exist.” Exchange Online uses 5.1.1 and also 5.1.10 (recipient not found).

Do: check for typos — the email syntax validator catches common domain misspellings — and stop mailing the address. If it’s an address in your own domain, check that the mailbox or alias exists. If the domain itself is wrong (5.1.2, bad destination system address), look at its MX records with the MX lookup.

550 5.7.1 — delivery not authorized

RFC 3463: delivery not authorized, message refused, the result of per-host or per-recipient filtering. In practice it’s a catch-all. Gmail returns it for, among other things, a policy set by the recipient’s domain, mail that is “likely unsolicited”, a very low reputation of the sending IP or domain, a missing or repeated From header and a missing Message-ID. Exchange Online uses it for senders who may not write to a group, for unable to relay and for client was not authenticated.

Do: read the text. A recipient policy (Gmail adds gcdp to errors from a Google Workspace administrator’s custom rules) is for the recipient’s administrator to resolve. For reputation, work through why emails go to spam; format errors mean fixing the message.

5.7.26 and other authentication failures

RFC 7372 defines X.7.26 as multiple authentication checks failed, alongside X.7.23 (SPF validation failed) and X.7.25 (reverse DNS validation failed). Gmail uses 550 5.7.26 when a message is unauthenticated (neither SPF nor DKIM passed), when the envelope sender domain’s SPF record ends in -all and the check fails, and when the From domain’s DMARC policy rejects the message. 421 4.7.26 is the temporary form: Gmail rate-limits unauthenticated mail.

Gmail has more codes for its sender requirements: 5.7.27 (SPF didn’t pass), 5.7.30 (DKIM didn’t pass), 5.7.25 (no PTR record, or its forward DNS doesn’t match the IP) and 5.7.29 (no TLS), each with a temporary 4.7.x counterpart: 4.7.27, 4.7.30 and 4.7.29, and for the PTR check 4.7.23. Exchange Online answers 5.7.509 when the sender’s domain fails DMARC and publishes p=reject, and Outlook.com rejects high-volume senders that miss its authentication requirements with 550 5.7.515.

Do: paste the headers of a message that did arrive somewhere into the email header analyzer and look at Authentication-Results. Then fix SPF, DKIM or DMARC alignment. For PTR errors, use the reverse DNS lookup.

421 4.7.0 — try again later

RFC 5321: 421 service not available, closing transmission channel; RFC 3463: X.7.0 other or undefined security status. Gmail uses 421 4.7.0 for, among other things, a very low reputation of the sending IP or domain, suspicious content or links, a missing PTR record and “TLS required for RCPT domain”. A related code, 421 4.7.28, means Gmail has detected an unusual rate of mail.

Do: let your server retry. If the code persists, reduce volume, check PTR and TLS, and look at Google Postmaster Tools.

452 4.2.2 — mailbox full

RFC 3463: X.2.2 mailbox full, intended as a persistent transient failure; in RFC 5321, 452 is insufficient system storage. Gmail: “The recipient’s inbox is out of storage space.” When the full inbox is also inactive, Gmail answers 552 5.2.2.

Do: let the retries run. An address that stays full for weeks is effectively abandoned, so stop mailing it. Note that RFC 5321 also uses 452 for too many recipients (Gmail: 452 4.5.3): your server should send the remaining recipients in another transaction.

554 with 5.7.x — transaction failed

RFC 5321: 554 transaction failed (as the greeting on a new connection: “no SMTP service here”). With a 5.7.x code it’s a policy rejection. Yahoo uses 553 and 554 for permanent problems, including invalid addresses, failed DMARC or DKIM checks, content it won’t accept and an IP listed by Spamhaus. Gmail uses 554 5.7.0 for “too many unauthenticated commands”.

Do: read the text. A blocklist mention means checking the listing and fixing its cause — the IP blocklist checker shows the public lists that include your IP; an authentication mention means the steps in the 5.7.26 section.

Reading a bounce message (NDR)

A non-delivery report is usually a multipart/report message (RFC 6522) with a human-readable part, a machine-readable message/delivery-status part (RFC 3464) and often the original message or its headers. The machine-readable part looks like this:

Reporting-MTA: dns; mail.example.net
Final-Recipient: rfc822; alice@example.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx1.example.org
Diagnostic-Code: smtp; 550 5.1.1 mailbox does not exist

1. Action: failed is a bounce; delayed means your server is still retrying.
2. Who said no: Reporting-MTA wrote the report. If a Remote-MTA field is present, the diagnostic came from that remote server; if it’s missing, it came from the reporting server itself — possibly your own server or email service, before the message left. Exchange Online reports show the same distinction as Generating server and Remote server.
3. Status and Diagnostic-Code: the enhanced code and the server’s actual reply. The Diagnostic-Code is the most precise information in the report.
4. Final-Recipient: the address that failed. It can differ from the address you sent to if the mail was forwarded.

Bounces for messages you never sent usually mean someone forged your address as the sender. A DMARC enforcement policy (how to configure DMARC) reduces the spoofing behind them.

Quick reference

You see	It means	Do
4xx / 4.x.x once	Temporary condition	Nothing; your server retries
4xx from one provider for days	Rate limiting, reputation or authentication	Slow down; fix the cause named in the text
5.1.x	Address problem	Fix the typo or stop mailing the address
5.2.x	Mailbox problem (disabled, full)	Stop mailing addresses that keep failing
5.4.x	Network or routing problem	Check the recipient domain’s MX records
5.6.x	Message content or format	Fix the message
5.7.x	Security or policy	Fix authentication or reputation, or contact the recipient’s admin

Not sure where to start? The delivery troubleshooter walks through the checks step by step.