A 550 bounce is a permanent rejection: the receiving mail server refused the message and will not retry it. The number that follows, the enhanced status code, is what actually tells you why. A 550 5.1.1 means the address does not exist and you should stop sending to it. A 550 5.7.1 or 550 5.7.26 means the receiver is blocking you on policy, which is a problem with your sending domain that affects every message you send there.
This guide teaches you to read the whole bounce, map the enhanced code to a root cause, and fix the two very different classes of 550 the right way.
The two numbers in a bounce, and why both matter
Every SMTP reply has a basic three digit code and, in modern servers, an enhanced status code in the form class.subject.detail (RFC 3463). The basic code tells you the severity; the enhanced code tells you the category.
- 4xx is temporary. The server will retry, so 421 or 4.x.x means "try again later," often greylisting or a rate limit.
- 5xx is permanent. The server rejects the message outright, and 550 is the most common 5xx.
The trap is treating all 550s the same. A 550 5.1.1 and a 550 5.7.1 both start with 550 but require opposite responses: one says remove this address, the other says fix your DNS and authentication.
What each common enhanced code means
| Bounce code | Meaning | Class | What to do |
|---|---|---|---|
| 550 5.1.1 | Recipient address does not exist | Bad address | Remove the address from your list, fix the typo |
| 550 5.1.10 | Address not found or not accepting mail | Bad address | Verify the recipient, suppress it |
| 550 5.7.1 | Delivery not authorized, policy or reputation block | Policy | Fix SPF, DKIM, DMARC, PTR, or delist your IP |
| 550 5.7.26 | Unauthenticated mail blocked by receiver policy | Authentication | Pass SPF or DKIM aligned with DMARC |
| 550 5.7.28 | Rate or reputation limit at the receiver | Reputation | Slow sending, clean the list, warm the IP |
| 554 5.7.1 | Message refused, often blocklist or content | Policy | Check blocklists and message content |
The pattern is easy to remember. A 5.1.x is about the recipient. A 5.7.x is about you: your authentication, your DNS, or your reputation.
Fixing a 5.1.x bounce: the address is the problem
When you get a 550 5.1.1, the mailbox does not exist at the receiving domain. There is nothing to fix on your side except your list. Correct the typo if it is an obvious one (a missing letter in the domain), otherwise suppress the address so you stop mailing it. Repeatedly sending to non-existent addresses raises your bounce rate, and a high bounce rate itself hurts reputation and can trigger the 5.7.x blocks below.
Fixing a 5.7.x bounce: your domain is the problem
A 5.7.x rejection is a policy decision by the receiver, and it usually points straight at your DNS. Read every continuation line of the bounce, because the server often names the exact failure (SPF, DKIM, or DMARC) in a later line. Then check these in order:
- SPF. Confirm the sending IP is authorized by your SPF record, and that the record does not exceed the ten DNS lookup limit, which causes a permerror and silent failures. See SPF record exceeds 10 lookup limit, fix it fast.
- DKIM. Confirm your messages are signed and the public key is published at the selector in DNS. A missing or wrong key means DKIM does not pass, which matters for DMARC alignment. See DKIM, why messages fail without it.
- DMARC. A 550 5.7.26 specifically means the message arrived unauthenticated and your DMARC policy told the receiver to reject it. You need SPF or DKIM to pass and to align with the From domain. See how to create a DMARC record.
- PTR and reverse DNS. Many receivers reject mail from an IP with no valid PTR record or with forward-confirmed reverse DNS that does not match. See reverse DNS, PTR, and FCrDNS.
- Blocklists. If authentication is clean but you still see 5.7.1 or 554, your IP or a linked domain may be listed. Check both IP blocklists and domain blocklists, since a URL in the body can trigger a rejection too. See URIBL domain blocklists.
Because a 5.7.26 is an infrastructure failure rather than one bad address, it affects every message you send to that provider at once. Since 2024, Gmail and Yahoo require bulk senders to authenticate, so an unauthenticated domain can go from delivering to fully blocked overnight. See Gmail and Yahoo bulk sender rules.
Confirm the DNS side before you retry
Do not guess at whether your records are correct. Run a DNS lookup to read your live MX, SPF (TXT), and DKIM records exactly as the receiver sees them, and use the diagnostics tools to check your mail host's reachability and reverse DNS in one place. Fixing a 5.7.x bounce is almost always a DNS change plus a wait for the old record to age out, so verify the new record is live before you resend.
FAQ
Is a 550 the same as being marked as spam? No. A 550 is a hard rejection at the SMTP layer, so the message never reaches the mailbox at all. Being filtered to a spam folder means the message was accepted and then sorted. A 5.7.1 block is stronger than a spam folder placement and needs a DNS or reputation fix.
Should I retry a 550? No. 550 is permanent by definition, so retrying the same message to the same address will bounce again. Fix the underlying cause first, whether that is removing a bad address or repairing authentication, then send a fresh message.
Why did mail work yesterday and 550 today? The most common reason is a policy threshold you crossed, such as a receiver newly enforcing DMARC, an IP that landed on a blocklist, or an SPF record that grew past the ten lookup limit. A 5.7.x code appearing suddenly points at your sending reputation or DNS, not the recipient.
What is the difference between 550 5.1.1 and 550 5.7.1? 5.1.1 means the address does not exist, so you suppress it. 5.7.1 means the receiver refused an existing address on policy grounds, so you fix SPF, DKIM, DMARC, PTR, or a blocklist listing. They look similar but require opposite actions.
Where in the bounce do I find the real reason? Read past the first line. Mail servers frequently put the specific cause in a later continuation line, naming SPF, DKIM, DMARC, or a blocklist URL. The enhanced status code plus that continuation line together give you the exact fix.
Once you can read the enhanced code at a glance, a bounce stops being a wall of jargon and becomes a one line diagnosis: fix the list, or fix the domain.