Email headers explained: the fields that matter
A beginner friendly guide to email headers: sender identity, SPF, DKIM, DMARC and routing evidence, and what each one does and does not prove about a message.
Choose the explanation that suits you. Both versions cover the same topic.
1. Display name and From address
The display name is designed for humans and is easy to imitate. The From address adds useful identity evidence, but attackers can register convincing domains or use compromised legitimate accounts.
2. Reply-To and Return-Path
Reply-To controls where a response is sent and Return-Path is used for delivery/bounce handling. Marketing and support platforms can create legitimate differences, while unrelated or machine-like domains can become strong supporting evidence when the rest of the message is suspicious.
3. SPF
SPF checks whether the sending server is authorised by the envelope-sender domain. A pass means the domain's SPF policy allowed that infrastructure; it does not prove the visible sender, business offer or destination is trustworthy.
4. DKIM
DKIM attaches a cryptographic signature from a signing domain. Successful verification helps show that signed parts of the message were not changed after signing, but the signing domain still needs to make sense in context.
5. DMARC
DMARC evaluates alignment between the visible From domain and SPF/DKIM identities. Failures can be important, although forwarding and third-party platforms can complicate interpretation. Passes should not be treated as a universal safety badge.
6. Received and source infrastructure
Received headers describe mail-server hops. Jatzo can use suitable public source information as supporting network context, while avoiding location or hosting-provider details as standalone proof of maliciousness.
7. Microsoft SCL/BCL and provider signals
Provider spam scores can be useful context. Bulk advertising can legitimately receive a higher bulk score, while strongly junk-classified messages deserve more attention when independent identity or behavioural evidence also looks wrong.
8. Why headers are only one layer
A perfectly authenticated message can still advertise a scam, request a fraudulent payment or lead to a malicious site. Strong investigation combines headers with intent, content, destinations, attachments and campaign relationships.
Provenance and trust boundaries
Uploaded Received, Authentication-Results and ARC fields can be forged. Jatzo describes the supplied claims and selected source candidate; it does not independently verify every DKIM signature or ARC chain.
Network and routing enrichment
PTR, forward-confirmed reverse DNS, ASN and optional RIPEstat prefix, registry and RPKI data describe infrastructure. RPKI validates route origin authorisation, not email legitimacy. Registry contacts may be stale. Check coverage and timestamps before drawing conclusions.