SMTP reply code
550 5.1.1 — mailbox does not exist
A 550 5.1.1 reply means the receiving mail server checked the address and the mailbox does not exist. It is a permanent failure — a hard bounce. Remove the address from your list; retrying will produce the same reply.
The facts
| Field | Value |
|---|---|
| Reply code | 550 |
| Enhanced status code | 5.1.1 |
| Class | 5 — permanent failure |
| Subject | 1 — addressing status |
| Detail | 1 — bad destination mailbox address |
| Bounce type | Hard |
| Should the sender retry? | No |
| Representative wording | 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table |
The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.
What VerifyInbox returns
| Field | Value |
|---|---|
emailStatus | undeliverable |
reason | mailbox_not_found |
mailboxStatus | invalid |
smtpCode / smtpEnhancedCode | 550 / 5.1.1 |
retryable | false |
| Charged | Yes, 0.5 credits. The probe established something definitive. A retryable result, where nothing was established, is the one that costs nothing. |
What the code actually says
The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.
So 5.1.1 decodes as: class 5, permanent. Subject 1, addressing — the problem is with an address rather than with the mailbox system, the network or the content. Detail 1, bad destination mailbox address. The receiving server is not reporting a policy, a quota or a reputation problem. It is saying the recipient does not exist there.
That specificity matters, because the neighbouring codes mean different things and get handled identically by most bounce processors. 5.1.3 is bad *syntax* in the destination address. 5.4.1 sits in the network-and-routing space entirely. And a 5.7.x is about the sender, not the recipient — 550 5.7.1 removed from a list is a working address deleted for someone else’s reason.
Why it happens
In order of how often it is the real cause: the person left and the mailbox was deleted; the address was typed wrong, at signup or on a form; the address was guessed from a pattern and the guess was wrong; or the local part is right but the domain is one the organisation stopped using.
It is also what a receiving server answers to a dictionary attack, which is why anything probing a mail server at volume from an unwarmed IP stops getting honest answers quickly.
What each provider actually says
Quoted from each provider's own published documentation, with the date it was read. Not paraphrased into a claim about what a provider "always" returns.
“The email account that you tried to reach does not exist. Please double-check the recipient's email address for typos or unnecessary spaces.”
“NDR errors 550 5.1.1 through 550 5.1.20 … generally indicate that the recipient can’t be found or that message routing information is invalid.”
“554 delivery error: dd This user doesn't have a yahoo.com account ([email protected]) [-5]”
What to do
If you sent the message
- The address is wrong or the mailbox is gone. Those are the only two options.
- Check for a typo first — a verification result carries a
didYouMeansuggestion when the domain looks like a near-miss for a common one. - Remove the address from your list, permanently, in the same pass.
- Do not retry it. The reply will be identical and each attempt is another bounce against your sending reputation.
If you own the receiving domain
- The mailbox does not exist on your server, whatever your address book believes.
- Check the alias and virtual mailbox tables — a removed alias is the usual cause when the mailbox behind it still exists.
- Confirm the MX record points where you think it does. A stale MX sends mail to a server that has never heard of your users.
- In a hybrid setup, check whether the accepted domain is authoritative when it should be relaying.
If you are a developer
- Treat
550 5.1.1as a permanent suppression and write it to a suppression list, not merely to a campaign exclusion. - Never retry it from your queue.
- Split on the first digit before anything else —
4xxand5xxneed opposite handling, and a bounce processor that does not distinguish them will either suppress live mailboxes or keep mailing dead ones. - Read the reply text as well as the code: a
5xxnaming a blocklist is about you, not the recipient.
To find out whether an address will return this before you send to it, run it through the free email verifier
Related codes
Related terms
Sources
- RFC 5321 — Simple Mail Transfer Protocol
- RFC 3463 — Enhanced Mail System Status Codes
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes
- IANA — SMTP Enhanced Status Codes registry
Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.