“5.1.1” Account does not exist

The “5.1.1 Account does not exist” bounce error (often reported as 550 5.1.1 User unknown or Recipient address rejected) is an SMTP failure indicating that the destination mail server was reached, but it could not find a mailbox matching the recipient’s email address. The domain name after the @ symbol is active and receiving mail, but the specific username before the @ symbol is invalid, deactivated, or blocked by routing rules. Resolving this error requires checking the recipient address for typographical errors, auditing alias and user directories, or correcting split-domain routing configurations.

Quick Fix: How to Resolve 5.1.1 Bounces

A 5.1.1 bounce indicates that the recipient’s mail server does not recognize the mailbox name. To fix this, verify the address for typos or spelling errors. If sending to a colleague within your organization, check the Google Admin Console to ensure their user account or email alias is active. If your company uses a hybrid mail setup (such as Google Workspace and Microsoft 365), verify your split-delivery routing rules.

What the 5.1.1 Signal Means

In SMTP communications, 550 5.1.1 is an RFC 5321 reply code denoting a permanent failure during the envelope exchange:

• Class 5xx: Permanent failure. The sending mail server will not automatically retry delivery.
• Subject .1.x: Addressing status. The issue is directly tied to the destination email address.
• Detail .x.1: Bad destination mailbox address. The mailbox does not exist at the specified destination host.

This error confirms that the domain’s DNS MX records are working correctly. The sending server successfully established an SMTP connection with the receiving mail server. However, when the sending server issued the RCPT TO:<user@example.com> command, the receiving server queried its directory, found no matching mailbox or alias, and rejected the transaction.

Outbound SMTP Connection Established
                  │
                  ▼
   HELO / EHLO Handshake Accepted
                  │
                  ▼
   MAIL FROM:<sender@yourdomain.com> Accepted
                  │
                  ▼
   RCPT TO:<nonexistent@example.com>
                  │
                  ▼
   Destination Server Queries Directory / User DB
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
   User Exists         User Not Found
        │                   │
   250 OK (Data Phase)  550 5.1.1 Recipient Rejected

Primary Causes of 5.1.1 Errors

1. Typographical Errors in the Recipient Address

The most common cause is a simple spelling error in the local part of the address (e.g., writing johndoe@example.com instead of john.doe@example.com). This also includes hidden trailing spaces or special characters introduced when copying and pasting addresses.

2. Deleted, Suspended, or Renamed Accounts

When an employee leaves an organization or an account is de-provisioned, their mailbox is deleted. Unless an administrator configures an email alias or catch-all route, any emails sent to that address will bounce with a 5.1.1 error. If an account is suspended rather than deleted, receiving systems will often return a different code, such as Fix: “5.2.1” Account Disabled for Inbound Mail.

3. Split-Delivery and Hybrid Routing Failures

In corporate environments where a domain is shared across multiple email platforms (e.g., some users on Google Workspace and others on Microsoft 365 or on-premise Exchange), incoming mail is routed through split delivery. If Google Workspace is authoritative for the domain but does not have a routing rule to forward unknown users to the secondary platform, external messages sent to users on the other system will bounce with a 5.1.1 error. For relay-specific variations of this problem, see Fix: “Recipient address rejected” (SMTP Relay) and Fix: “5.4.1” Recipient Address Rejected.

4. Disabled Catch-All Mailbox

If an organization previously routed all misspelled or unassigned email addresses to a central administrator mailbox via a catch-all setting, disabling that setting will cause all mistyped incoming messages to bounce with 5.1.1. If your catch-all route is failing unexpectedly, see Troubleshooting “Catch-all” Not Forwarding.

Diagnostic and Remediation Steps

Step 1: Verify the Recipient Address Syntax

1. Inspect the bounce report (NDR) returned to the sender.
2. Confirm that there are no accidental spaces, leading quotes, or illegal punctuation characters in the address.
3. Check with the recipient through an alternate communication channel to verify their current address.

Step 2: Check User and Alias Status (For Google Workspace Admins)

If you manage the domain receiving the 5.1.1 error:

1. Log in to the Google Admin Console.
2. Go to Directory > Users.
3. Search for the username to verify that the account exists and is marked as Active.
4. If the user was renamed, check their profile under User information > Email aliases to ensure their former email address is listed as an alias.

Step 3: Configure Non-Existent User Routing for Hybrid Deployments

If your organization runs a hybrid email deployment where some mailboxes live on an external server:

1. In the Google Admin Console, navigate to Apps > Google Workspace > Gmail > Routing.
2. Locate the Routing section and click Configure or Add Another Rule.
3. Under Email messages to affect, select Inbound and Internal – Receiving.
4. Under For the following types of messages, select Unrecognized addresses.
5. Under Route, choose Change route and select your secondary mail server (e.g., Microsoft 365 or an internal Exchange server).
6. Save the rule. Google Workspace will now forward mail for users it does not recognize to your other platform instead of bouncing the message with a 5.1.1 error.