SMTP 550 5.1.1 User Unknown: Mailbox Does Not Exist

550 5.1.1 is the most common hard bounce. RFC 3463 defines status 5.1.1 as "Bad destination mailbox address: the mailbox specified in the address does not exist". The receiving server accepted the connection, looked up the part before the @, and found no such recipient. The domain is reachable; the person is not.

Common wordings:

550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or unnecessary
550-5.1.1 spaces. Learn more at https://support.google.com/mail/?p=NoSuchUser

550 5.1.1 <kim@example.net>: Recipient address rejected: User unknown in virtual mailbox table

550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found

Microsoft 365 often phrases it as 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup, a closely related code for the same condition.

Decision order

1. Read the address in the bounce. Is it exactly what you intended?
2. Check that the domain's mail routes to the right server after a migration.
3. Ask whether the mailbox was deleted, renamed or never created.
4. If you operate the receiving server, check the recipient tables and alias maps.
5. Clean your list so you stop sending to it.

Step 1: look for typos and invisible characters

Compare the address character by character. Most 5.1.1 bounces come from gmial.com, a trailing dot, a space copied from a spreadsheet, a lookalike character, or name.surname versus n.surname. If the domain part itself is wrong (gmial.com), you would normally get a different failure because that domain has no mail server, not a 5.1.1.

If the address was copied from a web form or a CSV import, check for a hidden leading character or a non-breaking space:

printf '%s' 'kim@example.net' | xxd | head

Step 2: confirm the domain's MX is current

If the person definitely exists but you get 5.1.1, you may be talking to an old server. After a mail migration, a stale MX record can send you to a host that no longer has the mailbox. Check what the world currently sees:

dig +short MX example.net
dig +short TXT example.net

The MX Lookup and Email DNS Checker show the same from outside. Compare the answer with where the mailbox actually lives. If you find an old hostname, the record has not been updated or is cached; see how long DNS propagation takes and MX records explained. Also check whether the zone has more than one set of nameservers answering different records, using the Nameserver Lookup.

The bounce itself names the server that rejected you: look for host mx1.example.net[198.51.100.30] said in the log or the bounce body. If that server is not one of the current MX hosts, the stale route is the cause.

Step 3: confirm the mailbox exists

For a mailbox you can ask someone about, confirm directly: was the employee off-boarded, was the alias removed, did the school year end? Many hosts delete mailboxes on cancellation and then answer 5.1.1 for them. Gmail and Microsoft 365 both do this for removed accounts. Nothing on your end can bring the address back.

For your own server, an alias that "should work" often does not:

• Postfix virtual alias: the address is missing from virtual_alias_maps.
• cPanel: the forwarder or default address was disabled.
• Microsoft 365: the address is missing from the user's proxy addresses, or the mailbox is in a hybrid setup and the on-premises directory lacks the object.

Step 4: debug your own Postfix server

If external senders are bouncing with 5.1.1 for people who exist, ask Postfix directly:

postconf virtual_mailbox_domains virtual_mailbox_maps virtual_alias_maps local_recipient_maps
postmap -q kim@example.net hash:/etc/postfix/vmailbox
postmap -q kim@example.net mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
sudo postfix check && sudo postfix reload

postmap -q prints the mapped value if the key exists and nothing if it does not. After editing a hash: file, remember to run sudo postmap /etc/postfix/vmailbox. Run the query for each map type you use; a missing entry in one map is enough to reject. For delivery through Dovecot, doveadm user kim@example.net shows whether the user resolves.

The log line tells you which check fired:

postfix/smtpd[991]: NOQUEUE: reject: RCPT from mail.example.org[203.0.113.9]: 550 5.1.1 <kim@example.net>: Recipient address rejected: User unknown in virtual mailbox table; from=<a@example.org> to=<kim@example.net>

A catch-all is a policy choice, not a fix. It stops 5.1.1 but accepts every guess and lots of junk. Prefer explicit recipients and aliases.

Step 5: stop sending to bad addresses

A 5.1.1 is a permanent signal. Mark the address invalid in your list or CRM and do not retry. Repeated mail to nonexistent users is a spam-trap signal for some receivers and hurts reputation. Look at sending patterns with the Email Deliverability Test and read email going to spam if bounce rates are high. Keep unknown-user bounces separate from reputation bounces such as SMTP 550 5.7.1 rejected, which are about you, not the recipient.

How to verify

After fixing a typo or server table, send one test message and look for status=sent in the log. For a corrected MX record, query it from a public resolver and wait out the TTL. Use the Port Checker to confirm the corrected host answers on port 25.

Next steps

• Understand code families in email bounce codes explained.
• Verify your records with the MX Lookup.
• See mailbox full 552 5.2.2 for a mailbox that exists but cannot take mail.
• Review the relay access denied error if your server rejects its own domain.

FAQ

Can 550 5.1.1 be temporary?

Rarely. It is a permanent failure by definition. A few misconfigured servers return it during directory outages, so retry once if you know the address is valid.

Can I tell if an address exists before sending?

Not reliably. Many servers accept any recipient then bounce later, and others hide the answer to prevent harvesting. Treat verification services with caution.

Why does only one sender get 5.1.1?

The sender may be hitting an old MX or a different server that has its own stale cache. Compare the host ... said lines in each bounce.

Does 5.1.1 mean I am blocked?

No. It names the recipient, not you. Blocks use 5.7.x codes.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.