SMTP Header Analysis: What Receiving Servers Evaluate

• November 2022
• Engineering Memo · External Release

Every email message contains headers that receiving servers evaluate as part of their spam classification and authentication verification process. Understanding which headers are evaluated, what receiving servers check in each header, and what correctly configured headers look like allows operators to verify that their sending infrastructure is producing the expected header output and to diagnose misconfiguration from the header data in bounce reports and test message analysis.

The Received Headers: Tracing the Delivery Path

Each SMTP server that handles a message adds a Received: header documenting its role in the delivery chain. The topmost Received header is added by the final receiving server (the one that delivered to the recipient's mailbox); subsequent Received headers document earlier stages of transmission. A typical message from a commercial sending infrastructure has 2-3 Received headers: one from the sending MTA (PowerMTA), one from the receiving ISP's edge MTA, and one from the ISP's internal delivery server.

Spam filters analyze Received headers for anomalies that indicate spam behavior: excessive number of hops (spam messages sometimes show 8-12 Received headers from multiple intermediate relays), timestamps that go backwards (indicating header manipulation), or hostnames that do not resolve in DNS (indicating fake or modified headers). Clean commercial sending infrastructure produces 2-3 Received headers with consistent timestamps and fully resolvable hostnames in all hop entries.

The first Received header (added by the sending MTA) should include the EHLO hostname and the sending IP: from mail1.brand.com (mail1.brand.com [203.0.113.45]). When the EHLO hostname matches the PTR record for the sending IP and the A record for the EHLO hostname resolves to the sending IP, the FCrDNS (Forward-Confirmed Reverse DNS) check passes. Receiving servers verify this in the Received header and use it as a baseline identity check.

Authentication Headers

The Authentication-Results: header is added by the receiving server after completing SPF, DKIM, and DMARC verification. It records the result of each authentication check: spf=pass (domain of brand.com designates 203.0.113.45 as permitted sender), dkim=pass header.i=@brand.com header.s=2022 header.b=ABCD1234, dmarc=pass (p=quarantine). Reading the Authentication-Results header from a test message delivered to a seed inbox confirms that all three authentication mechanisms are passing correctly — which is the fastest way to verify end-to-end authentication configuration.

The DKIM-Signature: header contains the DKIM signature added by the sending MTA. Key fields to verify: d= should show the programme's own domain (brand.com), not an ESP's shared domain; s= should match the selector used in the DNS TXT record for the public key; h= should include at minimum From, To, Subject, Date, and Message-ID; bh= is the body hash that confirms the message body was not modified in transit. A DKIM signature with a missing or incorrect d= value is the most common DKIM misconfiguration, and it is immediately visible in the header.

The Received-SPF: header is added by the receiving server after SPF evaluation. A passing SPF result shows: pass (domain of mail.brand.com designates 203.0.113.45 as permitted sender). A failing result — fail, softfail, or permerror — indicates that the sending IP is not in the SPF record for the MAIL FROM domain, or that the SPF record has errors. The Received-SPF header from a test message provides direct evidence of the SPF evaluation outcome without requiring the operator to manually evaluate the SPF record.

The From, Reply-To, and List Headers

The From: header is the visible sender identity that recipients see and that ISPs use for DMARC alignment evaluation. The From: header domain must match (or be an organisational subdomain of) the DKIM signing domain or the MAIL FROM domain for DMARC alignment to pass. The From: header should contain a human-readable name alongside the email address: Brand Name <newsletter@brand.com> rather than just the email address.

The List-Unsubscribe: header enables one-click unsubscribe from email clients that support it (Gmail, Apple Mail) and from ISP-level unsubscribe interfaces. The correctly formatted header: List-Unsubscribe: <https://brand.com/unsubscribe?id=XXX>, <mailto:unsubscribe@brand.com?subject=unsubscribe>. Gmail's 2024 requirements also mandate the List-Unsubscribe-Post: header for one-click POST support: List-Unsubscribe-Post: List-Unsubscribe=One-Click. Both headers must be present for Gmail's one-click unsubscribe interface to display correctly.

The Message-ID: header uniquely identifies each message in the email system. It should follow the format <unique-id@sending-domain.com> where the sending domain matches the DKIM signing domain or the MAIL FROM domain. Missing or improperly formatted Message-ID headers are a spam scoring factor at some ISPs — legitimate commercial senders always include valid Message-IDs. PowerMTA generates Message-IDs automatically when configured; verify that the generated format matches the expected pattern.

Header analysis — reading the full headers from a test message delivered to a seed inbox — is the most direct verification method for the complete sending infrastructure configuration. It simultaneously verifies authentication (Authentication-Results), DKIM configuration (DKIM-Signature), delivery path (Received headers), and compliance headers (List-Unsubscribe). Building header analysis into the standard pre-campaign verification process — sending a test message to a seed inbox and checking the full headers before injecting the full campaign — catches configuration drift before it affects production delivery. The 10 minutes of header review before a campaign is the cheapest and most complete configuration verification available.

Using Header Analysis for Configuration Verification

The standard pre-campaign header verification workflow: (1) Send a test message from the production sending infrastructure to a Gmail seed address and a Yahoo seed address. (2) Open the test message and view full headers (Gmail: three-dot menu → Show original; Yahoo: three-dot menu → View raw message). (3) Verify the Authentication-Results header shows spf=pass, dkim=pass, dmarc=pass for both Gmail and Yahoo. (4) Verify the DKIM-Signature header shows d=brand.com (own domain, not ESP). (5) Verify the List-Unsubscribe and List-Unsubscribe-Post headers are present with correct values. (6) Verify the Message-ID follows the <uuid@brand.com> format. (7) Check the Received headers for FCrDNS consistency — the sending IP and EHLO hostname should match.

This 7-step verification takes 10-15 minutes and confirms the complete authentication and compliance header configuration for the campaign. Any failed check identifies a configuration issue that should be resolved before the campaign is deployed to production. The most common issues discovered through header verification: DKIM signing with ESP domain instead of own domain (identified in DKIM-Signature d= field), missing List-Unsubscribe-Post header (visible by its absence in the header list), SPF permerror from lookup limit (visible in Received-SPF as permerror), and DMARC failure from misaligned DKIM domain (visible in Authentication-Results as dmarc=fail).

Header verification should be run not just before new campaigns but after any configuration change to the sending infrastructure: DKIM key rotation, ESP migration, new VMTA configuration, template system changes that modify header generation. Configuration changes are the most common source of header misconfiguration — the change is applied, production traffic begins, and the misconfiguration is discovered days later from deliverability signals rather than immediately from header verification. Building header verification into the change deployment checklist prevents this delay.

Anomalous Headers: What They Indicate

Certain header patterns indicate configuration problems or security issues that require investigation. Multiple DKIM-Signature headers: A message with two DKIM-Signature headers (one from the sending MTA, one from a forwarding server) is normal — the forwarding server's DKIM signature may fail (message body modification), but the original sending MTA's signature should remain valid. Two DKIM-Signature headers from the same domain suggest that the message is being double-signed, which is a configuration anomaly to investigate but not a delivery failure risk. X-Original-To header: The presence of an X-Original-To header indicates the message was forwarded or processed by a mailing list system. This is relevant for understanding why DKIM may fail at the recipient if the forwarding service modified the message body.

Missing Message-ID: A message without a Message-ID header is misconfigured — all legitimate commercial email should have a unique Message-ID. Some poorly configured injection systems omit this header; PowerMTA generates it automatically. Missing Message-IDs are a spam scoring factor at many ISPs. X-Mailer header: The X-Mailer or User-Agent header identifies the email client or sending software. Spam filters may use this header as a signal; legitimate commercial sending MTAs (PowerMTA, Postfix) produce consistent, recognisable X-Mailer values. A missing X-Mailer is not a problem; an incorrect or suspicious X-Mailer may be a scoring factor for some spam filters.

Unusual X-headers: Custom X-headers are often added by campaign management systems for internal tracking (X-Campaign-ID, X-Mailchimp-ID, X-SendGrid-ID). These X-headers are visible to receiving servers and to recipients who view full headers, but they are not evaluated as spam signals by major ISPs in the same way that authentication headers are. They may inadvertently reveal internal campaign management information to recipients who view full headers — which is generally acceptable for transparency but should be understood as intentionally public information.

Header analysis is the most direct form of sending infrastructure configuration verification available. Every configuration element that affects delivery — authentication, identity, compliance — produces a corresponding header in the delivered message that can be read and verified from any seed inbox. Making header verification a routine practice, both before campaigns and after configuration changes, converts a rarely-used diagnostic tool into a systematic quality assurance practice that catches configuration drift early and maintains infrastructure integrity continuously. The headers speak; read them regularly, and the infrastructure will rarely surprise you with unexpected delivery problems.

The ARC Header Chain

Authenticated Received Chain (ARC) is a newer header system that allows email handling intermediaries (mailing lists, forwarding services) to pass authentication information through the forwarding chain. When a message is forwarded through a service that modifies the message body (breaking DKIM), the forwarding service can add ARC headers that attest to the authentication status before modification, allowing the final receiving server to evaluate the original authentication status alongside the current (post-modification) state.

ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers appear in messages that have been processed by ARC-capable intermediaries. Google, Microsoft, and Yahoo support ARC evaluation — when a message fails DKIM due to body modification by a mailing list but passes ARC, the ISP may use the ARC authentication chain to establish that the original sender was legitimate. This is particularly relevant for programmes whose recipients forward messages to other addresses or subscribe via mailing lists.

For outbound sending infrastructure, ARC is not directly relevant — the sending MTA does not need to generate ARC headers for outbound messages. ARC headers are added by intermediaries, not by original senders. Understanding ARC is relevant for diagnosing DKIM failures in forwarded messages: if DKIM fails in the Authentication-Results but ARC-Authentication-Results shows a passing chain, the failure is from forwarding body modification rather than from original sender misconfiguration. This distinction prevents unnecessary DKIM configuration changes in response to forwarding-induced DKIM failures.

Tools for Header Analysis

The primary header analysis tools available to email infrastructure operators: Mail-tester.com: sends a test message to a randomly generated address at mail-tester.com and provides a multi-signal analysis including authentication results, header verification, and spam scoring. Particularly useful for verifying authentication configuration as a complete check. MXToolbox Email Header Analyzer: accepts a raw header paste and analyzes the delivery chain, authentication results, and timing between hops. Google's GSuite Header Analyzer: available through Google Admin for Workspace accounts, provides Google-specific header analysis. Postmaster Tools test message: sending to a Gmail address and viewing the raw message provides the most accurate representation of how Gmail sees the message, including the Authentication-Results as Gmail generates them.

For ongoing header monitoring (beyond pre-campaign verification), seed address infrastructure — a set of email addresses at Gmail, Yahoo, Microsoft, and EU ISPs that receive a copy of each campaign — provides the data to review full headers for any campaign at any time. The seed addresses receive the message as an ordinary subscriber would, making their headers representative of the delivery experience for actual recipients. Seed list monitoring combined with header analysis capability covers both the inbox/spam placement monitoring and the authentication/compliance header verification with a single seed send per campaign.

Headers are the infrastructure's output, made visible. Reading them correctly — knowing what each header should say, what anomalies look like, and what misconfigurations they reveal — is the diagnostic literacy that makes email infrastructure management evidence-based rather than assumption-based. Every configuration decision the operator makes eventually manifests in headers that can be read and verified. Build the habit of reading them; maintain the standard of verifying them before every campaign; and the sending infrastructure's configuration will remain correct, verified, and documented through every change the programme makes.

What Headers Cannot Tell You

Header analysis reveals what the sending infrastructure produced and how the receiving server evaluated it — but it cannot reveal what happened inside the receiving ISP's spam classification process after the message was accepted. A message that passes all authentication checks (Authentication-Results shows spf=pass, dkim=pass, dmarc=pass) may still be delivered to the spam folder if the sender's domain reputation is Low at the ISP. The headers show that authentication passed; the inbox placement decision reflects the reputation tier, which is visible in Postmaster Tools (for Gmail) and SNDS (for Microsoft) but not in the message headers themselves.

This limitation is why header analysis is one component of a multi-tool verification process rather than the complete verification in itself. Header analysis verifies authentication and compliance headers; Postmaster Tools reveals domain and IP reputation; seed inbox monitoring reveals actual inbox vs spam placement; the accounting log reveals delivery rates and response codes. Together, these four data sources cover the complete delivery picture that no single source provides alone.

Understanding what headers tell you (authentication outcome, delivery path, compliance header presence) and what they do not tell you (reputation-based filtering decisions, post-acceptance placement decisions, ISP-internal routing) ensures that header analysis is used correctly as a configuration verification tool rather than misinterpreted as a delivery outcome diagnostic. Both capabilities are needed; use the right tool for each purpose.

The message headers are the contract between the sending infrastructure and the receiving server: they specify the sender's identity, authenticate the message, and indicate compliance with the receiving server's requirements. Reading them verifies that the contract is being offered correctly; the reputation data confirms whether the contract is accepted on favorable terms. Both matter; header analysis provides the first half of this picture with clarity and immediacy. Build the practice of reading headers; maintain the habit of verifying them; and the sending infrastructure's configuration will never drift from the correct state without the operator knowing it.

Headers are the language of email infrastructure. Learning to read them fluently -- knowing what each field means, what correct values look like, and what anomalies indicate -- is the diagnostic skill that makes every other deliverability practice more precise. Configuration changes become verifiable. Authentication problems become identifiable. Compliance gaps become visible. Header analysis is the diagnostic lens that makes the invisible visible. Use it before every campaign; use it after every configuration change; and the sending infrastructure will remain correctly configured and fully verified throughout the programme's entire operational lifetime.

The Pre-Campaign Header Checklist in Practice

The pre-campaign header checklist converts header analysis from a one-time diagnostic exercise into a systematic quality gate. For each production campaign before injection: send a test message to Gmail and Yahoo seed addresses; view full headers; check the seven items documented earlier in this note; record the results in the campaign management log; proceed to injection only when all seven items pass. This checklist approach takes 15 minutes per campaign and provides documented evidence that the sending configuration was verified before deployment.

For automated campaign workflows where manual header verification before each send is impractical, a periodic header verification cadence is the alternative: verify headers monthly (even when no configuration changes have occurred), and always verify immediately after any infrastructure change. The monthly verification catches configuration drift from ISP-side changes (an ISP update that changes how they report authentication results), system updates (MTA software updates that modify header generation), or certificate rotations that may introduce configuration mismatches.

The 10 minutes invested in header verification before a campaign deployment is the lowest-cost, highest-coverage configuration verification available. It exercises the complete authentication stack end-to-end, from the sending MTA's DKIM signing through the receiving server's SPF and DMARC evaluation, and reports the result in a single, readable header. Make it a habit. Make it a checklist item. Make it a quality gate. The configuration problems it catches before deployment are the deliverability incidents it prevents after deployment. That prevention is the return on the 10-minute investment, compounded over every campaign the programme ever sends.

Every misconfigured header is an infrastructure problem that header analysis catches before it becomes a delivery problem. Every correctly configured header is a signal that the infrastructure is doing its job. Read the signals. Verify the configuration. Trust what the data shows. That is evidence-based email infrastructure management in its most direct form.

Headers are the evidence. Read the evidence before every campaign. The configuration it validates will deliver the messages correctly; the problems it reveals will be corrected before they become deliverability incidents. That is the return on 10 minutes of header review — a return that compounds across every campaign the programme sends.

The receiving server's Authentication-Results header is the ground truth for your sending infrastructure's authentication configuration. Read it in every test message, before every campaign deployment, and after every infrastructure change. When it shows pass across SPF, DKIM, and DMARC, the configuration is correct. When it shows anything else, the configuration needs attention. The header never lies; it only shows what the receiving server actually evaluated. Trust it. Act on what it shows.