5.1.1 bounce: bad destination mailbox address
5.1.1Bad destination mailbox addressPermanent: retrying will not help
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table
What it means
RFC 3463 names X.1.1 "Bad destination mailbox address". The domain part of the address resolved and the mail server for it answered, but the server says the local part (the bit before the @) does not exist there. It is the single most common hard bounce on the internet.
The reply usually comes back during the SMTP conversation, right after the RCPT TO command, so your server never sends the message body. RFC 5248 pairs it with the basic codes 550 and 553. It is different from 5.1.2, where the domain itself is wrong, and from 5.2.1, where the mailbox exists but is switched off. A 5.1.10 means the domain publishes a null MX and takes no mail at all.
You can occasionally see 4.1.1 instead. Servers send that when a recipient lookup failed temporarily (for example their directory was unreachable), so the sender retries. Postfix also returns 450 4.1.1 when an address is unknown and the admin has soft_bounce or a temporary reject code configured. Treat repeated 5.1.1 as final.
Likely causes
- A typo in the local part, such as a missing letter or a swapped dot, or an outdated address from an old contact list.
- The person left the organisation and the mailbox was deleted or never forwarded.
- The recipient domain moved to a new mail provider and the new system does not have that mailbox yet.
- An alias or distribution list was removed while senders still use it.
- Directory sync lag on the receiving side (for example a new hire whose mailbox exists in one system but not yet in the gateway that checks recipients).
How to fix it
- Compare the quoted address in the bounce with the one you meant, character by character. Most 5.1.1 bounces are typos.
- Confirm the address with the recipient through another channel before sending again. Do not guess variations, since repeated bounces hurt your sender reputation.
- If you send bulk mail, remove the address from your list after the first 5.1.1. Mailbox providers treat repeated mail to unknown users as a sign of poor list hygiene.
- If you are the recipient’s admin and the mailbox should exist, check that it is in the directory your gateway or anti-spam service uses for recipient validation, and that the address is in the accepted domain list.
- After a migration, confirm the MX records point at the system that actually holds the mailboxes.
Checks that apply
- MX Lookup Confirms which servers receive mail for the domain, so you can tell whether the rejection came from the expected provider.
- SMTP Diagnostics Connects to the recipient MX and shows the banner, which identifies the system that rejected the address.
- Typosquat Scan Spots look-alike or misspelled domains, a common reason an address is unknown on the server that answered.
FAQ
- Will the sending server retry a 5.1.1?
- No. A 5.1.1 is permanent, so the message is returned immediately and no further attempts are made.
- Can a 5.1.1 be a false bounce?
- Yes, during migrations or directory sync problems a real mailbox can be reported as unknown. The recipient’s admin can confirm by looking up the address in their system.
- Does a 5.1.1 hurt my sender reputation?
- One does not matter. A high rate of unknown-user bounces signals a stale list to Gmail, Microsoft, and Yahoo and can lead to filtering.