Why does one email get delivered while another is blocked?

You send the same message to the same list. Same subject line. Same content. One lands in the inbox. The other disappears into the void. Not a bounce, not a complaint—just silence.

What changed? Not the content. Not the timing. The difference is in the headers—the technical metadata that travels with every email. A small variation in a header field can mean the difference between delivery and rejection.

Header analysis reveals why one email passes inspection while another fails. It’s not about the words you write. It’s about how the email is structured, signed, and routed. By comparing the headers of a delivering email with a rejected one, you can isolate the technical trigger—before you waste time editing content or adjusting send times.

This is how you stop guessing. How you trace deliverability issues to their real source. And how you reduce bounce rates, improve inbox placement, and build sender reputation over time.

Key takeaways

  • Even identical content can be delivered or blocked based on differences in email headers.
  • Header analysis exposes technical deliverability failures—such as missing SPF, incorrect DKIM, or mismatched HELO—without relying on guesswork.
  • Comparing headers from delivering versus rejected emails identifies specific policy or configuration issues that impact inbox placement.

What are email headers, and why do they matter for deliverability?

Email headers are the technical metadata attached to every message—containing sender info, routing details, timestamps, and authentication results like SPF, DKIM, and DMARC. They’re used by receiving servers to verify identity, detect spam patterns, and enforce security policies. Even small changes in header order, timing, or formatting can trigger filtering decisions, making them critical for consistent inbox placement. You can analyze them to spot discrepancies between a delivered email and a rejected one.

How headers reveal the full delivery journey

Every email you send travels through multiple servers, and each step leaves a header trace. These records show the exact path the message took—from your mail server to the recipient’s inbox, or to a bounce. By comparing the headers of a message that was delivered versus one that was rejected, you can see where the breakdown occurred.

For instance, a delivered email might show a clean DKIM signature and alignment with the sending domain. A rejected one might show a missing or failed DKIM validation, a mismatched SPF record, or an unexpected source IP. These details, invisible in the user interface, are visible only in the raw headers.

Why small differences matter

Spam filters and security systems treat header structure as a signal. A misaligned header field (like a missing or misplaced Received line) or a non-standard timestamp format can raise red flags—even if the content appears normal. Some servers reject emails based solely on a broken or inconsistent header chain.

Even minor changes such as adding a new routing header or altering the order of existing ones can break authentication alignment. This is why headers are not just logs—they’re part of the authentication and legitimacy assessment. As outlined in RFC 5322 (the standard for email format), header structure directly influences how a server processes the message.

If you're troubleshooting delivery issues, comparing raw headers from a successful and a failed send is one of the most reliable forensic methods. Tools like MailTester’s inbox placement tester can help you send test messages with traceable headers to simulate real-world conditions across major providers.

How to access and compare headers from two emails: delivering vs rejected

You can compare delivering and rejected email headers by saving both as .eml files, opening them in a plaintext editor, and examining key fields like From, Received, Authentication-Results, Return-Path, Message-ID, and Date. Look for missing authentication tags, timestamp mismatches, or abnormal path chains in the Received lines — these often reveal why one message was accepted and the other blocked.

  1. Save both emails as .eml files using your email client’s "Save As" or "Export" function. This preserves all header metadata, including authentication results and routing paths, which are critical for diagnosing delivery issues.
  2. Open each .eml file in a plaintext editor like Notepad (Windows) or VS Code (cross-platform). Avoid email clients — they normalize or hide raw header details. You’re looking for unfiltered SMTP-level information.
  3. Identify and compare these fields: From, Received, Authentication-Results, Return-Path, Message-ID, and Date. These are standardized by RFC 5322 and RFC 7208 — the foundation of email tracking and validation.
  4. Check for inconsistencies. A rejected email may lack DKIM or SPF passes in Authentication-Results, show a Received path from an unknown IP, or have a Return-Path that doesn’t match the domain in From. These are red flags for spam filters.
  5. Spot unusual timestamp offsets. A receiving server may reject an email if the Date header is wildly in the future or past compared to local time — a common sign of spoofing, as RFC 5322 requires reasonable time alignment.

Why the Received path matters

Each Received line shows a hop in the email’s journey. A delivering email typically has a clean, sequential chain from your server to the recipient’s. A rejected one may show a loop, an unexpected relay, or no authenticated origin. Use tools like MxToolbox to scan IPs from the Received lines for blacklisting or poor reputation.

What to do with the findings

If you spot missing SPF/DKIM, adjust your alignment and signing. If the Return-Path differs from the From domain, fix your sender setup. These fixes reduce hard bounces and improve deliverability — and you can test them using our inbox placement tester to confirm improvements before sending to a full list.

The real technical difference: SPF, DKIM, and DMARC results in headers

When comparing a delivered email to one that was rejected, look at the Authentication-Results header field. A delivered message typically shows "pass" for SPF, DKIM, and DMARC. A rejected message often shows "fail" or "neutral" for at least one of them. These results stem from how the receiving server evaluates the sender’s alignment with the domain’s published policies.

SPF: Checking the sending IP’s authorization

SPF (Sender Policy Framework) checks whether the IP address used to send the email is listed in the domain’s SPF record. If the sending server isn’t in that record, SPF fails. This is common with misconfigured mail servers or compromised accounts. You can inspect this in the Authentication-Results header using the spf=softfail or spf=fail indicators.

As defined in RFC 7208, SPF is a foundational check that prevents spoofing by validating the origin IP. A spf=pass result means the server was authorized. If it’s fail, the message may be flagged or rejected based on policy.

DKIM and DMARC: Proving integrity and alignment

DKIM (DomainKeys Identified Mail) uses digital signatures to verify that the message body and headers haven’t been altered in transit. The signature is checked against the domain’s public key. A failed DKIM check means the content was modified — possibly due to routing changes, spam filtering, or interception.

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It uses their results to decide whether to accept, quarantine, or reject the message. If both SPF and DKIM pass but there’s no DMARC policy, the result may show as neutral. If policy says “reject” and either check fails, the message is blocked.

DMARC results are also visible in the Authentication-Results header. A dmarc=pass indicates alignment and compliance. A dmarc=fail or fail means the message didn’t meet the domain’s policy, often leading to rejection.

When debugging a bounce, the header analysis tells you exactly why: a failed SPF means your IP wasn’t authorized. A DKIM fail means the signature didn’t match. A DMARC fail suggests misalignment or an enforced policy. These are not just diagnostics — they’re actionable intelligence.

You can test these alignments before sending by using MailTester’s inbox placement tool to simulate real-world delivery and catch issues early. It verifies your setup across real mail providers using live headers.

Run inbox placement tests to see how your messages perform in Gmail, Outlook, and other inboxes — with full header inspection and real-time feedback.

Common header red flags that trigger rejections

You can spot why an email was rejected by comparing the headers of a delivered message and a failed one. Look for missing or invalid DKIM signatures, SPF failures with non-DMARC-aligned domains, reversed or missing Received header hops, and mismatches between envelope-from and header-from addresses. These are red flags that spam filters and receiving servers treat as signs of forgery or poor configuration.

Key header anomalies to watch for

  • Missing or invalid DKIM signature: If the DKIM signature is absent or fails verification, the receiving server assumes the message was altered in transit or was never authorized by the domain. This is a hard rejection trigger. According to RFC 6376, properly signed messages must include a valid cryptographic signature that aligns with the domain's public key. Learn more about DKIM in the official specification.
  • SPF failure on a domain not aligned with DMARC: SPF checks if the sending IP is authorized by the domain. If SPF fails and the domain doesn't enforce DMARC policies, the email is likely flagged as suspicious. DMARC policies determine what action to take when alignment fails—without it, the message becomes vulnerable to spoofing. See the DMARC standards document.
  • Mixed or reversed Received header chain: The Received headers should show a logical, ordered path from sender to recipient. If hops are missing, out of sequence, or originate from unexpected IPs, the server may suspect routing abuse or spoofing. Real delivery chains usually follow a clear, progressive path.
  • Mismatched envelope-from and header-from addresses: The envelope-from (the return path) and header-from (the visible sender) must align in most cases. A mismatch, especially when one address is a generic or role-based email (like postmaster@ or info@), triggers spam filters. This is commonly seen in poorly configured autoresponders or bulk campaigns.

How to catch these before sending

Use a real-time email verification tool before sending. Check your list against known bounces, invalid domains, and high-risk patterns. Bulk verify your list to catch invalid or risky addresses before they hit the inbox. For developers, the verification API lets you validate addresses on-the-fly during user signup or transactional workflows.

How MailTester helps uncover header-level deliverability issues

You can use MailTester’s inbox-placement testing to compare a delivered message with a rejected one by analyzing full headers captured from real recipient servers. The tool automatically flags authentication failures, routing path anomalies, and policy mismatches—so you don’t need to manually decode raw .eml files. Results are interpreted in plain English, saving hours of troubleshooting.

Real headers, real insight

When you run an inbox placement test, MailTester sends messages to actual inboxes across major providers like Gmail, Outlook, and Yahoo. Unlike simulators, it captures the complete email headers as they appear on the receiving server—exactly what the recipient's mail system sees. This includes routing details, authentication records, and policy decisions.

Let’s say one email lands in the inbox and another gets blocked. You can run both through MailTester’s inbox placement test and compare their full headers side by side. The platform highlights deviations: missing or failed SPF, DKIM, or DMARC checks; unexpected relay IPs; or header policy mismatches that trigger filters. These aren’t speculative—you see the exact point where the rejection happened.

For example, a message might pass SPF but fail DKIM—MailTester flags that in plain terms: “DKIM signature verification failed.” You don’t need to know RFC 6376 to understand it. No guesswork.

Automatic detection, no parsing needed

Manually analyzing raw email headers is time-consuming and error-prone. It requires familiarity with standards like SMTP, MIME, and DNS-based authentication. MailTester removes that barrier. It cross-references each header against known delivery behaviors and known blocklist patterns, surfacing only the relevant warnings.

Some providers, like Postmark, have published guidelines on how header structures affect deliverability. Similar principles apply here—you’re not just checking if an email was delivered, you’re checking whether the path it took met the standards of the receiving system. You can use tools like MxToolbox to diagnose MX records or Spamhaus to check for blacklisting, but MailTester integrates that analysis into a single, digestible workflow.

Whether you’re debugging a high bounce rate or testing a new campaign, you gain clarity fast. You don’t need to be a developer to know why one version of your message worked and another didn’t.

With MailTester, you get a practical, real-time comparison tool. No guesswork, no jargon. Just deliverability insights, surfaced automatically.

Use header analysis to improve sender reputation and domain health

You can use header analysis to spot inconsistencies between delivering and rejected emails—like mismatched SPF, DKIM, or authentication records—that reveal hidden issues. These small discrepancies, when repeated, signal poor sending hygiene and damage your sender reputation over time. Let’s break down how tracking header differences helps you stay in good standing with inbox providers.

Headers reveal the hidden cost of authentication failures

A single failed SPF check in a rejected email header is a red flag. Even if your message gets through, repeated authentication lapses can trigger behavioral flags across major providers like Gmail and Outlook. These systems monitor patterns over time—consistent header anomalies are often treated as signs of impersonation or compromised infrastructure.

SPF, DKIM, and DMARC aren’t just formality. They verify your identity at the protocol level. When one fails, especially across multiple sends, it signals to receivers that your domain’s security is inconsistent. This leads to higher spam filtering risk, even if your content is benign.

Proactive header review catches problems before they scale

Many deliverability issues start small—maybe one header field isn’t aligned, or a domain has multiple SPF records. Left unchecked, these accumulate. Over weeks or months, that’s a reputation hit you can’t see until your inbox placement drops.

Regular header analysis lets you spot anomalies early. Compare headers from a successful send against a bounced or rejected one. Look for:

  • Different source IPs or sending domains
  • Mismatches in SPF or DKIM signatures
  • Missing or conflicting DMARC policies
  • Unexpected header additions like Received-SPF: fail or Authentication-Results failures

Tools like MailTester’s real-time verification API and bulk list checks detect many of these issues before you send. By cleaning addresses before delivery, you reduce the number of messages that trigger rejection or header warnings. This lowers strain on your infrastructure and helps maintain domain health.

Consistent review, especially when comparing deliverability outcomes, keeps your sending practices trustworthy. It’s not about perfection—but about reducing variability, which inbox providers use to assess reliability.

Real-world example: Two campaigns, one delivered, one rejected

You can use header analysis to compare a delivered email with a rejected one by examining authentication results, routing timestamps, and error codes. In one case, identical campaigns failed to deliver only when DKIM signing was broken — a flaw caught in the headers, not in content or sender reputation. Fixing the signing and retesting via inbox placement confirmed successful delivery.

Step-by-step: What the headers revealed

  1. Obtain the full headers for one delivered email and one rejected email from the same sender, same list, same content. Use tools like MXToolbox or your email provider’s debug logs to extract them without modification.
  2. Check SPF alignment. Both emails show SPF=pass — no issue here. SPF confirms the sending IP is authorized to send from the domain, a baseline check for both campaigns.
  3. Verify DKIM authentication. The delivered email shows DKIM=pass with a valid signature. The rejected one shows DKIM=fail. This is the first red flag: one campaign failed the most fundamental email authentication standard.
  4. Analyze the Received timestamps. The rejected email shows a 45-second delay between the first and second Received header. This delay correlates with the point where the receiving server flagged the message as suspicious — a common sign of poor sender infrastructure or misconfiguration.
  5. Look for reject codes. The rejected email’s final header includes 550 5.7.1 Message rejected: DKIM authentication failed. This directly points to authentication failure, not spam content or reputation.
  6. Compare routing chain. The delivered email has a clean, sequential routing chain with no intermediate rejections. The rejected one shows a jump from a known mail server to a secondary relay point with no documented SPF or DKIM setup — a hallmark of risky infrastructure.
  7. Apply the fix. Reconfigure the sending system to generate valid DKIM signatures, validate the public key is published in DNS, and use MailTester’s inbox placement test to verify delivery before sending at scale.

The key takeaway: if two campaigns are identical except for a single authentication failure in the headers, that’s the root cause. You don’t need to adjust content, timing, or sender reputation — just fix the underlying technical flaw.

Avoid common mistakes when analyzing email headers

You’re not just looking for one broken header—many filters accept messages with minor issues. Focus on the full chain of Received headers, validate timing anomalies, and always use raw server-side .eml files, not client previews. Don’t trust tools that hide their output; deliverability decisions depend on transparency, not convenience.

Use the right data, not just any data

  • Don’t assume one mismatched header (like a missing DKIM signature) means delivery failure—some filters allow it, especially if other signals (like SPF and IP reputation) are strong.
  • Never analyze headers from Gmail’s web interface or email clients. Their rendered view strips out critical fields. Use raw .eml files pulled directly from server logs or email archives.
  • Look at the timing between Received headers. Gaps larger than 10–15 minutes between hops may indicate spoofing or routing manipulation—common red flags for spam filters.
  • Don’t trust tools that summarize or filter raw headers. If a tool doesn’t show the complete, unmodified output, you can’t verify its claims.
  • Always compare a delivered message (accepted by the inbox) with one that failed. A side-by-side analysis of the full header chain reveals subtle differences that cause rejections.

Verify your own data, not just the tool’s output

Just because a tool says “SPF pass” doesn’t mean it’s accurate. SPF, DKIM, and DMARC checks must be validated independently using the full, unaltered header. For example, the RFC 7001 standard defines how DMARC alignment works—many tools misreport alignment even when it’s technically correct.

Let’s say you’re debugging a rejected campaign. The rejected email has a missing DKIM signature, but the delivered one has one. That’s useful. But if the rejected email’s DKIM signature was actually present and valid—just buried in a tool’s summary—you’ve wasted time chasing a red herring.

Don’t skip the raw data. If you’re verifying lists before sending, tools like MailTester’s email checker surface issues like disposable domains, invalid syntax, or role accounts—common reasons headers fail later. But once you’re troubleshooting delivery, go straight to the source: the raw header, verified against standards, not a dashboard summary.

How to integrate header analysis into your daily deliverability workflow

Run inbox-placement tests after every major campaign or list change, then compare the headers—especially for spam-flagged messages. Use MailTester’s real-time inbox tests to spot authentication failures, greylisting delays, or routing quirks before they hurt your sender reputation. Keep header logs to track patterns and catch issues early. Most importantly, automate checks where you can.

Start with inbox testing and header comparison

  • After each major campaign or list cleanse, run an inbox-placement test using MailTester’s inbox tester. This simulates how your email appears in real inboxes across major providers.
  • Save the full header output from each test—especially for messages that land in spam or get rejected.
  • Use RFC 5322 as a reference when examining headers. Look for discrepancies in sender IP, domain alignment, or missing authentication tags.
  • Compare headers across delivered and rejected emails: a single missing DKIM signature or inconsistent SPF can explain why an email fails.
  • When you spot a rejected email, check if its headers show a rejected authentication result—like "SPF FAIL" or "DKIM verification failed" — and correlate that with the delivery outcome.

Automate validation and integrate early checks

  • Set up alerts in your SendGrid or Mailchimp dashboard to flag failed authentication results. These warnings should trigger a manual review or auto-trigger a list cleanup.
  • Use MailTester’s integrations with HubSpot, Klaviyo, and SendGrid to validate sender setup before sending. You can catch misconfigured DKIM or SPF before a campaign even starts.
  • Validate new email addresses in bulk with MailTester’s bulk verification to catch invalid, catch-all, or disposable domains before sending.
  • For high-volume senders, integrate the MailTester API into your pre-send workflow to validate every address in real time.
  • Review header differences monthly. A change in a sending IP’s reputation or a shift in mail server response can surface in header timing or rejection codes.
When your sender reputation drops, the header often tells you why—before your inbox placement does.

Header analysis isn’t a one-time fix. It’s a habit in deliverability. Letting it run automatically—through tests, comparisons, and alerting—means you’re not chasing bounces, you’re preventing them.

Final takeaway: Header analysis is your first line of defense against email rejection

Headers contain the real story of every email’s journey. They’re not just debug logs — they’re a live record of sender reputation, routing decisions, and delivery outcomes.

By comparing the headers of a delivered message with one that was rejected, you expose the exact moment and reason delivery failed. Was it an SPF mismatch? A greylist delay? A catch-all response? The data is in the headers — and it’s actionable.

How MailTester makes header analysis accessible

MailTester extracts the noise from SMTP-level details and translates header differences into clear, repairable insights. You don’t need to read RFC 5322 or parse 40+ header fields manually.

With 98.9% accuracy, each verification and inbox-placement test gives you confidence. You’re not guessing — you’re aligning with real delivery signals from the inbox.

Sources

  • Belkins' analysis of 7.5 million cold emails sent in 2025 found an average reply rate of just 0.45% measured against total emails sent, with replies declining 20% from the first half to the second half of the year. — Belkins Cold Email Response Rates Study (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I analyze email headers without sending a test?

No. Headers reveal real recipient server behavior only when the email is processed through actual delivery paths. Testing with MailTester provides live header data from real inboxes.

What’s the difference between a rejected email and a spam-filtered one?

A rejected email fails at the server level due to authentication or policy violations. A spam-filtered email passes initial checks but is marked as low trust based on content or sender history.

Do all email clients show full headers?

No. Most clients hide or simplify headers. Use raw .eml files or tools like MxToolbox or MailTester to access complete header data.

How often should I compare headers between delivering and rejected emails?

Make it part of your monthly deliverability audit—especially after list changes, new senders, or campaign failures.

Is header analysis useful for cold outreach?

Yes. Cold emails are more likely to be rejected. Header analysis helps ensure your sender setup is valid before reaching prospects.

Can poor header formatting cause delivery failure?

Yes. Malformed headers—like incorrect line ending, missing field separators, or malformed Message-ID—can cause rejection by strict mail systems.

Does MailTester store my email headers?

No. MailTester processes headers only for the duration of a test and does not retain them. All data is processed securely and deleted after testing.

How accurate is MailTester’s header analysis?

MailTester’s inbox-placement tests use 98.9% accurate verification and real recipient systems. Header reviews are based on actual server responses, not assumptions.

Can I test multiple headers at once with MailTester?

Yes. Use the bulk verification or API to run multiple tests and compare header results across campaigns or senders.

What should I do if headers show DKIM fail but the message arrives?

Monitor for pattern changes. A single fail may not block delivery, but repeated failures harm sender reputation. Review signing setup immediately.

Do headers change over time during delivery?

Yes. Each relay adds a Received header. Final headers reflect the full delivery path. Use consistent sources (like test emails sent to the same domain) for comparison.

Is header analysis enough to fix deliverability problems?

No—it’s diagnostic. Use header findings to validate SPF/DKIM setup, fix list hygiene, or adjust sending behavior. Combine with reputation checks for full health.