SMTP Error 550

SMTP 550 is a permanent negative completion reply. Per RFC 5321 §4.2.1, any reply beginning with 5 means the command failed and the server will not accept the same message if you simply resend it — retrying unchanged produces the same 550. The canonical text in §4.2.3 is 550 Requested action not taken: mailbox unavailable (the spec lists it for a mailbox that is "not found, no access, or command rejected for policy reasons"). Per §4.3.2, 550 is a valid error reply to RCPT TO, MAIL FROM, and DATA — so the rejection can occur at any of these stages, not only at RCPT.

Because that one code covers several distinct situations, the human-readable text and the enhanced status code (RFC 3463, the class.subject.detail triplet like 5.1.1) after the 550 are what actually tell you the cause. Read those first.

What causes SMTP Error 550?

550 almost always comes from the receiving (recipient) server, not your authentication, and falls into two buckets:

1. The recipient address is bad (addressing — 5.1.x). This is the most frequent cause.

• 550 5.1.1 — bad destination mailbox: the part left of the @ doesn't exist on that domain (typo, deactivated/retired mailbox, stale list). RFC 3463 defines 5.1.1 exactly this way; SendGrid classifies this kind of invalid-address rejection as a hard bounce.
• 550 5.1.10 (Microsoft) / "recipient's email address doesn't exist" — usually the same idea (no such recipient), but Microsoft's own NDR documentation also lists broken inbox/forwarding rules, a missing Exchange Online license, or hybrid directory-sync gaps as additional causes — so it isn't purely an addressing issue.

2. A policy, reputation, or authentication block (security/policy — 5.7.x).

• 550 5.7.1 — delivery not authorized, message refused: blocked by per-recipient or per-host policy, blocklist, or content/spam filtering (RFC 3463 X.7.x).
• 550 5.7.1 ... DMARC policy — Gmail/Yahoo reject unauthenticated mail when your domain publishes a p=reject/p=quarantine DMARC policy and your SPF/DKIM don't align.
• 550 ... Spamhaus / "on our block list" — your sending IP or domain has a poor reputation.
• 550 5.7.1 Relaying denied / "Authentication is required for relay" — here the sending server is refusing to relay because you aren't authenticated to it. This is the relay/auth case the older version of this page emphasized; in practice it's a minority of real-world 550s.

Note: the second digit isn't decoded from the bare 550 itself — 550 is a single reply code. The detail comes from the enhanced code and text the server appends. Don't guess; copy the full line from the bounce.

How do I fix SMTP Error 550?

Work from the enhanced code and message text:

1. Read the full bounce / DSN. Capture the exact line, e.g. 550 5.1.1 <user@example.com> User unknown. The 5.x.x triplet and the prose are your diagnosis.
2. For 5.1.1 / "user unknown" (bad recipient): correct the typo, remove the address from your list, and adopt list hygiene — validate addresses on capture and suppress hard bounces so you stop mailing dead mailboxes. Repeated sends to invalid addresses hurt your reputation.
3. For 5.7.1 DMARC / "unauthenticated email" rejections: authenticate your sending domain. Publish SPF and DKIM records, ensure at least one aligns with your From: domain, and publish a DMARC record. With an ESP (SendGrid, SES, Mailgun, Postmark), complete its domain-authentication / sender-verification flow so DKIM signs with your domain.
4. For reputation / blocklist 550 (Spamhaus, "on our block list"): check your sending IP/domain against the named blocklist, request delisting after fixing the root cause (compromised account, spam complaints, bad list), warm up new IPs gradually, and keep complaint rates low.
5. For relay / "Authentication is required for relay": this one is on your side — configure SMTP AUTH on the client. Provide valid credentials over an authenticated submission port (587 STARTTLS or 465 implicit TLS — both valid per RFC 8314). For Gmail/Google Workspace use an App Password (with 2-Step Verification) or OAuth2 — Google disabled Less Secure Apps for personal Gmail in 2022, while Google Workspace ran a separate, longer phase-out that wasn't fully enforced until 2024–2025. Either way, basic password auth is retired for both.
6. Confirm it's permanent before resending. Because 5xx is permanent (RFC 5321 §4.2.1), resending the identical message to the same recipient just bounces again. Resend only after you've changed the address, the authentication, or the reputation condition.

If you send through Courier, the provider-level error and bounce reason are surfaced on the message in your logs, so you can see whether a given 550 is a 5.1.1 address bounce or a 5.7.1 policy/auth block and route or suppress accordingly.