Bounce and error codes

550 5.1.1: the mailbox at that address does not exist

Last updated 2026-08-31

Your message came back, and the person you wrote to never read it. The receiving server answered 550 5.1.1, and that code says it holds no mailbox at the address you used. You can send the message again, and the server answers with the same code. You own three of the causes: a typo, a stale Outlook Auto-Complete entry, and a report for mail you never sent. The rest is directory work inside their company. Further down, this page carries a block to send the person who runs their mail. Your DNS records took no part in this refusal. If the line in your bounce reads "Access denied" rather than "User unknown", 550 5.4.1 Recipient address rejected is the page you want.

Gmail, Exchange and Postfix word it differently

The three servers send the same digits, but each writes its own sentence after them. The wording sorts your bounce into the two cases below: an address you can fix, and a mailbox only their admin can create. Google's SMTP error table prints this one.

Exchange Online lists 5.1.1 in its NDR code table as Bad destination mailbox address, under 4 conditions.

• The sender typed the address wrong.
• The address does not exist in the destination email system.
• The mailbox moved, and the sender's Outlook recipient cache did not update.
• An invalid legacy domain name (DN) exists for that mailbox in Active Directory.

A mailbox that moved to Exchange Online returns a longer variant. Microsoft's own KB prints it with these hash marks.

An Outlook nickname cache holding a bad X.500 entry returns the near-twin 550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found. Both strings belong to Exchange. A bounce carrying either one points at directory work rather than at anything you publish.

Postfix writes its own sentence and names the table it searched. The line below is assembled from Postfix defaults rather than copied from a bounce. An operator who changed the reject code or the table-name setting reads different text.

The reply code comes from unknown_local_recipient_reject_code, which ships as 550. Postfix hard-codes 5.1.1 for an unknown recipient. A rejected sender address gets 5.1.0 instead. Postfix prints the table name because show_user_unknown_table_name defaults to yes. A virtual domain says "in virtual mailbox table", and a relayed one says "in relay recipient table".

Your log may print 550-5.1.1 with a hyphen on every line but the last one. RFC 5321 defines that form for a reply that runs to several lines. A hyphen after the code means more text follows, and a space means the reply ends there. The verdict reads the same either way.

Typos and stale cache entries explain most 550 5.1.1 bounces

Microsoft's page for 5.1.1 through 5.1.20 runs 5 sender-side solutions, in this order.

1. The address itself. Microsoft says it first: "It sounds too simple, but the wrong email address is the most common issue that causes 5.1.x errors." Read the domain twice as well as the local part. You have used that address for a year, so checking it feels absurd. Microsoft still starts there.
2. Your Auto-Complete list. Outlook also calls it the nickname cache. An entry in it can point at identifiers that no longer resolve. Delete that person from the list, then type the address by hand.
3. Sent Items. Open the message you actually sent and read the address on it. When that address differs from the one in the bounce, a rule on their side rewrote it.
4. Your own account. If Sent Items holds messages you never wrote, reset the password and tell your admin.
5. A message you never sent. When nothing in Sent Items matches the bounce, the report is backscatter and you can drop it.

Steps 1 and 2 clear the two causes a sender owns. After those, the address is the problem, and asking the person for a current one moves faster than another send.

Auto-Complete goes stale when a mailbox moves

Microsoft names the mechanism: the recipient "might have been moved from an on-premises Exchange organization to Exchange Online, or vice versa. Although the recipient's email address is the same, other internal identifiers for the recipient might have changed, which breaks your cached entry for the recipient." The To field shows the address you expect. Behind it, Outlook sends to an internal identifier that no longer resolves.

Delete the entry, then type the whole address. In Outlook on the web, select New mail, type the person's name in the To field until they appear in the drop-down list, select them with the arrow keys and press Delete. In the Outlook desktop client, use Microsoft's Remove AutoComplete list entries. Resending the original message reuses the same cached entry, so start a new message instead.

The same fix covers a reply to an old migrated message. Microsoft names two more causes: a stale X.500 name after a .pst migration, and an Offline Address Book that will not update.

Deleted mailboxes return the same code

An address that worked last year is no evidence that it exists now. Microsoft's own note on the 5.1.1 row says so: the error "can occur if the recipient's email address was previously valid but later changed or removed". The person who signed off your invoices left in the spring, an admin removed the account, and the address went with it. No amount of retyping brings it back. Ask the company for a current address, or write to a shared one you know is live.

Forwarding rules bounce an address you never typed

Open the bounce and open your Sent Items, then compare the two addresses. When they differ, your message reached the person, and a rule of theirs pushed a copy on to an address that does not exist. Microsoft's instruction is to contact that person by phone or in person, and to ask whether they set up a rule that forwards your mail somewhere else. The fix is theirs to make: correct the destination in the rule, or remove the rule. A mail flow rule written by their admin does the same thing at the server, and a mailbox delegate can do it too.

You cannot see any of that from outside, so send the person a note by another route.

Backscatter is a bounce for mail you never sent

If your Sent Items holds nothing matching the bounce, stop working the address. A spammer forged your address into the From field of their own mail, and the refusal came back to you. Microsoft calls that report backscatter and says plainly: "It's annoying, but if this NDR is backscatter, your account isn't compromised."

Read the report before you decide, since the fields say which message it refers to. The Mail Delivery Subsystem page walks those fields one at a time, and why an email bounces back covers the wider class of reports.

Receiving admins: the address has to exist as an object

The domain in the bounce is one you run, so creating the address is your job. Every sender who writes to that address reads the same refusal, and the report goes to them instead of you. A customer who writes to sales@ and reads that refusal decides the company does not want the order. One forwarded bounce may be the only one you ever see.

• The recipient object. Mail reaches an address only when your directory holds it as a mailbox, an alias on a mailbox, a group or a mail contact. Ask the sender to forward the bounce, since the exact address they used sits inside it.
• The license. Microsoft's steps for the neighbouring code 5.1.10 send an admin to Users and then Active users in the Microsoft 365 admin center. Confirm there that the account exists and holds a valid license for email.
• Catch-all routing. Google Workspace can collect misaddressed mail. The catch-all setting sits under Apps > Google Workspace > Gmail > Routing. It takes messages "sent to non-existent or incorrect email addresses in your domain" into one mailbox. That mailbox then accepts every address a spammer guesses at your domain, so give it an owner before you turn it on.
• The MX record. Microsoft lists a stale MX as a cause of 5.1.1, where the record "might point to an old email server". Its 5.1.10 page prints both hostnames a Microsoft 365 domain is meant to point at: <domain>.mail.protection.outlook.com and <domain>.subdomain.mx.microsoft. Both pages tell an admin to keep exactly one MX record for a domain enrolled in Exchange Online. Microsoft's note adds that DNS updates "can take up to 72 hours to propagate to all DNS servers on the Internet", so a same-day edit proves nothing yet.
• Service health. The Microsoft 365 admin center carries a Message Center and a Service health page, and Microsoft's first admin step is to read both.

Microsoft's Remote Connectivity Analyzer runs an Inbound SMTP Email test against a domain, with no login. From a terminal, dig answers the same question.

Swap in the domain from the bounced address. Left as example.com, the command answers 0 ., because that domain publishes a null MX. RFC 7505 defines the bare dot as an announcement that the domain accepts no mail.

In a hybrid tenant, a mailbox moved to Exchange Online needs a routing address on the on-premises mail user. It takes the form <alias>@<domain>.mail.onmicrosoft.com. Without one, on-premises Active Directory cannot route to that mailbox. When a cloud-only user has no matching on-premises object, Exchange returns the neighbouring 550 5.1.10 instead. Your message couldn't be delivered covers that repair.

Message to send the receiving admin

Nobody who can create that mailbox has seen your bounce. Send them the block below, with your own address and your own error line in it.

Leave RESOLVER.ADR or User unknown in the line you paste. Those words send an admin to the directory, and a bare 550 sends them to their spam filter.

You may not know who runs mail for that company. Send the block by any route that still reaches them: a phone call, a colleague, a shared inbox you know is live, or the account manager who sold you the contract. The person you reach can forward it, and the pasted line is the evidence their admin needs.

SPF, DKIM and DMARC did not cause this

The receiving server compares one field against its directory: the address you sent to. Your authentication results play no part in that check. Publishing a DMARC record does not create a mailbox, and tightening one does not remove a mailbox either.

Rejections that do come from your records name them in the text. 550 5.7.26 says the message is unauthenticated. 550 permanent failure covers what that leading 5 commits your server to. 5.1.1 points at the mailbox, and RFC 3463 says so plainly: "The mailbox specified in the address does not exist." Work the address, not your records.

550 5.1.1 against the codes it gets confused with

Several systems return one of these where you would expect another, so read the wording as well as the digits.

Exchange Online returns 5.4.1 instead when Directory-Based Edge Blocking turns the message away at the perimeter. Microsoft's table glosses that string as "The recipient's address doesn't exist". Both bounces mean the address does not exist, but the two servers reached that answer in different places. 550 5.4.1 Recipient address rejected covers the domain settings behind that one. If the wording in your bounce is "Access denied", read that page instead of this one.

You fixed this sender. Tomorrow the reports name the other hosts still sending as you, and we turn a day of XML into one email with a verdict per sender. On the paid plans, the day a report first names a new sender failing, you hear about it. Get the weekly digest. The first domain is free.