"550 5.1.1 User Unknown": What It Means and How to Fix It

“550 5.1.1 User Unknown” means the receiving mail server checked the address you sent to and found no mailbox with that name. The 550 says the rejection is permanent, and the 5.1.1 says the problem is the part of the address before the @. In most cases the address has a typo, the person has left the organization, or the account was closed. Resending the same message will fail again: correct the address or remove it from your list.

Below are the variations of this error you’ll see at different providers, the causes behind it, and how to fix it depending on whether you’re a one-off sender, a bulk sender, or the admin of the domain that’s rejecting mail.

What “550 5.1.1” actually means

The code has two parts:

• 550 is the basic SMTP reply. RFC 5321 defines it as “Requested action not taken: mailbox unavailable,” and says a 5yz reply means the client shouldn’t repeat the same request.
• 5.1.1 is the enhanced status code. RFC 3463 defines x.1.1 as “Bad destination mailbox address”: the mailbox specified in the address does not exist, and for internet mail that means the part to the left of the @ is invalid. RFC 3463 says this code is used only for permanent failures.

So the domain is fine. The server for that domain answered. It just doesn’t have that user.

What the error looks like at different providers

The same failure appears with different wording depending on who rejected it.

Gmail and Google Workspace (Google’s SMTP error list):

550 5.1.1 The email account that you tried to reach does not exist.
Please try double-checking the recipient's email address for typos
or unnecessary spaces.

Microsoft 365 / Exchange Online (Microsoft’s NDR reference):

550 5.1.1 RESOLVER.ADR.RecipNotFound

Microsoft also uses 5.1.10 Recipient not found when an SMTP address lookup fails, and for Outlook.com and Hotmail recipients it can return 550 5.5.0 Requested action not taken: mailbox unavailable, which its documentation describes as similar to 5.1.10.

Yahoo (Yahoo’s SMTP error codes):

554 delivery error: dd This user doesn't have a yahoo.com account

Yahoo uses 554 instead of 550, but it’s the same failure, and Yahoo says not to retry and to remove the address.

Postfix and many self-hosted servers:

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

All of these are hard bounces caused by a nonexistent mailbox.

Common causes of 550 5.1.1

1. A typo in the local part

jon.smith@ instead of john.smith@, jsmith@ instead of j.smith@, a missing letter, an extra space. Gmail’s own error text tells senders to check for typos and unnecessary spaces.

2. The person left the organization

Business addresses are deleted or disabled when employees leave. This is the main reason B2B lists decay, and it’s invisible to any check that only looks at the domain.

3. The account was closed for inactivity

Consumer providers close unused accounts on published schedules. Microsoft closes an Outlook.com mailbox if the owner hasn’t signed in at least once in a one-year period (Microsoft Support). Google may delete personal accounts that haven’t been used within two years (Google). Addresses that were valid when someone signed up can be gone a year or two later.

4. The address was never real

Fake signups, bot submissions, and made-up addresses like none@company.com or asdf@gmail.com produce 5.1.1 on the first send.

5. A mail system misconfiguration (internal mail)

If you’re sending to a colleague and get 5.1.1, the cause may be on your own system. Microsoft lists these possible causes for 5.1.1 in Exchange Online, alongside a mistyped address:

• The recipient’s mailbox was moved and the sender’s Outlook recipient cache didn’t update.
• An invalid legacy DN exists for the recipient in Active Directory.

How to fix 550 5.1.1 if you sent a one-off email

1. Check the address character by character. Look for transposed letters, a missing dot, a trailing space, or the wrong domain extension.
2. Don’t reply to an old thread or use autocomplete. Type the address fresh. Microsoft notes that when the cause is a stale Outlook recipient cache, resending the original message fails again; the sender needs to remove the cached entry and create a new message.
3. Confirm the address another way. Check the person’s email signature, website, or LinkedIn, or ask a colleague.
4. Accept that the person may have moved on. If they changed jobs, the old address won’t come back.

How to fix 550 5.1.1 as a bulk sender

For marketing and product email, 5.1.1 is the clearest case for immediate suppression.

1. Suppress the address on the first 5.1.1. Amazon SES tells senders to remove a permanently bounced address from mailing lists immediately (AWS). Unlike a soft bounce, there’s no reason to wait for a second failure.
2. Sync the suppression everywhere. Push it back to your CRM, sales engagement tool, and any other platform that sends email, so no one re-imports and re-mails it. Our existing guide on suppression list design covers how to scope this.
3. Tag the source. Record where the address came from. If one form or import produces most of your 5.1.1 errors, fix that source.
4. Check the rate, not just the addresses. A handful of 5.1.1 errors per send is normal decay. A large share of a send bouncing with 5.1.1 means you mailed an old or purchased list. Amazon SES puts accounts under review at a 5% bounce rate and may pause sending at 10% (AWS).
5. Recover valuable contacts manually. For a paying customer or an active deal, ask for an updated address through your app, by phone, or through another contact at the company.

Why ignoring 550 5.1.1 hurts deliverability

Mailbox providers read repeated mail to nonexistent users as a sign that you don’t maintain your list. The M3AAWG Sender Best Common Practices say that when a receiver tells you there’s no one at an address, the message should not be retried and the address should be suppressed, and that the volume of permanent failures is one of the inputs receivers use to judge a sender. Yahoo goes further and has a specific error for servers that send to excessive unknown recipients.

How to fix 550 5.1.1 if you’re the receiving admin

Sometimes the person reporting the error is the intended recipient, who says, “I exist, why is mail bouncing?” If you manage the receiving domain:

1. Confirm the mailbox or alias exists, with exactly the spelling the sender used, including any dots or hyphens.
2. Check recent migrations. Microsoft documents RESOLVER.ADR.RecipNotFound bounces after a mailbox is moved to Microsoft 365 when the on-premises mail-enabled user isn’t stamped with the correct target address (Microsoft Support).
3. Check aliases and forwarding. A removed alias or a broken forwarding rule can produce 5.1.1 or 5.1.10 even though the user’s primary mailbox works.
4. Check the MX path. If your MX points at a filtering gateway, make sure its recipient list is in sync with your mail server. A gateway with an outdated directory will reject valid users.

Can you prevent 550 5.1.1 errors?

Partly. You can prevent the ones caused by bad input:

• Typo detection at signup catches domain typos and nudges users to double-check what they typed. See common email typos.
• Double opt-in proves the address worked at least once.
• Regular list re-verification catches addresses that died since signup.

What you can’t fully prevent is decay after collection: people leave jobs and providers close accounts. And no check is perfect. Some domains accept mail for any address at check time and reject it later. See catch-all email domains and why emails still bounce after verification.

The free email verifier on this site helps with the input side. It checks syntax, confirms the domain exists and has MX records, flags disposable and role-based addresses, detects free-provider domains, and catches common domain typos. To be clear about its limits: it doesn’t connect to the recipient’s mail server over SMTP, so it can’t tell you whether jane@ exists at a valid domain. A 5.1.1 caused by a departed employee at a real company will pass a DNS-level check. That’s why bounce processing matters even when you verify.

For a broader look at how this error fits with other codes, see SMTP bounce codes explained.

FAQ

Is 550 5.1.1 a hard bounce or a soft bounce?

It’s a hard bounce. Both the 550 reply and the 5.1.1 enhanced code indicate a permanent failure, and RFC 3463 defines x.1.1 as a permanent-only code. Retrying won’t help.

Can 550 5.1.1 be temporary?

The code itself is permanent, but the underlying situation occasionally isn’t, for example a mailbox that’s mid-migration or an alias that was removed by mistake and restored. Those cases are rare and usually internal. For bulk sending, treat every 5.1.1 as permanent and suppress the address.

Why do I get 550 5.1.1 when the address worked last month?

The mailbox was most likely deleted or disabled since your last send, usually because the person left their company or abandoned the account. If it’s a colleague’s address on your own system, a mailbox migration or a stale autocomplete entry can also cause it.

Does 550 5.1.1 mean I’m blocked or blacklisted?

No. A 5.1.1 is about the recipient address, not about you. Blocks normally carry 5.7.x policy codes, such as Gmail’s 550 5.7.26 for DMARC failures. If you see 5.7.x, look at your authentication and reputation instead.

Should I resend after fixing the address?

Yes, if you’ve corrected an actual typo, send a fresh message to the corrected address. Don’t resend to the original address, and if you’re a bulk sender, make sure the bad version stays suppressed so it doesn’t come back through an old import.