550 5.1.1 User Unknown: What It Means and What to Do

The 550 5.1.1 user unknown bounce — or, in Gmail, the longer version 'the email account that you tried to reach does not exist' — means exactly what it says: there is no mailbox at that address on the destination server. Not a spam filter, not a temporary delay, not a network problem. The receiving server looked up the username and found nothing.

This matters because 550 5.1.1 is a permanent failure. A temporary failure (any 4xx code) tells your mail server to try again later. A 5.x.x code tells your server to give up. Retrying the same address produces the same result, and if you send at any volume, accumulating hard bounces against a dead address damages your sender reputation.

This article explains what the code means at the protocol level, covers the four realistic causes, and gives you the step-by-step fix for each — plus a way to diagnose which one you are actually dealing with.

What does 550 5.1.1 literally mean?#

The bounce code has two parts. The first, 550, is an SMTP reply code defined in RFC 5321. It means 'requested action not taken: mailbox unavailable.' Your message reached the destination server but was refused.

The second part, 5.1.1, is an enhanced status code defined in RFC 3463. The three digits break down as: class 5 (permanent failure), subject 1 (addressing status), detail 1 (bad destination mailbox address). Combined, they state that the specific mailbox named in the recipient address does not exist on that server.

The exact wording varies by server. Gmail returns '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 returns '550 5.1.1 RESOLVER.ADR.RecipNotFound; not found.' Other servers say 'user unknown', 'Recipient address rejected: User unknown in relay recipient table', or 'No such user here.' The phrasing differs; the cause does not.

The behaviour to understand is that all 5.x.x codes are permanent. Your sending server will not retry automatically. If you resend manually or rerun a sequence against the same address, it will bounce again for the same reason unless the address has been fixed.

The four causes of 550 5.1.1 user unknown#

Every 550 5.1.1 has one of four root causes. The fix depends on which one you have, so it is worth identifying the cause before doing anything else.

Fix 1: Correct a typo in the address#

A typo is the most common cause and the easiest to fix. The delivery status notification (DSN) that lands in your inbox will quote the exact address the server attempted to deliver to. That is the address to inspect.

1. 1

   Read the delivery status notification

   Open the bounce email. Look for a header line reading 'Final-Recipient', 'Original-Recipient', or 'Delivered-To' in the technical section of the bounce. This shows the exact address your server sent to, which may already reveal the typo.

2. 2

   Compare character by character against your intended address

   Common patterns: a transposed pair of letters (emial instead of email), a wrong top-level domain (.con instead of .com, .co instead of .com), a missing or doubled character, or a stray space that crept in at the start or end of the address.

3. 3

   Verify the domain independently if you are not certain

   If the domain itself looks unfamiliar, check whether the organisation's website uses that domain. A quick search for the company name and 'contact' will usually confirm the correct domain within thirty seconds.

4. 4

   Send a fresh message to the corrected address

   Do not reply to the bounce or resend the original message — compose a new one to the corrected address. If the contact lives in a CRM or mailing list, update the record before the next campaign so the corrected address carries forward.

Fix 2: Find the current address for a deleted or renamed mailbox#

When the domain is valid and no typo explains the bounce, the mailbox was probably deleted or renamed. The person may have left the organisation, changed their name, or the company updated its email format. The old address is gone permanently. You need the new one.

1. 1

   Check the company website

   Visit the organisation's contact page, team directory, or about section. Many companies list current staff or provide a general enquiry address. If you were writing to a named individual, look for their current profile or a listed replacement.

2. 2

   Search LinkedIn

   Find the person on LinkedIn. If they are still at the organisation, their current title may reveal the email format in use (first.last@ versus firstlast@). If they have moved on, their new employer is listed and you can find a current address from there.

3. 3

   Try the organisation's general contact address

   Send a brief note to info@, hello@, or contact@ at the same domain asking to be connected with the right person or department. This works reliably at smaller organisations and often at larger ones too.

4. 4

   Update every record that held the old address

   Once you have the correct address, update it in your CRM, mailing list, and address book before sending again. One correction now prevents the same bounce on every future message to that contact.

Fix 3: Handle a removed alias or disabled catch-all#

Some organisations route mail through forwarding aliases — addresses like press@, sales@, or partnerships@ that redirect to a real mailbox — or use catch-all configurations that accept any address at the domain. When an alias is deleted or the catch-all is turned off, messages to those addresses start bouncing with 550 5.1.1 even though the domain and its primary mailboxes are working fine. The fix depends on whether you are the sender or the mail administrator.

1. 1

   Confirm the domain is alive

   Send a test to a known-valid address at the same domain, or check whether the organisation's website is reachable and uses that domain. If other addresses there work, the domain is fine — only the specific alias is gone.

2. 2

   Contact the organisation through a working address

   Use the general contact address or a different person at the organisation to ask which address now handles what the alias used to. For press or partnership enquiries, the current contact is usually listed on the website.

3. 3

   If you are the mail administrator receiving these bounces

   Check your alias table in Google Workspace (Admin console, then Directory or Routing), Microsoft 365 (Exchange admin centre, Recipients section), or your SMTP server configuration. Restore the alias, create a redirect to an active mailbox, or create a new mailbox at that address — whichever matches the intended behaviour.

How to tell which cause applies to you#

Before applying a fix, work through three questions in order.

First: does the bounced address match what you intended to send to? Open the DSN, find the address the server tried, and compare it to your contact record or what you typed. If they differ by even one character, you have a typo — go to Fix 1.

Second: is the domain valid? Search for the organisation online. If their website uses a different domain from the one in the bounced address, you have a domain-level typo. If the domain matches and the organisation is active, the problem is the mailbox itself, not the domain.

Third: when did this contact last reply to you, and does the person still work there? If they replied recently using this address, the mailbox existed until recently — it was deleted or renamed, pointing to Fix 2. If you have never received a reply and cannot find the person in the organisation's directory, the address may have been an alias or a catch-all that never routed to a specific individual — go to Fix 3.

How to prevent 550 5.1.1 bounces#

Most 550 5.1.1 bounces are avoidable with a few consistent practices around how addresses enter your workflow and what you do when one bounces.

Validate addresses at the point of entry. When an address comes in through a form or an import, check the syntax and confirm the domain has working MX records before it enters your list. You cannot verify that a specific mailbox exists without sending, but domain-level validation eliminates a large share of future bounces before they happen.

Keep lists current. B2B email addresses decay faster than most senders expect — role changes, departures, and company rebrands all kill addresses without notice. Scrub any contact that has not engaged in twelve months and has not responded to a re-engagement attempt. Hard bounce rates climb fastest on lists that were once clean and then aged out.

Act on bounces the day they arrive. When a 550 5.1.1 lands, remove or correct the address before the next send. Bulk senders on platforms like Mailchimp or SendGrid get this automatically. One-to-one senders using a CRM or outreach tool have to act manually — build the habit of reviewing the bounce report after every send, not just when something feels wrong.

Verify before you reach out cold. If you derived an address ([email protected] or [email protected]), spend thirty seconds confirming the person and the format on the company website or LinkedIn before sending. A bounce you prevent is a bounce that never damages your sender score.

Managing bounce reports manually across multiple inboxes is easy to miss — hard bounces arrive mixed in with ordinary messages and it is easy to act on them inconsistently. We build AI Emaily, an AI-native email client that flags 550 5.1.1 hard bounces as they land, surfaces the contacts that need correcting, and helps draft the follow-up outreach to find a working address. If you send outreach across several accounts, it keeps address hygiene from slipping through the cracks. A 7-day free trial is available on the Pro plan.