SMTP 554 5.1.1: recipient address rejected (user unknown)

554 5.1.1 is a 5xx permanent failure. The enhanced status code 5.1.1 specifically means "bad destination mailbox address" — the recipient's domain exists and accepted the connection, but the specific mailbox does not exist on that server. This is a hard bounce: there is no condition under which retrying will succeed.

Who is at fault

Neither party in the sense of error — the address simply doesn't exist, usually because of a typo at signup, a decommissioned account, or stale list data from an address that was once valid.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<nonexistent@example.com>
554 5.1.1 <nonexistent@example.com>: Recipient address rejected: User unknown in virtual mailbox table

The rejection happens at RCPT TO, before DATA — the server never accepts the message body because it already knows the destination is invalid.

How the big three word it

Gmail and Microsoft 365 typically use base code 550 rather than 554 for this exact condition, while some self-hosted and smaller systems — along with Yahoo in some configurations — use 554. All three carry the same enhanced code and the same underlying meaning: the mailbox doesn't exist.

Diagnose it

$ dig MX example.com +short
$ swaks --to recipient@example.com --from test@mailpilots.in --server mx.example.com

Confirm the domain itself resolves and accepts mail (MX record valid, server reachable) to rule out a domain-level typo before concluding the specific mailbox is the issue.

Fix it, in order

1. Remove the address from your sending list immediately. There's no retry window — a hard bounce stays a hard bounce.
2. Check for a likely typo if this is a recently-collected address (common domain misspellings, transposed characters) and, if you can reach the person through another channel, confirm the correct address.
3. Audit your list collection process if hard bounces from this cause are frequent — it points to a validation gap at signup, not a one-off.
4. Track your hard-bounce rate over time; a rate climbing much above roughly 2% is itself a signal to receivers independent of any individual address.

A cause worth checking: catch-all domains and silent acceptance

One wrinkle worth knowing about: some domains configure a catch-all address that accepts mail for any local part, meaning a typo'd address at that specific domain won't produce a 554 5.1.1 at all — it will be silently accepted and then likely routed to a general mailbox or simply discarded. This cuts the other way from the topic of this post, but it's worth knowing: the absence of a 5.1.1 bounce doesn't guarantee the address you typed is the one the intended recipient actually reads. If you have independent confirmation (a reply, a click, a form submission) that the real person received the message, trust that over the absence of a bounce alone.

An additional diagnostic step

$ swaks --to recipient@example.com --from test@mailpilots.in --server mx.example.com -quit-after RCPT

Stopping the test transaction right after RCPT TO, rather than completing a full send, lets you confirm whether a given address is accepted or rejected without actually delivering a test message — useful for verifying a list in bulk before a real campaign run touches it.

Why there's no retry window here at all

Unlike every 4xx condition in this cluster, there is no backoff schedule to wait out: a 554 5.1.1 is rejected at RCPT TO on the very first attempt and will be rejected identically on every subsequent attempt, forever, because the condition it describes (the mailbox not existing) doesn't change on its own. Some MTAs will still log a handful of automatic retry attempts before formally generating the hard-bounce notification back to your application, which can create the misleading impression that a short delay might help — it won't, and the address should be suppressed as soon as the 5xx reply is confirmed, not after watching it fail a second or third time.

What not to do

• Don't retry sending to the same address. It will fail identically every time; repeated attempts only cost you reputation.
• Don't confuse this with a full mailbox (4.2.2) or a temporarily unavailable one (4.2.1). Those are 4xx deferrals worth retrying; 5.1.1 never is.
• Don't keep an address on an active list "just in case" after a confirmed 5.1.1. Continuing to send to confirmed-invalid addresses is one of the most direct ways to damage domain reputation at scale.

MailPilot tracks hard-bounce patterns per domain and flags list-hygiene problems as part of its reputation monitoring, so a rising 5.1.1 rate shows up as a signal before it affects inbox placement for your valid recipients.