An email header is the machine-readable section at the top of an email that tells mail systems who sent it, where it traveled, when it was created, how it was formatted, and whether key authentication checks passed. Recipients usually see only the subject line and message body, but mailbox providers use email headers heavily to evaluate legitimacy, routing, and deliverability.

What is an email header?

Every internet email has two major sections: the header and the body. The header comes first, followed by one blank line, then the body content that the recipient reads. An email header is made up of individual fields written as Field-Name: value pairs.

A simple message might begin like this:

From: Acme Alerts <alerts@notify.acme.example>
To: Maya Chen <maya@example.net>
Subject: Your deployment completed
Date: Tue, 08 Sep 2026 14:32:18 +0000
Message-ID: <20260908143218.48291@notify.acme.example>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Some header fields are created by the person or application sending the email. Others are added by the sending platform, receiving provider, spam filter, security gateway, forwarding service, or recipient mailbox as the message moves through the delivery path.

That distinction matters. A visible From: field is a sender claim; it does not, by itself, prove that the message was authorized by that domain. By contrast, authentication-related fields such as DKIM-Signature:, Authentication-Results:, and Received-SPF: document checks performed by mail infrastructure. Delivery headers such as Received: show the servers that handled the message.

Headers are not a single deliverability score or campaign metric. You do not calculate an “email header rate.” Instead, you inspect headers to understand the technical evidence behind metrics such as inbox placement, spam complaints, bounces, authentication pass rate, click rate, and unsubscribes.

Why email headers matter for deliverability

Mailbox providers must decide whether a message is safe, wanted, and correctly identified before they place it in an inbox, route it to spam, defer it, or reject it. Headers give them much of the structured information needed to make that decision.

A provider can use headers to assess whether:

  • the sending domain is authenticated;
  • the visible From: domain aligns with SPF or DKIM;
  • the message traveled through plausible, authorized infrastructure;
  • the sending server identifies itself consistently;
  • the message has valid date, address, and MIME formatting;
  • bulk mail contains required unsubscribe information;
  • the content was altered by a forwarder, mailing list, or security gateway;
  • the message resembles known phishing, spoofing, or spam patterns.

An email can have excellent copy, a recognizable brand, and a clean recipient list but still underperform when its technical headers are incomplete, misleading, malformed, or inconsistent. That is because deliverability starts before a person sees the message. The receiving server evaluates the envelope, connection, authentication records, reputation signals, content, and headers during acceptance and filtering.

Headers create an evidence trail

Think of an email header as a shipment label plus chain-of-custody record. The recipient-facing message may say it came from updates@yourbrand.example, but the header can show the actual sending service, mail-from domain, signing domain, relay hops, encryption status, and authentication result.

For legitimate senders, this evidence helps providers distinguish real application messages and campaigns from spoofed copies. For recipients and support teams, it makes technical troubleshooting possible. If an important password-reset message is missing, the full headers can reveal whether it was sent, deferred, rejected, routed through a security gateway, or delivered to spam.

Authentication is visible in headers

SPF, DKIM, and DMARC work alongside header fields and SMTP-envelope information. In broad terms:

  • SPF checks whether the IP address that sent the message is authorized to use the envelope sender domain.
  • DKIM adds a cryptographic signature in a DKIM-Signature: header. The recipient retrieves the corresponding public key from DNS and verifies that the signed parts of the message have not changed.
  • DMARC evaluates whether SPF or DKIM passed and whether the authenticated domain aligns with the domain shown in the visible From: header.

Google’s sender guidelines require all senders to Gmail to use SPF or DKIM, while bulk senders must use SPF, DKIM, and DMARC. That makes header-level authentication evidence essential for any program sending meaningful volume to Gmail recipients.

Headers affect campaign performance indirectly

Headers do not make an email persuasive on their own. They do, however, influence whether the email reaches the inbox where a subscriber can open, click, reply, or convert.

For marketing and lifecycle campaigns, bad authentication or faulty unsubscribe headers can increase spam placement, complaints, and blocks. For transactional email, header problems can be even more serious: a recipient may miss a verification link, receipt, login alert, or account notification because the message was filtered or rejected.

A reliable sending setup therefore treats header quality as foundational infrastructure, not as a final compliance detail.

The most important email header fields

A full header can contain dozens of fields. Some are standardized and required in normal message construction; others are optional, provider-specific, or added by intermediaries. The following fields are the most useful starting point when diagnosing sending and deliverability.

From, To, Cc, Reply-To, and Sender

The From: field identifies the author address displayed to the recipient. In standard email, every message should have a From: field. It is the identity users see in their mailbox interface.

From: Volanea Product <product@updates.example.com>

The To: and Cc: fields are display headers for intended recipients. They are not the same thing as SMTP envelope recipients, and they may not always represent every address that received a copy. Mailing lists, Bcc delivery, aliases, and forwarding can make the envelope path different from the visible fields.

Reply-To: tells the recipient’s email client where a reply should go. It is useful when a team sends from one identity but wants replies handled elsewhere, such as a support queue.

From: Northstar Billing <billing@northstar.example>
Reply-To: Northstar Support <support@northstar.example>

Sender: is less common in everyday application email. It can identify the agent that actually transmitted a message on behalf of the author when that sender differs from From:. Do not add it casually. A confusing Sender: value can make a message harder to understand and complicate identity analysis.

Subject, Date, and Message-ID

Subject: is the recipient-facing topic line. It affects engagement and may be included in DKIM signing, but it is not a proof of identity.

Date: describes when the message was composed. A wildly incorrect date can make an email look broken, affect threading, or confuse users. Make sure application servers keep accurate time through standard time synchronization.

Message-ID: is a globally distinctive identifier for a message. It commonly looks like this:

Message-ID: <e7f50760-6e53-4f5e-a5ca-222d490d1a21@notify.example.com>

Clients and servers use it for threading, duplicate detection, replies, and references. A message ID should be generated for each individual outbound message. Reusing one Message-ID across many sends can lead to threading mistakes, deduplication behavior, or confusing support investigations.

Received: the delivery path

Every mail server that accepts and relays a message typically prepends a Received: field. Because each new hop adds its line above existing lines, read the chain from the bottom upward to reconstruct the earliest visible path.

A simplified example:

Received: from outbound.mail.example (outbound.mail.example [192.0.2.44])
        by mx.recipient.example with ESMTPS id 7B8C9D
        for <maya@example.net>; Tue, 08 Sep 2026 14:32:25 +0000
Received: from app.internal.example (app.internal.example [10.0.0.15])
        by outbound.mail.example with ESMTP id A1B2C3
        for <maya@example.net>; Tue, 08 Sep 2026 14:32:20 +0000

The exact syntax and detail vary by server. A Received: chain can help identify unexpected relays, routing loops, delivery delays, sending IPs, and differences between what the sender expected and what the recipient provider observed.

However, do not assume every line is equally trustworthy. A server can add a header line to a message it receives, and untrusted content may contain forged header-like fields. The lines added by infrastructure you trust, especially the receiving provider’s own topmost records, carry the most diagnostic value.

Return-Path and the envelope sender

Return-Path: usually represents the SMTP envelope sender after final delivery. It is where non-delivery reports and many bounce messages are directed.

Return-Path: <bounces+customer-48291@bounce.example.com>

This address is often different from the visible From: address. That is normal. For example, a product notification can visibly come from alerts@product.example while bounces are processed at bounce.example.com.

The important deliverability question is whether the envelope sender domain has a valid SPF configuration and, when SPF is used for DMARC, whether it aligns with the visible From: domain under the organization’s DMARC policy. A different domain is not automatically wrong; an unaligned domain can be a problem when DKIM also fails or lacks alignment.

MIME-Version, Content-Type, and Content-Transfer-Encoding

MIME fields explain how the message body is structured and encoded. They are essential for reliable rendering of HTML, text alternatives, attachments, international characters, and inline media.

MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="boundary_4db7e9"

A multipart/alternative email generally includes both plain-text and HTML versions, allowing the recipient client to choose the most appropriate format. A simplified structure looks like this:

Content-Type: multipart/alternative; boundary="b1"

--b1
Content-Type: text/plain; charset=UTF-8

Your invoice is ready.

--b1
Content-Type: text/html; charset=UTF-8

<p>Your invoice is ready.</p>

--b1--

Malformed boundaries, invalid character declarations, missing encodings, or poorly generated HTML can create broken messages. In severe cases, they can also change the content after DKIM signing and cause signature verification failures.

List-Unsubscribe and List-Unsubscribe-Post

For marketing and subscription-based mail, unsubscribe headers make it easier for mailbox providers and recipients to process opt-out requests. A common pattern is:

List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe: field can provide a mailto address, an HTTPS URL, or both. The List-Unsubscribe-Post: field supports one-click unsubscribe processing when used with an appropriate HTTPS endpoint.

These headers do not replace a visible unsubscribe link in the email body, consent records, or sensible audience management. They complement them. For bulk senders, they can reduce friction for recipients who no longer want mail and can help prevent the worse outcome: a spam complaint.

Authentication headers: SPF, DKIM, DMARC, and ARC

Authentication fields are among the most important email headers for modern deliverability. They show whether checks passed, failed, or could not be evaluated at a particular receiving system.

DKIM-Signature

A DKIM signature is placed in the DKIM-Signature: header before delivery. It includes tags that identify the signing domain, selector, signing algorithm, signed headers, body hash, and cryptographic signature.

Here is an abbreviated, illustrative example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026;
 c=relaxed/relaxed; h=from:to:subject:date:message-id:mime-version;
 bh=QmFzZTY0RW5jb2RlZEJvZHlIYXNo;
 b=QmFzZTY0RW5jb2RlZFNpZ25hdHVyZQ==

Key tags include:

  • d=: the signing domain;
  • s=: the DKIM selector used to locate the public key in DNS;
  • a=: the signing algorithm, such as rsa-sha256;
  • h=: the header fields covered by the signature;
  • bh=: a hash of the body content;
  • b=: the signature itself.

Receiving systems query a DNS record at a location based on the selector and signing domain, such as mail2026._domainkey.example.com. If the public key is available and the signed message components still match, DKIM can pass.

A DKIM pass does not mean a message is inherently safe or wanted. It means the receiver verified that an authorized signer took responsibility for the message and that the signed parts were not changed in transit. Reputation, content, recipient engagement, and DMARC alignment still matter.

Authentication-Results

The Authentication-Results: header records a receiving server’s assessment of authentication checks. It may include SPF, DKIM, and DMARC results.

Authentication-Results: mx.recipient.example;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=mail2026;
 dmarc=pass header.from=example.com

This is an evaluation by the server that added the line. Another server farther along the path can perform its own checks and add its own results. When troubleshooting, prioritize the results added by the recipient environment where the delivery issue occurred.

Received-SPF

Some systems add a Received-SPF: field that describes their SPF evaluation.

Received-SPF: pass (recipient.example: domain of bounces@example.com
 designates 192.0.2.44 as permitted sender)
 client-ip=192.0.2.44; envelope-from=bounces@example.com;
 helo=outbound.mail.example;

This can help identify the client IP, the envelope-from domain, and the HELO or EHLO identity evaluated. It is useful context, but the exact format and availability vary across providers.

DMARC results and alignment

DMARC is not a header field that the sender adds in the same way as From: or DKIM-Signature:. It is a DNS-based policy and reporting framework. Its outcome is often reported in Authentication-Results:.

For DMARC to pass, the message generally needs either:

  1. SPF to pass with an aligned envelope sender domain; or
  2. DKIM to pass with an aligned signing domain.

Alignment means the authenticated domain is the same as, or suitably related to, the domain in the visible From: field according to the domain’s DMARC policy.

For example, this can pass through DKIM alignment:

From: Updates <news@example.com>
DKIM-Signature: d=example.com; s=mail2026; ...
Authentication-Results: mx.recipient.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

By contrast, an email with From: news@example.com and a passing DKIM signature from an unrelated mailvendor.example domain may not satisfy DMARC alignment. The sending platform may legitimately sign with its own domain as an additional signature, but a sender should also configure a signature aligned with its brand domain.

ARC headers

ARC stands for Authenticated Received Chain. ARC can preserve authentication assessments across intermediaries such as mailing lists and forwarders that modify a message in ways that may otherwise break DKIM or DMARC.

ARC uses three related header fields:

  • ARC-Authentication-Results:;
  • ARC-Message-Signature:;
  • ARC-Seal:.

ARC can provide useful context for recipients handling indirect mail. It is not a substitute for setting up SPF, DKIM, and DMARC correctly for the mail you send directly.

How to read full email headers

Full headers can look intimidating because they contain long lines, encoded values, timestamps, server names, and multiple authentication results. The fastest approach is to read them in a deliberate order instead of trying to understand everything at once.

Start with the visible identity

First, locate:

From:
Reply-To:
Return-Path:

Ask three questions:

  1. What address and domain did the recipient see in From:?
  2. Where will a reply go?
  3. What envelope sender will receive bounces?

Different answers can be legitimate. The goal is not to force every domain to match exactly. The goal is to confirm that the differences are intentional, understandable, and compatible with authentication alignment.

Then inspect authentication results

Search for the most relevant Authentication-Results: entry, usually one inserted by the recipient mailbox provider or its security gateway. Look for spf=pass, dkim=pass, and dmarc=pass.

If DMARC fails, determine why. Common patterns include:

  • SPF passed, but the envelope sender domain did not align with From:;
  • DKIM passed, but d= did not align with From:;
  • the DKIM signature failed because signed content changed;
  • the sender used a domain without a valid or discoverable DKIM public key;
  • the recipient received a forwarded or list-modified version of the original message.

Trace Received headers from bottom to top

Find every Received: field and start with the bottommost entry. That usually reflects the earliest visible transfer. Move upward one hop at a time, comparing timestamps and hostnames.

This can uncover slowdowns. If one handoff happened at 14:32:20 +0000 and the next at 15:04:48 +0000, the message spent more than 32 minutes between those points. That does not automatically mean a failure, but it gives your delivery team a concrete interval to investigate.

Check message construction fields

Review Date:, Message-ID:, MIME-Version:, Content-Type:, and any Content-Transfer-Encoding: lines. Look for obviously malformed values, unexpected character sets, missing multipart boundaries, or message IDs that appear reused across unrelated sends.

If the email contains links, images, or an unsubscribe action, inspect relevant headers and body URLs together. A sending system that signs a message before a downstream service rewrites links or adds a footer may accidentally break DKIM if those changes alter signed material.

Common email header problems and their causes

An email header problem can range from a cosmetic display issue to a deliverability failure. The cause is often not the header alone; it is an interaction between application code, sending infrastructure, DNS, a forwarding system, and recipient-side filtering.

SPF passes but DMARC fails

This frequently happens when a sender configures a third-party platform’s bounce domain but does not align it with the domain in From:. SPF may correctly authenticate the platform’s envelope sender, while DMARC still fails because the domains are unrelated.

For example:

From: notices@product.example
Return-Path: bounces@mailer.vendor.example
Authentication-Results: mx.recipient.example;
 spf=pass smtp.mailfrom=mailer.vendor.example;
 dkim=fail;
 dmarc=fail header.from=product.example

The fix is usually to enable custom sending-domain configuration with the provider, configure aligned DKIM for product.example or an appropriate subdomain, and publish the required DNS records. Do not try to solve this by merely changing the display name.

DKIM fails after a message is modified

DKIM signs selected headers and the message body. If a downstream system changes a signed portion after signing, verification can fail.

Common causes include adding a footer, rewriting URLs, changing MIME boundaries, modifying line endings, injecting a disclaimer, or transforming HTML after the original signing event. Mailing lists and security gateways are frequent sources of legitimate modification.

The practical fix is architectural: sign the final outbound representation of the message whenever possible. If a service must modify messages later, test its impact on DKIM and decide whether it should re-sign mail under a domain you control.

Missing or invalid Message-ID values

Some custom SMTP implementations omit Message-ID: or reuse a static ID in a template. This can harm threading and make deduplication or support investigation more difficult.

Generate a unique message ID for every delivery attempt. Keep it stable when you intentionally retry the same logical message only if your sending design and downstream behavior support that choice; otherwise, distinguish retries clearly in application logs while preventing duplicate customer messages.

Broken MIME formatting

Hand-built multipart messages are easy to get wrong. A missing boundary delimiter, duplicate body terminator, mismatched charset, or incorrectly encoded attachment can cause garbled copy, missing content, and inconsistent rendering.

Use a tested MIME builder from your email library or sending provider rather than concatenating raw body strings. Send test messages to multiple mailbox providers and inspect the raw source, especially after template-engine, attachment, and link-tracking changes.

Misleading or inconsistent From and Reply-To fields

A From: identity that looks unrelated to the product, landing page, or unsubscribe destination can trigger recipient distrust even if authentication passes. A surprising Reply-To: destination can have the same effect.

Keep brand identity coherent. A reasonable pattern is a recognizable display name and a stable subdomain, such as Acme Reports <reports@updates.acme.example>, with replies routed to a support address that clearly belongs to Acme. If you need a separate support domain, explain that choice in customer-facing workflows rather than hiding it in technical configuration.

Missing unsubscribe headers on bulk marketing mail

When a recurring campaign lacks easy opt-out paths, recipients may use the spam button instead. That damages complaint rates and signals poor list management.

Add a visible unsubscribe link in the body and provide compliant unsubscribe headers for eligible promotional messages. Do not attach marketing unsubscribe behavior to critical transactional email merely because it is sent through the same infrastructure; classify streams correctly so that authentication, templates, suppression rules, and user expectations remain clear.

Excessive or suspicious custom headers

Custom fields such as X-Campaign-ID:, X-Environment:, or X-Customer-ID: can be useful internally. But do not expose secrets, personally sensitive data, session tokens, database IDs that enable account access, or unneeded implementation details.

Custom headers can be seen by recipients, forwarded to other systems, retained in support tickets, or captured in security tooling. Treat them as externally visible metadata. Use opaque identifiers where correlation is necessary.

How to improve email headers and deliverability

Improving headers is not about making them look more complex. It is about making the message technically correct, authenticated, consistent, and easy for recipient systems to evaluate.

1. Authenticate a domain you control

Set up SPF and DKIM for the domain or subdomain used in your sending program. Publish a DMARC record for the organizational domain and monitor results before moving to a stricter enforcement policy.

For most businesses, separate subdomains clarify traffic purpose without fragmenting identity. For example:

  • notify.example.com for transactional notifications;
  • updates.example.com for product lifecycle mail;
  • news.example.com for newsletters or promotional campaigns.

Each stream should still be intentional about visible From: identity and alignment. Separating streams can make reputation analysis and incident containment easier, but it does not excuse poor list practices or weak authentication.

2. Sign the finished message

Ensure DKIM signing occurs after your application, template engine, tracking logic, footer insertion, and MIME assembly have produced the final message. This reduces the chance that an internal or vendor-side transformation invalidates the signature.

Review which fields are included in the h= tag of your DKIM signature. At a minimum, the visible identity fields should be protected in a sensible way. Your email infrastructure should handle signing decisions, but your engineering team should understand the consequence: any signed field modified after signing can affect validation.

3. Keep the visible From domain aligned

Use a From: domain that your organization controls and that can be aligned with your DKIM signing domain or SPF-authenticated envelope domain. Avoid sending important production mail from a free consumer mailbox or a domain that has no relationship to the website, product, or support workflow.

If you use an email API provider, complete its custom-domain setup rather than relying indefinitely on a shared vendor domain. The exact records and verification steps vary by provider, so use the platform’s email API setup guides and verify DNS before ramping up volume.

4. Use a dedicated bounce strategy

Set a valid envelope sender and process bounce messages or provider webhooks promptly. Permanent failures should be suppressed so you do not keep sending to undeliverable addresses. Temporary failures should be retried cautiously according to the sending platform’s queueing and retry behavior.

The Return-Path: will not be visible in the normal compose window, but it is part of a healthy operational setup. It gives your infrastructure a route for delivery feedback and supports SPF evaluation.

5. Generate standards-compliant content

Always include a valid Date: and unique Message-ID:. Use correct MIME structures for text, HTML, attachments, and international content. Provide a plain-text alternative for HTML email where appropriate.

Avoid manually creating raw headers unless you have a specific need and understand the relevant syntax. Header injection vulnerabilities can occur when untrusted input is allowed to insert line breaks into To:, Subject:, Reply-To:, or custom fields. Sanitize inputs and use established mail libraries that encode display names and header values safely.

6. Make unsubscribe easy for promotional mail

Include List-Unsubscribe: and, where applicable, List-Unsubscribe-Post: for subscription mail. Ensure the HTTPS unsubscribe endpoint performs the expected action without asking a recipient to log in, solve a puzzle, or navigate multiple marketing screens.

Also include a clear body-level unsubscribe link. Header-based unsubscribe is convenient in supported mailbox interfaces, while the visible link remains important for recipients who use another client or prefer to manage preferences directly.

7. Test headers before a major send

Send seed messages to inboxes at several providers and inspect their full headers. Check the results after every meaningful infrastructure change, including:

  • switching email platforms or SMTP relays;
  • changing your From domain or bounce domain;
  • enabling click tracking or open tracking;
  • adding a link-rewriting security product;
  • introducing a new template engine;
  • changing DKIM keys or selectors;
  • adding an outbound gateway or forwarding workflow.

Also test a realistic recipient journey: welcome email, password reset, receipt, trial reminder, newsletter, unsubscribe request, and suppression behavior. The goal is to catch differences between transactional and campaign streams before recipients report them.

8. Validate recipient addresses before sending

Header correctness cannot compensate for a poor recipient list. Sending to invalid, abandoned, mistyped, or risky addresses can create bounces and weaken sender reputation even when SPF, DKIM, and DMARC are perfect.

Use a free address verification tool when collecting or importing addresses, then combine validation with double opt-in where appropriate, bounce suppression, and engagement-based list hygiene.

A practical email-header troubleshooting workflow

When a recipient says “your email never arrived,” do not begin by guessing that it went to spam. Gather evidence and work from the message lifecycle.

  1. Confirm the application event. Verify that the password reset, invoice, campaign, or notification was actually triggered for the intended address.
  2. Find the provider event. Check whether the email API or SMTP provider accepted, queued, delivered, deferred, bounced, or suppressed the message.
  3. Match identifiers. Correlate your internal event ID with the email provider’s message ID and, where available, the RFC Message-ID:.
  4. Obtain full headers. Ask the recipient for the raw source or full headers if the message reached their mailbox or spam folder.
  5. Read recipient-side authentication. Find the recipient provider’s Authentication-Results: record and record SPF, DKIM, and DMARC outcomes.
  6. Trace the Received chain. Identify the sending IP or relay, the recipient gateway, and timing gaps.
  7. Compare expected domains. Confirm that From:, return-path/envelope sender, DKIM d=, and DMARC alignment match the architecture you intended.
  8. Check the message class. Confirm that marketing mail has unsubscribe mechanisms and that transactional streams are not accidentally mixed with campaign traffic.
  9. Test a fresh message. After a fix, send a newly generated message. Do not rely only on an older copy whose headers were created before DNS, signing, or template changes.

A good incident record captures the recipient domain, timestamp in UTC, sending domain, envelope sender, sending IP, DKIM selector, authentication outcomes, provider event status, and any rejection or bounce text. This turns a vague delivery complaint into an actionable technical case.

Email header examples for transactional and campaign mail

The exact set of headers changes by provider, but healthy messages tend to have recognizable patterns.

Transactional email example

From: Harbor App <accounts@notify.harbor.example>
To: maya@example.net
Subject: Reset your Harbor password
Date: Tue, 08 Sep 2026 14:32:18 +0000
Message-ID: <reset-7f3d4d2a@notify.harbor.example>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="harbor-reset-91"
Return-Path: <bounces+7f3d4d2a@bounce.harbor.example>
DKIM-Signature: v=1; a=rsa-sha256; d=notify.harbor.example; s=mail2026; ...

This design makes the message purpose clear. The visible From: address identifies Harbor, the transactional subdomain distinguishes notification traffic, the message ID is unique, and DKIM signs with a domain related to the visible sender.

Campaign email example

From: Harbor Weekly <weekly@news.harbor.example>
To: maya@example.net
Subject: 5 ways to speed up month-end close
Date: Tue, 08 Sep 2026 14:35:01 +0000
Message-ID: <weekly-20260908-48291@news.harbor.example>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="harbor-news-48291"
Return-Path: <bounces+48291@bounce.harbor.example>
List-Unsubscribe: <https://harbor.example/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
DKIM-Signature: v=1; a=rsa-sha256; d=news.harbor.example; s=mail2026; ...

The key difference is not merely the topic line. Campaign mail needs clear opt-out handling and should be separated operationally from urgent account notices. Separate subdomains can help teams interpret reputation and engagement signals, but recipients should still recognize the common brand.

What email headers cannot tell you by themselves

Headers are powerful diagnostic evidence, but they are not a complete deliverability report.

A header can show that DMARC passed, yet the message can still land in spam because the sender has poor reputation, recipients do not engage, the content looks suspicious, or complaints are high. Conversely, a technically pristine message may not be delivered if the recipient address does not exist, the mailbox is full, an account has a local filtering rule, or a corporate gateway blocks a category of mail.

Headers also cannot prove that a human opened or read the message. Open tracking, when used, is an imperfect proxy and can be affected by privacy protections, image blocking, and automated prefetching. Click events, replies, conversions, delivery events, complaint data, and unsubscribe data should be interpreted alongside header diagnostics.

The useful principle is simple: headers explain much of the technical path and authentication state, while broader sending data explains reputation and recipient response.

Email header best practices checklist

Use this checklist before treating a new stream as production-ready:

  • Use a recognizable From: name and domain you control.
  • Configure SPF, DKIM, and DMARC for the sending identity.
  • Ensure DKIM or SPF aligns with the visible From: domain for DMARC.
  • Generate a valid Date: and unique Message-ID: for each message.
  • Use correct MIME formatting for text, HTML, and attachments.
  • Sign the completed message after final content transformations.
  • Configure an envelope sender that can receive and process bounces.
  • Include clear body-level unsubscribe links for marketing mail.
  • Add unsubscribe headers for eligible subscription and bulk campaign mail.
  • Avoid secrets and unnecessary personal data in custom headers.
  • Inspect full headers in test inboxes after DNS, template, or provider changes.
  • Keep transactional and promotional streams operationally distinct.

Conclusion

An email header is the technical record that travels with every message. It contains the identity, routing, format, and authentication details that recipient systems use to decide how to handle mail—and that senders use to diagnose delivery problems.

For developers and email teams, the practical priority is not memorizing every possible field. It is building a coherent sending system: use aligned domains, authenticate with SPF, DKIM, and DMARC, generate valid message structure, process bounces, make campaign opt-outs easy, and inspect real headers whenever delivery behavior changes. When those fundamentals are in place, headers become a reliable source of evidence rather than a mystery hidden behind the inbox.

FAQ

Is an email header visible to recipients?

Most recipients see only selected fields such as From:, To:, Date:, and Subject:. Full email headers are usually available through a mailbox client’s “show original,” “view source,” or similar option. They include routing and authentication details that are not shown in the regular reading view.

Is an email header a deliverability metric?

No. An email header is message metadata, not a rate or score. It helps explain deliverability outcomes by showing authentication results, relay history, sender identity, and formatting details. Metrics such as bounce rate, complaint rate, and inbox placement must be measured separately.

Why does my email pass SPF but fail DMARC?

SPF can pass for the envelope sender domain while DMARC fails because that domain does not align with the visible From: domain. DMARC can also fail if DKIM does not pass with an aligned signing domain. Review Authentication-Results:, Return-Path:, From:, and the DKIM d= value together.

Can I edit email headers manually?

You can set some application-level fields, such as From:, Reply-To:, and custom metadata, through a mail library or email API. However, manually building raw headers is error-prone and can create formatting or security problems. Let your sending infrastructure generate transport, authentication, and delivery headers unless you have a specific, tested reason to control them.

Which email headers are most important to check first?

Start with From:, Return-Path:, Authentication-Results:, DKIM-Signature:, and Received:. Together, they show the visible identity, bounce identity, SPF/DKIM/DMARC outcomes, signing domain, and delivery path.