SMTP 550 Permanent Failure: What It Means

An SMTP 550 is a permanent rejection: the receiving server refused your message and won't accept it if you send it again unchanged. The number alone only tells you "no." The reason is in the enhanced status code that follows (like 5.1.1 or 5.7.1) and the text after it, and those split 550s into two very different problems: the address doesn't exist, or the receiver doesn't want mail from you.

Read the whole line before doing anything. A dead address and a reputation block have nothing in common.

What a 550 looks like

A bounce line has three parts: the basic reply code, the enhanced status code and human-readable text.

550 5.1.1 The email account that you tried to reach does not exist.

550 5.7.26 Unauthenticated email from example.com is not accepted due to
domain's DMARC policy.

550 5.7.606 Access denied, banned sending IP [203.0.113.7].

All three start with 550: one is a dead address, one a DNS problem, one a blocked IP. Multi-line replies repeat the code with a hyphen (550-5.7.1) on every line but the last.

What it means

RFC 5321, the SMTP standard, defines 550 as "requested action not taken," with the mailbox unavailable: not found, no access, or refused for policy reasons. The standard uses 550 both for unknown recipients and for refusing to relay mail on policy grounds, which is why one code covers so much ground.

Any reply starting with 5 is a permanent negative reply. RFC 3463, which defines the enhanced codes, describes a permanent failure as one "not likely to be resolved by resending the message in the current form." Your server won't retry it. Compare 4xx replies (like 421 or 451), which are temporary: the server is saying "not now," and your mail system will keep trying.

The enhanced code has three parts: class.subject.detail. The middle number is the useful one:

Most 550s that worry senders are 5.7.x.

Common 550s and where to go next

For the full list, see the SMTP error code lookup.

Common causes, most likely first

1. The address doesn't exist. Typos, people who left a company, abandoned mailboxes. This is 5.1.1 and it's the most common 550 by volume.
2. Authentication failed. Missing or broken SPF or DKIM, or a DMARC failure under p=reject. Gmail and Microsoft both now reject outright for this.
3. Reputation block. The receiver's own filters decided your IP or domain sends unwanted mail, usually because of complaints, spam traps or a sudden volume spike.
4. Public blocklist. The receiver checks a DNS blocklist (sometimes still called a blacklist) and your IP or a domain in the message is on it. The bounce usually names the list.
5. Infrastructure checks. No reverse DNS for the sending IP, malformed headers, or a server that won't relay for you.
6. Local policy. The recipient's admin blocked you, or a distribution list only accepts mail from members.

How to fix it

1. Get the exact bounce text from your ESP's bounce log or your mail server logs, not a summarized "hard bounce" label. Note who generated it: the receiver's server, or your own.
2. Read the enhanced code and the text. How to read a bounce message walks through it.
3. Check whether it's one address or many. One bounce at one domain is usually an address problem. The same 5.7.x code across many recipients at one provider is a block. The same code across many unrelated domains points at a public blocklist or your own authentication.
4. For address failures (5.1.x), suppress the address. Don't retry it and don't re-import it later.
5. For authentication failures, check your records with the email checker and the headers of a real message with the header analyzer.
6. For blocks and blocklists, find out what changed in your sending (a new list, a volume jump, a compromised account) before asking for removal. The blocklist playbook covers the process.
7. Resend after the fix. A 550 is never retried automatically, so recover important messages yourself.

How to confirm it's fixed

Track 550s by enhanced code and receiving domain, day over day. After an address cleanup, 5.1.1s should drop on the next send. After an authentication or reputation fix, 5.7.x bounces at that receiver should taper off over days.

How to keep it from coming back

• Validate addresses at signup and remove long-inactive subscribers before they become dead mailboxes or spam traps.
• Monitor DMARC reports, so authentication failures show up before the bounces do.
• Watch bounce codes by provider, not just overall bounce rate. A block at one provider hides inside a healthy average.

When to get help

If you're seeing 5.7.x rejections across several providers at once, or blocks that come back after every fix, the cause is usually upstream of the error code, and it's worth an outside look. Get in touch.

FAQ

Is a 550 a hard bounce?

Yes, in the sense that it's permanent and won't be retried. But not every 550 means the address is bad. Only 5.1.x codes say the address is the problem; 5.7.x codes are about you, not the recipient.

What's the difference between 550 and 554?

Both are permanent refusals. 550 is the more common code for rejecting a recipient or refusing by policy; 554 means the transaction failed and is often used by Postfix for policy and blocklist rejections, or to refuse a connection outright. See 554 5.7.1.

Should I retry a 550 later?

Not unchanged. Fix the cause first; hammering a reputation block can make it worse.