Will resending fix a 550?

Not without a change. 550 is permanent; the same message from the same server will be rejected again until you fix the cause.

Who has to act on a 550?

Depends on the enhanced code: 5.1.x usually needs a correct address from the recipient, while 5.7.x usually needs the sender to fix authentication or reputation.

SMTP 550: mailbox unavailable or rejected

550Requested action not taken: mailbox unavailablePermanent: retrying will not help

Example

550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in local recipient table

What it means

RFC 5321 defines 550 as "Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)". It is permanent, so the sending server stops trying and returns a bounce to the sender.

Because the definition includes policy, 550 is used for very different problems, and the enhanced code is what separates them. 5.1.1 and 5.1.10 mean the address does not exist. 5.7.1 is a general policy or permission refusal, often spam filtering or a blocklist. 5.7.23 is an SPF failure, 5.7.25 a missing PTR record, 5.7.26 a failed DMARC or unauthenticated message, and Microsoft’s 5.7.606 to 5.7.649 mean a banned sending IP.

Most 550 replies arrive at RCPT TO, refusing one recipient. Some arrive after DATA, when content or authentication checks run. Its temporary counterpart is 450; 554 is the other common permanent rejection, used more for whole transactions and connections.

Likely causes

The recipient address is misspelt, deleted, or never existed (550 5.1.1).
Your IP or domain is on a blocklist the receiver uses (550 5.7.1 with a DNSBL name).
Your message failed SPF, DKIM, or DMARC checks (550 5.7.23, 5.7.26).
Your sending IP lacks reverse DNS or has a generic one (550 5.7.25).
The recipient’s admin blocks your domain or restricts who can send to that mailbox (550 5.7.1, 5.7.133 on Microsoft).

How to fix it

Read the enhanced code and text in the bounce, then open the matching page: address problems start at 5.1.1, policy problems at 5.7.1.
For unknown users, check the spelling and ask the recipient for a current address; do not keep retrying.
For authentication failures, fix your records, for example `v=spf1 include:_spf.example.net -all` and a DKIM key for every sending service, then confirm with a test message.
For blocklists, look up your IP, remove the cause (a compromised account or open form), and request delisting from the list operator.
If you are the recipient’s admin, check your own rules and filters for the sender before telling them to change anything.

Checks that apply

Your domain or sending IP (fills in the checks below)

Blacklist Check Looks up your sending IP and domain on 40 DNSBLs, the first thing to rule out when a 550 mentions policy or spam.
Domain Health Grades your SPF, DKIM, DMARC, MX, and DNS in one pass so you can spot the failing piece behind a 5.7.x rejection.
Email Header Analyzer Reads a delivered or bounced message’s headers to show SPF, DKIM, and DMARC results as the receiver saw them.
MX Lookup Confirms the recipient domain and its mail hosts exist, helping you separate a typo in the domain from a missing mailbox.

FAQ

Will resending fix a 550?: Not without a change. 550 is permanent; the same message from the same server will be rejected again until you fix the cause.
Who has to act on a 550?: Depends on the enhanced code: 5.1.x usually needs a correct address from the recipient, while 5.7.x usually needs the sender to fix authentication or reputation.

All 191 bounce codes