SMTP error codes for bulk senders 2026: complete decision tree, MTA retry comparison, interactive diagnostic tool, and the post-November 2025 enforcement codes that decide your inbox placement

SMTP error codes in 2026 carry more operational weight than they did in 2022. Gmail’s November 2025 enforcement, Microsoft’s May 2025 DMARC requirement, Yahoo’s bulk sender enforcement — all three major receivers now return specific error codes that escalate from temporary warnings to permanent rejects within hours if the operator doesn’t react. Reading the codes correctly is the difference between fixing an issue in 1 day and recovering from reputation damage for 8 weeks.

This post is the operator-grade reference: complete decision tree as visual SVG with time-to-resolution per code, MTA retry behavior comparison across the 4 mainstream MTAs, an interactive diagnostic tool calibrated against 5 dimensions, the post-November 2025 enforcement codes from Gmail/Microsoft/Yahoo, complete bounce processing code that actually works, common production mistakes we see in audits, and the monitoring patterns that catch issues before they become visible.

Decision tree — complete flow of what to do per code

The full decision tree from receiving an SMTP response to executing the correct action, with time-to-resolution per error type:

Four critical observations from the decision tree. First, the divergence between 4xx and 5xx is categorical — 4xx requires no immediate action because the MTA retries automatically, 5xx requires immediate investigation. Second, enhanced codes are where the diagnostic information lives — a basic 550 without enhanced code is practically useless for debugging. Third, time-to-resolution scales 600x between the simplest error (5.1.1 suppress immediate, seconds) and the most severe (5.7.27 domain reputation, 4-12 weeks) — reading codes correctly is the difference between a 1-day fix and 2 months of recovery. Fourth, Gmail’s 4.7.26 warning is exceptionally time-sensitive — Gmail gives 24-72 hours to fix it before escalating to 550, a window during which you have the opportunity to resolve it without permanent damage.

MTA retry behavior comparison — chart with real intervals

Each MTA has its own default retry logic. The intervals during the 72 hours that typically constitute the effective retry window:

Three critical observations from the retry comparison. First, PowerMTA has the most conservative intervals (5 min → 30 min → 2 h → 8 h → 24 h) which minimize aggressive retries that can compound rate limiting issues. It is deliberate — designed for bulk senders where aggressive retry compounds problems. Second, KumoMTA uses aggressive exponential backoff (doubling each time) which is better for receivers that recover quickly from transient problems, but worse for greylisting scenarios where the receiver demands a longer wait. Third, Postal uses linear retry (every 30 minutes constant) which is predictable but suboptimal vs adaptive strategies. Which is best depends on the use case — high-volume bulk to multiple receivers favors PowerMTA’s conservative posture, transactional with time-sensitive delivery favors KumoMTA’s aggressive recovery.

Decision tool — what to do with your specific SMTP error

Rather than reading generic prescriptions, use the decision tool calibrated against five dimensions that returns a specific action plan:

The bounce log is the canonical truth about your sending program. Every other tool — Postmaster Tools, seed list testing, complaint feedback loops — gives you indirect or aggregated information. The SMTP error codes returned by receiving servers are the ground truth, and reading them correctly is the difference between fixing the right problem in 20 minutes and chasing the wrong problem for a week.

This post is the catalog of SMTP error codes that bulk senders actually encounter in 2026, organised by category. For each code we cover the standard format, what it actually means at the protocol level, the underlying cause that produces it, the fix path, and how the four production MTAs (PowerMTA, KumoMTA, Postal, Halon) handle the code in their default configurations. It is written for operators who have a bounce log open and need to figure out what to do.

SMTP error code structure 101

Before the codes themselves, a quick refresher on how to read them. SMTP error codes follow the format XYZ A.B.C [text] where:

• XYZ is the basic 3-digit code (4xx = temporary, 5xx = permanent)
• A.B.C is the enhanced status code (RFC 3463), giving more granular categorisation
• [text] is the human-readable explanation, which varies wildly by ISP

The enhanced status code is what actually tells you the cause. 421 4.7.0 and 421 4.7.28 look similar but mean different things. The first digit of A.B.C indicates persistence (4 temporary, 5 permanent), the second indicates category (1 = address, 2 = mailbox, 3 = mail system, 4 = network, 5 = mail delivery protocol, 6 = message content, 7 = security/policy), and the third is a specific sub-code within the category.

For bulk senders, the codes that matter cluster in 4.7.x (temporary security/policy) and 5.7.x (permanent security/policy). The other categories matter for transactional senders (5.1.1 invalid recipient, etc.) but the deliverability decisions live in the 7.x category.

Temporary deferrals (4xx codes)

Temporary errors mean retry is appropriate. The receiving server is signalling “not now, try again”. A correctly-configured MTA will retry these with exponential backoff for hours or days before declaring a final failure.

421 4.7.0 — Generic deferral, security or policy concern

Format examples:

• 421 4.7.0 Our system has detected an unusual rate of unsolicited mail originating from your IP address (Gmail)
• 421 4.7.0 [TSS04] Messages from 0.0.0.0 temporarily deferred due to unexpected volume or user complaints (Yahoo)
• 421 4.7.0 Try again later, closing connection (generic)

What it means: the receiving server is currently unwilling to accept your mail for security or policy reasons. The reason may be reputation-based, rate-based, or content-based.

Underlying causes:

1. IP or domain reputation has degraded enough that Gmail is throttling but not yet rejecting
2. Sudden volume spike triggered abuse detection
3. Authentication failure that the server is treating as suspicious rather than rejecting outright
4. TLS negotiation failure (421 4.7.0 TLS required for RCPT domain variant)
5. Generic server overload (rare from major ISPs but happens during incidents)

Fix path: identify which of the five causes applies. If reputation: address the reputation issue (warmup, list cleanup, content review). If volume spike: throttle per-ISP. If TLS: verify your MTA negotiates TLS correctly. Distinguish Gmail’s reputation 4.7.0 from Yahoo’s 4.7.0 from generic 4.7.0 — the fix is different for each.

Per-MTA handling:

• PowerMTA classifies as 4xx, retries with backoff. Configurable per-domain via <domain>...</domain> blocks
• KumoMTA native classification, retries with retry_interval set in Lua. Can implement per-domain custom logic
• Postal retries with default schedule; admin UI shows the deferral
• Halon classifies and retries; HSL can implement custom retry-policy per domain

421 4.7.28 — Bulk sender requirement violation (Gmail)

Format example: 421 4.7.28 [IP] Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily blocked.

What it means: the bulk-sender-specific deferral that Gmail introduced in November 2023 ahead of the February 2024 enforcement deadline. Indicates that your sending pattern triggered the bulk sender threshold (5,000+ messages/day to Gmail addresses) and you are not meeting the requirements.

Underlying causes (any of):

1. SPF or DKIM failing alignment
2. DMARC policy missing or p=none when receiver expected p=quarantine+ for bulk senders
3. Spam complaint rate above 0.1% threshold
4. One-click unsubscribe header missing on promotional mail
5. Compliance Status in Postmaster Tools v2 showing Fail

Fix path: check Postmaster Tools v2 Compliance Status. The failure reasons listed there are the diagnostic. Most often it is alignment (third-party sender breaking DMARC alignment) or the spam rate threshold being crossed.

2026 escalation: since November 2025, repeated 421 4.7.28 responses convert to 550 5.7.x permanent rejections after a small number of retries. Treating it as “just a deferral” stopped being accurate that month.

Per-MTA handling: All four MTAs classify as 4xx and retry. None of them fix the underlying compliance issue — that is operator work.

421 4.7.1 — Excessive volume to recipient domain

Format example: 421 4.7.1 Messages to [email protected] deferred due to excessive volume. Try again later.

What it means: volume-based throttling on the receiving side. Different from 4.7.0/4.7.28 — this is the receiver protecting itself from your volume rate, not flagging your reputation.

Underlying cause: you are sending too fast. Gmail expects bulk senders to spread sends across hours, not minutes. Sending a million messages to Gmail in a 30-minute window will produce this code en masse.

Fix path: distribute the send across more time. Per-ISP throttling is the structural fix. iCloud has its own variant of this code that triggers at lower volumes than Gmail.

Per-MTA handling:

• PowerMTA has max-msg-rate and max-smtp-out per domain/VMTA. Set conservative defaults for Gmail (500/hour/IP is a reasonable baseline)
• KumoMTA uses max_message_rate in Lua. Can be set per-domain dynamically
• Postal has rate limiting per server and per organisation
• Halon uses HSL throttling primitives. Most flexible per-domain

421 4.7.7 — Unsigned message (rare but happens)

What it means: receiver expected a DKIM signature and did not find one. Some Microsoft and corporate gateways enforce this strictly.

Fix path: ensure DKIM signing is enabled and the signature is valid. Verify the d= domain matches the From domain.

421 4.4.1 — Connection refused

What it means: your MTA could not establish a connection to the receiving server. Network-level issue rather than policy.

Underlying causes: firewall blocking, your IP listed in receiver’s connection-level blacklist (UCEPROTECT, sometimes Spamhaus DROP), receiver maintenance, DNS failure preventing MX lookup.

Fix path: check whether your IP is in any connection-level blacklists. Verify outbound port 25 is not blocked from your sending host. Test connectivity manually with telnet receiver.com 25.

Permanent rejections (5xx codes)

Permanent errors mean the message is dead. Retry will not succeed. The bounce should be processed and the recipient suppressed (for delivery failures) or the sending behaviour fixed (for policy failures).

550 5.7.1 — Domain reputation low / message rejected

Format example: 550 5.7.1 Our system has detected that this message is suspicious due to the very low reputation of the sending domain.

What it means: Gmail’s filter has classified your domain reputation as too low to deliver from. This is the rejection that follows accumulated 4.7.x deferrals when reputation does not recover.

Underlying cause: sustained negative engagement signals. Spam complaints, hard bounces, low engagement, history of 4.7.x deferrals not corrected. The receiver decided to stop accepting from you.

Fix path: this is the recovery scenario, not a quick fix. Standard warmup does not work because the domain reputation needs to be rebuilt through structured engagement-core sending. We cover the path back in our Gmail domain reputation recovery guide.

Per-MTA handling: all four MTAs treat as final failure (5xx). The bounce should be logged and the recipient should not be retried. The cause is upstream of the MTA.

550 5.7.26 — Authentication failure (DMARC alignment)

Format example: 550 5.7.26 This message does not pass authentication checks (SPF and DKIM both do not pass).

What it means: the message did not pass DMARC alignment, and the policy says reject. This is the most diagnostically useful 5xx because the cause is unambiguous — your authentication is broken.

Underlying causes:

1. SPF passing but the IP is not in the SPF record (record needs updating)
2. DKIM signature missing or signed by a domain that does not align with From
3. SPF including a chain that exceeds 10 DNS lookups (causes SPF to fail with PermError)
4. DMARC policy is p=reject and a third-party sender is breaking alignment

Fix path: systematic verification. Run an SPF lookup count check. Verify DKIM signature is present in headers. Check DMARC policy and alignment mode. Use the free deliverability checker to validate the public DNS state matches your intent.

Per-MTA handling: all four MTAs return the rejection to the sender. None of them fix the alignment — that is DNS work and configuration work upstream of the MTA.

550 5.7.515 — Microsoft DMARC enforcement

Format example: 550 5.7.515 Access denied, sending domain [domain] does not pass DMARC verification and has a DMARC policy of reject.

What it means: Microsoft’s equivalent of 550 5.7.26. Started appearing in volume around May 5, 2025 when Microsoft activated DMARC-based filtering for Outlook.com and Microsoft 365 consumer accounts.

Microsoft-specific note: Microsoft tends to be more aggressive about strict alignment than Gmail. A DMARC record with aspf=s or adkim=s (strict alignment) will fail Microsoft for any subdomain mismatch where Gmail might pass with relaxed alignment.

Fix path: same as 5.7.26. If you see this code only at Microsoft, check whether your DMARC has strict alignment configured. Loosening to aspf=r or adkim=r (relaxed) often resolves Microsoft-only failures.

550 5.7.1 — Message rejected by content filter (different sub-context)

Format example: 550 5.7.1 Message rejected because it contains content typical of spam.

What it means: content filter (SpamAssassin, Proofpoint, Barracuda) rejected the message based on content scoring. Same code as the reputation rejection above but different cause — read the text carefully.

Fix path: content review. Subject line keywords, link domains in the message body, image-to-text ratio, attachment types. This is editorial work, not infrastructure work.

550 5.4.300 — Message timed out

What it means: Microsoft-specific code indicating the message was queued too long without successful delivery. Often a chain symptom of repeated 4xx deferrals that hit the queue maximum age.

Fix path: identify the underlying 4xx deferral pattern that prevented delivery. Address that cause; the timeout will stop happening.

550 5.1.1 — Recipient address does not exist

What it means: the recipient’s mailbox does not exist on the receiving server. Hard bounce, suppress immediately.

Fix path: suppress the address from your list. Validate addresses at form submission. Run periodic list cleaning to catch addresses that became invalid.

Per-MTA handling: all four MTAs categorise as hard bounce. PowerMTA and KumoMTA write structured bounce records that downstream tools (MailWizz, ESP frontends, custom suppression systems) ingest automatically.

Authentication credential errors (535 codes)

Different category from DMARC failures. These are your sending tool’s SMTP-AUTH being rejected, not your domain’s reputation.

535 5.7.1 — Authentication credentials rejected

Format example: 535 5.7.1 Authentication failed: Invalid user name or password.

What it means: the username/password (or OAuth token) your sending tool used to authenticate to the SMTP relay was not accepted.

Underlying causes:

1. Wrong credentials in the sending tool configuration
2. Credentials revoked (password rotated, OAuth token expired)
3. Using an account password where the SMTP relay requires an app-specific password (Google Workspace, Microsoft 365)
4. IP-based restriction on the SMTP relay blocking your sending IP

Fix path: verify credentials in the sending tool. For Google Workspace, generate an app-specific password if 2FA is enabled. For Microsoft 365, verify the app password and that SMTP-AUTH is enabled on the user account (it is disabled by default since 2022).

Common confusion: 535 5.7.1 is your tool’s auth failing. 550 5.7.1 is your domain’s reputation failing. The codes look similar; the causes are completely different. Read carefully.

ISP-specific patterns

Gmail, Microsoft, Yahoo and iCloud each have characteristic patterns in their bounce responses. Recognising the source helps focus the fix.

Gmail patterns

• gsmtp suffix in the response identifies Gmail
• 421 4.7.28 is Gmail-specific (bulk sender requirement)
• 421 4.7.0 from Gmail is more often reputation-driven than rate-driven
• 550 5.7.26 is Gmail’s DMARC rejection
• 550 5.7.1 from Gmail is reputation rejection

Microsoft (Outlook.com / Microsoft 365) patterns

• 550 5.7.515 is Microsoft-specific DMARC rejection
• 550 5.7.510 indicates the recipient mailbox cannot accept incoming mail (usually disabled)
• 421 4.7.x from Microsoft is more often rate-driven than reputation-driven
• Microsoft often suggests senders register with sendersupport.olc.protection.outlook.com for delisting

Yahoo patterns

• [TSS04] token in 421 4.7.0 responses identifies Yahoo
• Yahoo references postmaster.yahooinc.com/error-codes in many responses
• Yahoo is more bounce-aggressive than Gmail — small percentage of bad addresses produces faster reputation impact

iCloud patterns

• 421 4.7.1 Messages to [email protected] deferred due to excessive volume is the Apple variant
• iCloud’s volume threshold is lower than Gmail’s — what passes Gmail can defer at iCloud
• iCloud rarely returns 5.7.x permanent rejections; it tends to defer indefinitely instead

How the four MTAs handle bounces differently

The MTA’s job is not to fix bounces — it is to classify them correctly and feed the right downstream signal. Here is how the four production MTAs differ:

PowerMTA

• Bounce categorisation: uses bounce-after directive in domain blocks to set retry duration. Default categorisation file (bounceFlags.csv) is sophisticated and battle-tested
• Output: accounting files in CSV format that downstream parsers (most ESPs, MailWizz, custom systems) can ingest automatically
• Per-domain control: rich <domain>...</domain> blocks allow per-receiver retry tuning

KumoMTA

• Bounce categorisation: Lua-based classification in events/smtp_response.lua. Default classifier covers major ISPs
• Output: structured logs in JSON or custom format via Lua
• Per-domain control: dynamic via Lua functions, can compute retry policy at runtime

Postal

• Bounce categorisation: built-in classifier with web UI for inspection
• Output: webhooks to your application with structured bounce data
• Per-domain control: organisation-level rate limits; domain-level policy is less granular than PowerMTA/KumoMTA

Halon

• Bounce categorisation: HSL-based, fully programmable
• Output: structured logs, event hooks for SIEM integration
• Per-domain control: HSL policies expressed as code, most flexible of the four

When to escalate from “fix the bounce” to “audit the program”

If your bounce log is dominated by:

• 5+% 5.7.1 codes: domain reputation is collapsing. Stop sending and start recovery
• 2+% 5.7.26 codes: authentication is broken. Fix DMARC alignment before next campaign
• 10+% 4.7.x deferrals not converting to delivery: rate or reputation issue, throttle per-ISP and audit
• Mixed 5.7.x patterns at multiple ISPs: structural problem (list quality, content, or both) — full audit needed

If your bounce log is healthy:

• Less than 1% total bounce rate
• 5xx codes dominated by 5.1.1 (invalid recipients, expected) and 5.7.1 only on stale segments
• 4xx deferrals converting to successful delivery on retry within 4 hours
• No pattern of authentication failures

The diagnostic value of bounce logs is highest when you read them code-by-code rather than aggregated. Aggregated bounce rates hide the difference between a list-quality problem (suppress aggressively) and a reputation problem (recovery engagement) and an authentication problem (DNS work). The codes tell you which one you have.

If reading bounce logs and fixing the upstream causes is not your team’s expertise, our deliverability audit covers exactly this work — bounce log analysis, code distribution, structural diagnosis, and remediation plan. We do this every week for clients we have never met before.

For the codes we did not cover here (full RFC 3463 catalog runs to 60+ codes), the Gmail SMTP errors official documentation and the SMTP Field Manual are the canonical references. The codes we did cover are the ones that matter for bulk senders in 2026.

What we run at Blue Spirit

For transparency: we operate dedicated PowerMTA hosting and offer SMTP error code interpretation as part of our deliverability audit. The honest summary of SMTP error codes in 2026: enforcement codes (5.7.515, 5.7.26, 5.7.27, 5.7.606) carry far more operational weight than they did in 2022. Reading them correctly is the difference between a 1-day fix and an 8-week reputation recovery.

If you want help diagnosing recurring SMTP errors or building robust bounce processing — that’s part of our deliverability audit. Most operators we audit have bounce processing that ignores enhanced codes entirely, missing the diagnostic information that would prevent recurrent issues.

Related reading

The bulk sender enforcement codes (5.7.515, 5.7.26) are direct outputs of bulk sender requirements. For compliance baseline see Gmail Yahoo Microsoft bulk sender 2026 compliance. When persistent enforcement errors indicate reputation collapse, Gmail domain reputation recovery covers the 90-day recovery framework. For the Microsoft-specific 5.7.515 deep dive see Microsoft SNDS and JMRP guide. For DMARC alignment errors that produce 5.7.26 see the DMARC enforcement 2026 survival guide and our email authentication 2026 guide. For IP reputation patterns that drive 4.7.x deferrals see our IP warmup 2026 guide.

---

Need help interpreting recurring SMTP errors or building bounce processing that actually catches issues? That’s part of our deliverability audit. We diagnose error patterns and build the monitoring most operators are missing.