SMTP 550 5.1.1: The Mailbox Does Not Exist

550 5.1.1 is a permanent SMTP rejection, commonly logged and bounced back as "user unknown". The receiving server looked up the recipient address and found no mailbox behind it. The message will never be delivered, retrying will not change the answer, and the address should come off your list. The 550 is the three-digit reply code. The 5.1.1 is the enhanced status code that says which part of the delivery failed.

The two numbers come from different specifications. RFC 5321 defines 550 as "Requested action not taken: mailbox unavailable" and puts it in the 5yz class, where the client "SHOULD NOT repeat the exact request". RFC 3463 defines the enhanced code 5.1.1 as "Bad destination mailbox address", and says it "is only useful for permanent failures".

What does a 550 5.1.1 bounce look like?

The code is standard. The text after it is written by whoever rejected the message.

• Gmail: 550 5.1.1 The email account that you tried to reach does not exist. Please double-check the recipient's email address for typos or unnecessary spaces. Gmail appends gsmtp to all of its error text.
• Microsoft 365: Exchange Online documents the enhanced code 5.1.1 as Bad destination mailbox address, and files the whole 5.1.1 to 5.1.20 range under recipients that cannot be found or routing information that is invalid.
• Postfix: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table, with local recipient table in place of virtual mailbox table depending on which lookup failed. This is Postfix's own default reject text, and it is the wording most self-hosted and gateway-relayed bounces carry. It often arrives quoted inside a bounce from Proofpoint or another inbound gateway sitting in front of a Postfix delivery host, so the wording belongs to that backend, not to the gateway that forwarded it.

Why does it happen?

The mechanics are ordinary:

• A typo in the local part. Microsoft calls the wrong address the most common cause of the whole 5.1.x range.
• The mailbox was deleted or deactivated. Valid once, not now.
• An alias or distribution list was removed and nothing resolves the address any more.
• A catch-all was switched off, so local parts it used to swallow now reject.
• The address never existed, because it was scraped, guessed, or mistyped at signup.
• A migration left stale routing behind, such as an MX record still pointing at the old server.
• On Exchange Online, the user object exists but has no mail license assigned.

What should a sender do?

Stop sending to that address. RFC 5321 puts 5yz replies in the do-not-repeat class, so the retry is wasted. Suppress the address, and pull it from whatever source produced it, or it comes back on the next import.

Hard bounces feed sender reputation. SendGrid recommends generating hard bounces from fewer than 5% of attempted messages, while stating that "there is no exact number or percentage of hard bounces that causes deliverability issues". That is one ESP's guidance, not a threshold anyone enforces. Google's published bulk-sender number is a spam-complaint rate, which measures something else.

What should a receiving admin check?

Three things, in order.

That the mailbox exists, that the username matches the address the sender used, and on Exchange Online that the account holds an active license. Then routing: a recipient's forwarding rule or an admin transport rule can redirect mail to an invalid downstream address and bounce it even though the typed address was correct. Then recipient filtering. Microsoft's Directory-Based Edge Blocking rejects invalid recipients at the service perimeter before spam or malware filtering runs, and returns 550 5.4.1 Recipient address rejected: Access denied rather than a 5.1.1.

Which codes get confused with 550 5.1.1?

• 550 5.1.10 "Recipient not found". An SMTP address lookup that returned nothing. A separate Microsoft code with a near-identical outcome.
• 550 5.1.0 "Sender denied". Recipient resolution failed, typically from a stale Outlook cache, not from an absent mailbox.
• 550 5.7.1 Policy, not addressing. It covers delivery not authorized, unable to relay, and client not authenticated. The recipient may exist perfectly well.
• 450 4.1.1 Looks nearly identical, behaves the opposite way. The leading 4 makes it temporary and retryable, and it usually comes from greylisting or address-verification caching. RFC 3463 restricts X.1.1 to permanent failures, so the pairing is common in the wild but outside the spec.

The full SMTP reply code list covers the rest.

Does verifying an address first prevent this?

Usually, not always. An SMTP probe issues RCPT TO and reads the same lookup that produces the bounce, without sending a message. A catch-all domain answers 250 for every local part. A greylisting server rejects first contact temporarily whether the address is real or not. Trueguard's email validation returns those cases as ambiguous rather than guessing.