How to read email headers: Received, Authentication-Results and DKIM

How to read email headers: Received, Authentication-Results and DKIM

By James Bayliss · Updated · Reviewed

In this guide
  1. Getting the full headers
  2. The Received chain
  3. Authentication-Results
  4. ARC headers
  5. DKIM-Signature
  6. Diagnosing with the analyzer
  7. Sources

Getting the full headers

The headers must come from the recipient's copy: that's where the receiver recorded its authentication results.

ClientWhere
Gmail (web)Open the message → ⋮ menu → Show original → Copy to clipboard
Outlook (desktop, classic)Open the message → File → Properties → Internet headers
Outlook on the web / new Outlook⋯ menu → View → View message details
Apple MailView → Message → All Headers
ThunderbirdView → Message Source

To send a problem message to someone else for diagnosis, forward it as an attachment. Forwarding inline replaces the original headers with yours.

The Received chain

Each server that handles a message adds a Received: header at the top. So the topmost header is the newest hop, and the bottom one is where the message started:

Received: from mail-relay.example.net (mail-relay.example.net [198.51.100.7])
        by mx.recipient.example with ESMTPS id 4b2c...
        for <alex@recipient.example>; Mon, 26 Oct 2026 14:02:31 +0000
Received: from app-server.internal (10.0.4.12)
        by mail-relay.example.net with ESMTP; Mon, 26 Oct 2026 14:02:29 +0000

Each one tells you:

  • from: the name the sending host claimed, and in parentheses what the receiving host verified (its reverse DNS and IP).
  • by: the server that added this header.
  • with: the protocol. ESMTPS or ESMTPSA means the hop was encrypted with TLS, and SA means the sender authenticated.
  • the date after the semicolon: when this server received it.

Subtract consecutive timestamps to find delays. A gap of minutes or hours at one hop points to queuing, greylisting, or a retry after a temporary rejection. Small negative gaps are just clock differences between servers.

Which IP did the receiver see?

For SPF and blocklist purposes, the important IP is the one in the first header added by the receiving organisation, i.e. the hop where mail crossed from the sender's systems into the recipient's. Everything below it was written by systems the sender controls, and can be forged.

Authentication-Results

The receiving server records its verdict in an Authentication-Results header (RFC 8601):

Authentication-Results: mx.recipient.example;
       spf=pass smtp.mailfrom=bounces.example.com;
       dkim=pass header.d=example.com header.s=selector1;
       dmarc=pass (p=REJECT) header.from=example.com
PartMeaning
mx.recipient.exampleThe server that made the checks (the "authserv-id")
spf=pass smtp.mailfrom=…SPF result and the envelope domain it was checked for
dkim=pass header.d=…DKIM result and the signing domain; there's one entry per signature
dmarc=pass header.from=…DMARC result for the visible From: domain, with the policy in parentheses

Read DMARC against the domains:

  • if dmarc=fail while spf=pass, compare smtp.mailfrom with header.from;
  • if dkim=pass, compare header.d with header.from.

A mismatch is an alignment problem; see DMARC alignment, explained.

Microsoft 365 adds its own fields, such as compauth= (composite authentication) and a reason= code. Treat compauth=fail the same way as a DMARC failure, and use the reason code to search Microsoft's documentation.

Only trust Authentication-Results added by your own receiving servers. A sender can insert a fake one further down; receivers are supposed to remove those, but always use the topmost header.

ARC headers

When a message passes through a forwarder or mailing list that changes it, the intermediary may add ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results (RFC 8617). They record the results the intermediary saw before it modified the message. If a final receiver trusts that intermediary, it can accept a message whose SPF or DKIM broke in transit.

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1;
        h=from:to:subject:date:message-id; bh=…; b=…
  • d= is the signing domain (compared with From: for DMARC), and s= is the selector; the key is at s._domainkey.d.
  • h= lists the headers covered by the signature. A gateway that rewrites one of them, or a mailing list that adds a footer to the body (bh=), breaks the signature.
  • Several signatures are normal: your domain plus the platform's own, for example.

Diagnosing with the analyzer

Paste the headers into the Email Header Analyzer. It lays out the hop path with delays, shows what the receiver recorded, re-checks SPF, DKIM keys and alignment against current DNS, and highlights where recorded and current results differ.

From the field: Email headers are extremely helpful to determine what went wrong with email delivery. Getting the headers from the recipient is the larger challenge for IT professionals. Ensure you word your request carefully and provide step by step instructions to maximize your chances of success.

Sources

Check it now

Email Header Analyzer Why did this message arrive late, land in spam, or fail authentication?

Related guides