E
Email Deliverability

Email Deliverability Troubleshooting: Diagnose and Fix Delivery Problems

A diagnostic guide for email deliverability problems. Covers emails going to spam, bounces, authentication failures, provider-specific issues, and sudden delivery drops.

Your open rates dropped 30% overnight. A prospect says they never received your proposal. Your support inbox is filling up with customers who did not get their password reset emails. Something broke, and you need to figure out what, fast.

Email deliverability problems are frustrating because the symptoms are vague and the causes are varied. A message can fail for authentication reasons, reputation reasons, content reasons, or infrastructure reasons. Sometimes it is a combination of all four. The key to fixing delivery problems quickly is knowing how to read the signals, match them to a root cause, and apply the right fix without making things worse.

This guide gives you a real diagnostic framework. Not just a list of links, but an actual process for narrowing down what went wrong and how to fix it. For background on how deliverability works at a fundamental level, see our complete email deliverability guide.

The First 5 Minutes: Emergency Checklist

When deliverability breaks suddenly, you need a triage process. Do not start changing DNS records or rewriting email templates until you have identified the actual problem. Here is what to check, in order, before you touch anything.

Step 1: Confirm the problem is real. Check your email service provider's (ESP's) delivery dashboard. Look at bounce rates, delivery rates, and complaint rates for the last 24 to 48 hours. A single recipient reporting a missing email is not an emergency. A sudden change in aggregate metrics is.

Step 2: Run an authentication check. Use our free deliverability checker to test your Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) status. If any of these are failing, you have found your problem. Do not skip this step. Authentication failures cause the vast majority of sudden deliverability drops.

Step 3: Check blacklists. Go to Email Blacklist Checker and run your sending domain and IP address. Blacklist additions can happen within hours and cause immediate delivery failures. According to Return Path research, being listed on even one major blacklist can reduce inbox placement by over 25%. [1]

Step 4: Review recent DNS changes. Ask your team whether anyone modified DNS records in the last 48 hours. A mistyped SPF record, an accidentally deleted DKIM CNAME, or a new service added without updating authentication can all cause immediate failures.

Step 5: Check for volume anomalies. Did you send a campaign to an unusually large list? Did you email a cold segment you have not contacted in months? Did a developer accidentally trigger a batch of transactional emails? Volume spikes, especially to unengaged recipients, are one of the fastest ways to damage sender reputation.

Step 6: Look for provider-specific enforcement changes. Check our deliverability news and the postmaster blogs for Google and Microsoft. Both providers have rolled out bulk sender requirements that went into effect in 2024 and 2025, and enforcement continues to tighten. [2] [3] A policy change on their end can affect your delivery overnight.

Do not make multiple changes simultaneously. If you change your SPF record, rotate your DKIM key, and modify your sending frequency all at once, you will not know which change fixed the problem (or made it worse). Change one thing, wait, measure, then proceed.

For a more thorough version of this process, see our email deliverability audit checklist, which provides a 30-minute structured review.

Diagnostic Decision Tree

Before diving into the detailed sections below, use this quick decision tree to jump to the right place.

Is your email bouncing with an error code? You are dealing with a server-level rejection. Go to Bounces and Rejections.

Are your emails arriving but landing in spam or junk? The server accepted the message, but the mailbox provider filtered it. Go to Emails Going to Spam.

Are your emails arriving for some recipients but not others? This is usually provider-specific filtering or authentication that passes at some providers but fails at others. Go to Provider-Specific Quirks.

Are your emails arriving slowly or in batches? You are likely being throttled. Go to Soft Problems: Throttling and Intermittent Issues.

Did everything break at once after a DNS or platform change? This is almost certainly an authentication failure. Go to Authentication Failures.

Is the problem only affecting one sending platform but not others? You have a platform-specific configuration issue. See our platform setup guides for per-platform troubleshooting.

How to Read Email Headers for Diagnosis

Before we get into specific symptoms, you need to know how to read the diagnostic information that every email carries with it. Email headers are the single most useful troubleshooting tool available to you. They tell you exactly what happened during delivery, which checks passed or failed, and where in the chain things went wrong.

To view headers in Gmail, open the message, click the three dots, and select "Show original." In Outlook, open the message, click File, then Properties, and look in the "Internet headers" box. In Apple Mail, go to View and then Message, then All Headers.

Key Headers to Look For

Authentication-Results: This is the most important header for deliverability troubleshooting. It shows the results of SPF, DKIM, and DMARC checks as evaluated by the receiving server. Here is what a healthy one looks like:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=selector1;
       spf=pass (google.com: domain of [email protected] designates 198.51.100.1 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

If any of those show fail or softfail, you have your diagnosis. The header will also tell you why it failed, including which IP was checked against SPF and which DKIM selector was evaluated.

Received: These headers form a chain showing every server the message passed through, from bottom (origin) to top (destination). Each "Received" header includes a timestamp. If there is a large time gap between two consecutive Received headers, the message was delayed at that hop. This is how you diagnose slow delivery.

X-Spam-Status (or similar): Many receiving servers add a header showing the spam score and which rules triggered. SpamAssassin-based systems use X-Spam-Status and include the individual rule scores. For example:

X-Spam-Status: Yes, score=7.2 required=5.0
  tests=HTML_IMAGE_RATIO_02, MISSING_MID, SPF_FAIL,
  DKIM_SIGNED_BUT_FAIL, RCVD_IN_SORBS_DUL

This tells you the message scored 7.2 (above the 5.0 threshold), and the specific rules that contributed to the score. Each rule name is searchable and will tell you exactly what triggered it.

X-Forefront-Antispam-Report (Microsoft): This Microsoft-specific header contains the Spam Confidence Level (SCL) and Bulk Complaint Level (BCL) scores. An SCL of 5 or higher typically means the message was sent to junk. The SFV field shows the filtering verdict: SFV:SPM means spam, SFV:NSPM means not spam.

For a deeper guide to header analysis, see email header analysis.

Soft Problems vs. Hard Problems

Understanding the difference between soft and hard delivery problems will save you hours of misdiagnosis.

Hard Problems

Hard problems cause consistent, reproducible failures. Every email fails the same way, every time. Examples include:

  • SPF record is missing or incorrect (every email from that domain fails SPF)
  • DKIM key does not match the DNS record (every signed email fails verification)
  • DMARC policy is set to p=reject and alignment is broken (every email gets rejected)
  • Your IP or domain is listed on a major blacklist (delivery fails to all providers using that list)
  • Your sending domain has no MX record (some providers reject mail from domains that cannot receive replies)

Hard problems are actually easier to fix because they are consistent. Run an authentication check, identify the failure, fix the record, and wait for DNS propagation.

Soft Problems

Soft problems are intermittent. They affect some messages but not others, some providers but not all, some days but not every day. Examples include:

  • Throttling based on sending volume or reputation (the first 500 emails deliver fine, the next 5,000 get deferred)
  • Content-based filtering that triggers only on certain messages
  • Engagement-based filtering where Gmail or Outlook deprioritizes your mail because recipients have stopped opening it
  • Shared IP reputation issues where another sender on your IP caused a temporary dip

Soft problems are harder to diagnose because they are inconsistent. They require looking at patterns over time, comparing delivery rates across providers, and analyzing which segments or message types are affected.

Emails Going to Spam

Your email was accepted by the receiving server (no bounce), but it ended up in the spam or junk folder instead of the inbox. This is the most common deliverability complaint. It is also the hardest to diagnose because mailbox providers do not tell you why they filtered a message.

Why It Happens

Spam filtering is a scoring system. Each message is evaluated against dozens of signals, and the cumulative score determines inbox vs. spam placement. The major signal categories are:

  1. Authentication: Did SPF, DKIM, and DMARC all pass? Failure on any one of these is a strong negative signal.
  2. Sender reputation: What is the historical sending pattern of this domain and IP? According to Validity's 2025 Deliverability Benchmark, sender reputation accounts for roughly 80% of filtering decisions at major mailbox providers. [4]
  3. Engagement: Are recipients opening, clicking, replying to, or marking these messages as spam? Gmail in particular weights engagement heavily.
  4. Content: Does the message contain patterns associated with spam? This includes link-to-text ratio, image-to-text ratio, known spam phrases, and URL reputation.

Diagnostic Steps

Start with authentication. Run your domain through our deliverability checker and through SPF Record Check to verify records are correct. Then check your domain reputation at Google Postmaster Tools. If your reputation is listed as "Low" or "Bad," that is likely the primary cause.

Next, look at the email headers of a message that landed in spam (see the header analysis section above). The Authentication-Results header will tell you if authentication failed. The X-Spam-Status or equivalent header will tell you which content rules triggered.

General Guides

Bounces, Rejections, and SMTP Error Codes

Bounces mean the receiving server actively refused your email. Unlike spam placement, bounces give you explicit error information. The Simple Mail Transfer Protocol (SMTP) error code tells you exactly what category of problem you are dealing with.

How to Read SMTP Error Codes

SMTP error codes follow a three-digit pattern. The first digit is the most important:

  • 4xx codes are temporary failures. The server is saying "try again later." Your sending system should automatically retry these.
  • 5xx codes are permanent failures. The server is saying "do not retry, this will not work."

Here are the most common error codes you will encounter, along with real-world examples of the error strings.

421 (Service Not Available / Try Again Later)

421 4.7.0 [TSS04] Messages from x.x.x.x temporarily deferred due to unexpected volume or user complaints
421 4.7.28 Gmail has detected unusual activity from your sending IP. Please try again later.

This is a throttling response. The receiving server is telling your mail transfer agent (MTA) to slow down. It is not a rejection. Your server should retry automatically, usually with increasing delays (known as exponential backoff). If you see persistent 421 errors, it typically means you are sending too fast or your IP reputation has dipped below a comfort threshold. Yahoo and Gmail use 421 responses aggressively for rate limiting.

450 (Mailbox Temporarily Unavailable)

450 4.2.1 The user you are trying to contact is receiving mail at a rate that prevents delivery
450 4.7.1 <[email protected]>: Recipient address rejected: Policy Rejection

Similar to 421 but scoped to a specific recipient rather than your entire sending IP. This often means the recipient's mailbox is full, the account is temporarily suspended, or per-recipient rate limits have been hit. Usually resolves on its own.

550 (Mailbox Not Found / Permanent Failure)

550 5.1.1 The email account that you tried to reach does not exist
550 5.7.1 [CS01] Messages from x.x.x.x have been blocked by the recipient's organization
550 5.7.26 This message does not pass authentication checks (SPF and DKIM both)

This is the most common permanent bounce. The 5.1.1 sub-code means the address does not exist, which is a hard bounce that should immediately remove the address from your list. The 5.7.1 sub-code means a policy rejection, often a blacklist or organizational block. The 5.7.26 sub-code (used by Microsoft) means authentication failure.

553 (Mailbox Name Invalid)

553 5.1.3 Invalid address
553 5.1.8 Sender address rejected: Domain not found

Usually means the sender or recipient address is malformed, or the sending domain does not have valid DNS records. Check that your sending domain has proper MX and A records.

554 (Transaction Failed)

554 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using Spamhaus
554 5.7.5 Permanent Error evaluating DMARC policy
554 5.7.9 Message not accepted for policy reasons

This is the "catch-all" permanent rejection. The 5.7.1 variant with a blacklist reference means your IP is listed on a DNS-based Blackhole List (DNSBL). The 5.7.5 variant is a DMARC enforcement rejection, which became much more common after Google and Microsoft began enforcing bulk sender requirements in 2024. [2] [3] See our detailed guide on 554 DMARC errors.

Further Reading on Bounces

Authentication Failures

When SPF, DKIM, or DMARC checks fail, the result ranges from spam placement to outright rejection, depending on your DMARC policy and the receiving provider's enforcement level. Authentication failures are one of the most common causes of sudden deliverability drops because they are often triggered by DNS changes.

How to Identify Which Protocol Failed

Run your domain through SPF Record Check, DKIM Test, and DMARC Record Checker. Then check the Authentication-Results header on a delivered message (see the header analysis section above).

Here is a quick decision framework:

SPF is failing: Either your sending IP is not included in your SPF record, or your record has a syntax error, or you have exceeded the 10-lookup limit. The most common cause is adding a new sending service without updating your SPF record. See SPF fail explained and SPF too many lookups.

DKIM is failing: Either the DKIM DNS record does not exist, the selector does not match, or the key in DNS does not match the key used to sign the message. This often happens when migrating between platforms or rotating keys. See DKIM fail and DKIM errors troubleshooting.

DMARC is failing: DMARC requires that either SPF or DKIM passes and aligns with the From domain. You can have SPF passing and DKIM passing, but if neither one aligns with the domain in the From header, DMARC still fails. This alignment requirement is the most common source of DMARC failures. See DMARC fail and DMARC alignment explained.

General Authentication Troubleshooting

Provider-Specific Quirks

Not all mailbox providers filter email the same way. A message that lands in the inbox at Gmail might go to spam at Outlook, or vice versa. Understanding provider-specific behavior is essential when your deliverability problems are not uniform across all recipients.

Gmail

Gmail uses a category tab system (Primary, Promotions, Social, Updates, Forums) in addition to spam filtering. Your marketing email might not be in spam at all. It might be in the Promotions tab, which many users never check. This is not the same as a spam problem, and the fix is different.

Gmail also weights engagement more heavily than other providers. If recipients stop opening your messages, Gmail gradually moves them to Promotions and eventually to spam. Google Postmaster Tools is your primary diagnostic resource for Gmail. It shows domain reputation, IP reputation, spam rate, and authentication status. A spam complaint rate above 0.10% is a warning. Above 0.30% is critical, per Google's 2024 bulk sender requirements. [2]

See Gmail spam issues and Postmaster Tools guide for detailed Gmail troubleshooting.

Microsoft Outlook and Office 365

Microsoft uses a Focused Inbox / Other Inbox split for consumers and many enterprise users. Messages that land in "Other" are not in spam, but they are much less likely to be read.

Microsoft also uses its Smart Network Data Services (SNDS) portal, which shows IP reputation and complaint rates. The tricky part with Microsoft is that enterprise customers often layer additional filtering on top. Mimecast, Proofpoint, and Barracuda are the most common enterprise email security gateways. These gateways apply their own rules before the message even reaches the Microsoft mailbox. If your email is being blocked at an enterprise customer, the block may be at the gateway level, not at Microsoft's level.

Microsoft's bulk sender enforcement (announced late 2024, enforcement beginning 2025) mirrors Google's requirements: SPF, DKIM, and DMARC must all pass, and complaint rates must stay below 0.30%. [3]

See Outlook deliverability issues for detailed Microsoft troubleshooting.

Apple iCloud Mail

Apple Mail's deliverability is complicated by Mail Privacy Protection (MPP), which was introduced in iOS 15 and macOS Monterey. [5] MPP pre-fetches all images, including tracking pixels, making open rates unreliable for Apple Mail users. You cannot use open rates to measure engagement with Apple recipients, which means you also cannot use opens to segment engaged vs. unengaged Apple users.

Apple's spam filtering is less transparent than Google's or Microsoft's. There is no public postmaster tool. Authentication (SPF, DKIM, DMARC) is still the foundation, but beyond that, Apple provides limited visibility.

See Apple iCloud Mail deliverability for what is known about Apple's filtering behavior.

Yahoo and AOL

Yahoo (which also handles AOL email) was one of the first major providers to enforce strict DMARC policies. Yahoo's own domains publish p=reject, which means any email with a yahoo.com From address that is not sent through Yahoo's servers will be rejected by DMARC-enforcing receivers. [6]

Yahoo adopted Google's bulk sender requirements in parallel. The requirements are virtually identical: SPF, DKIM, and DMARC must pass, one-click unsubscribe headers must be present, and spam complaint rates must stay below 0.30%. [7] See Yahoo/AOL sender requirements for specifics.

Soft Problems: Throttling and Intermittent Issues

If your emails are being accepted but delivered slowly, or if you are seeing temporary 4xx errors that resolve on their own, you are dealing with throttling. Throttling is not a failure. It is the receiving server telling you to slow down.

Why Throttling Happens

Mailbox providers throttle senders for several reasons:

  • Volume spikes: Sending significantly more email than your usual pattern triggers rate limiting. If you normally send 1,000 emails per day and suddenly send 50,000, providers will slow you down.
  • New IP or domain: If your sending IP or domain has little or no history, providers are cautious. This is why email warmup exists.
  • Reputation dip: A temporary increase in complaints or bounces can cause providers to throttle rather than block outright.

How to Identify Throttling

Look for 421 and 450 SMTP response codes in your ESP's delivery logs. These are temporary deferrals. Your MTA should retry these automatically. Also look at delivery timing. If your ESP shows that a campaign "completed" delivery over several hours instead of the usual 30 minutes, throttling is likely the cause.

How to Fix Throttling

You usually do not fix throttling directly. You fix the underlying cause. If you spiked volume, spread your sends over a longer period. If you are on a new IP, follow a warmup schedule. See email warmup and email warmup for new domains. If your reputation dipped, focus on sending to your most engaged recipients first to rebuild positive signals.

For a complete guide, see email throttling explained.

End-User Guides

Sometimes the problem is not on your end. The recipient's email client may be filtering legitimate messages, or the recipient may not know where to look for filtered mail. These guides are written for recipients, not senders, and you can share them directly with people who report missing emails.

Building a Troubleshooting Process

One-time fixes are not enough if you want consistent deliverability. You need a repeatable process for catching problems early, before they affect large numbers of recipients.

Monitor Continuously

Set up ongoing monitoring for your authentication records and blacklist status. DNS records can be accidentally modified by anyone with access to your domain registrar or DNS provider. A monitoring system catches these changes within minutes instead of days. Our deliverability checker provides point-in-time testing, and our monitoring service provides continuous alerts.

Track the Right Metrics

Not all metrics are equally useful for troubleshooting. Focus on these, in order of diagnostic value:

  1. Bounce rate by type (hard vs. soft, with error codes)
  2. Spam complaint rate (from feedback loops, not from recipients self-reporting)
  3. Delivery rate (accepted vs. rejected, per provider)
  4. Inbox placement rate (requires seed testing or tools like Google Postmaster Tools)
  5. Engagement rate (opens are unreliable due to Apple MPP, but clicks remain a solid signal)

See email deliverability metrics for a deeper explanation of what each metric tells you.

Know When to Escalate

Some problems cannot be fixed from the sender side alone. If you are consistently blocked by a specific provider despite correct authentication and clean lists, you may need to submit a sender support request. Google, Microsoft, and Yahoo all have sender support forms. Enterprise gateways like Mimecast and Proofpoint require the recipient's IT team to whitelist your domain.

If you are on a shared IP and another sender's behavior is dragging down your reputation, the fix may be migrating to a dedicated IP. See dedicated vs. shared IP for guidance on when that makes sense.

Catch problems before your recipients do

Automated monitoring for SPF, DKIM, DMARC, MX records, and blacklist status. Get alerts when something breaks. $39/month.

References

  1. Return Path, "The Sender Score Benchmark Report," Return Path Research. Findings on the impact of blacklist listings on inbox placement rates.
  2. Google, "Email Sender Guidelines," Google Support, 2024. Requirements for bulk senders including authentication and spam rate thresholds. https://support.google.com/a/answer/81126
  3. Microsoft, "Strengthening Email Ecosystem — Outlook's New Requirements for High-Volume Senders," Microsoft Community, 2024. Announcement of bulk sender authentication and complaint rate requirements. https://techcommunity.microsoft.com/blog/outlookblog/strengthening-email-ecosystem--outlook%E2%80%99s-new-requirements-for-high-volume-luftpost/4399730
  4. Validity, "2025 Email Deliverability Benchmark Report," Validity, 2025. Analysis of sender reputation's role in mailbox provider filtering decisions.
  5. Apple, "Mail Privacy Protection," Apple, 2021. Introduction of pre-fetching for remote content in Mail on iOS 15 and macOS Monterey. https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios
  6. Yahoo, "Yahoo DMARC Policy Update," Yahoo Sender Hub, 2014. Yahoo's adoption of a strict p=reject DMARC policy for yahoo.com domains. https://senders.yahooinc.com/
  7. Yahoo, "Yahoo Sender Requirements," Yahoo Sender Hub, 2024. Bulk sender requirements aligned with Google's guidelines including authentication, one-click unsubscribe, and complaint rate thresholds. https://senders.yahooinc.com/best-practices/

Related Articles