Bounce and error codes
Why Are My Emails Bouncing or Being Blocked? How to Read the Bounce Message
The bounce message tells you why your email was blocked. Find the raw SMTP response, note who rejected it, check 4xx vs 5xx, then read the text for the cause.
On this page
Your emails are bouncing because a receiving server refused them, and the bounce message says why. Find the raw SMTP response in the bounce (not your ESP's summary), note which server sent it, check whether the code starts with 4 (temporary) or 5 (permanent), then read the text after the code. That text usually names the exact cause: a bad address, failed authentication, a blocklist or a reputation block.
This page walks through that process step by step. If you already have a code and want to look it up, use the SMTP error codes lookup table.
Bounced, blocked or filtered: know which problem you have
Three things get called "bouncing," and only two of them leave you a message to read.
- Bounced. The receiving server rejected the message during the SMTP conversation, or accepted it and later sent back a failure notice. You get a bounce with a code and text.
- Deferred. The receiving server said "not now" with a 4xx code. Your server retries. If the retries run out, it becomes a bounce. Your ESP may show these as "delayed" or "soft bounces."
- Filtered. The server accepted the message and put it in spam. No bounce, no code, nothing to read. If that's your problem, start with why emails go to spam instead.
Step 1: Get the raw bounce text
Your ESP's dashboard probably says something like "Hard bounce: blocked" or "Invalid." That's a label someone else applied, and it's often wrong in ways that matter. Find the original SMTP response:
- ESP or sending platform: look in the bounce or event log for a field called something like "reason," "diagnostic," "SMTP response" or "bounce message." Export it if you can.
- Your own mail server: the MTA log (Postfix, Exim, PowerMTA and so on) records the remote server's full reply for every failed attempt.
- A bounce in your inbox: if you sent from Outlook or Gmail and got a non-delivery report (NDR) back, open it. The useful part is near the bottom, under a heading like "Diagnostic information for administrators" in Microsoft's NDRs, or in the attached delivery status section.
Step 2: Find the parts of the bounce
A standards-based bounce is called a delivery status notification (DSN), defined in RFC 3464. It has a human-readable explanation, a machine-readable status section and usually a copy of your original message or its headers. The status section looks like this:
Reporting-MTA: dns; mta1.example.net
Arrival-Date: Sat, 10 Oct 2026 14:02:11 +0000
Final-Recipient: rfc822; jane@example.org
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx.example.org
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host
[203.0.113.7] blocked using zen.spamhaus.org;
https://check.spamhaus.org/query/ip/203.0.113.7
Last-Attempt-Date: Sat, 10 Oct 2026 14:02:13 +0000
The fields that matter:
| Field | What it tells you |
|---|---|
Final-Recipient | The address that failed. |
Action | failed means it's over. delayed means it's still retrying. |
Status | The enhanced status code (class.subject.detail). |
Remote-MTA | The server that rejected you. This tells you who to deal with. |
Diagnostic-Code | The receiving server's actual reply, code and text. This is the important one. |
Microsoft's NDRs show the same information with friendlier labels: generating server, rejected recipient, remote server, enhanced status code and SMTP response.
Step 3: Work out who rejected it
Look at Remote-MTA (or the remote server in an NDR) and the recipient domain. The same code means different things depending on who sent it:
- A mailbox provider (Gmail, Outlook.com, Yahoo, iCloud): its own reputation and policy systems are talking. There's usually a provider-specific code or help link in the text.
- A corporate security gateway (Proofpoint, Mimecast, Cisco, Barracuda): the recipient's organization filtered you. See Proofpoint, Mimecast, Cisco Talos or Barracuda.
- Your own server or ESP (the bounce was generated before the message left): the problem is on your side, such as a suppression list, a sending quota or a blocked outbound account.
Step 4: Check temporary versus permanent
The first digit decides how urgent this is.
- 4xx (and status 4.x.x) is temporary. The message is queued and will be retried. A handful is normal. A wave of them from one provider is a reputation warning: Gmail's 421 4.7.0, Yahoo's TSS04 and Microsoft's 451 4.7.650 all fall here.
- 5xx (and status 5.x.x) is permanent. The message won't be retried. Resending it unchanged gets the same answer.
Step 5: Read the diagnostic text for the cause
The status code's middle digit gives you the category (x.1 addressing, x.2 mailbox, x.4 routing, x.7 security or policy). Then scan the text for these clues:
| If the text mentions | It's probably | Go to |
|---|---|---|
| "does not exist," "user unknown," "no such user" | A bad or closed address | 550 5.1.1 |
| "unauthenticated," "SPF," "DKIM," "DMARC," "not aligned" | An authentication failure | 550 5.7.26, rejected per DMARC policy, Gmail rate limits |
A hostname like zen.spamhaus.org or bl.spamcop.net | A public blocklist listing | Email blocklists |
| "unsolicited," "reputation," "rate limited," "try again later" | A provider's reputation filter | Gmail 550 5.7.1, 421 4.7.28 |
| "PTR," "reverse DNS" | Missing reverse DNS on the sending IP | 550 5.7.25 |
| "relay access denied" | A routing or configuration problem | 554 5.7.1 |
S3150, S3140 | Outlook.com's block list | Outlook S3150 |
5.7.606 to 5.7.649, 5.7.708, 5.7.511 | A Microsoft IP or sender ban | Microsoft delisting |
[CS01], [HM08] | An iCloud policy rejection | iCloud CS01 |
Copy any URL in the text into your browser. Providers and blocklists put them there for a reason, and they often lead straight to the lookup or delisting page for your specific IP.
Step 6: Look at the pattern, not one bounce
One bounce tells you about one message. To know what's really going on, group a day or a week of bounces by receiving domain and by code:
- One provider, one code, lots of volume: that provider has a problem with you specifically. Work that provider's page.
- Many unrelated domains, same blocklist named: a public blocklist listing. Follow the blocklist playbook.
- Many domains, authentication errors: a DNS or sending-service setup problem. Check the domain with the SPF, DKIM and DMARC checker.
- A slow trickle of 5.1.1 across everyone: normal list decay. Make sure those addresses are being suppressed.
Step 7: Fix, then confirm
Fix the cause the text pointed you to, then watch the same bounce category over the next few sends. Authentication fixes usually show up within a day or so, once DNS propagates. Reputation blocks lift more slowly, and only if the behavior that caused them changed. If you need to check what the receiving server saw on a message that did get through, the email header analyzer shows the authentication results.
When to get help
If you're seeing several different codes across several providers, or a block keeps coming back after you've fixed what the bounce named, there's usually a reputation issue underneath that a single bounce won't show. Get in touch if you want help untangling it.
FAQ
Why does my ESP say "invalid address" when the address is fine?
Some ESPs classify policy blocks as hard bounces and suppress the address. If the raw text mentions a blocklist, authentication or reputation instead of an unknown user, the address is probably fine and the block is about you, not them.
Can I get a bounce for an email that went to spam?
No. When a message lands in the spam folder, the receiving server accepted it, so no bounce is generated. Bounces only happen when delivery is refused or fails.
What does "delivery time expired" mean?
Your server kept getting temporary (4xx) errors and gave up after its retry window ran out. Look at the earlier deferral messages in your logs; they hold the real reason.
Why is the bounce in English when my recipient is in another country?
The SMTP response itself is almost always in English. Microsoft notes that the SMTP response in its NDRs is always English, even when the friendly explanation above it is localized.
Sources
Related guides
- 421 4.7.0: Try Again Later (Gmail Deferrals and Low Reputation)Gmail's 421 4.7.0 is a temporary deferral. Most often it means your IP or domain reputation is very low, or your IP has no valid reverse DNS. Here's the fix.
- 421 4.7.28 / 550 5.7.28: Gmail Detected an Unusual Rate of Unsolicited MailGmail's 421 4.7.28 means it's rate limiting your IP, domain or URL because of volume or spam signals. Pause, slow down, then fix the reputation cause.
- 451 4.7.650: Temporarily Rate Limited Due to IP Reputation (Microsoft)451 4.7.650 means Outlook.com is deferring mail because it doesn't trust your sending IP yet. Slow down, mail engaged users and fix what hurt reputation.
- 550 5.1.1: Recipient Address Rejected, User UnknownA 550 5.1.1 bounce means the recipient's mailbox doesn't exist. It's a permanent failure: fix any typo, or remove the address from your list if it's correct.
- 550 5.1.8: Access Denied, Bad Outbound Sender (Microsoft 365)550 5.1.8 means Microsoft 365 blocked a user from sending, usually because the account was compromised or hit sending limits. An admin must unblock it.
- 550 5.4.1: Recipient Address Rejected, Access Denied (Microsoft)550 5.4.1 means Microsoft 365 didn't find the recipient in that organization's directory. Check the address; if it's right, the recipient's admin must fix it.
Still stuck?
Some deliverability problems take an experienced eye to untangle. Tell me what you're seeing and I'll tell you what I'd check first. The first 30-minute call is free.