5.1.1 user unknown: the mailbox does not exist

What the bounce means

The enhanced status code 5.1.1 is the receiving server saying the mailbox named in the recipient address does not exist. It usually appears as 550 5.1.1, often with text like “user unknown” or “no such user here,” but the three-digit reply code and the wording vary by server; the enhanced code is the reliable part. The server took your connection, looked up the local part (the piece before the @), found no account by that name, and refused the message.

This is a permanent failure, and it is entirely about the address. Your SPF, DKIM, DMARC, IP reputation, and content were never the question. Retrying changes nothing, because the mailbox will not exist on the next attempt either.

Where bad addresses come from

• Typos at capture. Someone typed jsmiht@ instead of jsmith@ into your signup form, and nothing checked it. The address was wrong from the first second you had it.
• Departed employees. The person left, IT deleted the mailbox, and an address that delivered fine for years starts returning 5.1.1. Common on B2B lists, where a few percent of contacts change jobs every month.
• Stale lists. Consumer mailboxes get abandoned, and providers eventually delete them. A list that has not been mailed in a year or two will hit a band of 5.1.1 on its first send back.
• Retired role addresses. A support@ or info@ alias that was cleaned up when a team or product went away.

Why repeated 5.1.1 sends hurt you

One 5.1.1 is routine. A pattern of them is a signal, and receivers read it. Mailbox providers track each sender's unknown-user rate, because the senders who hammer nonexistent mailboxes are overwhelmingly the ones working from purchased, scraped, or ancient lists. A rising unknown-user rate marks your list as low quality and weighs on how the receiver treats the rest of your mail from the same domain and IPs. The bounce itself is harmless; continuing to send into it is what does the damage.

How to handle it

• Suppress the address after the first bounce. Every serious sending platform has a suppression list; make sure 5.1.1 lands on it automatically. Never build a retry loop around a permanent code.
• Fix it at capture time. Typo-check new signups: flag local parts with obvious slips, suggest corrections for near-miss spellings of major mail domains, and consider confirming the address with a first email before it joins your main list.
• Verify important contacts out of band. If the bounce is a customer or a deal, do not guess at spellings by resending. Call them, or check the company directory, and capture the correct address once.
• Re-permission old lists before mailing them. A list that has sat cold is exactly where 5.1.1 clusters live. Warm it carefully or clean it first, rather than discovering the dead addresses at full volume.

Frequently asked

What does 5.1.1 user unknown mean?

The receiving server looked up the mailbox named in the recipient address and found nothing. The account does not exist there: a typo, a deleted mailbox, or an address that never existed. It is a permanent failure keyed on the address, not on your sending setup.

Should I retry a 5.1.1 bounce?

No. 5.1.1 is a permanent failure; the mailbox will not exist on the next attempt either. Suppress the address after the first bounce. If the contact matters, confirm the correct address out of band instead of resending to the broken one.

How is 5.1.1 different from 5.2.1 and 5.1.2?

5.1.1 means no mailbox by that name exists. 5.2.1 means the mailbox exists but is disabled, so it could come back. 5.1.2 means the domain half of the address does not resolve in DNS at all, so the receiving server was never even reached.

Can 5.1.1 bounces hurt my sending reputation?

Repeated ones can. Mailbox providers read a sender's unknown-user rate as a list-quality signal, because senders who hit many nonexistent mailboxes are usually working from purchased, scraped, or very old lists. Suppressing 5.1.1 addresses promptly keeps that rate low.