SMTP 550 5.1.1 Bounce Code: What It Means and How to Fix It

A bounce reading 550 5.1.1 is the receiving server answering your message with one specific sentence: this mailbox does not exist here. It is the most common hard bounce, and the fix depends on which side of the message you are on.

What 550 5.1.1 actually says

The code has two parts that come from two different standards. 550 is the SMTP reply code from RFC 5321, used when a mailbox is unavailable and a failure should be reported as permanent. 5.1.1 is the enhanced status code from RFC 3463, written as class.subject.detail.

Part	Value	Meaning
Class	5	Permanent failure: resending the same message is not likely to succeed
Subject	1	Addressing problem
Detail	1	Bad destination mailbox address: the mailbox in the address does not exist

The IANA registry adds a useful nuance: X.1.1 usually points at the local part, the text before the @. The domain was found and answered; it just did not recognise that user.

How to read the full bounce line

Servers wrap the code in free text that differs by provider, so match on the numbers, not the wording. Gmail, Exchange and smaller hosts phrase the same condition differently: "user unknown", "recipient address rejected" or "the email account that you tried to reach does not exist". Look at the diagnostic line in the delivery status notification, usually written as Diagnostic-Code: smtp; 550 5.1.1 ..., and at the Final-Recipient field to see which address failed. If you are unsure how to find those fields, the guide on reading email headers shows where they sit.

✉️Email ValidatorSyntax, MX, disposable and typo checks, single or bulkOpen the tool →

5.1.1 versus the codes it is confused with

Several bounce codes look similar but need a different response. Treating them all as "bad address" either throws away good contacts or keeps dead ones.

Code	Registry meaning	What to do
5.1.1	Bad destination mailbox address	Fix a typo if obvious; otherwise suppress the address
5.1.2	Bad destination system address: the domain does not exist or cannot accept mail	Check the domain spelling; suppress if the domain is dead
5.1.3	Destination address has invalid syntax	Fix the format at the point of collection
5.1.6	Mailbox has moved, no forwarding address	Suppress; look for a new address through another channel
5.2.2 / 4.2.2	Mailbox full; RFC 3463 says to use it as a persistent transient failure	Treat as soft: retry later, suppress only after repeated failures
5.7.1	Delivery not authorized, message refused	Not a list problem: look at your sender reputation, authentication and content

If you sent the message: a four-step fix

1. Read the address, character by character. Common slips are gmial.com, a trailing period, a space or a comma. Google lists typos and stray spaces among the causes of its "address doesn't exist" bounce.
2. Correct only obvious typos. A one-letter domain misspelling is safe to fix. Guessing at the local part (jon@ versus john@) is not: you may mail a stranger.
3. Suppress the address if it still bounces or you cannot verify it. Retrying a permanent failure does nothing and lowers the share of your list that can be reached.
4. Find the source. If many 5.1.1 bounces trace back to one sign-up form or one import file, fix the intake: add address validation at entry and a confirmation step.

A worked example: sorting 96 bounces

You send to 8,000 contacts and receive 96 bounce notices. Sort them by enhanced code before touching the list:

Code	Count	Action	Share of 8,000 sent
5.1.1	71	Suppress	0.89%
5.1.2	9	Suppress	0.11%
4.2.2	11	Retry next send	0.14%
5.7.1	5	Investigate sender side	0.06%

The permanent address failures are 71 + 9 = 80 addresses, which is 80 ÷ 8,000 = 1.00% of the send. The 5 policy rejections are not evidence of bad addresses, so removing them would delete real subscribers. The 11 mailbox-full cases are not removed yet. To compare these figures with other metrics, see bounce and complaint rates.

🧹Email List CleanerRemove duplicates and invalid addresses, fix typos and split by providerOpen the tool →

If you are the recipient and real mail bounces

When people report 5.1.1 for an address you know exists, the sender is not at fault. Work through these on your side:

• Was the mailbox or alias created on the platform that now receives mail? After a migration, mail can land on a system that never received the account.
• Are MX records pointing at the right host? Old MX entries send mail to the previous provider, which answers that the user is unknown.
• Is the address a distribution list or shared mailbox restricted to authenticated senders? External senders can be rejected with a code that looks like unknown user depending on the platform's settings.
• Was the account recently renamed? Add the old address as an alias.

The MX and syntax layers of address checking are explained in how email validation works.

Common mistakes

• Retrying a 5xx. RFC 3463 describes a permanent failure as one not likely to be resolved by resending. Retries are for 4xx.
• Suppressing on a single soft bounce. Mailbox-full and temporary server errors often clear up.
• Ignoring the subject digit. Dozens of different failures begin with 550; the second part is what separates them.
• Assuming a bounce notice you did not trigger is a problem. If you did not send the message, the notice can be backscatter from someone who forged your address; there is nothing to fix on your list.

For a broader list-maintenance routine, see email list hygiene.

Frequently asked questions

What does 550 5.1.1 mean in plain terms?

The receiving mail server found the domain but has no mailbox for the name before the @. It is a permanent failure, so the message is not queued for another attempt.

Is 550 5.1.1 a hard bounce or a soft bounce?

A hard bounce. The first digit 5 marks a permanent failure in RFC 3463, which says resending the message in its current form is unlikely to help.

Can a valid address return 550 5.1.1?

Yes, when the recipient domain has misrouted mail, such as old MX records after a migration, or a mailbox that was never created on the new platform. The sender sees the same code.

How is 5.1.1 different from 5.1.2?

Per the IANA registry, 5.1.1 means the mailbox part of the address is bad, while 5.1.2 means the destination system, the domain, does not exist or cannot accept mail.

Should I retry a message that bounced with 5.1.1?

No. Correct an obvious typo and send again to the corrected address, otherwise remove the address from your list.

References & further reading

1. RFC 3463 — Enhanced Mail System Status Codes
2. IANA — Enhanced Status Codes registry
3. RFC 5321 — Simple Mail Transfer Protocol
4. Google — Fix bounced or rejected Gmail messages