SMTP 550 error explained and how to fix it

An SMTP 550 error is a hard bounce. The receiving mail server rejected your message and refused delivery. The most common cause is a mailbox that does not exist, but 550 also covers blocked senders, policy rejections, and blocklisted IPs. Read the text after the code to know which.

What does an SMTP 550 error actually mean?

A 550 is a permanent negative reply in the SMTP protocol. The 5 means permanent failure, so retrying the exact same send will not help. The server decided your message cannot be delivered to that recipient. The specific reason sits in the human-readable text that follows the three digits.

Every SMTP reply starts with a three-digit code, and the first digit is the class. Codes in the 2xx range mean success. The 4xx range means a temporary problem worth retrying. The 5xx range means permanent rejection. A 550 is the workhorse of that 5xx range. It is the code most mailbox providers return when they refuse a message outright. Because 550 covers so many situations, the text string beside it is where the real diagnosis lives.

There is a practical reason this matters. A 4xx soft bounce will often clear on its own when your mail server retries over the next day or two. A 550 will not. Retrying the same message to the same address after a hard 550 just tells the receiving server you are not maintaining your list. Do that enough and providers start throttling or blocking you outright.

The most common 550 reject codes

Not all 550s are equal. Some point at the recipient, some at your sending reputation, and some at content or policy. Here is how the frequent variants map to a verification verdict and the action that actually clears them.

The pattern is consistent. When the text describes the recipient, the address is the problem, and verification labels it Invalid. When the text describes your server, your IP, or a policy, the address may be perfectly good, and no amount of list cleaning fixes it.

One more nuance. A single 550 from one recipient is noise. A pattern of 550s across many recipients at the same provider is a signal. If Gmail or Outlook starts returning 550 policy rejections across your whole send, the recipients are fine and your reputation is the problem. Segment your bounces by domain and by reason code so you can tell the two apart quickly.

How do you fix an SMTP 550 error?

First read the text after the digits. If it names the mailbox (user unknown, no such user), the address is dead, so remove it. If it names your IP, domain, or policy, the problem is your sending setup, not the recipient. Fix authentication and reputation, then resend to valid contacts only.

1. Open the bounce message and copy the full 550 line, including the enhanced status code like 5.1.1 or 5.7.1.
2. Decide who owns the problem. Recipient-side codes like user unknown mean the address is bad. Sender-side codes like relaying denied or blocked mean your infrastructure is the issue.
3. For bad addresses, suppress them immediately so they never receive another send. Repeated hits to dead mailboxes damage your sender reputation.
4. For sender-side rejects, confirm SPF, DKIM, and DMARC all pass, then check your IP and domain against the major blocklists.
5. Re-verify the rest of the list before the next campaign so you are not guessing which addresses will bounce next.

Clean data is the fix that scales. Run every new list through the Free Email Verifier before the first send, then suppress the invalids for good. If you would rather hand list building and hygiene to a team, Synthisia runs done-for-you lead generation and meeting booking on verified data.

550 vs 5.1.1 vs 5.7.1: reading the enhanced status code

Modern servers pair the blunt 550 with a three-part enhanced status code defined in RFC 3463. The pattern is class.subject.detail. A leading 5 confirms permanent failure. The middle and last numbers narrow the cause. 5.1.1 points at a bad mailbox. 5.1.2 flags a bad domain. 5.7.1 means the message was refused for policy or authentication reasons. Reading these two numbers together tells you whether to scrub the address or fix your own house.

Here is a quick read. A bounce that says 550 5.1.1 is telling you the local part is wrong and the inbox is gone. A bounce that says 550 5.7.1 is telling you the server saw your message and chose to reject it, usually over SPF, DKIM, DMARC alignment, or a blocklist hit. The first is a list problem. The second is a deliverability problem. They live in different teams and need different fixes.

How do you stop 550 errors before you send?

Verify addresses before they enter a campaign. Most 5.1.1 user-unknown bounces are predictable. An MX and SMTP-level check finds dead mailboxes, catch-all domains, and role accounts in advance. Clean the list, suppress the invalids, and your bounce rate stays under 2%, which protects the sender reputation that prevents policy-based 550s.

This is the cheapest insurance in email. Run a new list through the free Free Email Verifier before you import it. Paste the addresses or drop a CSV, and the file is parsed in your browser, so nothing gets uploaded. A local scan strips obvious junk and duplicates without touching your quota, then the remaining addresses get MX-record and SMTP-level mailbox checks. You get Deliverable, Risky, Invalid, and Unknown verdicts, plus typo suggestions for fixable addresses. Export the clean set and send only to those.

When a 550 is really a catch-all or a reputation signal

Some domains accept every address at the SMTP handshake, then bounce the bad ones hours later with a 550. These catch-all servers are why a message can pass a live check and still fail. Treat catch-all and Unknown results as their own risk tier. Send to them slowly, watch for delayed bounces, and suppress anything that returns a hard 550. On the sending side, a rising 550 rate that is not about missing mailboxes usually means reputation. Check your authentication, your complaint rate, and the blocklists before you blame the recipients.

Read the code, assign ownership, scrub or fix, and re-verify before the next send. That loop turns 550 errors from a recurring headache into a rare event. Verification handles the recipient side, and steady authentication and reputation work handles yours. Keep both tight and hard bounces stay where they belong, close to zero.