Why your email bounced (and what you can fix)

A bounce is a delivery-status notification generated when a mail system could not deliver your message. It arrives as a "Delivery Status Notification" or "Mail Delivery Failed" message; it may quote the recipient server's SMTP response, or report a DNS, routing, or connection failure the sending side hit before ever reaching the recipient. Inside is usually the best available clue to what went wrong — learn to read it and most bounces stop being mysterious. Two checks before anything else: confirm the notice refers to a message you actually sent (forged "bounces" exist — don't click links in unexpected ones), and if the message had several recipients, check which address failed: delivery status is per recipient, and the others may have received it fine.

Permanent failures vs temporary deferrals

The first thing to identify is whether the response was permanent or an invitation to retry.

• Permanent rejection (5xx codes) — the receiving side refused the request as sent: the mailbox doesn't exist, the message was refused by policy, or it was too large. Your server reports it as a failure; resending the same message unchanged won't help.
• Temporary deferral (4xx codes) — not a final failure. The mailbox is full, the server is busy, or you've been greylisted. Your sending server queues the message and retries on its own; it may send you a "delivery delayed" notice, and only if the retries run out does it send a final failure — which can still quote the original 4xx condition. How long it retries is the sending server's own configuration, so don't assume a fixed window and don't keep resending by hand.

Reading the SMTP code

Two things matter: the three-digit basic code (whether it starts with 4 or 5) and the enhanced status code (like 5.1.1 or 4.2.2) plus the full diagnostic text — that detail, not the bare number, is what identifies the problem. Don't treat similar numbers as interchangeable: 452 (temporary "insufficient storage", retry) and 552 (permanent quota/size refusal) are different outcomes despite looking alike. Some notices are too vague to diagnose alone; then your provider's logs are the next stop.

550 5.1.1 Recipient address rejected: User unknown   → destination mailbox doesn't exist (permanent)
452 4.2.2 Mailbox full / over quota                   → temporary: recipient inbox full, retry
552 5.2.2 Mailbox full / over quota                   → permanent refusal: contact the recipient
552 5.2.3 / 5.3.4 Message too large                   → permanent: shrink it or share the file another way
421 / 451  Try again later / temporarily deferred      → greylisting, rate limits, or server busy (temporary)
4xx/5xx ... SPF/DKIM/DMARC ...                         → an authentication result contributed
554 ... blocked using a blocklist ...                  → a reputation or policy check rejected it
Connection timed out                                  → no response in time — cause not yet known

• 550 5.1.1 "User unknown" — the destination system says that mailbox doesn't exist. Often a typo — but the mailbox may also have been removed or renamed, so if the address looks right, get a current one or reach the person another way rather than resending blind. A common permanent failure, and often fixable from your side.
• 452 vs 552 mailbox-full — the 4xx version is temporary: your server retries and the recipient may clear space. The 5xx version is a permanent refusal: reach the recipient another way. If the diagnostic instead says the message is too large (5.2.3/5.3.4), that one is yours: compress or drop attachments, or use a file-sharing link — encoding makes an emailed file bigger than the original.
• 421 / 451 deferred — temporary. Greylisting deliberately rejects a first attempt and usually accepts the retry; busy servers also defer during spikes. Let the automatic retry work — but watch for a later final-failure notice, because a 4xx invites a retry without promising acceptance.
• SPF, DKIM, or DMARC mentioned — an authentication result or policy contributed to the rejection. That can mean DNS records, but also a sending service that isn't authorized in your SPF, DKIM signing that's off or misaligned, or a forwarding hop — so read the complete diagnostic before touching anything. If you edit DNS: never add a second SPF record (update the existing one), and check DKIM signing is enabled for the published selector. Tip 8, secure mail server, covers the setup.
• 554 blocked / listed — a reputation or policy check rejected the message. Identify exactly what is listed — an IP, a domain, something else — and whether the list is public (with a published removal process) or the receiver's own policy. Fix the underlying cause first; some listings then expire on their own, others need a removal request.
• Connection timed out — no SMTP response arrived in time. That could be the destination server, DNS, routing, a firewall, or your own sending service — the timeout itself doesn't say. Let retries run; if it becomes final or keeps recurring, hand the diagnostic to your email provider.

Who fixes what

The diagnostic usually tells you who is best placed to act — as a guide, not a law:

• You: correct a mistyped address, fix your sending service's authentication (carefully — see above), avoid sending patterns that trip filters, shrink oversized messages.
• The recipient: a full mailbox, a rejecting or offline server, an over-aggressive filter on their side. Contact them by phone and let them sort it out.
• Your email provider: routing, reputation, blocklists, reverse DNS, shared-server issues. If you send through a managed mailbox, a website's mail function, or a newsletter platform, the provider controls the sending IP and any delisting — give their support the complete diagnostic rather than trying to delist anything yourself.
• Nobody — just wait: greylisting and temporary deferrals usually clear on the automatic retry.

Read the enhanced code and diagnostic text first and you'll usually know whether to fix an address, involve your provider, or simply let the retry do its job — and when the notice is too vague to tell, the diagnostic plus your provider's logs is the pair that answers it.

What to do

1. First confirm the bounce matches something you actually sent, then find the code — the 4xx/5xx number, the enhanced status (e.g. 5.1.1), and the diagnostic text — and check which recipient it applies to.
2. A 4xx is a temporary deferral — the sending server retries on its own; wait, but watch for a final failure notice.
3. A 550 "User unknown" — check for a typo; if the address looks right, get a current one from the recipient another way.
4. Authentication mentioned? Read the full diagnostic before changing DNS — no second SPF record, correct the existing setup, or hand it to whoever runs your email.
5. Mailbox-full: temporary retries itself, permanent means contact the recipient. Message too large: shrink it or share a link. Timeout: let retries run, escalate to your provider if it recurs.
6. Blocklist bounce: identify what is listed, fix the cause, then follow that list's current guidance — via your provider if they control the sending IP.