Header Hygiene in High-Volume Sending: What ISP Filters Inspect

• March 2020
• Engineering Memo · External Release

Email headers are the metadata layer of a message — they tell receiving servers who sent the message, when, to whom, with what priority, and through what infrastructure. In high-volume sending, header hygiene — the correctness, completeness, and consistency of the message headers — contributes to deliverability through ISP filtering signals that many operators underestimate relative to the more visible factors of IP reputation and authentication.

This note documents which headers ISP filters inspect, what signals each header generates, and the specific header hygiene practices that distinguish well-formed high-volume email from the header patterns associated with spam and automated bulk sending systems.

Why Headers Matter to ISP Filters

ISP spam filters began as primarily content-based systems — scoring messages based on word patterns in the subject and body. Modern ISP filters, particularly Gmail's ML-based classification, evaluate the complete message including headers as part of a multi-dimensional scoring system. Headers that deviate from RFC 5322 specifications, contain internal inconsistencies, or match patterns associated with spam infrastructure generate negative scoring signals — not of the same magnitude as complaint rate or authentication failure, but accumulating over millions of messages into measurable effects on domain reputation and inbox placement.

The filtering consequence of poor header hygiene is typically not a hard rejection (5XX) — it is increased scrutiny and slight spam-folder routing probability. At high volume, "slight" effects become statistically significant: a 2-percentage-point inbox placement disadvantage from systematically poor header hygiene, compounded across 1 million messages per month, represents 20,000 messages that did not reach the inbox when they would have from a correctly-headered sender with equivalent reputation.

The From: Header — Identity, Alignment, and Display Name

The From: header is the most critical header for both authentication (DMARC alignment) and recipient trust (the name they see). Its format requirements under RFC 5322 are: either a bare email address (user@domain.com) or a display name followed by an email address in angle brackets (Display Name <user@domain.com>). Violations of this format — malformed addresses, missing angle brackets, improperly encoded display names — generate parsing errors that some ISPs treat as suspicious signals.

For DMARC alignment, the From: header's domain must align with either the domain in the DKIM signature (d= tag) or the domain in the MAIL FROM (Return-Path). Misalignment — From: user@brand.com but DKIM d=esp.com with no SPF alignment — causes DMARC failure regardless of how correctly each individual authentication mechanism is configured. The From: domain is the anchor of the entire authentication chain.

The display name deserves specific attention for spam filter evaluation. Display names that contain the full domain (e.g., "Brand Name brand.com") duplicate information in ways that are associated with phishing attempts that use the display name to impersonate a legitimate domain. Display names that are entirely different from the brand (the From: address shows user@brand.com but the display name says "Amazon Security Notice") are the classic phishing pattern. While legitimate senders would never do the latter, the former is a common well-intentioned mistake that some filters flag. Keep display names to the brand name only: "Brand Name" or "Brand Name Team" — not "Brand Name | newsletter.brand.com" or "Brand Name — unsubscribe here".

The Message-ID Header — Uniqueness and Format

The Message-ID header must be present in every email and must be globally unique — no two messages should share a Message-ID. The format is <local-part@domain>, where the domain should be the sending domain or a subdomain of it (not @localhost, which is the default in many MTA configurations). The local part should be sufficiently random or time-based to ensure uniqueness at scale.

PowerMTA generates Message-IDs automatically with a random component and the virtual MTA's configured hostname as the domain. The default configuration is typically correct — using the EHLO hostname as the Message-ID domain. The configuration to verify: if the EHLO hostname is a generic internal hostname rather than the sending domain's hostname, Message-IDs will reference an internal domain that does not match any DNS record. Change the smtp-source-host configuration to use a publicly resolvable hostname consistent with the sending domain, and Message-IDs will be generated with appropriate domain references.

Sequential Message-IDs — where each message has an ID that is simply one number higher than the previous (001@domain.com, 002@domain.com) — are associated with spam systems that generate simple sequential identifiers. Randomised identifiers that include a timestamp component and at least 12 random characters are the correct pattern. A Message-ID like <1714567890.x8k4m2p9q3hs@mail.yourdomain.com> (Unix timestamp + random hex + domain) meets uniqueness requirements without exposing sequential patterns.

The Date: Header — Accuracy and Timezone Handling

The Date: header must be present and must accurately reflect when the message was created, in RFC 2822 format with a timezone offset (e.g., "Tue, 01 Apr 2025 09:30:00 +0000" or equivalent local timezone). ISP filters flag Date: headers that are in the future (messages dated later than their delivery time), very far in the past (messages dated months before delivery, indicating a queued and delayed message or a spoofed date), or in incorrect format.

The most common Date: header problem in high-volume environments: messages that sit in the delivery queue for extended periods because of deferral accumulation, by which time the Date: header (set at injection time) may be hours or days old. An ISP receiving a message whose Date: header says it was created 3 days ago, delivered today, will see a large timestamp gap between creation and delivery. While this is not a definitive spam signal on its own, it combines with other signals in the spam classification — and it is an indicator of the retry pressure problem that produces extended queue times, which is itself a reputation signal.

PowerMTA sets the Date: header at injection time, which is correct. The way to prevent Date: staleness in production is to prevent message age accumulation in the queue — correct retry configuration, adequate throughput capacity, and active deferral management. The Date: header symptom is a diagnostic indicator of queue health problems, not an independent header problem to be solved separately.

List-Unsubscribe: The Bulk Email Standard Header

The List-Unsubscribe header is an established standard for bulk email, defined in RFC 2369 (1998) and widely supported by major email clients and ISPs. For high-volume senders, including this header is a best practice that directly affects deliverability: ISPs including Gmail and Yahoo use the presence of a properly formatted List-Unsubscribe header as a positive trust signal, because it demonstrates that the sender has implemented the infrastructure to process unsubscribes programmatically.

The header format includes two mechanisms: a mailto: URI that allows email clients to send an unsubscribe email on the recipient's behalf, and an https: URI that links to a web-based unsubscribe endpoint. Both mechanisms should be present in every bulk marketing email. The correct format: List-Unsubscribe: <mailto:unsub@yourdomain.com?subject=unsubscribe>, <https://yourdomain.com/unsubscribe?uid={unique_id}>.

Gmail displays a visible "Unsubscribe" link in the email interface for messages that include a valid List-Unsubscribe header with an https: URI. This display reduces the friction of the unsubscribe process, which in turn reduces the number of recipients who use the "Report Spam" button as a substitute for unsubscribing — a direct benefit to the sender's complaint rate and domain reputation.

The https: endpoint referenced in the List-Unsubscribe header must be publicly accessible and functional. A non-functional unsubscribe endpoint is treated by ISPs and spam filters as evidence of bad-faith list management. The endpoint should confirm unsubscription immediately, add the address to the global suppression list, and display a clear confirmation to the recipient. MailWizz generates correct List-Unsubscribe headers automatically when configured correctly in the campaign delivery settings.

Received: Header Chain — Inferring Infrastructure

The Received: header chain — the set of trace headers added by each MTA that handled the message in transit — tells ISPs the path the message took from sender to recipient. ISP filters read this chain to: verify the sending infrastructure matches the From: domain's claimed infrastructure, identify unexpected relay hops that might indicate message re-routing through compromised servers, and check the total transit time (very long transit times suggest queue accumulation from retry pressure).

For legitimate bulk email, the Received: header chain should be short — typically 2–3 hops: the sending MTA, possibly an intermediate relay, and the receiving ISP's MX server. Chains with 5 or more hops suggest the message was forwarded multiple times or traversed an unusual network path. The sending MTA's Received: header should include the EHLO hostname that matches the PTR record of the sending IP — FCrDNS-inconsistent Received: headers (where the EHLO hostname in the header doesn't match the IP's PTR record) add to the authentication mismatch signals that increase filter scrutiny.

PowerMTA configuration can suppress the internal "Received:" header that it adds when injecting messages from the sending application — the injection-side Received: header reveals internal server addresses and PowerMTA version information that is not useful for delivery and can be fingerprinted by filters. The PowerMTA received-header no directive in the source configuration suppresses this header for injection connections from trusted local sources.

MIME Headers and Content-Type Consistency

MIME headers — Content-Type, MIME-Version, and Content-Transfer-Encoding — must be consistent with the message content. A message declared as text/html in the Content-Type header but containing plain text without HTML tags, or a message declared as multipart/alternative but containing only one MIME part, creates inconsistency that some filters flag. These are not common errors in well-configured sending environments, but they appear in custom-built sending systems that handle MIME construction without thorough RFC compliance.

The most common MIME header hygiene issue in production: missing or incorrect charset declarations. HTML messages must declare a charset — typically UTF-8 — in either the Content-Type header (Content-Type: text/html; charset=utf-8) or in an HTML meta tag. Messages without charset declarations may be rendered incorrectly by email clients in some configurations, and their DKIM signatures are more vulnerable to encoding-related failures during transit as described in the encoding issues note.

Multipart/alternative messages — which include both HTML and plain-text versions of the same content — are the best practice format for marketing email. ISP filters that process content for spam classification can read the plain-text part even when image-heavy HTML bodies provide limited text for analysis. Plain-text parts also reduce the image-to-text ratio concern that affects messages where all visible content is in images. MailWizz generates multipart/alternative messages by default when both HTML and text versions are configured in the campaign.

Automated Header Verification in Production

Header hygiene verification should be part of the pre-send checklist for every new campaign template and every infrastructure configuration change. The verification process: send a test message from the production sending infrastructure to a test inbox at Gmail, Yahoo, and Microsoft; retrieve the raw message source; verify that all required headers are present in the correct format; verify that the Received: header chain is the expected length; verify the Message-ID domain is correct; verify List-Unsubscribe is present with both mailto: and https: URIs and that the endpoint is functional; verify Date: is current and in correct format.

For high-volume environments, automated header verification can be built into the pre-campaign injection pipeline: a pre-flight check that injects a test message, retrieves it from a monitored test inbox, parses the headers programmatically, and passes or fails the campaign deployment based on header compliance. This catches header issues before any recipients receive the campaign, rather than discovering them from DMARC reports or ISP feedback after the campaign has sent. The pre-flight check is a one-time engineering investment that prevents a recurring category of avoidable deliverability issues.

Custom X-Headers: Useful or Noise?

Custom X-headers (non-standard headers prefixed with X-) serve two functions in high-volume email: they carry campaign metadata that the bounce processing and FBL complaint handling systems use to attribute bounces and complaints back to specific campaigns, and they provide operational context that can be useful for diagnosing delivery problems. Both functions are legitimate and well-served by custom X-headers.

The hygiene concern: spam systems frequently add custom X-headers with distinctive fingerprints that ISP filters learn to associate with those systems. An X-header that uniquely identifies the email software version (X-Mailer: SendBulkEmails 3.2.1) or the infrastructure provider in a way that is associated with known spam operations creates a filter signal regardless of the message content or sender reputation. The principle: use X-headers for operational purposes (X-Campaign-ID, X-List-ID, X-Sender-ID) that serve your own bounce and complaint processing pipeline, but avoid verbose X-headers that identify specific software versions or infrastructure details.

In PowerMTA, custom X-headers can be added to outgoing messages through the source directive configuration or through headers in the injected message itself. MailWizz adds campaign identifiers as X-headers in the injected message for bounce processing purposes. Reviewing which X-headers are added and ensuring none create unnecessary fingerprinting is part of the initial configuration review for any new sending environment.

The Return-Path and Bounce Domain

The Return-Path header (equivalent to the MAIL FROM envelope address) specifies the email address where bounce notifications (DSN messages) are sent. In standard configurations, this is the bounce processing address — bounce@yourdomain.com or a randomly generated bounce address per message (VERP — Variable Envelope Return Path) that enables precise bounce attribution to individual recipient addresses.

The Return-Path domain has SPF significance: it is the domain whose SPF record is checked for the sending IP. For SPF alignment under DMARC, the Return-Path domain must match the From: domain (exact match under strict alignment, or organisational domain match under relaxed alignment). Using a return-path domain that is completely different from the From: domain — for example, a dedicated bounce domain that is not a subdomain of the From: domain — produces SPF alignment failure for DMARC, meaning the programme must rely entirely on DKIM for DMARC compliance.

VERP (Variable Envelope Return Path) uses a unique Return-Path address per recipient — typically formatted as bounce+recipient-hash@yourdomain.com — that allows the bounce processing system to identify which recipient address bounced from a single inbound bounce message, without needing to parse the bounced message body. This is the most precise bounce attribution approach for high-volume environments and is supported by MailWizz's bounce server configuration. The VERP subdomain must be part of the SPF record for the sending domain and must forward-resolve correctly in DNS for the Return-Path to function as expected.

Header Ordering and RFC Compliance

RFC 5322 specifies an advisory ordering for headers — the order in which they conventionally appear. While the ordering is not strictly enforced by most receiving servers, non-standard header ordering can trigger scoring signals in filters that look for ordering patterns associated with spam systems. The conventional ordering places origination headers first (From:, To:, Date:, Subject:), followed by authentication-related headers (Received:, DKIM-Signature:), then content-related headers (MIME-Version:, Content-Type:), and finally X-headers.

PowerMTA respects standard header ordering in messages it processes. The ordering concern typically arises in custom-built sending systems where headers are added in a non-standard sequence by the application code. If the sending application adds headers in unusual order — Subject: before From:, or custom X-headers before standard headers — the message structure deviates from expected patterns. While this is a minor signal individually, it combines with other signals in the multi-dimensional scoring that ISP filters apply.

The most reliable approach: use the campaign management platform (MailWizz) to generate headers rather than custom application code, because established platforms generate headers in RFC-compliant order by default. When custom application code is unavoidable, follow the RFC advisory ordering explicitly in the code's header generation logic.

Subject Line Length and Encoding

The Subject: header is the most visible header to recipients and receives significant attention in email marketing for open rate optimisation. From a header hygiene perspective, it has specific length and encoding requirements that affect both rendering and spam filter scoring.

RFC 5322 recommends keeping headers to 78 characters per line, with line folding for longer content. Subject lines longer than 78 characters should be folded (split across lines with whitespace indentation) according to RFC 2822 folding rules. Many email clients handle unfolded long subject lines correctly, but some processing systems or spam filters may treat excessively long unfolded subjects as a formatting violation signal.

Subject lines containing non-ASCII characters — emojis, accented characters, non-Latin scripts — must be encoded using RFC 2047 encoded-words or the SMTPUTF8 extension. The most widely compatible approach for emoji in subject lines is UTF-8 encoding declared with the charset parameter. The challenge: encoded subject lines that are too long after encoding may be truncated in some email clients, potentially breaking the message's intended subject line. Testing subject line rendering across major email clients is advisable for campaigns that include non-ASCII characters in subject lines, separate from the deliverability testing process.

Spam filters have historically associated certain subject line patterns with spam: excessive punctuation (multiple exclamation marks), all-caps words, extreme urgency language ("ACT NOW", "URGENT"), and very long subject lines that appear in the recipient's inbox as truncated. These content-level considerations are distinct from the structural header hygiene concerns discussed in this note, but they interact: a structurally malformed Subject: header on a message with spam-associated content patterns amplifies the negative signals from both.

Header hygiene is the foundational correctness layer of email that many operators address only reactively — when DMARC reports reveal alignment problems, when Gmail rejects messages for missing unsubscribe headers, or when filter signals indicate a header-related issue. Proactive header hygiene — verifying all headers before campaign deployment, maintaining RFC compliance in all sending paths, and monitoring header-related signals in DMARC reports — prevents these reactive situations. The investment is modest: a template verification checklist and a pre-flight test process require minimal engineering time and eliminate a category of preventable deliverability issues that otherwise surface under the worst possible conditions — during active campaign sends at high volume. Headers that are correct from the start, maintained through configuration discipline, and verified before each campaign launch represent the baseline professionalism that distinguishes infrastructure managed for deliverability excellence from infrastructure that merely functions at baseline correctness.