Few bounce messages are as common, or as often misread, as 550 5.1.1. It reads like an accusation against your server, but it usually says something much simpler: the receiving mail system looked for the mailbox you addressed and could not find it. The wording varies by provider. You may see "User unknown", "Recipient address rejected: User unknown in virtual mailbox table", "The email account that you tried to reach does not exist", "No such user here" or "Bad destination mailbox address". They all describe the same permanent condition. This guide explains how to read the code, lists the real causes in order of how often they occur, shows how to confirm which one you have, and explains what to do whether you are the sender, the owner of the mailbox or the person responsible for a mailing list. It also covers the cases where the message is misleading, so you do not spend a day fixing something that is not broken.
What the code means
An SMTP reply has a three-digit code and, on modern servers, an enhanced status code. The first digit of the three-digit code tells you whether to retry: 4 means temporary, 5 means permanent. In the enhanced code, the first number repeats that class, the second number is the subject, and the third is the detail. Subject 1 is "addressing", and detail 1 is "bad destination mailbox address". The standard that defines these codes is RFC 3463. So 550 5.1.1 means a permanent failure because the destination mailbox address is bad. Retrying will not help, and every retry to an address that does not exist is counted against your reputation. Our general guide to reading a bounce code and the longer list in SMTP reply codes explained give the wider context.
What a real bounce looks like
Read the whole bounce, not only the subject line. The useful details are in the diagnostic section. Here is a typical example, with the sensitive parts replaced:
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach
does not exist. Please try double-checking the recipient's email address
for typos or unnecessary spaces.
Remote-MTA: dns; mx.example.netThree lines matter. Final-Recipient is the address the remote server tried to deliver to, which may differ from the one you typed if a forwarding rule or alias rewrote it. Status is the enhanced code. Remote-MTA is the server that refused the message, which tells you whether the refusal came from the recipient's own mail system or from a gateway in front of it. If the refusing server is not the final mailbox host, the check may have been made against a copy of the directory that is out of date.
The causes, from most to least common
1. A typo in the address
This is the cause in a majority of cases. The domain may be right and the name wrong, or the other way around: jane.doe instead of jane.doe1, a missing letter, a swapped pair of letters, a trailing space or a comma pasted from a spreadsheet. Domains are misspelled too, such as gmial.com, but a misspelled domain usually produces a different failure, because the domain itself does not resolve. Look at the address in the bounce character by character. If it came from a web form, check whether your form validates the address and asks the visitor to confirm it.
2. The mailbox was closed or never existed
People change jobs, schools close accounts and users delete free mailboxes. A list collected years ago will contain many addresses that no longer exist. Providers also stop accepting mail for inactive accounts. Sending to such addresses is the main way a healthy list slowly becomes a reputation problem. Remove any address that returns 5.1.1, and do so automatically after the first occurrence, not after the third.
3. The domain exists but does not host that user
The right company, the wrong name. A company may use first.last@ for some staff and flast@ for others, or may have changed its naming scheme. Check the format used in a recent message from that organisation, or ask the person for the right address.
4. Directory and routing rules at the recipient
Organisations that use Microsoft 365 or Google Workspace sometimes receive a 5.1.1 or a related code for an address that does exist, because the address is a distribution group set to accept mail only from internal senders, a shared mailbox that is not set up for outside mail, or a mailbox that has not finished provisioning. On Exchange Online you may see 550 5.1.10 RESOLVER.ADR.RecipientNotFound, which means the same as 5.1.1 for practical purposes, or a 5.4.1 reply when directory-based edge blocking rejects unknown recipients. If the recipient insists that the address works, ask them to check how it is configured, and to read their own message trace for the rejection.
5. A catch-all or alias was removed
If an address used to work and suddenly bounces, the domain owner may have removed an alias, a forwarding rule or a catch-all. The change might be recent and deliberate. Ask the recipient for a current address.
6. A stale cache or a split mail setup
When a company migrates mail from one platform to another, a sending server may briefly reach the old system, which no longer has the mailbox. The error then looks like a bad address, even though the new system would accept the message. If the bounce appears for many users of one domain at the same time, suspect this and contact the domain's administrator, rather than removing all of the addresses at once.
How to confirm the cause
First, read the address in the bounce. Second, check the domain's mail setup with a lookup of its MX records, which tells you which system answers for it (see what an MX record is). Third, test the address without sending a message, using an SMTP conversation up to the recipient step:
dig MX example.net +short
openssl s_client -starttls smtp -connect mx.example.net:25 -crlf
EHLO test.example.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
QUITIf the server answers 250 to RCPT TO, the address is accepted at that moment. A 550 5.1.1 there confirms the rejection and shows that it does not depend on your message content. Be careful: many servers accept everything during the conversation and bounce later, or deliberately give no information to prevent address harvesting, and repeated probing from one address can be treated as abuse. Do not build a bulk checker out of this. For lists, use a proper validation step, as described in email validation before sending. If your outbound port is blocked, the guide on how to test an SMTP connection explains the alternatives.
What to do next
| If you are | Do this |
|---|---|
| A person who sent one message | Check the spelling, remove spaces, and confirm the address with the recipient through another channel. Do not keep resending. |
| An application sending to user-supplied addresses | Validate the format at sign-up, send a confirmation message, and mark the address as invalid after the first 5.1.1. |
| A marketer with a list | Suppress the address immediately, review the source of the batch, and run the list through validation before the next send. See suppression list management. |
| The owner of the mailbox | Check that the account exists, is licensed and is not suspended; check aliases and groups; read the message trace for the rejection. |
| A domain administrator who sees rejections for real users | Check directory sync, recipient policies and migration status. Make sure the MX records point at the platform that holds the mailboxes. |
When the message is misleading
Not every 5.1.1 means the address is wrong. Some mail systems return it when they reject a message for another reason but do not want to reveal that the user exists. Examples include a recipient that only accepts mail from approved senders, and a server that treats your sending as suspicious and answers as if the user did not exist. The clues are that the same address works from another sender, that many valid addresses at the same domain bounce at once, or that the rest of the bounce text mentions policy, a block list or a reputation. In that case, treat it as a blocking problem and follow the guides on blocked messages and blocklist removal.
Stopping it from happening again
A rate of permanent bounces above about two percent starts to hurt reputation at most large mailbox providers, and a good sender keeps it well below one percent. Prevent 5.1.1 bounces at the source. Ask for the address twice or send a confirmation message at sign-up; use double opt-in for lists, as described in double opt-in; never buy or scrape lists; and remove addresses automatically on a hard bounce. Review the bounce reports each week, group them by domain and reason, and look for patterns, such as a single import that produced most of the failures. The metric and the thresholds are explained in bounce rate: what is a good rate.
See every bounce with its reason Delivery logs show the exact server reply for each recipient, and bad addresses are suppressed automatically.
References and further reading
Frequently asked questions
What does SMTP 550 5.1.1 mean?
A permanent failure: the receiving server could not find the mailbox you addressed. The usual causes are a typo, a closed account or an address that never existed.
Should I retry after a 550 5.1.1 bounce?
No. It is a permanent failure. Correct the address or remove it, because repeated sends to nonexistent addresses damage your sender reputation.
Why do I get 5.1.1 for an address that exists?
The address may be a group or shared mailbox that does not accept outside mail, a mailbox still being provisioned, or a server that gives a misleading answer for policy reasons. Ask the recipient to check their message trace.
What is the difference between 5.1.1 and 5.1.10?
5.1.1 is the standard bad-mailbox code. 5.1.10 is a code used by Exchange Online for a recipient that could not be found. Both are permanent.
How do I avoid 5.1.1 bounces in a mailing list?
Confirm addresses at sign-up, use double opt-in, validate before sending, and suppress any address on its first hard bounce.