550 Permanent Failure

A 550 is different from a temporary 4xx bounce like 421 or 450. There is no "try later" here: the receiving server rejected the message on purpose, and resending the exact same email to the exact same address usually just produces another hard bounce. The good news is that 550s are readable once you know where to look. The 550 code itself only tells you the category. The real answer sits in two parts of the bounce: the enhanced status code (5.x.y, for example 5.1.1 versus 5.7.1) and the server's plain-text explanation ("user unknown," "relay denied," "blocked," "policy").

Below is a table of the variants you will actually see in a bounce log, followed by a fix playbook for each cause. If you already have the exact code, jump straight to fix 5.1.1 or fix 5.7.1, the two buckets that cover most outbound sending.

What are the common 550 permanent failure variants?

Most 550 bounces fall into a handful of buckets. Match the exact wording in your bounce to the row below to find the cause fast.

In outbound sending, the two buckets that matter most are 5.1.1 (list quality) and 5.7.1 (sender trust). That's why teams pair strict pre-send verification, which reduces unknown-user bounces, with authentication checks and reputation monitoring, which reduce policy blocks. Overloop's built-in email verification and bounce tracking show you which bucket you're in before a campaign burns your domain.

How do you read the bounce message and find the real cause?

A "550 permanent failure" becomes obvious once you isolate two fields: the enhanced status code (5.x.y) and the receiver's free-text explanation. The 550 is the SMTP reply code. The 5.x.y is the reason class, and it points straight to the fix. SMTP enhanced status codes are defined in RFC 3463, but the practical mapping below is what outbound teams actually use.

Use this quick extraction process on any bounce log, whether it came from Google Workspace, Microsoft 365, Postfix, SendGrid, Amazon SES, or Mailgun:

1. Find the enhanced status code. Look for a pattern like 5.1.1, 5.2.1, or 5.7.1, usually next to "Diagnostic-Code:" or "Status:".
2. Copy the receiver's exact text. Phrases like "user unknown", "mailbox disabled", "blocked", "SPF fail", "DMARC policy" carry the real clue.
3. Identify who has to change something. 5.1.x usually means the address is wrong on your end. 5.7.x usually means your sending identity or infrastructure triggered a policy.
4. Match the code to a playbook. Fix list quality for 5.1.1, fix authentication and reputation for 5.7.1, and wait on mailbox capacity for 5.2.x.

If your bounce report includes the original message headers, check the Authentication-Results header for "spf=pass/fail", "dkim=pass/fail", and "dmarc=pass/fail". That single line usually explains a 5.7.1 faster than guessing.

How do you fix 550 5.1.1 (recipient address doesn't exist)?

A 5.1.1 code means the receiver cannot map the local part of the address (everything before the @) to a real mailbox. This is the cleanest 550 to fix because it is almost always a data problem, not a deliverability one.

1. Copy the exact address from the bounce. Do not trust your CRM field. In Gmail and Microsoft 365 bounces, the failed address usually appears next to "Final-Recipient" or "Original-Recipient". One wrong character is enough to trigger 5.1.1.
2. Fix obvious formatting errors. Remove trailing punctuation, double dots, stray spaces, and pasted display names like "Jane Doe <jane@company.com>". Confirm you did not send to a placeholder such as "info@" or a literal "{email}" token.
3. Check for a wrong alias pattern. Many companies use first.last, firstinitiallast, or first only. If your list source guessed the pattern, validate it against a second source, such as a LinkedIn profile or a company press release, before you trust it.
4. Confirm the domain can receive mail. A misspelled or parked domain can still produce 5.1.1-style wording. Look up MX records with a DNS tool such as MXToolbox. No MX record, or one pointing nowhere, means it's a domain issue, not a mailbox issue.
5. Verify the mailbox before you resend. Run the address through an email verification service that checks syntax, domain, and SMTP-level validity. If verification returns "invalid" or "unknown," do not retry it from the same campaign.
6. Stop the repeat at the source. Block sends to unverified addresses, suppress every contact that hard-bounced with 5.1.1, and require a second data source for any guessed address. Overloop's built-in email verification catches this before launch, not after the bounce.

How do you fix 550 5.7.1 (blocked by policy, spam, or authentication)?

When the mailbox exists but the receiver still refuses your message, 550 5.7.1 usually means the receiving server does not trust your sender identity. You fix this by aligning authentication (SPF, DKIM, DMARC) and removing infrastructure red flags such as missing reverse DNS or a bad HELO/EHLO name.

1. Confirm what failed in the headers. Open the bounce or the original message headers and find Authentication-Results. Look for "spf=fail/softfail", "dkim=fail", or "dmarc=fail". Google Workspace and Microsoft 365 message trace tools typically surface the same signals.
2. Fix SPF. Publish one SPF TXT record for the domain in RFC 7208 format, including every legitimate sender (Google Workspace, Microsoft 365, SendGrid, Amazon SES, Mailgun, and so on). Remove duplicate SPF records and keep your DNS lookups under the SPF limit of 10.
3. Fix DKIM. Enable DKIM signing in your sending system and publish the DKIM public key in DNS for the selector it uses. Send a test email and confirm "dkim=pass" in Authentication-Results.
4. Fix DMARC alignment. Publish a DMARC TXT record at _dmarc.yourdomain per RFC 7489, so at least one of SPF or DKIM aligns with the visible From domain. Start with p=none to monitor, then move to quarantine or reject once DMARC reports show consistent passes.

Receivers often fold infrastructure checks into 5.7.1 even when your content looks fine. The usual suspects: a missing PTR record (your sending IP should reverse-resolve to a hostname that resolves back to the same IP), a bad HELO/EHLO name such as "localhost", domain or IP reputation damage from high bounce rates or sudden volume spikes, and forwarding rules on the recipient side that break SPF alignment.

How do you fix a 550 caused by a blocklist or reputation hit?

When your list is clean and 550s keep coming, you're usually dealing with reputation: the receiving system doesn't trust your sending domain or IP. Many of these bounces still show 550 5.7.1, but the text hints at "blocked," "reputation," "listed," or names a specific filter. Treat a blocklist as a symptom. Rush to delist while you keep sending the same traffic, and you often get relisted within days.

1. Pause risky sends for 24 to 72 hours. Stop cold sequences and new list uploads; keep only essential 1:1 mail. This prevents more negative signals while you diagnose.
2. Confirm what's listed and where. Check your sending IP and domain against a tool such as MXToolbox Blacklist Check. If you send through a shared IP pool, delisting "your" IP may not even be possible.
3. Cut your list harder than feels reasonable. Suppress every hard bounce, every role address you don't need (info@, sales@), and any "unknown" verifier result. Segment out catch-all domains.
4. Send to the best-engaged segment first. Start with recipients who replied recently or read your mail regularly. Keep cold outreach off until metrics stabilize.
5. Throttle volume and smooth spikes. Reputation systems react badly to step changes. Increase daily volume gradually and keep send times consistent.
6. Fix the root cause before you request delisting. If the bounce text references authentication, correct SPF, DKIM, DMARC, rDNS, and HELO/EHLO first. A clean delist request doesn't compensate for a broken sending identity.
7. Request delisting last, and document what changed. Include the remediation steps and dates. For Spamhaus specifically, follow the official process at Spamhaus Lookup.

Watch your bounce logs as you ramp back up. A falling 5.7.1 rate and fewer "listed" messages mean the receiver's trust score is recovering. If blocks persist after cleanup, look at content patterns (links, tracking domains) and infrastructure (shared IP reputation, a misconfigured relay).

How do you fix a 550 error on Gmail, Outlook, or Yahoo?

The fixes above apply everywhere, but each major mailbox provider shows its own bounce wording and gives you a different tool to check reputation and authentication. Match your exact provider below before you resend.

Gmail and Google Workspace

Gmail's standard text for a nonexistent address is 550 5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. A policy or spam block on Gmail typically reads 550 5.7.1 Our system has detected that this message is likely unsolicited mail. Check domain and IP reputation, spam rate, and authentication status in Google Postmaster Tools. If you send 5,000 or more messages a day to Gmail addresses, also confirm you meet Google's bulk sender requirements: valid SPF, DKIM, and DMARC, plus a spam rate under 0.3% in Postmaster Tools.

Outlook and Microsoft 365

Microsoft's nonexistent-mailbox bounce usually reads 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup. Reputation and policy blocks on Outlook.com and Microsoft 365 commonly show 550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider. Look up your sending IP's complaint and reputation data in Smart Network Data Services (SNDS), and use the Exchange admin center's message trace if you also manage the receiving mailbox. If the block persists after you fix authentication, Microsoft's sender support form is where you request a review.

Yahoo and AOL

Yahoo and AOL, which share the same mail infrastructure, commonly reject with 554 5.7.9 Message not accepted for policy reasons, which points to their deliverability portal, or with 550 5.1.1 <address> Address rejected for a mailbox that does not exist. Check authentication guidance and sender reputation status at Yahoo's sender hub. Yahoo and AOL blocks are more often reputation-driven than a single bad address, so register for their Complaint Feedback Loop once you send any real volume.

How do you prevent 550 errors before you send?

Cold outreach breaks when you scale volume faster than you scale trust. The goal is simple: keep daily output high while keeping permanent failures, both 5.1.1 hard bounces and 5.7.1 policy blocks, low.

• Verify before you send. Run pre-send verification (syntax, domain, mailbox checks) and suppress "invalid" results. Any address that already produced a 5.1.1 goes to a permanent suppression list. Overloop verifies emails inside the outbound workflow, so bad addresses never enter a sequence.
• Warm up by mailbox, not by campaign. Ramp each inbox gradually with low daily volume, then increase in small steps while watching hard bounces and 5.7.1 blocks. Treat a new domain or a new mailbox as a fresh sender identity. See our email warmup guide for the ramp schedule.
• Throttle by recipient domain. Gmail, Microsoft, and corporate gateways react differently. Cap sends per domain per day and spread volume across more inboxes to avoid the sudden-spike pattern that triggers policy rejections.
• Keep list hygiene running daily. Remove hard bounces, mark "mailbox full" as retry-later, and suppress role addresses that produce policy blocks. For the other four bounce categories that don't start with 550, see our guide to 7 reasons emails bounce.
• Track by sending domain, not just by campaign. Sustained policy blocks are a sender reputation problem more than a single-email problem. Our sender reputation guide covers how to check and repair the score that sits behind every 5.7.1.

As of 2026, Google's bulk sender guidelines, in force since February 2024, require senders of 5,000+ daily messages to a Gmail address to keep spam complaints under 0.3% as measured in Google Postmaster Tools, on top of valid SPF, DKIM, and DMARC. Crossing that threshold is one of the more common, entirely preventable causes of a fresh wave of 5.7.1 bounces.