exim.ro

How to read email headers: route, delays, SPF, DKIM

How to read a message's headers: the Received route and its delays, Authentication-Results for SPF, DKIM and DMARC, ARC, and anti-spam fields.

Updated 4 min read7 sections

Run the Header analyzer

Every message carries a header section that records where it has been and what the receiving servers concluded about it. The Header analyzer turns it into a table; this guide explains what it reads and how to interpret it.

Getting the full headers

Mail programs hide most headers. Look for "Show original", "View source", "Show message source" or "View message details". Copy everything from the top down to the first empty line; the analyzer drops anything after that line, which is the body.

Received: the route

Each server that accepts the message adds a Received field at the top of the header (RFC 5321, section 4.4). Read from the bottom up, they give the route from the sender to the recipient:

Received: from mx.sender.example (mx.sender.example [192.0.2.10])
        by mx.recipient.example (Postfix) with ESMTPS id 4F1A2;
        Tue, 23 Sep 2026 10:15:07 +0000 (UTC)
  • from is how the sending side introduced itself, followed in parentheses by what the receiver found: usually the reverse DNS name and the IP address in brackets.
  • by is the server that wrote the line.
  • with is the protocol. ESMTPS and ESMTPSA mean the connection used TLS; the final A means the sender authenticated (RFC 3848). Many servers also note the TLS version and cipher.
  • After the last ; comes the time the server received the message.

Only the lines added by servers you trust are reliable: anything below the first server outside your control was written by someone else and may be invented.

Delays

The analyzer subtracts each hop's time from the previous one. A few seconds per hop is normal. Longer gaps usually come from:

  • a queue on the sending server, or a retry after the receiver answered with a temporary error;
  • greylisting, which deliberately defers the first delivery attempt from an unknown sender;
  • a mailing list holding the message for moderation;
  • content scanning on a busy filter.

A negative delay means two servers disagree about the time: one clock is wrong. The first hop is compared with the Date field, which comes from the sender's own device and is the least reliable clock of all.

Authentication-Results: what the receiver concluded

Receiving servers record their checks in Authentication-Results (RFC 8601):

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

The first word is the name of the server that did the checks. Each method has a result: pass, fail, softfail, neutral, none, temperror or permerror. The analyzer takes each method from the topmost field that reports it, because that is the server closest to the recipient; fields further down were added earlier, and a sender can write fake ones.

Two common patterns:

  • SPF fails, DKIM and DMARC pass. The message was forwarded, for example by a mailing list. The forwarder's address is not in the original sender's SPF record, but the DKIM signature survived, and DMARC needs only one of the two to pass and align.
  • DKIM fails after a mailing list. Lists often add a footer or change the subject, which breaks the original signature. ARC exists for this case.

ARC

When a server forwards mail it can seal the results it saw, in ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results fields numbered i=1, i=2, and so on (RFC 8617). A later receiver can then decide to trust the earlier results even though forwarding broke SPF or DKIM. cv= in each seal records what that sealer found when it checked the earlier seals: none for the first, then pass or fail.

Anti-spam fields

Filters often add their verdict:

  • SpamAssassin: X-Spam-Status: No, score=-2.1 required=5.0 tests=..., or with Exim X-Spam_report: (-2.1 / 5.0 requ) .... The message is spam when the score reaches the required value.
  • Rspamd: X-Spamd-Result: default: False [-4.51 / 50.00]; SYMBOL(score)... with the score, the threshold and the rules that fired.
  • Microsoft 365: X-Forefront-Antispam-Report with SFV (the spam filtering verdict), CAT (the category of policy applied), SCL and others, and X-Microsoft-Antispam with BCL, the bulk complaint level. Microsoft notes that in cloud mailboxes SCL no longer decides the verdict; SFV and CAT do.

Scores are only comparable with the threshold of the same filter.

Sources