SMTP 550 Error Fix Guide: Diagnosing and Resolving Every 550 Variant

SMTP error 550 is not a single error — it's a family of permanent rejection codes that each point to a different underlying problem. Treating them all the same way (suppressing the address, tweaking content, or waiting it out) will resolve some cases and make others worse. This guide provides the diagnostic decision tree for each major 550 variant so you can identify what's actually happening and take the right remediation action.

Understanding 550 Codes: The Three-Digit Structure

Every SMTP response code is three digits. The first digit tells you the category: 5xx codes are permanent failures — the receiving server is definitively rejecting the message and will not accept a retry without a change. The second and third digits, and the extended status code (the X.Y.Z format that follows), tell you why.

The critical operational distinction: a 5xx response means the receiving server has made a permanent decision about this message or this sender. Retrying without changing something will produce the same rejection. Unlike 4xx codes (temporary failures where retry is appropriate), 5xx codes require investigation and remediation before any retry attempt.

The Most Common 550 Error Variants and Their Root Causes

550 5.1.1 — User Unknown / Address Does Not Exist

This is a list quality problem, not a sending problem. The address you're sending to doesn't exist at the recipient domain. The receiving server checked its recipient database and found no such user.

>> MAIL FROM:<bounce@esp-provider.net>
<< 250 OK
>> RCPT TO:<user@gmail.com>
<< 250 OK
>> DATA
<< 550-5.7.26 This message does not have authentication information or fails
   to pass authentication checks. To best protect our users from spam,
   the message has been blocked.
   z15-20020aa7957f000000b006b91c22e985si9837215pfk.8 - gsmtp

# Root cause: DKIM passes for esp-provider.net, not your domain.
# From: header shows noreply@yourcompany.com => DMARC alignment fails.
# Fix: generate DKIM selector on yourcompany.com, configure in ESP.

Diagnostic question: Is this one address or many? A single 5.1.1 is normal list churn (someone left a company, changed their email, or the address was entered with a typo). A campaign generating 5.1.1 rates above 2% indicates systematic list quality problems.

Root causes for high 5.1.1 rates:

• List was purchased or scraped rather than organically collected
• List hasn't been verified or cleaned in an extended period
• B2B list where a significant portion of contacts have left their companies
• Signup form accepts any input without real-time email validation

Remediation: Immediately and permanently suppress the bounced address. For campaign-level 5.1.1 rates above 2%, run the affected list segment through a bulk verification service before the next send. Implement real-time email validation at point of capture to prevent recurrence.

550 5.7.1 — Policy or Reputation Block

This is the most commonly misdiagnosed 550 error because it has multiple distinct causes that require completely different responses. The 5.7.1 code indicates a policy-level rejection — but the policy could be triggered by your IP reputation, your domain reputation, authentication failures, or the recipient organization's specific rules.

The error message string is your diagnostic tool. Read it carefully:

• "Our system has detected an unusual rate of unsolicited mail" (Gmail 5.7.1) — IP reputation block at Gmail. Your IP has accumulated enough negative signals that Gmail is rejecting connections from it. Check Gmail Postmaster Tools Compliance Status and Spam Rate immediately.
• "High Probability of Spam" — Content filtering. Your message triggered spam scoring. Review content for spam trigger words, excessive links, image-heavy HTML, or suspicious URL domains in your tracking or content links.
• "Client host [x.x.x.x] blocked using [blocklist]" — IP is on a referenced DNSBL. Identify which list and follow the delisting process for that specific list.
• "550 5.7.26 This message does not have authentication information" (Gmail) — DMARC failure. Your SPF or DKIM alignment is failing, and your DMARC policy is set to reject. Fix alignment first.
• "550 5.7.515 Access denied, sending domain does not meet the required authentication level" (Microsoft) — Your domain doesn't meet Microsoft's bulk sender authentication requirements. SPF, DKIM, or DMARC is missing or misaligned.
• "Relaying denied" — The receiving server won't accept delivery to the specified address from your server. This may indicate either an unauthorized relay attempt or a corporate email gateway policy blocking your domain.

Diagnostic sequence for 550 5.7.1:

1. Read the exact error message string — don't just log the 5.7.1 code
2. Is the rejection at Gmail, Outlook, Yahoo, or a corporate domain? Each has different interpretation
3. Is this a single recipient or widespread across multiple recipients at the same ISP? Widespread = reputation/authentication issue, not individual recipient policy
4. Check blacklists for the sending IP
5. Check Gmail Postmaster Tools if rejections are at Gmail
6. Verify SPF, DKIM, and DMARC are all passing and aligned

550 5.7.26 / 5.7.23 — DMARC / SPF Authentication Failure

These codes indicate that your DMARC policy (p=quarantine or p=reject) is causing rejection because the message failed authentication checks.

550-5.7.26: DMARC policy failure. The message failed DMARC alignment — either SPF alignment failed AND DKIM alignment failed, and your DMARC policy says to quarantine or reject the message.

550-5.7.23: SPF validation failure specifically — the sending IP isn't authorized in your SPF record.

These errors look like they're affecting the recipient, but they're actually caused by your own authentication configuration. The fix is to your DNS records, not to the message content.

Diagnostic steps:

1. Check your DMARC aggregate reports (rua address) for the affected time period. Which sending sources are generating failures?
2. Send a test message from the same sending infrastructure and inspect the Authentication-Results header. Look for dmarc=fail or spf=fail.
3. For SPF failures: run dig TXT yourdomain.com and verify all sending IPs are in the SPF record. Check for lookup count overflow (above 10 lookups = PermError).
4. For DMARC alignment failures: check whether the DKIM signing domain matches your From domain, and whether the Return-Path/envelope-from domain aligns with your From domain.

550 5.7.515 / 5.7.606 — Microsoft Authentication and Blocklist Errors

Microsoft introduced several specific error codes in 2025 that correspond to their new bulk sender requirements and their internal blocklists:

550 5.7.515 Access denied, sending domain [Domain] does not meet the required authentication level — Your domain doesn't meet Microsoft's bulk sender requirements (SPF, DKIM, DMARC for senders above 5,000 emails/day to Outlook/Hotmail/Live addresses). This requirement took effect May 5, 2025. Fix: implement all three authentication protocols with proper alignment.

550 5.7.606 Access denied, banned sending IP — Your IP is on Microsoft's internal blocklist. This is distinct from third-party DNSBLs and requires a delist request through Microsoft's Sender Intelligence Portal (sendersupport.olc.protection.outlook.com).

550 5.7.1 Service unavailable, Client host [x.x.x.x] blocked using Customer Block List AS(XXXX) — IP is on Microsoft's Customer Block List. Submit delist request at sender.office.com.

550 5.2.1 — Mailbox Disabled or Not Accepting Messages

The recipient mailbox exists in DNS (the domain resolves to valid MX records) but the specific mailbox account is disabled, over quota and permanently unavailable, or configured to not accept external email. Unlike 5.1.1 (address doesn't exist), 5.2.1 indicates the mailbox exists but isn't functional. Suppress permanently — repeated attempts won't resolve the issue.

How to Triage When You See Mass 550 Rejections

A sudden increase in 550 errors — a campaign generating 5–10% rejection rates when your previous campaigns generated under 0.5% — is an incident requiring immediate triage before the next send.

First five minutes:

1. Pull a sample of 20–30 rejection message strings from your MTA logs. Do they all say the same thing or are there multiple different error messages?
2. Are the rejections concentrated at one ISP (all from Gmail, or all from Outlook) or spread across multiple ISPs?
3. Check MXToolbox Blacklist Checker for the sending IP immediately
4. Check Gmail Postmaster Tools Compliance Status and Spam Rate

If concentrated at Gmail with reputation messages: IP reputation incident. Check for Spamhaus listings. Pause sends to Gmail while investigating. Review recent complaint rate data in Postmaster Tools.

If concentrated at Outlook with 5.7.515: Authentication compliance failure. Implement or fix SPF/DKIM/DMARC alignment before any further sends to Microsoft addresses.

If 5.1.1 bounce rate is suddenly high: List quality incident. Identify which list segment or import caused the spike. Pause that segment immediately. Run verification before proceeding.

If rejections are widespread across multiple ISPs with similar content-filtering language: Content problem. The message body triggered spam filters broadly. Identify which element (specific phrase, URL, image-to-text ratio) is causing the filtering.

The 550 Errors You Should Never Just Suppress and Move On

For 5.1.1 and 5.2.1 errors, suppressing the address and moving on is correct. For 5.7.x errors, suppressing without root-cause investigation is wrong and will produce more 5.7.x errors on your next send — because the problem isn't the address, it's your sending reputation, authentication, or content.

The 550 error categories that require full investigation before the next send:

• Any 5.7.1 error with a reputation message — investigate and resolve the reputation issue first
• Any 5.7.26 or 5.7.23 (authentication failure) — fix authentication before any further sends
• Any 5.7.515 (Microsoft authentication requirement) — you cannot send to Microsoft addresses until this is resolved
• Mass 550 errors appearing suddenly across multiple ISPs — stop sending and diagnose the root cause before continuing

Last updated: March 30, 2026