Tracing an Email: Received Headers, SPF, DKIM and DMARC

You receive an email from support@yourbank.com asking you to verify your account. The sender address looks right. But something feels off — the links point somewhere strange, the tone is urgent, and your bank has a policy of never asking for credentials by email.

The email headers tell you the truth about where this message actually came from. They reveal the path the message took, which servers accepted and forwarded it, and the cryptographic results of the sender's authentication checks.

The Email Header Analyzer parses any set of email headers and extracts the authentication results, the Received chain, and the security indicators.

The Received chain: reading it newest-first

Every mail server that handles a message adds a Received: header. The newest (most recent) hop is at the top; the oldest (originating server) is at the bottom.

Received: from mail.example.com (mail.example.com [203.0.113.10])
        by mx.gmail.com with ESMTPS id abc123
        for <recipient@gmail.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
        Mon, 01 Jan 2024 12:00:00 +0000 (UTC)
Received: from submitting-client (unknown [198.51.100.5])
        by mail.example.com with SMTP
        for <recipient@gmail.com>;
        Mon, 01 Jan 2024 11:59:30 +0000 (UTC)

The first Received header is from Gmail's receiving server. The second is from mail.example.com (the last server that sent the message to Gmail). Working backward through the chain tells you the full path.

Key fields in a Received header:

• from server — the sending server's hostname
• by server — the receiving server's hostname
• with ESMTPS — the protocol used (SMTP over TLS)
• for — the final recipient address
• timestamp — when the receiving server processed it

The authentication results: ARC, SPF, DKIM, DMARC

These headers are added by the receiving server, not the sending server. They report the results of authentication checks.

SPF (Sender Policy Framework) — verifies that the sending server's IP is authorized to send for the domain.

Authentication-Results: mx.gmail.com;
  spf=fail (google.com: domain of notfromgoogle@gmail.com
  does not designate 198.51.100.5 as permitted sender)

A fail here means the message came from a server not authorized for the claimed domain. This is strong evidence of spoofing when the From address claims to be from the domain.

DKIM (DomainKeys Identified Mail) — verifies that the message was signed by the domain's private key.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector;
  h=from:to:subject; bh=abc123...; b=xyz...
Authentication-Results: mx.gmail.com;
  dkim=fail (body hash mismatch) header.d=example.com

pass means the signature was valid — the body and headers have not been modified in transit. fail means the signature did not verify — either the message was tampered with, or the selector/key is wrong.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — aggregates SPF and DKIM results against the domain's published policy.

Authentication-Results: mx.gmail.com;
  dmarc=fail (p=reject) header.from=example.com

A dmarc=fail with p=reject means the domain's policy instructs receivers to reject messages that do not pass both SPF and DKIM. A legitimate bank email will not have a DMARC failure.

Spotting spoofing: the practical checklist

For an email claiming to be from yourbank.com:

1. Check the From display name — From: "Your Bank" <support@yourbank.com> is what you want to see. From: Your Bank <support@secure-yourbank.com> uses a lookalike domain.
2. Check Return-Path or Reply-To — these may differ from From. A mismatch between From and Return-Path is a red flag.
3. Check the SPF result — fail on the claimed domain means the sending server is not authorized.
4. Check the DKIM result — pass means the body was signed by the domain. fail means it was not.
5. Check the DMARC result — fail with a p=reject policy means the domain instructs receivers to block it.
6. Inspect the Received chain — if the originating server IP is in a country you do not expect, or the hostname looks like a throwaway domain, that is suspicious.

ARC (Authenticated Received Chain)

Forwarded emails (sent through a mailing list, a forwarding service, or an auto-forwarding rule) modify the message and would break SPF and DKIM. ARC preserves the original authentication results so that the final receiving server can see what the original checks showed, even after forwarding.

What headers do not tell you

Email headers tell you which servers handled the message and what those servers thought about its authenticity. They do not tell you:

• Whether the links in the body are malicious (look at them, hover over them, use a URL scanner)
• Whether the message content is legitimate (only the sender can verify that)
• Whether the sender account was compromised (DKIM can pass with a stolen key)

Use the Email Header Analyzer to parse any suspicious email's headers — paste the full raw headers and get a structured view of the authentication results and Received chain.

For validating whether an email address format is deliverable, the Email Validator checks MX records and format validity. For building authenticated emails with DKIM signatures (if you run a mail server), the Email Signature Generator generates the DKIM record you need to publish in DNS.