Email bounces explained in one line: a bounce is an email that could not be delivered, returned to the sender with a report saying why. A 5xx code means a hard bounce (permanent, such as an unknown user) and a 4xx code means a soft bounce (temporary, such as a full mailbox). Read the status code first, then the diagnostic text beside it, because that wording names the actual cause.
What actually happens when an email bounces
Email delivery is a conversation between servers. Your mail client hands a message to your outgoing server, which looks up the recipient domain's mail exchanger in DNS and connects to it. That receiving server replies with a three-digit SMTP status code at each stage. If it accepts the message, delivery continues. If it refuses, the sending server either gives up immediately or retries later, and eventually returns a report to the address in the message's return path.
That report is the bounce. It usually arrives as a separate message with an empty or system-generated sender, a subject like "Undelivered Mail Returned to Sender" or "Delivery Status Notification (Failure)", and a body containing the original headers plus the receiving server's explanation. The modern standard for machine-readable reports is the Delivery Status Notification defined in RFC 3464, which wraps the failure details in a message/delivery-status part.
Two details matter more than people expect. First, bounces go to the envelope sender, not necessarily the "From" address you see, so a mailing list or an automated system may receive the bounce rather than you. Second, a bounce is not the same as a spam rejection you never see: some filters silently discard mail after acceptance, which produces no bounce at all. If nothing arrives and nothing bounces, the message was probably accepted and then filtered.
What is the difference between a hard bounce and a soft bounce?
The split between hard and soft bounces is the single most useful distinction in the whole subject, because it determines whether retrying is sensible.
- Hard bounce (permanent). The receiving server has made a final decision: the mailbox does not exist, the domain does not exist, the address is disabled, or policy forbids delivery. Retrying will not help. Codes are in the 5xx range.
- Soft bounce (temporary). Something is wrong right now but might resolve: the mailbox is full, the server is overloaded, the message is too large, or the receiving side is deliberately stalling. Codes are in the 4xx range, and well-behaved senders retry for a period (commonly a few hours to a few days) before giving up and issuing a final bounce.
The trap is that a soft bounce can become a hard one. A mailbox that stays full past the retry window turns into a permanent failure from the sender's point of view. Equally, some servers return a 5xx for a condition that is arguably temporary, because their policy is simply to refuse. Always read the diagnostic text alongside the code rather than trusting the number alone.
How do you read a bounce message line by line?
Bounce reports look intimidating because they quote the entire original message. Skip to the parts that carry information:
- The status code. Look for a line beginning
Status:in the delivery-status part, or an SMTP reply such as550 5.1.1 User unknownin the diagnostic text. The first digit is the verdict: 5 is permanent, 4 is temporary. - The enhanced status code. The dotted number after the SMTP code (5.1.1, 4.2.2 and so on) narrows down the cause. These are registered in the IANA sub-registry that accompanies RFC 3463.
- The diagnostic text. The human-readable sentence from the receiving server. This is where you learn whether the mailbox is missing, full, or blocked by policy.
- The action field. Values such as
failed,delayedordeliveredtell you what the reporting server did. Adelayedreport is a warning, not a final bounce. - The original recipient. Confirm which address failed, especially if you sent to several.
If you want to check the path a message took before it failed, the techniques in our guide to reading email headers apply to bounce reports too, since they carry the original headers inside them.
What do the common bounce codes mean?
The table below covers the codes you will meet most often. Enhanced codes are conventions that most large providers follow, but wording and exact behaviour vary between servers and change over time, so treat the diagnostic text as authoritative.
| Code | Typical meaning | Hard or soft | What usually helps |
|---|---|---|---|
| 5.1.1 | Recipient address does not exist | Hard | Check the spelling; contact the person another way |
| 5.1.2 | Domain exists but has no such host or mailbox route | Hard | Verify the domain; it may be retired |
| 5.1.3 | Bad syntax in the address | Hard | Fix the address format |
| 5.2.2 | Mailbox full (quota exceeded) | Often hard in practice | Recipient must free space; sender can retry later |
| 5.4.1 | No route to the destination host | Hard | Domain's mail records are broken or missing |
| 5.7.1 | Delivery refused by policy, often a blocklist or spam filter | Hard | Sender reputation and authentication need attention |
| 4.2.2 | Mailbox full, reported as temporary | Soft | Retry later; recipient clears space |
| 4.4.1 | No answer from the destination host | Soft | Usually resolves on retry |
| 4.7.0 | Temporary policy refusal, including greylisting | Soft | Legitimate senders retry and get through |
Greylisting deserves a note: some servers reject unfamiliar senders once with a 4xx on purpose, on the theory that spam software will not retry. A real mail server will, usually within minutes. If you see a single temporary refusal followed by successful delivery, that is the system working as designed, not a fault.
Why do legitimate emails bounce when the address looks fine?
Several causes have nothing to do with a typo:
- Authentication failures. If your domain publishes SPF, DKIM or DMARC records and your sending server does not align with them, receivers may reject or quarantine the message. Our explainer on SPF, DKIM and DMARC covers what these records do.
- Reputation and blocklists. A shared sending IP with a poor history can get your mail refused with a policy code. This affects small senders using shared hosting more than they expect.
- Message size and content. Oversized attachments or content that trips a filter can produce a refusal, sometimes phrased vaguely.
- Expired or abandoned addresses. Disposable inboxes are a special case: once a temporary address expires, mail to it has nowhere to go. Our piece on how long temp mail lasts explains the timers.
- Recipient-side rules. Some organisations reject all mail from certain domains or from addresses not on an allowlist, regardless of content.
If you are the recipient waiting for a message that never appears and no bounce reaches you, the problem is more likely filtering than bouncing. Our checklist for when a verification email is not arriving covers that scenario step by step.
What should senders do about bounces?
For anyone running a list, a product's signup flow, or a transactional mail system, bounces are feedback, not noise.
- Separate hard from soft before acting. Remove hard-bounced addresses from regular sending promptly; retry soft bounces on a schedule instead of hammering the server.
- Never retry a 5xx. Repeated attempts at a permanently failing address waste resources and can look like abuse.
- Watch your bounce rate as a signal. A rising proportion of unknown-user replies usually means your list is stale or your signup form accepts typos. Providers publish their own thresholds and policies, so check the documentation for the service you use rather than assuming a universal number.
- Fix authentication first. If policy refusals cluster, verify SPF, DKIM and DMARC alignment before blaming recipients.
- Process bounces automatically. Delivery Status Notifications are structured; parse the status fields rather than regexing the prose. Developers automating test flows will find the patterns in our guide to disposable email for developers useful for exercising failure paths deliberately.
One honest caveat: many receiving systems now accept mail and discard it later, so a clean send log does not prove delivery. If you need certainty, use a mechanism that asks the recipient to act, such as a confirmation link.
What can recipients do when mail to them bounces?
If people tell you their mail to your address bounces, work through the likely causes in order:
- Confirm the exact address. Ask for a screenshot of the bounce. Aliases, plus-addressing and old addresses are frequent culprits.
- Check your mailbox quota. A full mailbox produces 4.2.2 or 5.2.2 replies. Clear space or upgrade the plan.
- Check filters and blocks. If you set a rule that rejects certain senders, their mail bounces rather than landing in spam.
- Check domain settings. If you own the domain, confirm its mail records still point somewhere valid; a lapsed hosting plan breaks delivery silently.
- Consider whether the address is still alive. Temporary inboxes expire by design. If you use one for a signup and later need password resets, the address will bounce, which is why a stable alias is often the better choice for anything long-lived.
There is nothing a recipient can do about a sender-side policy block except ask the sender to fix their authentication or reputation. Bounces are usually one-sided problems.
Sources
- IANA registry of SMTP Enhanced Status Codes — the current list of registered codes and their meanings.
- NIST SP 800-63B: Digital Identity Guidelines — guidance on email as an identity and recovery channel.
In short
Read the code first: 5xx means stop, 4xx means wait. The diagnostic text tells you whether the mailbox is missing, full or blocked, and that in turn tells you whether the fix belongs to the sender or the recipient. Senders should prune hard bounces, retry soft ones on a schedule, and treat policy refusals as a reputation and authentication problem. Recipients should check quota, filters and whether the address still exists. And remember the quiet failure mode: mail that is accepted and then filtered produces no bounce at all, so silence is not proof of delivery.