550 5.1.1 User Unknown: Recipient Doesn't Exist

Problem

Mail bounces with a permanent non-delivery report carrying 550 5.1.1 and some variant of User unknown, No such user, Mailbox not found, or the email account that you tried to reach does not exist. The message never reached a mailbox, and the sender gets an NDR naming the recipient address. This is the most common permanent bounce on the internet, and it means exactly one thing: the address you sent to does not exist on the server that answered.

Symptoms

• The NDR contains 550 5.1.1 followed by wording like User unknown, No such user here, Recipient address rejected: User unknown, or does not exist.
• Gmail bounces end with gsmtp and read 550-5.1.1 The email account that you tried to reach does not exist.
• Microsoft bounces cite RESOLVER.ADR.RecipNotFound or does not exist.
• Other recipients on the same domain receive mail fine; only one address bounces.
• The address looks correct and the recipient swears the mailbox exists.

What This Error Actually Means

Read the enhanced status code as two separate claims. The 550 is a permanent SMTP rejection — do not retry, the same address will bounce again. The 5.1.1 is RFC 3463’s enhanced status X.1.1, “Bad destination mailbox address”: the receiving server looked for the mailbox named to the left of the @ and found nothing.

The decision happens early, at RCPT TO, before the server weighs your reputation, your SPF, or your content. That is why it is so often misdiagnosed. People see a hard 550 and start hardening authentication, when the receiver never got far enough to care who sent the message. It refused the address, full stop.

The trap is the word “exist.” The server isn’t making a claim about the whole internet — only about itself. When it says 5.1.1, it means I have no such mailbox. If the mailbox really does live somewhere, but the mail arrived at a server that doesn’t host it, you still get 5.1.1. The address is real; the delivery target is wrong. Those are two different failures wearing the same code.

Top 3 Causes

1. The address is genuinely wrong or gone — A typo, a deleted or renamed mailbox, an offboarded employee, a removed alias, or a stale entry on a mailing list. The server checks, finds no mailbox, refuses. This is 5.1.1 doing its job.
2. Mail is reaching the wrong server — The address exists, just not where the message landed. The domain’s MX record points at a provider that doesn’t host that mailbox: a leftover MX after a migration, a broken split-delivery setup, or a catch-all that was disabled and stopped papering over the gap. Fixing the mailbox won’t help until the MX points at the host that actually has it.
3. The mailbox exists but isn’t a deliverable target yet — An alias, nickname, or distribution address that was never created; a Google Workspace or Microsoft 365 user provisioned but not mail-enabled or licensed; or a directory that hasn’t propagated a freshly created recipient. It’s “real” in an admin console but invisible to the SMTP front door.

Diagnose with DechoNet

• Email Check on the recipient domain confirms where its mail actually routes. If the MX points somewhere unexpected — an old provider, a parked host, or nowhere useful — you’ve found the “exists but wrong server” case without touching the mailbox.
• Email Header Analyzer reads the bounce itself: confirm the code is 5.1.1 (not 5.4.1 directory-block, not 5.7.x authentication) and identify the reporting host. gsmtp means Google answered; protection.outlook.com means Microsoft. That tells you whose rules you’re up against.
• DNS Check shows the domain’s MX priorities and any recent changes. A demoted, duplicated, or leftover MX record quietly catching mail is a classic cause of a valid address bouncing 5.1.1.

Resolution Checklist

• Confirm the code is 5.1.1, not 5.4.1 (Microsoft edge/directory block) or 5.7.x (authentication/policy). The number decides which fix applies.
• Re-check the address character by character. Copy-paste it from a known-good source instead of retyping — one wrong letter is the single most common cause.
• Ask the recipient’s admin to confirm the mailbox or alias exists, is active, and is mail-enabled. A licensed user is not always a deliverable address.
• If you control the recipient domain, verify the MX points at the provider that actually hosts the mailbox. Clean up stale MX records left behind by a migration or split-delivery change.
• If the mailbox was created recently, wait for provisioning and directory propagation before assuming it’s broken.
• Remove hard-bounced addresses from your sending list. Hammering a 5.1.1 address repeatedly is a spammer signal and erodes your sender reputation.

When to Escalate

• This bounce is generated by the recipient’s server, so the fix usually belongs to the recipient’s administrator, not you. Forward them the exact NDR — the 5.1.1 code and the reporting host tell them precisely which mailbox, alias, or directory entry is missing.
• If you own the recipient domain, the MX is correct, and a valid mailbox still bounces 5.1.1, escalate to your mail provider with a message trace. A confirmed, mail-enabled recipient that the front door still can’t see points at a routing or provisioning fault on their side.