"550 5.1.1 User unknown" (also seen as "Recipient address rejected: User unknown" or "No such user") means the receiving mail server does accept mail for the domain, but the specific mailbox in the address does not exist on it. Unlike relaying denied, the server recognizes the domain — it just has no such recipient. The usual causes are a mistyped address, a deleted or renamed mailbox, or mail being routed to the wrong server (a stale MX) that does not know the user. The fix is to correct the address, restore/alias the mailbox, or fix routing so mail reaches the server that holds the account.
What It Looks Like
The rejection comes at the RCPT TO stage and names the recipient. The 5.1.1 enhanced status code specifically means "bad destination mailbox address":
# Postfix
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in
virtual mailbox table
# Google Workspace
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.
# Exchange / generic
550 5.1.1 User unknown
550 5.1.1 <user@example.com>: Recipient address rejected: undeliverable addressThe distinguishing detail is 5.1.1 plus a message about the recipient or mailbox — the domain was accepted, the user was not.
Confirm where the domain's mail is routed
Why It Happens
1. The address is mistyped
By far the most common cause. A transposed letter, a wrong domain suffix (.co vs .com), an extra character, or an old address that has since changed. The server is telling you exactly that: no mailbox by that name.
2. The mailbox was deleted, renamed, or never existed
The recipient left the organization, the account was removed, or it was renamed (e.g. j.smith became john.smith) without an alias. Mail to the old name now bounces.
3. Mail is routed to the wrong server (stale MX)
The domain's MX record points at an old mail host that no longer has the mailbox — for example after a migration where the MX was not updated, or a split-delivery setup where the wrong server answers. The user exists, but not on the server receiving the mail.
4. No catch-all and the alias/distribution list is gone
The address was an alias or distribution list that has been removed, and the domain has no catch-all to absorb unmatched recipients — so the specific address is now unknown.
5. Case or plus-addressing the server does not honor
Rarely, a server rejects an address variant it does not recognize — an unusual local-part, or plus-addressing (user+tag@) on a system that does not support it. The base mailbox works but the variant is unknown.
5.1.1 User unknown — the domain is accepted but the mailbox does not exist. 5.7.1 Relaying denied — the server will not accept the domain at all. 5.2.2 Mailbox full — the mailbox exists but is over quota. Read the enhanced status code; each points at a different fix.How to Diagnose It
First rule out a typo, then confirm mail is even reaching the right server. If the MX points somewhere unexpected, the "unknown" user may exist on a different host:
# Where is the domain's mail actually routed?
dig MX example.com +short
# e.g. "1 aspmx.l.google.com." <- is this the current provider?
# A stale MX from a previous host is a common cause of a valid user
# appearing "unknown" — the old server no longer has the mailbox.
# Sanity-check the exact address for typos before anything else:
# user@example.com vs user@example.co vs user@exmaple.comHow to Fix It
Fix A — Correct the recipient address
If you are the sender, re-check the address character by character against a known-good source. Confirm the domain suffix and local-part are exact, and beware autocomplete resurfacing an old, deleted address. This resolves the large majority of these bounces.
Fix B — Restore the mailbox or add an alias
If you run the receiving domain and the user should exist, create the mailbox, or add an alias mapping the old address to the current one so mail keeps flowing after a rename or departure:
; Example: alias an old/renamed address to the real mailbox
old.name@example.com -> john.smith@example.com (alias)
; Or add a catch-all only if you intend to accept all unmatched recipients
; (use sparingly — catch-alls attract spam)Fix C — Fix a stale MX so mail reaches the right server
If the mailbox exists on your current provider but mail bounces as unknown, your MX record is likely still pointing at an old host. Update MX to the current provider's exchangers and remove any leftover records:
; Point MX at the current mail provider (example: Google Workspace)
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
; Remove stale MX entries from the previous host.Fix D — Handle aliases, lists, and plus-addressing
If the address was a distribution list or alias, recreate it or point senders at the current address. If the issue is plus-addressing on a system that does not support it, send to the base mailbox (user@) instead of the tagged variant.
Verify the Fix
After correcting the address or fixing routing/mailbox config (and allowing any MX TTL to expire), send a test to the recipient and confirm a 250 acceptance instead of the 550 5.1.1 rejection:
# Confirm MX resolves to the current mail host
dig MX example.com +short
# A successful send ends with:
# 250 2.1.5 Recipient OK (or 250 2.0.0 Ok: queued)
# instead of 550 5.1.1 User unknownFrequently Asked Questions
The address is definitely correct — why is it still user unknown?
Then mail is probably reaching the wrong server. Check the domain's MX record: a stale entry from a previous host will accept the domain but not have the mailbox. Update MX to the current provider and wait for the old TTL to expire.
Is 550 5.1.1 a permanent failure?
Yes. 5.x.x codes are permanent — the server will not retry. The message bounces immediately and must be resent after the address or configuration is fixed; it will not be delivered later on its own.
What is the difference between 5.1.1 and 5.7.1?
5.1.1 means the mailbox does not exist on a server that does handle the domain. 5.7.1 means the server will not accept the domain at all (relaying denied). The status code tells you which one you have.
Could a catch-all hide this problem?
A catch-all would accept the mail instead of bouncing, but it also accepts every misdirected and spam message, so it masks typos rather than fixing them. Prefer explicit aliases for addresses you actually want to keep working.
My whole team's incoming mail bounces user unknown — what now?
That points to routing, not individual addresses. Verify the MX record is the current provider's, confirm the mailboxes exist on that provider, and check the server's accepted-domains and mailbox table. A recent migration with an un-updated MX is the classic cause.