Worked example 6 of 11
A spoofed 'bank security alert'
A forged From address that fails every check. It only reached the inbox because the bank's DMARC policy is still p=none.
What to notice
The From line says security@examplebank.example, and nothing in the headers backs that up:
- SPF fails. The message came from
203.0.113.77, a rented server (vps-77.cheaphost.test), which isn't on the bank's list of permitted senders. - There's no DKIM signature at all, so
dkim=none. - DMARC fails, and the comment shows why the message still arrived:
p=NONE. The bank publishes DMARC in monitoring mode, so receivers report the failure but don't block it. Withp=rejectthis message would have bounced. - Replies go elsewhere.
Reply-To: examplebank.helpdesk@webmail.test. Anyone who answers writes to the attacker, not the bank. - The Date header claims a time one hour after delivery, and the server's name in the HELO (
mail.examplebank.example) is a lie: the receiving server's own reverse-DNS lookup foundvps-77.cheaphost.test.
Any one of these is a reason not to click. Together, they're a textbook forgery.
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.
- Fromexamplebank.example
- Sent from203.0.113.77
- Hops3
- In transit2 s
- ViaGoogle
Red flags 3
- HighDMARC failed
Your provider recorded dmarc=fail: nothing proved that this message really comes from examplebank.example. Unless it came through a mailing list or forwarder, treat it as a forgery. Learn more show in headers
- MediumReplies go to a different domain
Reply-To is examplebank.helpdesk@webmail.test, so hitting Reply sends your answer to webmail.test, not to examplebank.example. That is normal for some newsletters and help desks, and a favourite trick in invoice and CEO fraud. Learn more show in headers
- LowDate is later than delivery
The Date: header is 1 h 0 min after the first server received the message. The sender's clock is wrong, or the header was made up. 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.
Neither SPF nor DKIM passed for a domain aligned with the From domain, and that domain publishes DMARC: the From address is not authenticated.
domain policy p=none · applied: none
SPF SPF checks whether the server that delivered the message was allowed to send for the envelope (bounce) domain.
The envelope domain says this server is NOT allowed to send its mail (a hard "-all" fail).
google.com: domain of security@examplebank.example does not designate 203.0.113.77 as permitted sender
Alignment with the From address
- SPF examplebank.example failSPF fail, so it can't count
No passing check is aligned with the From domain, so DMARC can't pass. 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.
Who it claims to be from
- From
- Example Bank Security
security@examplebank.example↧ - Reply-To
examplebank.helpdesk@webmail.testdifferent organisation ↧- Return-Path
security@examplebank.example↧- Subject
- Unusual sign-in attempt: verify your account within 24 hours (decoded from utf-8) ↧
- Date
- Mon, 19 Oct 2026 13:20:33 +0000 = 2026-10-19 13:20:33 UTC ↧
- Message-ID
<20261019122033.8E2F14A0C1@vps-77.cheaphost.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-19 13:20:33 UTC (sender's clock +0000)
- clock skew −1 h 0 min
- +1 smx.google.com Googlefrom mail.examplebank.example
203.0.113.772026-10-19 12:20:34 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::772026-10-19 12:20:35 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.