Email bounce-back messages explained (what the codes mean)

A bounce-back is not an error string. It is a structured document, defined by RFC 3464, delivered as an ordinary email to the address in your Return-Path — which is the envelope sender, not the From header. It carries named fields: which server reported the failure, which recipient it concerns, whether delivery was abandoned or delayed, an enhanced status code, and the raw text the remote server actually said. Read those fields and the diagnosis is usually immediate. Read only the subject line and you will misfile half of them.

A bounce-back is addressed to a mailbox you may not be reading

The routing rule is unambiguous and constantly misunderstood. When a receiving server cannot deliver a message it has already accepted, it generates a notification addressed to the envelope sender — the address supplied in the SMTP MAIL FROM command at the start of the transaction, which appears in a delivered message as the Return-Path header.

It is not sent to the From header. It is not sent to Reply-To. Those are display and reply routing; the envelope sender is where delivery failures go, and the two are often deliberately different.

RFC 3464 adds one more rule that explains why these messages look odd: "Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e., MAIL FROM:<>." A bounce has no return address of its own, so a bounce cannot bounce. That is the loop protection, and it means the message arrives with an empty Return-Path: <>, which some filters treat with suspicion and some mail rules discard.

Two configurations therefore make bounces invisible while everything looks healthy:

• The Return-Path is on the platform's bounce domain. Common, and usually fine, because the platform reads it and reports back. Verify that it does.
• The Return-Path is on your sending domain and that domain cannot receive mail. This is the failure. RFC 5321 section 5.1 specifies that a domain with no MX records is treated as having an implicit MX at its address record, so mail is attempted against your web server, where nothing is listening on port 25. Every asynchronous bounce fails silently.

Your dashboard will show those messages as delivered, because the receiving edge answered 250 before it discovered the problem. Acceptance and delivery are separate events, and only the second one produces a bounce.

Opening one up: the three parts of a delivery status notification

A DSN is a MIME message with a top-level content type of multipart/report and a report-type parameter of delivery-status, specified by RFC 3464 with the container media type defined in RFC 6522. It has three parts, and the middle one is where the answers live.

Part one — the human-readable explanation. Prose written by the reporting server. Useful, informal, and not the authoritative source. This is the part most people read and the only part most email clients display.

Part two — message/delivery-status. The machine-readable block, structured as field: value lines in two groups.

Per-message fields describe the report itself. Reporting-MTA is required and names the server that generated the notification. Original-Envelope-Id, DSN-Gateway, Received-From-MTA and Arrival-Date are optional.

Per-recipient fields describe one recipient's outcome. Final-Recipient and Action and Status are all required. Original-Recipient, Remote-MTA, Diagnostic-Code, Last-Attempt-Date and Will-Retry-Until are optional and are the ones that make a diagnosis fast.

Part three — the original message, or its headers, or nothing. Optional. Useful when you need to confirm which campaign and which send produced the failure.

Reading one field by field

Here is an illustrative DSN body — the field names and structure are exactly as RFC 3464 defines them; the domains and addresses are invented for the example.

Reporting-MTA: dns; mail.yoursendingdomain.com

Arrival-Date: Tue, 8 Sep 2026 09:14:22 +0000

Final-Recipient: rfc822; [email protected]

Original-Recipient: rfc822; [email protected]

Action: failed

Status: 5.1.1

Remote-MTA: dns; prospectco-com.mail.protection.outlook.com

Diagnostic-Code: smtp; 550 5.4.1 Recipient address rejected: Access denied [DB8PR04MB6...]

Read it in this order.

Action first. failed means the reporting server has abandoned this recipient and no further notification should be expected. delayed means it is still trying. This field settles the retry question on its own, and it can disagree with the status code — RFC 3464 gives the case where a server retries for days and then sends a failed DSN whose status still begins with 4.

Remote-MTA second, because it tells you *whose* refusal this is. Here it is Microsoft's Exchange Online edge, which immediately narrows the catalogue you are searching.

Diagnostic-Code third. This is the verbatim reply the remote server gave, prefixed by its type — smtp;. It is the single most informative field in the whole document and the one to classify on. Note the mismatch in the example: the DSN's own Status field says 5.1.1 while the remote server said 5.4.1. The reporting server has normalised. Trust the diagnostic text.

Final-Recipient last, to confirm which address this concerns. It differs from Original-Recipient when an alias or list expanded, which matters if you are about to suppress something.

The catalogue, organised by what you have to change

Codes are easier to remember when they are grouped by the fix rather than by their number. Four groups, and they call for four completely different actions.

Group one — the address is dead. Suppress it.

• 550 5.1.1 The email account that you tried to reach does not exist — Gmail, no such mailbox.
• 550 5.4.1 Recipient address rejected: Access denied — Microsoft's Directory-Based Edge Blocking, which Microsoft documents as rejecting "messages for invalid recipients at the service network perimeter" before any filtering runs. The address is not in the tenant directory.
• 550 5.1.10 RESOLVER.ADR.RecipientNotFound — the same conclusion from Exchange's recipient resolver.

These are the only bounces that justify permanent suppression, and permanent is what suppression is. What separates a hard bounce from a soft one covers the classification rules underneath this group.

Group two — your authentication or your DNS. The recipient is innocent.

• 550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy — Gmail enforcing a policy you published.
• 550 5.7.509 Access denied, sending domain does not pass DMARC verification and has a DMARC policy of reject — Exchange Online enforcing a policy you published, at any volume.
• 550 5.7.515 Access denied, sending domain does not meet the required authentication level — Microsoft's high-volume rule for consumer Outlook, Hotmail and Live addresses, enforced from 5 May 2025 for domains sending more than 5,000 messages a day. Same 5.7 prefix as the previous line, entirely different cause: one is a policy you set, the other is a volume threshold you crossed.

Suppressing a recipient for any of these deletes a valid prospect for a fault in your own DNS.

Group three — your own account or credentials. Not a reputation event at all.

• 535 5.7.8 Username and Password not accepted — bad credentials or an app password that was never created.
• 550 5.7.139 SMTPClientAuthentication is disabled for the tenant — Microsoft 365 with authenticated SMTP switched off at tenant level. Note that the substring 5.7.1 sits inside 5.7.139, so a naive pattern match reads a tenant policy about your account as a permanent rejection of their recipient.
• MessageRejected, Email address is not verified, AccountSendingPausedException — Amazon SES refusing to submit because of your identity, your sandbox status or your account state.

If you connect Microsoft 365 and Outlook and see the second of those, the fix is a tenant setting, not a DNS record and not your list.

Group four — slow down, or fix reputation.

• 421 4.7.0 Try again later, closing connection — throttling. Reduce rate.
• 450 4.2.0 or 451 4.7.1 with greylisting language — a deliberate temporary refusal to an unfamiliar sender. Retry on schedule and it clears.
• 550 5.7.1 Our system has detected that this message is likely unsolicited mail — Gmail refusing you for reputation. A batch of these means stop sending and diagnose, not suppress everyone in the batch.
• 552 5.2.2 Mailbox full — the address exists and the person has stopped clearing it. Retry, then treat as dormant.

Why the order you classify in decides what gets deleted

Two of those four groups carry 5xx codes and none of them are about the recipient. That makes classification order load-bearing rather than cosmetic.

Autocloz matches the diagnostic text against pattern sets in a fixed sequence: complaint first, then sender-side configuration, then hard, then block, then soft, and only if none of those match does it fall back to the numeric code, where 5xx defaults to hard. The sender-side set is checked before the hard set specifically so that account suspended, sandbox, not verified, message rejected and sending paused cannot be read as a dead mailbox. Only hard and complaint cause suppression, and suppression is permanent and workspace-wide.

That ordering exists because of a real incident: on 1 August 2026 an Amazon SES AccountSuspendedException arrived carrying a 5xx, matched the generic fallback, and put a valid recipient on a global suppression list because of an AWS billing problem. A pattern order is a cheap fix for an expensive class of mistake.

Autocloz's free plan covers 5 users and 10 mailboxes with the six-way bounce classifier, workspace-scoped suppression and SPF, DKIM and DMARC monitoring included — start free and read one real bounce end to end before building any rule on top of it.

What a bounce costs inside your own sending system

A bounce is not only a signal to a receiver. It has an internal price, and the arithmetic is worth knowing because it explains why a mailbox stops sending.

Autocloz keeps a health score per mailbox, starting at 100. On each send outcome:

• Success: +1, capped at 100.
• A 4xx rejection: −2.
• A 5xx rejection: −8.
• Auto-pause when the score reaches the threshold, 40 by default and configurable per workspace.

From a clean 100, eight consecutive 5xx rejections trip it: 92, 84, 76, 68, 60, 52, 44, then 36 on the eighth. Recovery is deliberately asymmetric — climbing back from 40 to 100 takes sixty successful sends at +1 each, so damage is eight times faster than repair. That asymmetry is the point. A mailbox that has just refused eight messages in a row should not be back at full weight after eight good ones.

Two branches deliberately deduct nothing.

A failure with no provider reply code at all. That is the raw-exception path: expired credentials, a network fault, a library error, our own bug. The mailbox was never judged by a receiver, so none of it is evidence about its reputation. This branch used to fall through to −2, and during one queue-layer outage a live mailbox decayed from 100 to 12 across roughly 44 infrastructure failures and auto-paused itself, advising the operator to check SPF, DKIM and DMARC — on a mailbox that had sent nothing that day and showed 0.0% bounce and 0.0% complaint.

A configuration fault carrying a 5xx. An unverified sending identity or a paused provider account produces a real 5xx that says nothing about reputation. Health is left alone and the mailbox's last_error is stamped with the real cause, so the operator fixes the identity rather than chasing DNS records that were already correct.

Resuming a paused mailbox also lifts the score to the threshold plus 20 rather than merely flipping the status flag, because a resume that leaves the score at 38 re-pauses on the next send — a mailbox at 38 that succeeds recovers to 39 and trips the same check inside one tick.

Why you will never see most of your bounces, and what to do about it

Three mechanisms hide them, and all three are fixable.

The Return-Path is unreachable. Set an MX record on your sending domain and prove it receives. This is the single most common cause and the easiest to check.

The bounce is asynchronous and nobody reads the mailbox. Large receivers increasingly accept at the edge and generate a DSN minutes or hours later. If your platform does not poll that mailbox, those failures never reach your statistics and every address in the batch stays in your list to be mailed again.

Your bounce rate is a lagging figure by construction. Today's number describes outcomes that arrived today, not sends that happened today, which is why a threshold-based auto-pause always reacts to a batch that finished hours ago. Why that latency limits every control built on a bounce rate is worth reading before you set a threshold, and how a bounce rate is defined differently by every system that reports one is worth reading before you compare yours to anyone else's.

A quick audit that takes ten minutes: send one message from your sending mailbox to a deliberately invalid address at a domain you know rejects unknown recipients, wait, and confirm that the bounce arrives somewhere you can see it. If it does not, everything above is theoretical for you. Running the same check across every connected mailbox is what continuous mailbox and domain monitoring exists to automate, and a self-audit of the whole sending setup covers the records that make bounces readable in the first place.

What a bounce-back cannot tell you, and what Autocloz does not do

A bounce reports one delivery attempt to one recipient at one moment. It cannot tell you whether an accepted message reached an inbox or a spam folder, because the folder decision happens after acceptance and is never reported back through SMTP. A campaign with a 0.1% bounce rate and no replies has a placement problem that no bounce will ever describe.

It cannot tell you intent either. A 5.7.1 refusal on a per-recipient filter and one on a per-host filter read identically and mean different things, and no receiver publishes which it applied.

And Autocloz specifically. It classifies on the diagnostic text first and the numeric code second, which means a receiver that returns a bare code with no text falls back to the crude rule where any 5xx is treated as a hard bounce — that is the least accurate path in the system and it is the one a terse server forces. Gmail signals a reputation block with 5.7.1, an enhanced code the standard defines as a policy refusal, and this classifier treats it as permanent, so a batch refused for reputation can put innocent recipients on the suppression list; the list is reviewable and an owner or admin can remove an entry, which is the mitigation rather than a fix. It reads bounces that reach a mailbox it has access to, and it cannot read a Return-Path mailbox you have not connected. It does not verify addresses by SMTP probe at all, so it cannot pre-empt a hard bounce on a domain that refuses recipient enumeration. And it cannot see inside a receiving filter any more than anyone else can — the bounce is the receiver's own account of what it did, and that account is all there is.