sfw/fix
550 5.1.1 medium

550 5.1.1 User unknown / recipient address does not exist

A hard bounce: the mailbox in the RCPT TO doesn't exist on the receiving server, so delivery permanently fails.

What you see

550 5.1.1 <[email protected]>: Recipient address rejected:
550 5.1.1 User unknown
550 5.1.1 The email account that you tried to reach does not exist.

What’s actually happening

The receiving server checks the recipient address and reports there's no such mailbox. This is a permanent (hard) bounce — retrying sends the same 550 every time. It's specifically about the local-part not existing on a domain that does (compare with 5.7.1, which is a policy block on a valid address, and 5.4.x, which is a routing failure).

Common causes

  • A typo in the address — jhon@ instead of john@, a wrong TLD, or a missing letter
  • The mailbox was deactivated, the employee left, or the account was deleted
  • Stale list data: an address that was valid once but has since been removed
  • A catch-all was turned off, so previously-tolerated addresses now bounce
  • Wrong domain entirely — right person, outdated company domain after a rebrand or migration

How to fix it

  1. Confirm it's truly 5.1.1, not 5.7.1Read the enhanced code in the bounce. 5.1.1 = address doesn't exist (correct it). 5.7.1 = address exists but was policy-blocked (fix auth/reputation). 5.4.x = DNS/routing. Treating a policy block as a bad address wastes effort and vice versa.
  2. Re-check and correct the addressVerify spelling of the local-part and domain against a known-good source — a signature, the company website, LinkedIn. For a likely typo (gmial.com), correct and resend once. For a guess, don't keep firing at variations; that looks like a dictionary attack and hurts reputation.
  3. Remove the address from your list immediatelyHard bounces must be suppressed, not retried. Pull the address out of your sending list/CRM so it never gets mailed again. ESPs auto-suppress hard bounces; if you send from your own server, maintain your own suppression list.
  4. Watch your overall bounce rateA bounce rate above ~2-3% signals stale data to mailbox providers and drags your reputation down — which then causes 5.7.1 policy rejections on your good addresses too. Clean the list at the source.
  5. Verify addresses before bulk sendsRun new or old lists through an email verification service (or SMTP-probe carefully) before a campaign so dead addresses are caught before they bounce against your reputation.

Stop it recurring

Suppress hard bounces permanently and verify lists before bulk sends so dead addresses never accumulate.

Related errors