SMTP Error 550 5.1.1: What It Means and How to Fix It
You sent an email, and a bounce came back with a line like 550 5.1.1 The email account that you tried to reach does not exist or 550 5.1.1 User unknown. This is the most common hard bounce there is, and the good news is that it is also the clearest: the receiving mail server is telling you, definitively, that the mailbox is not there.
This guide explains what each part of the code means, the handful of situations that produce it, what to do with the address, and how to stop the error from showing up in the first place.
What 550 5.1.1 means, piece by piece
SMTP replies have two codes. The first, three-digit number is the basic reply code from the original SMTP standard. The second, dotted one is an "enhanced status code" added later to give more detail.
- 550 is a permanent failure. The server will not accept the message, and retrying will not help. Anything starting with 5 is permanent; anything starting with 4 is temporary.
- 5.1.1 breaks down as class 5 (permanent), subject 1 (addressing), detail 1 (bad destination mailbox). In plain words: the address does not exist on this server.
The text after the codes is free-form and varies by provider. Gmail says "The email account that you tried to reach does not exist". Postfix servers often say "Recipient address rejected: User unknown in virtual mailbox table". Exchange says "Recipient not found by SMTP address lookup". They all mean the same thing.
Why a mailbox does not exist
In practice, 550 5.1.1 comes from one of five situations.
- A typo.
jhon.smith@instead ofjohn.smith@, or a domain misspelt at sign-up. This is the biggest source on opt-in lists, because nobody checks what they typed into a form. - The person left. Company mailboxes are deleted when employees leave. On B2B lists, this is the largest cause: a list that was 100% valid two years ago will have lost a meaningful share of its contacts to job changes.
- An abandoned free account. Gmail, Outlook.com and Yahoo delete accounts after long periods of inactivity, and the address then starts returning 5.1.1.
- A made-up address. Purchased or scraped lists often contain addresses that were guessed from name patterns and never existed.
- A migration that dropped mailboxes. When a company moves mail providers, aliases and old mailboxes sometimes do not come across.
What to do with the address
Remove it. A 5.1.1 is permanent by definition, so there is nothing to retry. Most sending platforms suppress the address automatically after a hard bounce, but check: if you import the same list into a new tool, the suppression does not come with it.
If the contact matters, look for a new address rather than resending. For a business contact, check LinkedIn for their current company. For a customer, use another channel to ask for an updated email.
What you should not do is keep sending. Every 5.1.1 counts against your sender reputation. Mailbox providers watch the share of your mail that bounces, and a rate above 2% starts to hurt inbox placement for everyone else on your list, as explained in our guide to reducing bounce rate.
When 550 5.1.1 is not really about the address
Occasionally a server returns 5.1.1 for a mailbox that does exist. The common cases:
- Wrong domain in the MX records. If a company's DNS points mail to a server that does not know about the domain, every address returns 5.1.1 until DNS is fixed. You can check where a domain's mail goes with the free MX lookup tool.
- A partially completed migration. One server knows the mailbox, the other does not, and which one answers depends on which MX record was picked.
- Anti-spam policy dressed up as 5.1.1. A few providers use 5.1.1 for addresses they refuse to deliver to for policy reasons. The free-text part of the reply usually gives it away: look for words like "policy", "blocked" or a link to a support page.
If you see 5.1.1 for a whole domain at once, especially a domain you know is active, treat it as a server problem on their side and wait before removing the contacts.
How to catch these addresses before you send
The error exists because the address was never checked. An email verifier runs the same SMTP conversation a mail server would, up to the point where the recipient is accepted or rejected, and then disconnects without sending anything. An address that would bounce with 5.1.1 is reported as undeliverable before it costs you anything.
Three habits remove almost all 5.1.1 bounces:
- Verify at sign-up. Catch typos at the form, while the person is still there to correct them.
- Verify before each campaign to any segment that has not been mailed in the last few months. That is when job changes and abandoned accounts accumulate.
- Never mail a purchased list without verifying it. These lists carry the highest share of addresses that never existed.
InboxSure does exactly this check. Upload a list and every address comes back as Deliverable, Undeliverable, Risky or Unknown with the reason, so the 5.1.1 addresses are removed before your sending platform ever sees them. You can read how the check works in how email verification works without sending an email.
550 5.1.1 compared with similar codes
| Code | Meaning | Action |
|---|---|---|
| 550 5.1.1 | Mailbox does not exist | Remove the address |
| 550 5.1.2 | Domain does not exist or has no mail server | Remove; check for a domain typo |
| 550 5.1.10 | Recipient not found (Microsoft wording) | Remove the address |
| 552 5.2.2 | Mailbox full | Keep; retry later |
| 550 5.7.1 | Rejected for policy or reputation reasons | Fix your sending setup, not the address |
| 450 / 451 4.x.x | Temporary failure, often greylisting | Retry automatically |
The 5.7.1 case deserves its own explanation, because it looks like a recipient problem and is actually a sender problem. We cover it in why your emails bounce from Outlook with 550 5.7.1.
Frequently asked questions
Related reading
Ready to clean your email list?
InboxSure verifies emails via web, bulk CSV upload, or API — security-first and GDPR-friendly.