Email Deliverability Troubleshooting Guide by Symptom Class

Deliverability failures almost always leave evidence, but only in the right layer. Engineers who look only at their sending platform dashboard miss the verdict hidden in the received message's Authentication-Results and X-Spam headers. This email deliverability troubleshooting guide is organized by symptom class precisely because the diagnostic path for a hard bounce is completely different from the path for silent filtering. Treating them the same is why most debugging sessions stall. Start at the message, not the dashboard.

Why Generic Deliverability Advice Fails Engineers

Most existing deliverability content reduces diagnosis to "check your sender reputation" and then points you at a reputation lookup tool. That advice works as a starting guess and fails as a methodology. Reputation scores are lagging aggregate signals, they tell you something went wrong over a period of time, not what failed for this message right now.

Engineers need raw evidence: SMTP response codes from the receiving MTA, the Diagnostic-Code field in the bounce NDR, the Authentication-Results header stamped by the destination server, and the X-Spam-Score verdict from the content filter. Without those, you are guessing. This guide skips the guessing and walks through each symptom class with its specific evidence layer and diagnostic procedure.

Before You Diagnose: Build Your Diagnostic Toolkit

The Evidence Layer: Headers, SMTP Logs, and Bounce NDRs

Three primary evidence sources cover almost every deliverability failure:

1. Raw email headers, the full received-chain, Authentication-Results, X-Spam-*, and DKIM-Signature fields from the delivered or trapped message. For reading email headers to diagnose delivery failures, every hop in the Received: chain is a timestamp and a routing record.
2. SMTP session logs, your sending MTA's outbound log captures the exact server response for every delivery attempt. This is the primary source for bounce and deferral analysis.
3. Bounce DSN payloads, the Non-Delivery Report (NDR) / Delivery Status Notification (DSN) includes a machine-readable Diagnostic-Code: field containing the receiving MTA's SMTP response verbatim.

Essential free tools: MXToolbox for DNS record inspection and blacklist lookups, mail-tester.com for a scored preflight check, Google Postmaster Tools for domain and IP reputation trends, and DMARC aggregate report processors (such as dmarcian or the open-source parsedmarc) for authentication visibility across all sending streams.

Authentication Preflight: SPF, DKIM, and DMARC Checks

Authentication must pass before you chase reputation. A reputation problem and an authentication misconfiguration look identical from the sending dashboard, both result in spam folder placement or rejection, but they have entirely different fixes.

Verify in this order:

• SPF, does your sending IP appear in the authorized IP set published in the sending domain's SPF record? Check with dig TXT yourdomain.com or MXToolbox's SPF lookup.
• DKIM, does the d= domain in the DKIM-Signature header match the RFC5322 From: header domain? Resolve the selector: dig TXT selector._domainkey.yourdomain.com. A missing or misconfigured selector returns NXDOMAIN.
• DMARC, does either SPF or DKIM pass and align with the From: domain? When DKIM's d= domain does not align with the From: domain, DMARC fails even if SPF passes. This shows up in Authentication-Results as spf=pass, dkim=fail, dmarc=fail on the same line, a pattern that misleads engineers who stop reading at SPF.

For the full authentication stack explained, see how SPF, DKIM, and DMARC authentication actually works. Authentication failures also surface through DMARC aggregate reports, check those before opening any reputation investigation.

Symptom Class 1, Hard and Soft Email Bounce Troubleshooting

Reading the SMTP Response Code in the NDR

Open the NDR and find the Diagnostic-Code: field. It contains a three-digit SMTP reply code, optionally an enhanced status code, and a human-readable reason string. The first digit is the only one that matters for triage:

• 5xx = permanent failure. The receiving MTA rejected the message and will not accept a retry. Remove the address from your list immediately. Common examples: 550 5.1.1 (user unknown), 550 5.7.1 (policy rejection), 553 5.1.3 (invalid address syntax).
• 4xx = transient failure. The receiving MTA is deferring. Your MTA will retry according to its retry schedule.

The reason string is the diagnostic signal. 550 5.7.1 Message rejected as spam by Content Filtering points to a content policy block at the receiving MTA, not an IP reputation issue, directing diagnosis toward header and content inspection rather than a delisting request. 550 5.7.1 Your IP has been blocked points to IP-level policy, which is a different fix entirely. For a full code-by-code reference, use the SMTP error codes reference for diagnosing bounces by code. For the specific 550 5.7.1 path, how to fix a 550 5.7.1 rejection covers the remediation options in detail.

SMTP Soft Bounce Retry Logic and When It Breaks

A 4xx response triggers your MTA's retry queue. Postfix and Exim both default to retrying for several days before generating a final bounce NDR. The retry schedule typically backs off exponentially, first retry in minutes, subsequent retries in hours.

The diagnostic trap: a sustained 4xx from a major mailbox provider is often not a transient queue issue. It is a policy signal dressed as a temporary failure. If the same destination returns 421 4.7.0 on every retry for 12+ hours, the receiving end is throttling or soft-blocking your IP. That is not "try again later", it is "fix the underlying issue." Look at the enhanced status code second segment (the 4.7.x part) to determine whether you are dealing with rate limiting or policy.

Symptom Class 2, Email Deferral SMTP: Diagnosing 4xx Patterns

Rate Limiting vs. Policy Deferrals: Reading the Enhanced Status Code

RFC 3463 enhanced status codes use a three-part dotted format: class.subject.detail. For 4xx deferrals, the subject digit identifies the category:

• 4.2.x, mailbox or service status. A 450 4.2.1 usually means the mailbox is full, temporarily unavailable, or subject to a per-mailbox policy. This can escalate to a permanent 550 if the condition persists.
• 4.4.x, network or routing issue. Indicates a DNS or MX resolution problem on the sending or receiving side.
• 4.7.x, security or policy. A 421 4.7.0 from a major mailbox provider typically signals IP-level throttling due to volume or complaint rate. Treating a 421 4.7.0 and a 450 4.2.1 as identical "just retry later" situations misses the signal: one is rate-based, the other is a soft policy rejection that may escalate to a hard block.

When you see persistent 4.7.x deferrals, correlate the sending IP and volume against your complaint rate in Google Postmaster Tools before increasing retry frequency.

MX Record Troubleshooting and Routing Failures

MX routing failures produce 4.4.x or 5.4.x codes and are distinct from reputation blocks. Diagnose with:

dig MX targetdomain.com

Check for: correct priority weighting (lower number = higher priority), at least one resolvable A/AAAA record for each MX hostname, and a matching PTR (reverse DNS) record for your sending IP. A missing PTR is a common soft-block trigger, many receiving MTAs defer or reject mail from IPs without valid reverse DNS.

Split-horizon DNS is a subtler MX problem: your internal DNS resolves the MX to an internal address while external resolvers return the correct public record. SMTP session logs will show connection timeouts or refused connections to an IP that doesn't accept inbound SMTP from the public internet. Verify MX resolution from an external resolver (use dig MX domain.com @8.8.8.8) to eliminate split-horizon as a variable.

Symptom Class 3, Email Going to Spam Fix and Silent Filtering

Spam folder placement and silent discard leave no SMTP error. Your sending MTA recorded a 250 OK, delivery is complete from its perspective. Silent filtering, where a message is accepted with 250 OK but never reaches inbox or spam folder, is the hardest failure class precisely because the sending side has nothing to investigate.

The only evidence is in the received message's header block.

Reading the X-Spam and Authentication-Results Headers

Request a copy of the delivered message (use a seed address at the destination domain if possible, or a monitoring service). Then read:

• X-Spam-Status: and X-Spam-Score:, stamped by SpamAssassin-based filters and many enterprise gateways. These show the aggregate spam score, the threshold, and the individual rule hits that contributed to it. A message that scores above threshold lands in spam; one accepted for silent discard may not have these headers at all.
• Authentication-Results:, stamped by the receiving MTA. Look for spf=, dkim=, and dmarc= verdicts. A dkim=fail combined with dmarc=fail is a strong spam-folder driver even when content is clean. See reading the Authentication-Results header for DMARC failures for the full DMARC failure path.
• X-Forefront-Antispam-Report: (Microsoft) and X-Google-DKIM-Signature: (Google), provider-specific diagnostic headers that expose filter category codes and routing decisions.

For DKIM failures specifically, DKIM signature verification failures and how to resolve them covers selector misconfiguration, key rotation errors, and body canonicalization issues.

Email Blacklist Removal: Identifying Which List and Why

The fix most guides recommend first, "check if you're blacklisted", is actually a step you take after ruling out authentication failures and content scoring. If authentication passes and content is clean, then check blacklists.

Identify the exact list from the rejection or deferral string in the NDR. A message rejected by Spamhaus will include a string referencing spamhaus.org and the specific zone, zen.spamhaus.org (IP-based) versus dbl.spamhaus.org (domain-based). Barracuda rejections reference b.barracudacentral.org. MXToolbox's blacklist check queries the major lists simultaneously.

Once you identify the list:

1. Go to the list operator's site and look up your IP or domain to read the listing reason.
2. Fix the underlying cause, open relay, compromised account, or complaint spike, before requesting removal.
3. Submit the delisting request through the operator's process. Spamhaus, Barracuda, and Invaluement each have distinct processes and timelines.

Requesting delisting before fixing the root cause results in re-listing, often with a longer waiting period before the next removal request is accepted.

Sender Reputation Check and Long-Term Email Deliverability Diagnosis

Reputation dashboards, Google Postmaster Tools, Microsoft SNDS, and Yahoo Complaint Feedback Loop, are aggregate views. They show trends over time, not per-message verdicts. Use them for correlation, not root cause.

Reading Postmaster Dashboard Signals Back to Header Evidence

Google Postmaster Tools reports reputation at the domain level, keyed to the DKIM d= domain. If you are sending from multiple streams, transactional, marketing, notifications, each stream that uses a different DKIM signing domain appears as a separate reputation entry. A reputation drop in Postmaster Tools should be correlated back to the specific sending stream by matching the d= domain in your SMTP logs.

A domain reputation drop without a corresponding IP reputation drop suggests the problem is complaint-rate or content-driven, not infrastructure-driven. The inverse, IP reputation drop with stable domain reputation, suggests a volume or connectivity issue on that specific IP.

Microsoft SNDS reports complaint and filter rates per IP. Yahoo's Complaint Feedback Loop delivers individual complaint messages with the original headers intact, which lets you identify the exact campaign, message, or list segment generating complaints, trace the X-Mailer-Sent-To or List-Unsubscribe headers in the FBL copy.

For tracing the full delivery path through email header forensics, the received-header chain reconstructs the exact routing path, which is essential when reputation signals point to a specific MX or egress IP.

Triage decision tree:

Each path in the email deliverability diagnosis starts at the evidence layer specific to that symptom class. The sender reputation check is the last correlation step, not the first.

Stop guessing at SMTP codes and header fields. Email Decoded maps every layer, from the SMTP handshake to the Authentication-Results verdict, in one engineering-grade reference. Explore the book and wiki at emaildecoded.wiki.