Worked example 7 of 11
CEO fraud: a real webmail account with a borrowed name
Everything passes, because the attacker used a genuine free webmail account. The trick is in the display name, which contains the boss's real address.
What to notice
This is the message that fools people who know about SPF and DKIM: every check passes. The attacker opened a real account at a free webmail service (freemail.test) and sent from it, so freemail.test really did send this message, and DMARC confirms it.
The deception is entirely in the From line:
From: "Dana Whitfield (dana.whitfield@company.example)" <d.whitfield.office@freemail.test>
The display name contains the CEO's genuine work address. Most phone mail apps show only the display name, so the recipient sees what looks like the boss's address. The real address, in angle brackets, is a webmail account.
Other tells: the message is short and urgent ("are you at your desk?"), the Message-ID and route show a webmail service rather than the company's own mail system, and there's no history in the thread (no In-Reply-To or References).
MailDingo's verdict is "suspicious" despite the passes, because a display name that contains a different address is a high-severity flag.
The analysis
Produced by the same code that runs in the analyser.
Suspicious
Warning signs: treat this message as suspicious
MailDingo found 1 serious warning sign. Don't click links, open attachments or reply until you've checked with the sender another way.
- Fromfreemail.test
- Sent from198.51.100.14
- Hops3
- In transit2 s
- ViaGoogle
Red flags 1
- HighDisplay name contains a different address
The name shown is "Dana Whitfield (dana.whitfield@company.example)" but the real address is d.whitfield.office@freemail.test. Many phones show only the name, so this is a classic spoofing trick. Learn more show in 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=reject · 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 d.whitfield.office@freemail.test designates 198.51.100.14 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 freemail.test passaligned (exact match)
- DKIM freemail.test 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
- freemail.test selector fm1 · rsa-sha256 · signed 2026-10-22 18:45:10 UTC · covers 6 header fields ↧
Who it claims to be from
- From
- Dana Whitfield (dana.whitfield@company.example)
d.whitfield.office@freemail.test↧ - Return-Path
d.whitfield.office@freemail.test↧- Subject
- Quick favour - are you at your desk? ↧
- Date
- Thu, 22 Oct 2026 18:45:08 +0000 = 2026-10-22 18:45:08 UTC ↧
- Message-ID
<a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d@freemail.test>↧- Services seen
- Google (Gmail / Google Workspace) mailbox
Route 3 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-22 18:45:08 UTC (sender's clock +0000)
- +2 s
- +1 smx.google.com Googlefrom out-14.smtp.freemail.test
198.51.100.142026-10-22 18:45:11 UTC (−0700 local) ↧Probably where your provider took the message in from the outside world. The IP here was seen by the receiving server, so it is the most trustworthy origin address in the headers. - +1 s2001:db8:4a5:10::c32026-10-22 18:45:12 UTC (−0700 local) ↧
First to last server: 2 s. Reading delays
The headers 16 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.