What Is an Email Header? A Deliverability Practitioner's Guide

Your campaign was accepted. Authentication looks healthy. Yet engagement has fallen, and messages that used to reach the inbox are appearing in spam.

An email header is a useful place to start investigating. It can show which infrastructure sent a message, how it traveled, and which authentication checks the receiving provider recorded. It cannot tell you everything about the provider's filtering decision.

That distinction matters. Reading headers well means knowing what the evidence supports, what it leaves unanswered, and what to check next.

For teams running lifecycle campaigns, newsletters, transactional messages, or multiple client programs, the goal is not to memorize every field. It is to connect message-level evidence with inbox placement, sending history, and reputation so the next decision is clearer.

What an email header actually is

An email header is the information attached to a message that describes its sender, recipients, subject, timing, format, routing, and authentication. Think of it as the message's accompanying record, separate from the body the recipient reads.

Some fields are created by the sending application. Others are added by servers as the message moves toward its destination. This is why a full email header can contain much more than the familiar From and Subject lines.

For a sender, that record helps answer practical questions:

• Did this message leave through the expected email service provider?
• Which domain signed it?
• Did the receiving provider find an aligned identity?
• Was there an unusual delay between servers?
• Did a forwarding service change the delivery path?

An email deliverability test adds another piece of evidence: where a test message actually landed. The header explains parts of the journey. Placement testing observes the destination.

Visible headers and raw headers answer different questions

The visible header is the summary your email client displays, usually From, To, Subject, and Date. It helps someone decide who appears to be writing and whether to open or reply.

The full, or raw, header includes that information alongside routing records, authentication results, message identifiers, and formatting instructions.

A visible From address alone does not prove the sender's identity. Likewise, a recognizable display name does not prove that a familiar business sent the message. Authentication evidence lives elsewhere in the full header.

There is also a separate SMTP envelope, the information servers use during transport. Its sender and recipient addresses can differ from the visible From and To fields. That is normal in many mailing systems, especially where a provider handles bounces or distributes a message to a list.

Read these layers together rather than expecting one address to explain the entire send.

How to view the full email header

Use the received message, ideally from the mailbox where the issue occurred. A copy in your Sent folder does not contain all the information added by the receiving system.

Google documents the header-viewing steps for several clients, while Microsoft provides separate instructions for new, classic, and web Outlook.

Copy the full header rather than a screenshot of the authentication summary. An email header analyzer can help organize long routing chains and timestamps.

Headers can contain personal addresses, internal hostnames, and unique identifiers. Keep an untouched original for your investigation, and use an approved tool before sharing customer message data externally. Redacting signed fields can also prevent meaningful signature verification, so distinguish a shareable copy from the original evidence.

The core header fields, explained

Most investigations begin with a small group of fields. Each tells you something different.

MIME means Multipurpose Internet Mail Extensions. A MIME-Version: 1.0 line does not, by itself, mean a message contains an attachment. Read it alongside Content-Type and the message's individual parts.

Under the base Internet Message Format standard, Date and From are the universally required fields. Conditional requirements and provider rules also apply. Do not treat that minimum as a campaign template: Google's sender guidelines, for example, require a valid Message-ID and prohibit duplicated single-instance headers.

A timestamp such as Wed, 12 Dec 2007 13:39:22 -0800 includes a timezone offset. Here, the local time is eight hours behind UTC. Convert timestamps to a common timezone before comparing them.

Read the Received chain from bottom to top

As mail servers receive a message, they add Received entries above the existing ones. To reconstruct the recorded sequence, begin with the lowest relevant entry and work upward.

Consider this simplified, illustrative chain:

Received: from relay.example.net by mx.example.org;

 Wed, 12 Dec 2007 21:39:22 +0000

Received: from submit.example.net by relay.example.net;

 Wed, 12 Dec 2007 21:38:49 +0000

The lower entry records the handoff from the submission server to the relay. The upper entry records the relay's handoff to the receiving server. The timestamps are 33 seconds apart.

That gap identifies a period worth investigating. It does not establish whether the cause was a queue, a network delay, or a receiver temporarily slowing acceptance. Check server logs and SMTP responses before assigning a cause.

Focus on changes relative to the expected route:

• A relay that did not appear in earlier messages.
• Repeated delays around the same handoff.
• A sending IP that differs from the provider's expected pool.
• A hostname associated with an unfamiliar vendor.

A long chain is not automatically suspicious. Security gateways, forwarding services, and internal routing can add legitimate entries.

Nor is every entry equally trustworthy. A sender can insert header text before handing over a message. Start with records added by infrastructure you trust, then work backward. The chain is evidence of the recorded route, not a guaranteed account of every internal processing step.

Authentication results need alignment context

Authentication is where header analysis becomes especially useful. It is also where a simple green checkmark can be misleading.

SPF, or Sender Policy Framework, checks a sending IP against the policy for an envelope domain. In ordinary messages, that is the domain used in the SMTP MAIL FROM address. It does not directly authenticate the visible From address.

DKIM, or DomainKeys Identified Mail, checks a cryptographic signature. A valid signature associates signed content with the signing domain. The d= value in DKIM-Signature identifies that domain. It does not establish that the message is wanted or that every possible part of the message is protected.

DMARC connects authentication to the visible From domain. It requires a passing SPF or DKIM result with an aligned domain. One qualifying method is enough for DMARC to pass, even though bulk sender requirements can separately require both SPF and DKIM to be configured.

Alignment means the domains satisfy the applicable matching rule. Relaxed alignment allows related domains under the same organizational domain. Strict alignment requires an exact domain match.

Here is an illustrative result:

From: Updates <news@example.com>

Return-Path: <bounce@mailer.example.net>

Authentication-Results: mx.example.org;

 spf=pass smtp.mailfrom=mailer.example.net;

 dkim=pass header.d=example.com;

 dmarc=pass header.from=example.com

SPF passes for mailer.example.net, but that domain does not align with example.com. DKIM passes with example.com, which does align. DMARC therefore has a qualifying DKIM path.

Now imagine the DKIM signing domain were also example.net. SPF and DKIM could both pass for that provider's identity while neither aligned with the visible From domain. Two authentication successes would not establish DMARC success for example.com.

Read the receiver's Authentication-Results field and the identities attached to each result. Do not trust an arbitrary authentication header just because it says pass. For more detail on signing, see DKIM authentication explained.

The operational question is sharper than “Did authentication pass?” It is “Which identity passed, did it align, and did this receiver evaluate the message we actually sent?”

Spoofing, forwarding, and ARC complicate the picture

The From field can be forged. Attackers can also add convincing-looking header text, so identity checks must rely on trusted receiving infrastructure rather than the message's claims about itself.

Forwarding creates a different problem. A legitimate message can arrive from a forwarding server whose IP is not authorized by the original envelope domain's SPF policy. SPF may then fail at the final destination.

DKIM can survive forwarding if the signed content remains intact. A mailing list that rewrites a subject or adds a footer may invalidate a signature, depending on what was signed and how the message changed.

ARC stands for Authenticated Received Chain. It allows participating intermediaries to attach signed records of authentication assessments along the route. A receiving provider can use those records when evaluating forwarded mail.

ARC does not repair SPF, guarantee DMARC success, or automatically make a message trustworthy. The ARC specification distinguishes a validated chain from trust in the organizations that created it.

When a forwarded message shows a failure, compare it with a direct delivery from the same source. Determine whether the problem exists at origin or appeared after an intermediary changed the route. That prevents a forwarding edge case from triggering unnecessary DNS changes across an otherwise healthy program.

What to do when SPF passes but inbox placement drops

Start with a specific scenario: a newsletter is still accepted, SPF passes, but recent tests show worse Gmail placement while Yahoo remains stable.

Do not rewrite SPF simply because it is the most visible setting. Work through the evidence in order.

First, verify the identity. Inspect a recent Gmail header. Confirm the expected From address, envelope domain, DKIM signing domain, and DMARC result. Compare them with a previously healthy message from the same sending stream.

Next, confirm the scope. Is the decline limited to one provider, one template, one sending IP, or one subscriber segment? A global average can hide the affected group.

Review changes around the first decline. Look for audience expansion, a new acquisition source, increased frequency, a template update, or an infrastructure migration. Timing gives you hypotheses, not proof.

Compare supporting signals. Review DMARC aggregate reports for authentication patterns among reporting receivers. Check Google Postmaster Tools, complaints, delivery errors, and recent placement tests. Aggregate reports do not tell you whether each message reached the inbox, and a header does not expose a provider's complete reputation model.

Test a narrow change. If the sending identity is stable but the template changed, compare controlled content variants. If complaints rose after adding a dormant segment, pause that segment before changing unrelated infrastructure.

Mailora supports this approach through provider-level placement testing, authentication visibility, historical comparisons, and practitioner guidance. The value is a better-supported next step, not another isolated score.

Why one-off header inspection is not enough

A header describes one message received at one destination at one moment. It does not represent all the IPs in your provider's pool, every subscriber segment, or next week's campaign.

Keep comparable evidence over time. For important sending streams, retain test results, representative headers, relevant configuration changes, and the dates those changes reached production.

Before a major campaign, test through the actual sending system with the intended domain, template, links, and tracking. After launch, compare provider responses and reputation trends with the pre-send baseline.

Mailora's deliverability monitoring features include recurring tests and historical provider breakdowns. These make it easier to see whether a result is isolated or part of a repeated pattern.

Seed tests still have limits. Test mailboxes do not reproduce every subscriber's history or behavior. Use them alongside real delivery logs and audience signals, not as a guarantee of universal inbox placement.

Connect header fields to infrastructure decisions

Headers can help expose a mismatch between your intended sending setup and the infrastructure actually used.

The sending IP can be checked against your provider inventory and reverse DNS configuration. The Return-Path domain can reveal whether a custom bounce domain is active. The DKIM signing domain can show whether your branded signing setup is being used.

Keep the checks distinct. A provider-owned PTR hostname can be legitimate. It does not need to match the visible From domain to satisfy DMARC, because PTR is not a DMARC alignment identifier.

If a message moved onto a shared IP, investigate that pool's reputation with your provider. If you use a dedicated IP, confirm who owns its warm-up, reverse DNS, and incident response. Dedicated infrastructure gives you more responsibility, not an automatic placement advantage.

IPv4 addresses use four numbers between 0 and 255, such as the documentation address 192.0.2.10. IPv6 addresses look different and can also appear in headers. Investigate the IP the receiver actually observed rather than assuming all messages left through IPv4.

What each role should do with header evidence

Email marketers: Compare the campaign that underperformed with a healthy send. Check whether the identity, provider, or template changed before assuming the subject line caused the decline.

Operators managing multiple sending systems: Keep a record of approved From domains, signing domains, bounce domains, and providers. Investigate unexpected changes rather than normalizing constant identity rotation.

RevOps teams: Tie an affected sending stream to the business process it supports. A delayed account notification and a weak newsletter test have different consequences and escalation paths.

Consultants and agencies: Use the same evidence package for each client: an original header, provider-level test results, relevant timestamps, recent changes, and a named owner. Keep client data separated when sharing findings.

Choose header tools for the question you need answered

Manual tools such as MxToolbox's header analyzer and Google Admin Toolbox Messageheader can make an individual header easier to read. They are useful for investigating routing and timing without scanning every line manually.

That specific lookup remains a snapshot, regardless of what other services the vendor offers. It does not replace monitoring across messages and time.

Mailora complements header inspection with placement testing, reputation context, authentication checks, and practical recommendations. Use the individual message to identify a question, then use repeated measurements to decide whether the answer holds across your sending program.

Frequently asked questions

Can email headers be spoofed or faked?

Yes. Sender-supplied fields can be forged. Give greater weight to authentication results and routing records added by trusted receiving infrastructure, and preserve the original message for investigation.

Do email headers contain the sender's real IP address?

They may reveal the IP of the sending mail server, not necessarily the person's device. Webmail services, relays, and forwarding systems can obscure the original endpoint. An IP address alone does not identify a person.

Why does email pass SPF and DKIM but still land in spam?

The passing domains may not align with the visible From domain. Even when DMARC passes, mailbox providers still evaluate other signals, including reputation, complaints, sending behavior, and message content.

What is the difference between From and Return-Path?

From is the visible author address. Return-Path records the envelope sender at delivery and commonly supports bounce handling. They serve different purposes and do not need to be identical.

How many Received headers is normal?

There is no universal count. Compare the chain with the expected route for that sending system. An unfamiliar relay or repeated delay is more useful evidence than length alone.

Make the next send easier to diagnose

Choose one important sending stream. Save a representative received header, confirm its aligned identity, and pair it with a provider-level placement test. That gives you a baseline you can compare with the next meaningful change.

A header becomes valuable when it helps you decide what to investigate, fix, or leave alone. Build that habit before the next campaign, not only after an incident.

Run your first test with Mailora.