SMTP Error 550: What It Means and How to Fix It

A 550 SMTP reply means the receiving mail server permanently rejected the message: resending it unchanged will fail again. As explained in our guide to how SMTP works, every reply pairs a three-digit code with an enhanced status code in the form X.Y.Z, and 550 almost always carries one. That enhanced code holds the real explanation: 5.1.1 means the mailbox does not exist, 5.7.1 means a policy or reputation-based block, and 5.7.26 means the message failed an authentication check such as SPF or DKIM. The first three digits only confirm the failure is permanent. The enhanced code tells you whether the problem is the recipient address, a sender reputation issue, or a misconfigured authentication record, and that distinction decides what to fix next.

Why 550 Always Comes With a Second Code

SMTP replies follow a strict format defined in RFC 5321: a three-digit reply code, optionally followed by an enhanced status code in the form class.subject.detail (X.Y.Z). RFC 3463 defines that format and the codes IANA maintains in its enhanced status code registry. The class digit (5) matches the basic reply code and confirms a permanent failure. The subject digit narrows the category: 1 for addressing, 2 for the mailbox itself, 7 for security and policy. The detail digit gives the specific reason within that category.

A bare 550 with no enhanced code is legal but rare. Nearly every modern mail server includes one, because it is the only part of the reply a script (or a person) can act on without guessing.

What a 550 Rejection Looks Like on the Wire

Unlike a bounce that fails during message submission, most 550s happen right after RCPT TO, before your application ever gets to send the message body:

C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table
C: QUIT
S: 221 2.0.0 Bye

The server never got as far as accepting the DATA command. That is normal: a 5.1.1 rejection is the receiving server telling you, at the earliest possible point, not to bother sending the rest of the message.

Common 550 Variants and What Each One Means

The same 550 reply code covers different problems depending on the enhanced status code attached. These are the variants senders run into most often.

Code	What It Means	Typical Cause	What to Do
550 5.1.1	Bad destination mailbox address	The recipient address does not exist on the destination server	Remove the address from your list immediately; do not retry
550 5.1.10	Recipient address has null MX	The recipient’s domain published a null MX record, meaning it accepts no mail at all	Confirm the domain and address; the domain is not a valid mail destination
550 5.2.1	Mailbox disabled, not accepting messages	The account exists but is suspended, deactivated, or over quota indefinitely	Contact the recipient through another channel; treat as permanent unless told otherwise
550 5.7.1	Delivery not authorized, message refused	A per-host or per-recipient policy block: blocklisting, content filtering, or a recipient-side rule	Check your IP and domain reputation, review message content, confirm you were not blocked directly
550 5.7.26	Multiple authentication checks failed	The message failed more than one authentication check, most often SPF and DKIM both failing under a DMARC policy	Fix SPF and DKIM alignment for the sending domain before resending

5.7.26 is a Gmail favorite. Google’s own troubleshooting documentation is direct about the cause: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.” RFC 7372 is where this multi-check status code entered the registry, well after the original 2003 code list, which is why the detail digit runs as high as 26.

5.1.10 is less common but shows up whenever a receiving domain has explicitly declared it accepts no mail using a null MX record, a mechanism RFC 7505 standardized specifically so senders stop retrying against domains that will never accept email.

For 5.7.1, Microsoft’s Exchange Online documentation notes that the error “typically indicates a security setting in your organization or the recipient’s organization is preventing your message from reaching the recipient,” and that in most cases you “can’t fix the problem yourself”: the recipient’s mail admin has to adjust the block on their end.

How to Diagnose a 550 Bounce in Three Checks

Most 550s can be triaged without contacting anyone, if you check things in the right order.

1. Read the full enhanced status code, not just “550.” A 550 5.1.1 and a 550 5.7.26 come from completely different failure paths and need different fixes.
2. Verify the address and domain are actually correct. Typos, expired addresses, and domains that switched providers account for most 5.1.1 and 5.1.10 failures. An MX lookup on the recipient domain confirms whether it still accepts mail at all.
3. If the code is a 5.7.x, check your own house first. Verify SPF and DKIM are passing for the sending domain, and check your sending IP against a blocklist tool such as MXToolbox before assuming the recipient is at fault.

Jumping straight to “the recipient must be wrong” is the most common mistake. Most 5.7.x rejections trace back to a sender-side configuration gap, not a recipient-side one.

Should You Retry After a 550?

Never retry a 550 unchanged. The reply code’s first digit already confirms the failure is permanent, unlike a 4xx temporary failure that is worth retrying with backoff. See our soft bounce vs hard bounce guide for the full distinction and how each should be handled programmatically.

The right response depends on the enhanced code. Suppress the address for 5.1.1, 5.1.10, and most 5.2.1 cases, since resending will fail every time. For 5.7.x policy and authentication codes, fix the underlying cause first (DNS, SPF, DKIM, or a blocklist listing), then send a single fresh attempt rather than looping retries. Getting this wrong has a compounding cost: an elevated bounce rate starts affecting deliverability for every message you send afterward, and repeated 5.7.x rejections directly damage sender reputation at the receiving mailbox provider.

Frequently Asked Questions