Ctrl + K
Email13 min read

How Email Headers Work

Understand how email headers work, how mail servers use them to route messages, and how headers help with authentication, troubleshooting, and email security.

Published: 2026-09-02

Every email contains more information than the message you see on screen. Along with the visible subject, sender, recipient, and body, an email contains a collection of structured metadata called headers. These headers help email software identify the message, route it between mail servers, authenticate its origin, and process its contents.

Understanding how email headers work is useful when troubleshooting delivery problems, investigating suspicious messages, analyzing authentication failures, or simply learning how email moves across the Internet.

What Is an Email Header?

An email header is a structured field containing metadata about an email message. Headers appear before the message body and follow a standardized field-name and value format.

From: alice@example.com
To: bob@example.net
Subject: Project Update
Date: Wed, 26 Aug 2026 07:30:00 +0300
Message-ID: <abc123@example.com>

Each field has a particular purpose. Some fields describe the message itself, while others are added by mail servers as the message moves through the delivery system.

Email Headers vs the Message Body

ComponentPurpose
HeadersMetadata used to describe, route, authenticate, and process the message
BodyThe actual text, HTML, and other message content
AttachmentsFiles included through the message's MIME structure

Your email application normally hides most technical headers and presents only selected fields in a user-friendly interface. The complete message contains considerably more information.

How Email Headers Are Created

Different parts of the email delivery process can create different headers. The sending email client may create fields such as From, To, Subject, Date, and Message-ID. Mail servers then add their own delivery and processing information.

Email client
    ↓
Creates message headers
    ↓
Outgoing mail server
    ↓
Adds delivery information
    ↓
Intermediate mail servers
    ↓
Add Received headers
    ↓
Recipient mail server
    ↓
Adds authentication and processing results

The From Header

The From header identifies the author or sender address presented to the recipient. It is usually the address displayed most prominently by an email client.

From: Alice <alice@example.com>

The From address is important for displaying sender identity and for DMARC alignment, but it should not be treated as proof that the message actually originated from that sender.

The To Header

The To header identifies the primary recipient or recipients displayed as the intended destination of the message.

To: Bob <bob@example.net>

The To header is message metadata and does not by itself describe every recipient involved in the SMTP delivery process.

The Cc and Bcc Headers

Cc allows additional visible recipients to receive a copy of the message. Bcc is used for recipients whose addresses should normally remain hidden from other recipients.

To: bob@example.net
Cc: carol@example.net
Bcc: dave@example.net

Bcc is handled differently from To and Cc because the Bcc information is normally removed from the copy delivered to other recipients.

The Subject Header

The Subject header contains the message subject displayed by the email client.

Subject: Project Update

Subject values can contain encoded representations when they include characters outside basic ASCII. Email software decodes these representations before displaying the subject to the user.

The Date Header

The Date header contains the date and time associated with the message as generated by the sending software.

Date: Wed, 26 Aug 2026 07:30:00 +0300
⚠️ The Date header is not necessarily the exact time when the recipient's mail server received the message. Received headers provide additional delivery timestamps.

The Message-ID Header

Message-ID is an identifier intended to uniquely identify a particular email message. Mail clients and servers can use it for message threading, references, diagnostics, and tracking.

Message-ID: <20260826043000.12345@example.com>

The exact format varies between mail systems, but Message-ID values are normally enclosed in angle brackets.

The Reply-To Header

Reply-To specifies the address that email software should normally use when the recipient replies to a message. It can be different from the From address.

From: notifications@example.com
Reply-To: support@example.com

This is common for automated systems where messages are sent from a notification address but replies should go to a support mailbox.

The Return-Path and SMTP Envelope

The SMTP envelope contains information used during mail transport. The envelope sender is used for delivery failure handling and is commonly represented in the delivered message by the Return-Path field.

Return-Path: <bounce@example.com>

The Return-Path, From, and Reply-To fields can all contain different addresses because they serve different purposes.

FieldMain Purpose
FromVisible author or sender identity
Reply-ToPreferred destination for replies
Return-PathEnvelope sender used for bounce handling

How Received Headers Work

Received is one of the most important headers for understanding how an email traveled through the mail system. Mail servers normally add a Received field when they accept a message from another system.

Received: from mail.example.com
    by mx.example.net
    Wed, 26 Aug 2026 04:31:12 +0000

When an email passes through several mail servers, each server can add another Received header. This creates a record of the message's delivery path.

Reading Received Headers

Received headers are normally analyzed from the bottom upward. The oldest entry is generally near the bottom, while newer receiving systems add their entries above earlier ones.

Received: Server C
Received: Server B
Received: Server A

Approximate path:

Server A → Server B → Server C

This ordering makes Received headers particularly useful when investigating delivery delays or unexpected mail routing.

How Email Headers Record Delivery Time

Mail servers can add timestamps to their Received headers. Comparing timestamps between successive servers can reveal how long the message spent between processing stages.

Header PatternPossible Interpretation
Seconds between entriesNormal transfer
Several minutesPossible processing or queue delay
Hours between entriesPotential delivery or infrastructure problem
Unexpected timestampsPossible clock or header anomaly
⚠️ A timestamp difference does not automatically prove where a delay occurred. Mail queues, clock synchronization, relays, and header formatting can all affect the interpretation.

Authentication-Results

Authentication-Results records authentication checks performed by a mail system. It commonly contains results for SPF, DKIM, and DMARC.

Authentication-Results: mx.example.net;
    spf=pass;
    dkim=pass;
    dmarc=pass

These results help receiving systems and administrators determine whether a message passed important email authentication checks.

How SPF Appears in Headers

SPF checks whether the sending IP address is authorized to send mail for a domain according to that domain's SPF policy. A receiving server can record the result in Authentication-Results.

Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=example.com

How DKIM Appears in Headers

DKIM adds a cryptographic signature to an email. The recipient's mail system can use a public key published in DNS to verify the signature.

DKIM-Signature: v=1;
    d=example.com;
    s=mail;
    ...

A successful DKIM verification can then appear in Authentication-Results.

Authentication-Results: mx.example.net;
    dkim=pass header.d=example.com

How DMARC Appears in Headers

DMARC evaluates authentication results together with domain alignment requirements. A receiving system can record the result and the domain associated with the visible From address.

Authentication-Results: mx.example.net;
    dmarc=pass header.from=example.com

This makes the From header particularly important when interpreting DMARC results.

DKIM-Signature Header

DKIM-Signature is a special header containing information required to verify an email's DKIM signature. It can include the signing domain, selector, algorithm, signed headers, and cryptographic signature.

DKIM-Signature: v=1;
    a=rsa-sha256;
    d=example.com;
    s=mail;
    h=from:to:subject:date;
    bh=...;
    b=...

The presence of a DKIM-Signature header does not automatically mean that DKIM verification succeeded. The receiving system must validate the signature.

Content-Type and MIME

Email headers also describe how the message body is structured. Content-Type tells the receiving software what kind of content it is processing.

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

Messages containing both plain text and HTML versions commonly use multipart MIME structures.

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

Content-Transfer-Encoding

Content-Transfer-Encoding specifies how message content is represented for transport. Common values include 7bit, quoted-printable, and base64.

Content-Transfer-Encoding: base64
⚠️ Base64 is an encoding method, not encryption. Base64-encoded email content can be decoded without a secret key.

How Attachments Are Described

Attachments are represented through MIME headers and multipart boundaries. Content-Disposition commonly identifies whether a MIME part should be treated as an attachment.

Content-Disposition: attachment;
    filename="report.pdf"

The attachment's actual data is stored in the corresponding MIME part rather than being represented solely by the Content-Disposition header.

Custom Email Headers

Mail servers, applications, security gateways, and marketing platforms can add custom headers containing additional metadata.

X-Mailer: Example Mail Client
X-Campaign-ID: 12345

Historically, many custom fields used the X- prefix. Their meaning depends on the software that generated them, so they should not be interpreted without considering their source.

How Headers Move Between Mail Servers

Email delivery normally involves SMTP servers. When one server transfers a message to another, the receiving server can add information describing that transaction.

Sender
  │
  ▼
Outgoing SMTP server
  │
  ▼
Security gateway
  │
  ▼
Recipient SMTP server
  │
  ▼
Mailbox
  │
  ▼
Email client

As the message moves through this process, the collection of headers can grow. Delivery-related headers therefore provide a useful record of how the message reached the final mailbox.

Why Some Headers Are More Trustworthy Than Others

Not all headers have the same level of trust. A sender can construct many of the headers that appear in an outgoing message. By contrast, a receiving mail server adds its own Received and authentication information when processing the message.

When analyzing a suspicious email, server-generated information from trusted infrastructure is generally more useful than blindly trusting fields supplied by the sender.

Can Email Headers Be Forged?

Yes. Many ordinary header fields can be manipulated by software creating the message. This is why the visible From address alone cannot establish that an email is authentic.

Email authentication mechanisms and server-added delivery information provide additional evidence. A proper investigation considers multiple independent signals instead of relying on a single header.

Email Headers and Sender Spoofing

Spoofing occurs when an attacker makes a message appear to come from an address or domain that did not actually authorize the message. The From header is commonly involved because it controls the sender identity displayed to the recipient.

SPF, DKIM, and DMARC were designed to help receiving systems evaluate sender authenticity and domain relationships. Their results are commonly visible through Authentication-Results.

Can Headers Reveal the Sender's IP?

Email headers can contain IP addresses, particularly in Received fields. However, these addresses usually identify systems involved in message transmission and do not necessarily identify the sender's personal device.

⚠️ An IP address in an email header may belong to a mail server, relay, proxy, security gateway, or other infrastructure rather than the person who wrote the message.

How to View Full Email Headers

Most email services and desktop clients provide a way to inspect the original message or full headers. The exact location depends on the application.

  • Open the email message.
  • Open the message options or actions menu.
  • Choose the option for viewing the original message, source, or full headers.
  • Locate the header section.
  • Copy the headers if you need to analyze them.

When sharing complete headers for troubleshooting, consider removing personal addresses, internal hostnames, tracking identifiers, and other information that is not necessary for the investigation.

How to Analyze Email Headers

1. Check From.
2. Check Reply-To.
3. Check Return-Path.
4. Inspect Message-ID.
5. Review Authentication-Results.
6. Check SPF.
7. Check DKIM.
8. Check DMARC.
9. Read Received headers from bottom to top.
10. Compare delivery timestamps.
11. Look for unexpected mail servers.
12. Check for suspicious inconsistencies.

Example of a Complete Header Set

From: billing@example.com
To: customer@example.net
Reply-To: support@example.com
Return-Path: <bounce@example.com>
Date: Wed, 26 Aug 2026 07:30:00 +0300
Subject: Your Invoice
Message-ID: <abc123@example.com>

Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=example.com;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

Received: from mail.example.com
    by mx.example.net
    Wed, 26 Aug 2026 04:31:12 +0000

This example shows how several headers work together. From identifies the visible sender, Reply-To specifies where replies should go, Return-Path identifies the envelope sender, Message-ID identifies the message, Authentication-Results records authentication checks, and Received describes the delivery step.

Common Email Header Problems

  • From and Reply-To use unexpected addresses.
  • SPF, DKIM, or DMARC authentication fails.
  • Received headers show an unexpected delivery path.
  • There are unusually large gaps between delivery timestamps.
  • The message uses an unexpected sending domain.
  • Authentication identities do not match the visible sender as expected.
  • Message headers contain malformed or unusual values.
  • The message appears to have passed through unexpected infrastructure.

Email Header Troubleshooting Checklist

☐ Inspect From
☐ Inspect To and Cc
☐ Check Reply-To
☐ Check Return-Path
☐ Check Message-ID
☐ Review Received headers
☐ Compare timestamps
☐ Review Authentication-Results
☐ Check SPF
☐ Check DKIM
☐ Check DMARC
☐ Identify unexpected relays
☐ Look for suspicious inconsistencies

Frequently Asked Questions

How do email headers work?

Email headers contain structured metadata used to identify, route, authenticate, format, and process an email. The sending application creates some fields, while mail servers add delivery and processing information.

What is the purpose of email headers?

Headers provide information needed to process messages, including sender and recipient details, routing information, authentication results, timestamps, message identifiers, and content metadata.

Who adds email headers?

The sending email client or application creates many basic headers, while outgoing, intermediate, and receiving mail servers can add additional delivery and processing headers.

What does the Received header do?

A mail server normally adds a Received header when it accepts a message. Multiple Received fields can help reconstruct the sequence of systems involved in delivering the email.

Why are Received headers read from bottom to top?

Each receiving server normally adds its Received entry above existing entries, so the older delivery steps are generally found lower in the header list.

What is Authentication-Results?

Authentication-Results records authentication checks performed by a mail system, commonly including SPF, DKIM, and DMARC results.

What is the difference between From and Reply-To?

From identifies the sender displayed to the recipient, while Reply-To specifies the address that email software should normally use when the recipient replies.

Can email headers reveal an IP address?

Yes. Received headers can contain IP addresses associated with mail servers or connections. However, an address found in a header is not necessarily the sender's personal IP address.

Useful Email Tools

Email Header Analyzer can help inspect complete email headers and identify important fields. Email Address Validator is useful for checking email address syntax, while Mailto Link Generator creates mailto links for web pages. Email Obfuscator can help reduce simple automated email harvesting, and HTTP Header Viewer is useful for examining HTTP headers when comparing web and email protocols.

Conclusion

Email headers are a fundamental part of how email works. They provide the metadata required to identify messages, route them between servers, describe their contents, and record authentication and delivery information.

The most useful way to understand an email is to look at its headers as a collection rather than focusing on one field. From and Reply-To describe sender and reply identities, Received records delivery steps, Message-ID identifies the message, Return-Path relates to bounce handling, and Authentication-Results records important security checks.

Once you understand these relationships, full email headers become a powerful troubleshooting and security tool rather than a confusing block of technical text.

Found an issue?

Found an error, outdated information, or something missing from this article? Let me know through the Contact page.

Your feedback helps improve our articles and keep them accurate and useful.