Bounce and SMTP reply codes
Hard bounce vs soft bounce: how to read a bounce reply
Short answer
An SMTP rejection has a three-digit reply code for software, text for people and, often, a dotted enhanced status code such as 4.2.2. A 4xx reply is a soft bounce, a temporary failure that a retry may clear; a 5xx reply is a hard bounce, so fix the address or the cause, or stop mailing it.
Hard and soft are industry terms: the SMTP standards speak of permanent and transient failures, and the IANA registry names class 4 "Persistent Transient Failure". M3AAWG's Sender Best Common Practices, version 4.0 from August 2026, defines a hard bounce as a permanent failure and a soft bounce as a temporary one.
Hard bounce vs soft bounce
| Kind | Reply code | Enhanced class | What it means | What to do |
|---|---|---|---|---|
| Soft bounce | 4xx | 4.x.x | A temporary failure. The same request may succeed later. | Let the retries continue. |
| Hard bounce | 5xx | 5.x.x | A permanent failure. Resending the message unchanged is unlikely to work. | Change the message or the destination before a new send. |
RFC 5321 writes these replies as 4yz and 5yz. Its rule of thumb is that replies are 4yz "if they can be successful if repeated without any change in command form or in properties of the sender or receiver". A failure that needs a change first, such as a corrected address, belongs in 5yz. Microsoft's Exchange Online documentation draws the same line for dotted codes: "a 5.x.x code indicates a permanent error, and a 4.x.x code indicates a temporary error". For bounces reported in Amazon SES notifications, see what an Amazon SES bounce notification tells you.
A soft bounce can still end in a non-delivery. When the retries run out and the failure comes back to the sender, RFC 5321 says to read it as a non-delivery, like a permanent failure. RFC 3464 shows this in its own example: after five days of retries, the report says Action: failed with Status: 4.0.0. A final failure can still carry a class 4 code.
Some hard bounces can be fixed: RFC 5321 notes that even some permanent errors can be corrected, and a new attempt is fine after the correction.
Where a bounce shows up
A bounce reaches you in one of two ways: as a reply during the SMTP session, or as a separate bounce message later.
During the SMTP session. The receiving server can refuse a recipient or the whole message with a 4xx or 5xx reply, and your sending server records that reply at once. This is a synchronous bounce. M3AAWG notes that "most NDRs occur synchronously but this can vary based on the composition of the list" (an NDR is a non-delivery report).
After a 250. When the receiving server answers the message data with 250, RFC 5321 says "it is accepting responsibility for delivering or relaying the message". If delivery fails after that, the server "MUST formulate and mail a notification message". That bounce message has an empty envelope sender, written <>, and goes to the envelope return path, not to the From header. M3AAWG adds that B2B mail may see more of these asynchronous bounces, and that such a bounce can come "hours or even days later".
In Exchange Online, the server that generates the NDR tells you which case you are in. If the remote server never accepted the message, Exchange Online writes the NDR itself. If the remote server accepted it and later rejected it for content restrictions, the remote server writes the NDR. Microsoft adds that after such a late rejection "the remote server value isn't populated".
For what a 250 does and does not tell you about the inbox, see why delivered does not mean inbox.
How to read the reply line
The line below shows the parts of one reply. It joins the code and text that Gmail's SMTP error list documents for a full inbox with the gsmtp marker that Gmail adds to all its errors. It is documented text, not a captured bounce:
452is the reply code. RFC 5321 says: "The first digit denotes whether the response is good, bad, or incomplete." Here4means a temporary failure, and a client may read the second digit to see roughly what kind of error it was.4.2.2is the enhanced status code, writtenclass.subject.detail. In RFC 3463, the class says whether the delivery attempt succeeded, the subject gives the probable source of the problem and the detail names the exact condition. Here class4is a temporary failure, subject2is the mailbox and detail2means the mailbox is full.- The rest is text for people, and
gsmtpat the end is Gmail's marker.
RFC 2034 sets the order: "Servers supporting the Enhanced-Status-Codes extension must preface the text part of almost all response lines with a status code." The two codes must also agree: "a 4xx response must incorporate a 4.X.X code, and a 5xx response must incorporate a 5.X.X code".
The subject digit hints at who has to act:
X.1.xcovers addressing. RFC 3463 says: "These errors can generally be corrected by the sender and retried."X.2.xcovers the mailbox: "Mailbox issues are assumed to be under the general control of the recipient."X.7.xcovers security and policy, such as filtering for a recipient or a host and cryptographic checks. Such a reply is not proof that the address is dead.X.0.0is for errors where only the class is known.
A long reply can span several lines. RFC 5321 says every line "except the last" starts with the reply code and a hyphen, and "the reply code on each of the lines MUST be the same." 550 5.7.26 unauthenticated email shows a multi-line Gmail reply. To look up a dotted code, use the IANA registry.
Let the code decide, then read the text
RFC 5321 is strict about this: "An SMTP client MUST determine its actions only by the reply code, not by the text". Retry or stop by the code, then read the text, because it can explain why. A 535 reply to the AUTH command, such as Exchange Online's SMTP AUTH refusals, rejects the login during submission; it is not a bounce.
The text varies more than the code. M3AAWG notes that "the descriptive message can be customized to meet the needs of the receiver". In Exchange Server, the enhanced status code picks the user text in an NDR, and "the code value isn't altered by Exchange". Admins can rewrite that text for each code, while the code stays the same. Gmail adds markers such as gsmtp, and Apple's postmaster guidance says: "Most of the errors will also include a URL that provides more information."
The code alone also leaves the address question open. M3AAWG says the codes "do not clearly state whether or not the address should be removed from the mailing list". It also writes that an email service provider (ESP) can hide these details: "Too often these details are hidden by the ESP by only returning aggregate data". It adds: "Customers may need access to the actual NDR message to troubleshoot delivery issues."
How to read a bounce message
A standard bounce message is a delivery status notification (DSN). RFC 3464 defines it: "A DSN is a MIME message with a top-level content-type of multipart/report", with the report-type delivery-status. RFC 6522 sets out its parts:
- A human-readable message (required).
- A machine-readable account of what happened,
message/delivery-statusin a DSN (required). - The returned message, a part of it or only its headers (optional).
The example in RFC 3464, Appendix E, reports a message that could not be sent for five days. Here are its subject line and three of the lines for the failed recipient, with the other lines left out:
The message/delivery-status part holds fields such as these:
| Field | What it tells you |
|---|---|
Action | failed: the message "could not be delivered to the recipient", and the reporting server has stopped trying. delayed: it has not delivered the message yet and will keep trying. delivered does not mean that anyone read the message. |
Status | The enhanced status code. Its first digit is 2 for success, 4 for a persistent temporary failure and 5 for a permanent failure. |
Diagnostic-Code | The code that the mail transport actually issued, such as smtp; 550 user unknown in RFC 3464's other example. Status is sometimes less precise, so read both. |
Remote-MTA | The server that the reporting server was talking to when delivery failed. |
Reporting-MTA | The server that attempted the delivery, relay or gateway step that the report describes. |
Final-Recipient | The recipient address the report is about. It may differ from the address you sent to. |
Will-Retry-Until | Delay notices only: the date after which the reporting server expects to stop trying. |
Do not sort reports by the Status digit alone: the example above pairs Action: failed with a class 4 status.
Not every bounce looks like the standard
Gmail tells its users that a failed message brings "an automated bounceback email with an error message" (Gmail bounce help). It comes from "Mail Delivery Subsystem (mailer-daemon@googlemail.com)", and its subject line is often "Delivery Status Notification (Failure)".
Microsoft calls its delivery status notification a bounce message, and the common kind is a non-delivery report (Exchange Online NDRs). In Microsoft's older NDR layout, the SMTP response sits under "Diagnostic information for administrators", in English and not customizable. The enhanced status code chooses the text in the user information section.
A delay notice is not a bounce. When Action is delayed, the reporting server "has so far been unable to deliver or relay the message, but it will continue to attempt to do so". Wait for the final result.
Check that the bounce is yours
RFC 3464 warns: "DSNs may be forged as easily as ordinary Internet electronic mail." Before you act on a bounce message, match it to a message you sent, for example by the Message-ID in any returned headers.
When the code and the words disagree
Some documented replies put the same words under different codes, or pair a code with a class the standards do not allow. The rows below come from Gmail's SMTP error list.
| Provider and code | Documented text | What the standard says | Why it matters |
|---|---|---|---|
Gmail 450 4.2.1 and 550 5.2.1 | "The user you are trying to contact is receiving email at a rate that prevents additional messages from being delivered." | Class 4 is a temporary failure and class 5 a permanent one (RFC 3463). | The same sentence arrives as a soft bounce or a hard bounce. Only the 450 text adds "Please resend your message at a later time." |
Gmail 452 4.2.2 and 552 5.2.2 | "The recipient's inbox is out of storage space." The 552 text adds "and inactive". | For a full mailbox: "This code should be used as a persistent transient failure." (RFC 3463) | Gmail reports the full inbox as a hard bounce when the account is also inactive, although RFC 3463 treats a full mailbox as transient. |
Gmail 421 5.7.32 | "Your email was blocked because the From: header (RFC5322) in this message isn’t aligned with either the authenticated SPF or DKIM organizational domain." | "a 4xx response must incorporate a 4.X.X code, and a 5xx response must incorporate a 5.X.X code" (RFC 2034) | The 421 allows a retry, but class 5 says the message or the destination must change first. |
These are documented provider texts, checked on 26 October 2026, not captured bounces, and the pages can change. Retry by the code, as RFC 5321 requires. Decide about the address from the code and the text together, because the code alone does not say whether to remove it.
What to do with each kind
Soft bounce
Let the retries run. RFC 5321 says "the retry interval SHOULD be at least 30 minutes" and "the give-up time generally needs to be at least 4-5 days". Some receivers also "tempfail or greylist an initial message", M3AAWG notes, so do not treat one soft bounce as a hard one. When the retries end without delivery, count the message as not delivered, as RFC 5321 asks.
Hard bounce
Do not retry the same message. For permanent failures, M3AAWG says: "Regardless of the descriptive text, these types of errors are always telling the sending server not to retry this message."
Something has to change first. For class 5, RFC 3463 says: "Some change to the message or the destination must be made for successful delivery."
- For a mistyped or missing address, correct the address or stop mailing it. 550 5.1.1 user unknown covers that reply.
- A policy reply (
X.7.x) does not prove that the address is dead. Find and fix the cause first, such as the failed authentication in 550 5.7.26 unauthenticated email.
Apple's postmaster guidance says: "Track the temporary and permanent SMTP errors from our mail servers and act on them accordingly." It also asks: "Have a standard policy for handling bouncing addresses." For Sendtier's suppression list, see Suppressions.
How Sendtier reports bounces
In Sendtier, delivery results come from the mail server's logs: delivered, delayed (temporary failure), bounced (including asynchronous bounces), failed (expired or administratively bounced) and complained (feedback reports). Webhooks carry them as event types such as email.delayed, email.bounced and email.failed. In the mail server's queue, mail older than the maximum age of 7 days expires. RFC 5321 generally recommends allowing at least 4–5 days before giving up.
A permanent bounce or a complaint adds the recipient to the suppression list automatically; a temporary failure does not. Outside reports (asynchronous bounces, complaints) count only when their per-recipient tag matches, so a forged report, which RFC 3464 warns about, changes nothing.
Receiving-server replies are available when recorded, so you can see why an address failed. Start free with a test key in the quickstart; test emails are never delivered.
Sources were checked on 26 October 2026: RFC 5321, RFC 3463, RFC 2034, RFC 3464, RFC 6522, IANA enhanced status code registry, Gmail SMTP error list, Gmail bounce help, Exchange Online NDRs, Exchange Server NDRs, Apple postmaster guidance and M3AAWG Sender Best Common Practices.