550 5.1.1 user unknown: meaning and fix

What 550 5.1.1 means, how providers word it, common causes, related SMTP codes, and how to handle retries and suppressions.

A 550 5.1.1 reply means the receiving server rejected that recipient address for this message, most often because the mailbox does not exist. Treat it as a permanent failure: do not retry the same message until you fix the address or the receiving configuration.

Microsoft also returns this code for routing or directory problems on its side. Sendtier suppresses an address when Amazon SES reports the bounce type Permanent, not because the SMTP digits are 5.1.1.

How to read the reply

The first number is the basic SMTP code. In RFC 5321, a 5yz reply is a permanent failure, so the client should not repeat that request until the cause is corrected. A 4yz reply is transient, and the client should try again. Section 4.2.3 describes 550 as "mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)".

The dotted number is the enhanced status code. RFC 3463 writes it as class.subject.detail. Class 5 means the message is unlikely to succeed unchanged, so the message or the destination has to change. Subject 1 is the address. Detail 1 means that mailbox does not exist. For an Internet address, the part left of @ is invalid, and this detail applies only to permanent failures.

RFC 2034 places the dotted code before the text. The class must match, so 550 takes a 5.x.x code. The IANA registry lists basic codes 451 and 550 for X.1.1. RFC 5321 calls 5yz replies permanent negative replies and 4yz replies transient negative replies. RFC 3463 calls class 5 a permanent failure and class 4 a persistent transient failure.

What mailbox providers write

Gmail and Microsoft document 5.1.1 errors. Yahoo's missing-account sample is a 554 line, with no dotted 5.1.1.

Gmail

Gmail's SMTP error list documents reply 550 5.1.1 as: "The email account that you tried to reach does not exist. Please double-check the recipient's email address for typos or unnecessary spaces."

Microsoft 365

The Exchange Online non-delivery report catalog labels 5.1.1 "Bad destination mailbox address". Its listed causes include a mistyped address, and an address that does not exist in the destination system. They also include a stale Outlook cache after a mailbox move, and an invalid legacy domain name (DN) for the mailbox.

After a migration, stale Outlook recipient data can cause an ExRecipNotFound failure. The ExRecipNotFound article quotes 550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found.

Yahoo

Yahoo's SMTP error codes put a missing Yahoo account under "Recipient does not exist." Yahoo's sample bounce includes this excerpt: "554 delivery error: dd This user doesn't have a yahoo.com account". For this sample, Yahoo says: "You should not retry delivery of the message. It will never complete successfully."

Apple

Apple's iCloud Mail help does not give a 5.1.1 reply. It says an "unknown address" or "undelivered mail returned" message means you should check the Sent mailbox for a correct address.

How to tell the causes apart

Gmail's bounce help lists spelling errors, a stray quotation mark, trailing dots, and spaces, and it says the address may have changed. When the bounced address shows one of those, ask the person who typed it to correct it.

If the address looks correct, ask the recipient to confirm it through another channel. Check the diagnostic for forwarding, routing, or directory problems before concluding that the mailbox does not exist.

A disabled mailbox that still exists is 5.2.1. Gmail's SMTP error list writes 550 5.2.1: "The email account that you tried to reach is inactive." The same list also uses that code for a permanent receive-rate refusal, so read the sentence. RFC 3463 allows this detail as permanent or transient.

A wrong domain is 5.1.2. RFC 3463 puts that failure in the part to the right of @. Gmail writes 553 5.1.2: "We weren't able to find the recipient domain." Invalid recipient-address syntax is 5.1.3. Gmail lists 553 5.1.3 with the excerpt "is not a valid RFC 5321 address."

On Microsoft 365, the same 5.1.1 can be a bad MX record, a forward to an invalid address, or a stale Outlook cache (troubleshooting guide). The admin repairs the mailbox, the MX record, or the forward, and the sender confirms the address.

When the on-premises directory has no object for a cloud mailbox, Microsoft documents 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup (RecipientNotFound). IANA X.1.10 is a null MX, with basic code 556 (RFC 7505). Read the text before you treat 5.1.10 as a null MX.

The table gives standard SMTP meanings. Provider-specific uses follow the table.

CodeMeaning in the standardUsually permanent / temporary in SMTPWhat to do
5.1.0An address caused the failure, with no finer detail. RFC 3463PermanentRead the diagnostic and resolve the address problem before a new submission.
5.1.1The mailbox does not exist. The local part is invalid. RFC 3463Permanent onlyFix the address or the receiving configuration before a new submission.
5.1.2The destination system does not exist, or cannot accept mail. The domain part is invalid. RFC 3463PermanentFix the domain.
5.1.10Null MX. RFC 7505PermanentThe domain refuses mail.
5.2.1The mailbox exists and is not accepting mail. Either class is allowed. RFC 3463Permanent when the class is 5Confirm that the mailbox was disabled.
5.2.2Mailbox full, reported as permanent. The registry says to use a persistent transient failure. RFC 3463Permanent reportCheck the provider diagnostic. For a quota failure, retry after capacity is restored.
4.2.2Mailbox full. The recipient can delete mail to make space. RFC 3463Persistent transientRetry later.
5.7.1The sender is not authorized to send to the destination. RFC 3463Permanent onlyFix the policy or the filter.
5.7.26More than one authentication check failed. The checks are not named. RFC 7372PermanentInvestigate authentication. This code alone does not prove the address is invalid; Sendtier suppression still follows the SES bounce type.

The Amazon SES bounce type decides suppression in Sendtier, not the Usually permanent / temporary in SMTP column.

On Gmail's SMTP error list, a recoverable full inbox is 452 4.2.2: "The recipient's inbox is out of storage space." An inactive full inbox is 552 5.2.2: "The recipient's inbox is out of storage space and inactive."

Exchange Online's NDR catalog defines 5.2.2 as "Submission quota exceeded", a sender rate limit. On-premises Exchange documents 5.2.2 as "Mailbox full" (Exchange Server bounce messages). A full public folder is 554 5.2.2, with the text "The recipient's mailbox is full and can't accept messages now. Please try resending this message later or contact the recipient directly." (public-folder quota). For this public-folder case, resolve the quota problem before retrying.

Gmail's 550 5.7.26 says: "This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM." That page also uses 5.7.26 for an SPF -all failure and a DMARC rejection. IANA X.7.26 means more than one check failed, and it does not name DMARC. Microsoft's 5.7.1 article says its troubleshooting guidance also applies to 5.7.0 through 5.7.999.

What your application should do

Stop automatic retries of the failed request while you investigate, confirm the address, and resolve any routing or directory problem before submitting again. For Sendtier's automatic suppression decision, use the SES bounce type.

A corrected address is a new submission. RFC 3463 says the sender can generally correct an addressing error. RFC 5321 allows a new attempt after a real change, such as a corrected spelling. Do not invent that change: show the address to the person who typed it. For a stored contact, pause sending while you confirm the address and investigate the failure.

Yahoo tells senders: "You should remove the email address from your mailing list." The same page says: "List managers should have a policy for removing email addresses that generate 5xx errors/bounces." Yahoo also says: "Review your mailing lists and remove any addresses that generate bounces." Source: Yahoo's SMTP error codes.

Apple's postmaster guidance asks bulk senders to manage bouncing addresses, remove inactive subscribers and persistent bounces, and keep unsubscribed or suppressed addresses blocked.

How Sendtier records and handles bounces

Sendtier is in public preview. The service runs in AWS eu-central-1 (Frankfurt) and sends through Amazon SES in that region. AWS is a subprocessor. Live sending is limited during the public preview.

When Amazon SES reports a bounce, the event keeps the type (Permanent, Transient, or Undetermined) and the subtype. For each recipient, Sendtier preserves the action, status, and diagnostic_code values SES supplies; those values can be empty. The status is the enhanced code, such as 5.1.1, when SES includes it. The diagnostic code is the receiving server's reply text when that server returns one. The event also keeps the reporting MTA and the remote MTA IP when SES reports them. Emails, events, and webhook deliveries stay 30 days by default.

Permanent bounces and complaints automatically suppress the affected addresses; Transient and Undetermined bounces do not.

A later send to a suppressed address fails with 422 recipient_suppressed. The API lets you add, list and remove suppressions in your account. See Suppressions. Webhooks deliver email.bounced for this event, and you can inspect a delivery and resend it. The errors guide explains that 422.

Illustrative bounce-event data, not a complete webhook payload or a captured delivery result. action, status, and diagnostic_code can be empty. reporting_mta and remote_mta_ip may be absent. MTA names use the dns; form.

{  "bounce_type": "Permanent",  "bounce_subtype": "General",  "reporting_mta": "dns; mta.example.com",  "remote_mta_ip": "192.0.2.1",  "recipients": [    {      "email": "user@example.com",      "action": "failed",      "status": "5.1.1",      "diagnostic_code": "smtp; 550 5.1.1 user unknown"    }  ]}

If diagnostic_code is empty, use status when present, and do not infer missing details.

Sendtier keeps the bounce details Amazon SES reports, so you can see why an address failed. Start free with a test key in the quickstart.