A 550 is the reply that most people see when an email fails. The official definition is "requested action not taken: mailbox unavailable", and it is a permanent failure. That definition is broad on purpose. In real bounces, 550 appears with dozens of different texts and enhanced codes: the address does not exist, the mailbox is disabled, the domain does not accept mail, the recipient only accepts mail from certain senders, the message was blocked by policy, or authentication failed. Because the number is the same, people often treat every 550 as the same problem, and fix the wrong thing. This guide is a map. It explains what the number promises, how the enhanced code narrows it down, lists the most common 550 variants with who must act, and gives a diagnosis path that works for any bounce. If you already know your exact code, the table in the middle will take you to the right guide.
What a 550 reply promises
SMTP replies are grouped by their first digit. A 5 means that the failure is permanent for this attempt, and the sending server should not try again unchanged. The second digit, 5, relates to the mail system, and the third gives the detail. A 550 in RFC 5321 means that the requested mail action was not taken because the mailbox is unavailable, for example because it was not found or it is not accessible for policy reasons. The enhanced status code that follows (RFC 3463) is far more helpful. It repeats the class in the first number, uses the second number for the subject (1 addressing, 2 mailbox, 3 mail system, 4 network, 5 protocol, 6 content, 7 security or policy), and the third for the detail. Read these two parts together: the plain text a human wrote, and the enhanced code a machine can sort.
The common 550 variants
| Enhanced code | Typical text | Meaning | Who must act | Guide |
|---|---|---|---|---|
5.1.1 | User unknown, account does not exist | The mailbox is not there | Sender fixes or removes the address | 550 5.1.1 |
5.1.2 | Bad destination system address, domain not found | The recipient domain cannot receive mail | Sender checks the domain; recipient checks DNS | MX records |
5.1.8 | Sender address rejected, domain not found | The sender domain cannot be verified | Sender fixes DNS or the envelope address | Sender domain not found |
5.2.1 | Mailbox disabled, not accepting messages | The account is disabled or closed | Recipient or administrator | Contact the person another way |
5.2.2 | Mailbox full, over quota | No room to store the message | Recipient frees space | Mailbox full |
5.4.1 | Recipient address rejected: Access denied (Exchange Online) | The directory does not list the address, or the edge rejects unknown recipients | Sender or recipient administrator | Check the address and the tenant |
5.7.1 | Delivery not authorized, message refused, blocked, spam | A policy decision about you or the message | Sender, with the recipient help if needed | 554 and policy blocks |
5.7.26 | Unauthenticated email is not accepted | Authentication failed for the sending domain | Sender fixes SPF, DKIM, DMARC | Gmail 5.7.26 |
5.7.509 | Access denied, sending domain does not pass DMARC | DMARC policy of reject was applied | Domain owner fixes alignment | DMARC rejection |
Who should act: three questions
When you get a 550, ask three questions in order. Is the problem the address? Codes in the 5.1.x and 5.2.x families describe the recipient or sender address or the mailbox. Check spelling and ask the person. Is the problem the policy? Codes in 5.7.x describe a decision about you or the message. Read the text for hints: block list, spam, authentication, relay or sender restrictions. Is the problem the system? Codes in 5.3.x and 5.4.x describe size limits, routing or the network. Each question points to a different person who can fix it, and you save time by asking them in this order.
Details that explain the confusing cases
The same address works from another sender
If a recipient can receive mail from other people but not from you, the 550 is about you. The usual causes are a sender restriction (the recipient accepts mail only from certain senders), a block that applies to your IP or domain, or an authentication failure. Ask the recipient to check their message trace or spam settings, and test your authentication with a message to a mailbox you control.
The error appears for only some recipients at one domain
This points to the recipient side. Some addresses may be groups or shared mailboxes that accept mail only from internal senders, others may be newly created and not yet visible in the directory, and still others may have been deleted. Compare the addresses that work with those that fail and ask the administrator.
The error appears for every recipient at one domain
This suggests a block of your IP or domain, an authentication failure, or a change at the recipient (for example a migration). Check the IP against block lists (how to check), check authentication and look for announcements about the recipient's mail platform.
The error appears for every recipient everywhere
This points to your own system: the sender domain, the envelope sender, a misconfigured server, a lapsed domain or an account that is blocked by your provider. Test with a simple message to a different provider and check your account status.
Test, do not guess
A manual SMTP session shows where the 550 arises. Connect to the recipient's mail server and issue the commands up to RCPT TO. If the 550 comes at MAIL FROM, the problem is the sender address or domain. If it comes at RCPT TO, it is the recipient or a policy about the pair of sender and recipient. If it comes after DATA, it concerns the content or authentication of the message. The commands are in how to test an SMTP connection. Be gentle: some servers treat repeated probing as abuse, and many deliberately give the same answer for every recipient to prevent address harvesting.
What senders should do for each family
- Address problems (5.1.x, 5.2.x). Fix or remove the address. Suppress it after the first hard bounce. Never keep sending.
- Policy problems (5.7.x). Check authentication, reputation, content and list quality. Slow down and send to engaged recipients. Ask the provider for review if needed.
- System problems (5.3.x, 5.4.x). Check message size, routing, DNS and the recipient's mail platform; try again later if the cause may be temporary, but expect a permanent code to stay.
All of these cases belong in your suppression and monitoring routine: see suppression list management and hard and soft bounces.
What recipients and administrators should do
If you are the person who did not receive an expected message, ask the sender for the full bounce, because it holds the code and text. Check your own spam and quarantine folders. If you manage the mail system, use the message trace to find the rejection; it identifies the rule that fired. For allow lists, be specific and temporary. If your directory or recipient policies reject valid addresses, repair the synchronisation or the address list. If your users are on a migrated system, make sure that the MX records point to the platform that holds the mailboxes, as described in migrating email providers without losing deliverability.
Avoiding 550 bounces in bulk sending
A bulk sender should expect some 550 bounces and handle them well: a rate of permanent failures that stays low, quick suppression of bad addresses and a response to any spike. A spike usually has a single cause, such as a new list import, a change in authentication, a new sending IP or a block at one provider. Group bounces by code and by receiving domain each day, and look at the biggest group first. The article on bounce rate explains the metric and typical thresholds, and email validation before sending shows how to stop most address problems before they happen.
See the exact reply for every recipient Delivery logs record the code and text from the receiving server so you can fix the right problem.
References and further reading
Frequently asked questions
What does SMTP 550 mean?
A permanent failure meaning the requested action was not taken, usually because the mailbox is unavailable or a policy refused the message. The enhanced code explains which.
Is a 550 error my fault?
Not always. It may be a wrong address, a closed mailbox, a recipient policy or a problem with your authentication or reputation. The text and code show which.
Should I resend after a 550?
Not unchanged. Correct the address or fix the policy cause first. Resending without a change usually fails again and may harm your reputation.
What is the difference between 550 5.1.1 and 550 5.7.1?
5.1.1 means the mailbox address is not found. 5.7.1 means a security or policy decision refused the message.
How can I find out why a 550 happened?
Read the full bounce text and enhanced code, check the address, authentication and block lists, and test an SMTP session up to the recipient step.