Gmail "Address not found" 550 5.1.1 - How to Fix

Mail bouncing back with "Address not found" and error 550 5.1.1? The receiving server is reporting that no mailbox exists at that address. Here is how to work out why, from both the sending and receiving side.

The Error

Address not found

Your message wasn't delivered to jsmith@example.com because the address
couldn't be found, or is unable to receive mail.

The response from the remote server was:
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. For more information, go to
https://support.google.com/mail/?p=NoSuchUser  ... - gsmtp

The enhanced status code is the part that matters. 5.1.1 specifically means bad destination mailbox address. The leading 5 means permanent - the sending server will not retry.

Why This Happens

The receiving mail server accepted the connection, read the recipient address, and found nothing to deliver to. In a Google Workspace domain, that means the address is not a user, an alias, a group, a resource, or a routing destination.

Distinguish this clearly from 550 5.7.1, which means the address exists but the message was refused on policy or reputation grounds. The two look similar in a bounce report and need completely different fixes.

The usual causes, in the order worth checking them:

1. A typo in the address - the single most common explanation
2. A deleted user whose address is still in circulation
3. A removed alias, or a group that was renamed
4. MX records pointing somewhere other than Google
5. A routing rule sending mail to a destination that rejects it
6. A secondary domain added in the Admin console but never fully configured

If You Are the Sender

Start with the cheap checks:

• Read the address character by character. Transposed letters, .com against .co, and a trailing space copied from a web page account for most of these.
• Check for an autocomplete entry that outlived the person. Gmail suggests addresses long after they stop working - delete the stale contact rather than retyping around it.
• Confirm the address through another channel before assuming the domain is broken.

If the address is definitely right, the problem is on the receiving domain and the recipient's administrator needs to act.

Fix 1: Confirm the Address Exists

In the Google Admin console, type the address into the search bar at the top. It matches users, aliases and groups.

For a definitive answer about what happened to a specific message, use Reporting > Email Log Search. Enter the recipient address and a time window; the result shows whether the message reached Google at all and how it was handled. This is the fastest way to separate "we never received it" from "we received it and rejected it", and those point at very different causes.

Fix 2: Handle a Deleted User

When someone leaves and their account is deleted, every message to their address bounces. Two supported options:

Add the address as an alias on a colleague's account. In the Admin console open the receiving user, go to User information > Email aliases, and add the departed employee's address. Mail then arrives in that colleague's mailbox. Aliases are free and do not consume a licence.

Restore the deleted user. Google retains a deleted account for 20 days. Go to Directory > Users, open the three-dot menu and choose Recently deleted users. Restoring re-creates the mailbox and its contents.

Two constraints trip people up. An alias can take up to 24 hours to activate. And an address cannot be an alias on one account while still assigned as the primary address of another - including a deleted account still inside its restore window, which is why an alias added immediately after a deletion sometimes appears to do nothing.

Fix 3: Check MX Records

If every address on the domain bounces, suspect DNS rather than individual accounts:

dig +short MX example.com

A domain delivering to Google Workspace should return Google's mail servers. If it returns a previous host, mail is being delivered to a server that has never heard of your users, and every message produces this bounce.

This is a classic mid-migration failure: the domain is fully configured in the Admin console, so everything looks correct there, while DNS still points elsewhere.

# Confirm from an authoritative nameserver rather than a cache
dig +short MX example.com @8.8.8.8

Fix 4: Look for Routing Rules

Check Apps > Google Workspace > Gmail > Routing and Default routing for rules that redirect mail. A rule pointing at a decommissioned server, or at an address that no longer exists, produces this bounce for the addresses it matches while everything else delivers normally.

Content compliance and objectionable content rules can also reject mail, though those usually generate a different status code. Email Log Search names the rule that acted on a message, which saves reading through every rule by hand.

Also confirm the user is not suspended. A suspended account's behaviour differs from a deleted one, but it is worth ruling out while you are in the console.

Fix 5: Decide About a Catch-All

You can route mail for unrecognised addresses to a nominated mailbox instead of bouncing it, using Default routing with the Unrecognized addresses condition.

The tradeoff is real. A catch-all stops legitimate mail being lost to a typo or a stale address, but it also accepts every message aimed at guessed addresses - info@, admin@, sales@ - which means directory-harvest spam lands in a real mailbox and your domain begins accepting mail it should refuse. Most administrators enable a catch-all temporarily during a migration or a rebrand, then turn it off.

A narrower alternative is to add specific former addresses as aliases, which catches the mail that actually matters without opening the domain to everything else.

Verify the Fix

# MX records resolve to Google
dig +short MX example.com

Then send a test message to the affected address from an external account and confirm it arrives. In the Admin console, Reporting > Email Log Search should show the message as delivered rather than rejected.

If you added an alias, allow up to 24 hours before concluding it has not worked.

Prevention

• Add a departing employee's address as an alias on their manager's account as part of the offboarding process, before the account is deleted. Doing it afterwards means fighting the restore-window constraint.
• Keep a record of which aliases exist and why. Undocumented aliases get removed during tidy-ups, and the resulting bounces are hard to trace back.
• Verify MX records immediately after any DNS change or domain migration, not only when someone reports a bounce.
• Publish a monitored postmaster@ and abuse@ address on every domain you own, so failures reach a person rather than nobody.
• Review routing rules periodically. Rules pointing at retired servers are a common source of bounces on otherwise healthy domains.

Summary

1. Sender: check the address for typos and clear stale autocomplete entries
2. Admin: search the address in the Admin console and run Email Log Search
3. Departed staff: add the address as an alias, or restore the user within 20 days
4. All addresses bouncing: check dig +short MX example.com
5. Selective bounces: review Routing and Default routing rules