SMTP error code · permanent failure (5xx)

SMTP error 550 5.1.1: the email account that you tried to reach does not exist

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026

550 5.1.1 means the receiving server has no mailbox for the address you sent to: the classic user unknown bounce. It's permanent: the address is misspelled, deleted, or the domain's MX records point at a server that doesn't know it. Verify the address and re-send; retrying unchanged fails forever.

550 5.1.1 at a glance
Code550 5.1.1
ClassPermanent (5xx): the message was refused and will not retry
CategoryRecipient
Side at faultEither side
Auth-relatedNo

What the bounce actually says

The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.

Gmail (Google Workspace)

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

Source: knowledge.workspace.google.com

Microsoft 365 (Exchange Online) — NDR code text

550 5.1.1 Bad destination mailbox address

Source: learn.microsoft.com

Yahoo Mail — rejects unknown users with reply code 554

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

Source: senders.yahooinc.com

RFC 3463 — the standard definition every server maps to

550 5.1.1 X.1.1 Bad destination mailbox address — The mailbox specified in the address does not exist. For Internet mail names, this means the address portion to the left of the "@" sign is invalid. This code is only useful for permanent failures.

Source: datatracker.ietf.org

Why you're seeing 550 5.1.1

550 5.1.1 is the receiving server saying it looked up the mailbox (the part of the address left of the @) and found nothing. The connection worked and DNS resolved; the server refused the address at the door because no account matches it. Unlike authentication or reputation bounces, this code says nothing about your sending setup. Read it in one of two directions: if you sent the mail, the address is wrong, stale, or deleted; if people emailing *your* domain are getting it, your MX records or mailbox provisioning are pointing deliveries at a server that doesn't know the account.

Likely causes, ranked

Likely causeWhat's happening
The address has a typoBy far the most common trigger, and the one Gmail's bounce text calls out directly. A misspelled name, a stray space, `j.smith` when the mailbox is `jsmith`, or a guessed address that was never right. The receiving server can't fuzzy-match: one wrong character is a nonexistent mailbox.
The mailbox was deleted or deactivatedThe address used to work: an employee left and IT removed the account, a free-mail account was closed for inactivity, or an alias was retired. Old contact lists and CRMs keep these addresses alive long after the mailbox is gone.
A stale autocomplete or cached entryOutlook's autocomplete cache stores internal identifiers alongside the address. After a mailbox migration those identifiers change, so the cached entry keeps bouncing even though the visible address is correct. Microsoft's own 5.1.1 troubleshooting dedicates a full solution to clearing it.
The recipient forwards to a dead addressThe mailbox you wrote to exists, but a forwarding rule on the recipient's side re-sends your message to an address that doesn't. Tell-tale sign: the address in the NDR isn't the one you typed.
Your own domain's MX records point at the wrong serverIf senders emailing your domain hit `550 5.1.1`, deliveries may be landing on an old mail host, or on a new one where the mailbox was never provisioned. That's common mid-migration, when MX flips before every account and alias is created on the new platform.
Backscatter: you never sent the original messageA spammer forged your address into the From field, their spam bounced, and the useless NDR came to you. If your Sent folder has no matching message, there's nothing to fix and the bounce can be ignored.

How to fix 550 5.1.1

  1. Check the recipient domain's MX records

    Run the domain from the bounced address through the free MX checker below. If the domain has no MX records or they point at a dead or misconfigured host, no address at that domain can receive mail; the problem is bigger than one mailbox. If MX looks healthy, the issue is the address itself.

    Run the check now

    Enter the sending domain and the check runs instantly on the next page. Free, no signup.

  2. Verify the address character by character

    Check the local part for typos and stray spaces, and confirm the address with the recipient out-of-band: phone, chat, their website. Most 5.1.1 bounces end here. 550 is permanent, so nothing re-sends on its own: fix the address and send again.

  3. Delete the stale autocomplete entry and retype the address

    If the address is definitely correct but keeps bouncing, remove the recipient from your mail client's autocomplete suggestions and type the address by hand. Migrated mailboxes leave broken cached entries that fail even when what's on screen looks right.

  4. If senders can't reach your domain, fix MX and provisioning

    Confirm your MX records point at your current mail host (for Exchange Online that's a single record at a host derived from your domain with dots turned into dashes, like contoso-com.mail.protection.outlook.com) and that the bounced mailbox or alias actually exists there. DNS changes can take up to 72 hours to propagate, so recently-flipped records may still serve stale answers.

  5. Remove dead addresses from your lists

    Yahoo's guidance is explicit: don't retry, remove the address. Mailbox providers track unknown-user rates as a list-hygiene signal, and repeatedly hammering dead mailboxes erodes your sender reputation for the addresses that do exist.

  6. If you never sent the message, treat it as backscatter

    Check your Sent folder. No matching message means a spammer forged your From address and you're seeing the reject of their mail, not yours. Ignore the NDR. But if Sent contains messages you didn't write, reset your password and involve your admin.

Related free tools: Email security score

Frequently asked questions

Permanent. Any code starting with 5 is a hard failure: the sending server won't retry, and re-sending the same message to the same address produces the same bounce. Transient problems use codes starting with 4. The only path forward is correcting the address (or the recipient domain fixing its mail setup) and sending again.

Either, but it's about the address, never about your sending reputation or authentication. Most often it's sender-side: a typo or a stale contact entry. Sometimes it's recipient-side: a deleted mailbox, a forwarding rule pointing at a dead address, or MX records aimed at a server that doesn't hold the account.

Three usual suspects: a stale autocomplete entry in your mail client (delete it and retype the address), a forwarding rule on the recipient's side that relays to a dead address (the NDR shows an address you never typed), or the recipient domain's MX pointing at a host where the mailbox was never provisioned. Confirm with the recipient out-of-band and check their domain's MX records.

Your MX records first, then mailbox provisioning. This pattern is common right after a mail migration: MX flips to the new platform before every mailbox and alias is created there, or old MX records linger in DNS caches for up to 72 hours. Run your domain through the MX checker, confirm the records point at your current host, and verify the bounced address exists on it.

A one-off bounce doesn't. A pattern does: mailbox providers read high unknown-user rates as the signature of a bought or badly-maintained mailing list, and score the sending domain and IP accordingly. Prune every 5.1.1 address from your lists the first time it bounces.

Related error codes

550 5.4.1552 5.2.2451 4.3.0550 5.7.1
Email deliverability, fixed: the full guide

Not sure this code is your only problem?

Run a free email security score: every authentication and deliverability gap for your domain, in one pass.