Worked example 1 of 11
A genuine message from a colleague (Google Workspace)
A normal, fully authenticated message between two companies that both use Google. The baseline every other example is compared with.
What to notice
This is what a healthy message looks like. Three things to notice:
- One server added the Authentication-Results field:
mx.google.com, the recipient's own provider. Its verdict is the one that counts. - All three checks pass and line up with the From domain. SPF passed for
example.com(from the envelope addresspriya.shah@example.com), and the DKIM signature is byd=example.comtoo. Both align withFrom: priya.shah@example.com, so DMARC passes. Only one of them needed to. - The route is short and quick. The sender's Google server handed the message to the recipient's Google server in about a second. The Date header says 15:42:05 +0100 (the sender's clock, in British Summer Time), which is 14:42:05 UTC, a few seconds before the first Received time of 07:42:17 −0700, which is 14:42:17 UTC.
The first Received: by 2001:db8:… line was written inside Google's own network and has no "from" part; that's normal for mail submitted through Gmail's web interface.
The analysis
Produced by the same code that runs in the analyser.
Looks genuine
Authenticated: it really came from example.com
Your provider's DMARC check passed, so example.com (or a service it authorised) sent this message. That proves the domain, not the intent: make sure example.com is the organisation you expect.
- Fromexample.com
- Hops2
- In transit0 s
- ViaGoogle
Red flags 0
No red flags found in these headers.
Authentication
Checked by mx.google.com, the server that added the top Authentication-Results field: normally your own provider. show in headers
DMARC DMARC asks: did SPF or DKIM pass for a domain that matches the From address you see? That match is called alignment.
SPF or DKIM passed for a domain that aligns with the visible From domain: the From address is authentic.
domain policy p=quarantine · applied: none
SPF SPF checks whether the server that delivered the message was allowed to send for the envelope (bounce) domain.
The sending server is on the envelope domain's list of permitted senders.
google.com: domain of priya.shah@example.com designates 192.0.2.41 as permitted sender
DKIM DKIM checks a cryptographic signature that a domain (d=) put on the message, proving that domain handled it and the signed parts were not changed.
The signature verified: the signing domain really handled this message and the signed content is unchanged.
Alignment with the From address
- SPF example.com passaligned (exact match)
- DKIM example.com passaligned (exact match)
At least one passing check is aligned with the From domain, which is all DMARC needs. Alignment is shown in relaxed mode (same organisation); a domain can demand strict mode (exact match) in its DMARC record, which this tool can't look up.
DKIM signatures on the message
- example.com selector google · rsa-sha256 · signed 2026-10-13 14:42:17 UTC · covers 13 header fields ↧
ARC chain 1
Each forwarding server that sealed the message recorded what it saw. These are claims by those servers; they only count if your provider trusts the sealer.
- i=1 sealed by
google.comcv=nonesaw: dkim=pass spf=pass dmarc=pass↧
Who it claims to be from
Route 2 hops
Oldest first. Each server adds a Received line on top, so this is the header list read from the bottom up. Times are converted to UTC.
- Written Date header: 2026-10-13 14:42:05 UTC (sender's clock +0100)
- +13 s
- +0 s2001:db8:4a5:10::f0c2026-10-13 14:42:18 UTC (−0700 local) ↧
First to last server: 0 s. Reading delays
The headers 19 fields
sender route authentication ARC
All names, domains and addresses on this page are fictional: domains under example.com/.net/.org and the reserved .example and .test names (RFC 2606, RFC 6761), IPv4 addresses from the documentation ranges in RFC 5737 and IPv6 from 2001:db8::/32 (RFC 3849). Signatures are placeholders and won't verify.