Email Bounce Code 550: Five Sub-Codes and Who Can Fix Each (2026)
A 550 bounce means the receiving mail server permanently rejected your message, and the sub-code that follows it, things like 5.1.1 or 5.7.1, tells you exactly why. Two of the five sub-codes covered here (5.1.1 and 5.1.10) only clear once the recipient's own admin acts, while the other three (5.4.1, 5.7.1, and 5.7.15) are yours to fix through SPF, DKIM, DMARC, or a blocklist request. Match your exact string against the table below before you touch anything.
What SMTP error 550 means (permanent hard bounce vs. temporary 4xx)
SMTP error 550 is a permanent hard bounce: the receiving server rejected your message outright and will reject the identical message again if you resend it unchanged. A 4xx code, by contrast, is a temporary soft bounce that a normal mail transfer agent retries automatically over the following hours.
The three-digit code is only the first layer. The digit that leads it (2, 4, or 5) signals success, temporary failure, or permanent failure at that step of the SMTP handshake. The digits that follow 550, the enhanced status code standardized in RFC 3463, narrow that permanent failure down to one of several distinct causes: an addressing problem, a routing problem, or a security and policy problem. Resending a 550 without changing anything wastes the attempt, since the same rejection fires again. For the broader hard bounce versus soft bounce split, what a bounced email actually is covers the mechanics in more depth.
How to read a 550 bounce message and find your exact sub-code
A 550 bounce notification carries three parts: the SMTP status line, a human-readable explanation from the recipient's server, and an enhanced status code in the form X.Y.Z sitting right after the 550. That code, not the surrounding prose, is what tells you which sub-code you actually have.
A typical bounce reads something like 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table. The 5.1.1 is the part to isolate; everything after the colon is the recipient server's own wording, which varies. Your outbound server logs this exchange at the point it reached the recipient's MX records and got refused, so the same underlying problem can arrive worded differently depending on whether Gmail, Yahoo, or Outlook is doing the rejecting. Pull the exact code before you start troubleshooting; guessing from the prose alone sends you down the wrong path.
The 550 sub-code table: 5.1.1, 5.4.1, 5.7.1, 5.7.15, 5.1.10
Five sub-codes account for nearly every 550 bounce a sender encounters. 5.1.1 and 5.1.10 flag address problems, 5.4.1 flags a routing or relay block, and 5.7.1 and 5.7.15 flag policy or authentication rejections. The table below maps each to its RFC 3463 class and who has to act on it.
| Sub-code | RFC 3463 class | What it signals | Who fixes it |
|---|---|---|---|
| 5.1.1 | Addressing status | The recipient's server has no mailbox matching that address | Recipient's admin, unless it was your own typo |
| 5.4.1 | Network and routing status | The recipient's server refused to relay or accept mail from your sending domain or IP | You, the sender |
| 5.7.1 | Security or policy status | The message was refused on policy grounds, most often a failed SPF, DKIM, or DMARC check | You, the sender |
| 5.7.15 | Security or policy status | A provider-specific policy rejection, most commonly reported by Outlook and Microsoft 365 in connection with an authentication failure | You, the sender |
| 5.1.10 | Addressing status | The recipient's address failed validation before delivery was even attempted, a step earlier than the mailbox-level rejection in 5.1.1 | Recipient's admin |
The first digit and the class digit after it (X.7 for security and policy, X.1 for addressing, and so on) are standardized under RFC 3463. The second and third digits inside families like 5.7.x and 5.1.x are extended by individual mailbox providers, so Gmail, Yahoo, and Outlook can return different exact wording for the same underlying rejection even when the sub-code matches.
550 errors you can fix yourself (SPF/DKIM/DMARC, blocklisting, PTR records)
5.4.1, 5.7.1, and 5.7.15 are all sender-side problems: broken or missing SPF, DKIM, and DMARC configuration, an IP or domain on a blocklist, or a missing PTR record. Every one of these is something you can find and correct without waiting on the recipient.
Start with authentication. If you haven't set up SPF, DKIM, and DMARC correctly, that's the first thing to check against a 5.7.1 or 5.7.15 rejection. A common SPF mistake is having more than one record for the same domain; if a lookup turns up multiple SPF records starting with v=spf1, merge them into one before you resend. A DKIM signature that comes back as a temporary error rather than a clean pass or fail is worth fixing at the DNS level too, since some receiving servers treat an unreadable signature the same as a missing one.
Blocklisting is the other major cause of 5.4.1. Spamhaus is the DNSBL most often responsible for an IP or domain being refused outright, so checking your domain's reputation is worth doing before you assume the problem is purely a configuration issue. A missing or mismatched PTR record, the reverse DNS entry that should resolve your sending IP back to a hostname matching your domain, is a separate but related fix; new mail servers frequently ship without one set.
Once you've made a DNS-level change to SPF, DMARC, or your PTR record, give it time to propagate before resending. Waiting roughly 72 hours after a DNS change is the safer window; resending immediately after editing a record often hits the old cached answer and produces the same rejection.
550 errors only the recipient's admin can fix (deleted mailbox, delivery restrictions)
5.1.1 and 5.1.10 sit on the recipient's side. The mailbox no longer exists, or their mail system enforces a delivery restriction you can't see from the outside. No configuration change on your end clears either one; the address itself is gone or blocked at their server.
A deleted or inactive mailbox is the most common version: an employee left the company, a personal account was closed, or the address was never real to begin with. Delivery restrictions are less obvious. Some mailbox providers enforce internal-only distribution lists or admin-configured sender allow lists that reject external mail regardless of how clean your authentication is, and 5.1.10 in particular reflects an address-validation failure that happens before the message would even reach a live mailbox. The correct move on both is the same: remove the address from your list rather than continuing to resend, since retrying accomplishes nothing.
How to prevent 550 bounces going forward
Preventing 550 bounces means fixing the causes before they trigger a rejection: verified SPF, DKIM, and DMARC records, a sending IP with no blocklist history, a correctly configured PTR record, and a list checked for dead addresses before you send.
New domains and IPs should ramp sending volume gradually rather than sending at full volume on day one; a sudden spike from an unfamiliar sender is one of the signals mailbox providers use to justify a 5.4.1 or 5.7.1 rejection. Warming up a new server over several weeks builds the reputation history that lets larger sends through cleanly later.
Monitoring matters as much as setup. Google Postmaster Tools gives visibility into spam complaint rates and authentication pass rates for domains sending to Gmail, and as of February 2024, Google requires senders of 5,000 or more daily messages to Gmail addresses to keep spam complaints under 0.3 percent. Staying under that threshold is one of the clearer, provider-published benchmarks available for judging whether your sending practices are drifting toward a 5.7.x rejection before it happens.
List hygiene closes the loop on 5.1.1. Running a list through email verification before your first send to it catches most of the dead and mistyped addresses that would otherwise come back as 5.1.1, so the mailbox never gets deleted addresses in the first place; a syntax check alone won't do this, since a correctly formatted address is not the same as a working one.
Email bounce code 550 questions people ask in 2026
Is a 550 bounce the same as a hard bounce?
Yes. A 550 code is SMTP's way of signaling a permanent, hard bounce: the recipient's server rejected the message outright and won't accept the same unchanged message on retry. That's distinct from a 4xx soft bounce, which a mail server retries on its own.
Should I keep resending after a 550 error?
No, not without changing something first. A 550 is a deliberate rejection, so resending the identical message triggers the identical rejection. Fix the underlying cause indicated by the sub-code (an authentication issue, a blocklist, a bad address) before you try again.
What's the difference between a 550 and a 554 error?
Both are permanent SMTP failures, but they tend to surface at different points and for different reasons. A 550 usually reflects an addressing or policy decision made after the message was evaluated, while a 554 more often signals the connection itself was refused, frequently tied to a blocklist or a DMARC enforcement failure.
Does one 550 bounce hurt my sender reputation?
A single 550 rarely does lasting damage on its own. A pattern of repeated 550s, especially the 5.4.1 and 5.7.1 varieties tied to blocklisting or failed authentication, is what mailbox providers weigh when scoring your domain's reputation over time.
