Worked example 10 of 11
A genuine invoice from a badly configured small business
Not every failure is an attack. This invoice is real, but the firm's web host isn't in its SPF record, it doesn't sign with DKIM and it has no DMARC record.
What to notice
A plumbing firm's invoicing plugin sends mail straight from its web-hosting server. Nobody told the domain's SPF record about that server, so:
spf=softfail: the domain's record ends in~all, which means "probably not us, but don't reject". The sending IP198.51.100.200(web17.webhost.test) isn't listed.dkim=none: the plugin doesn't sign.dmarc=none: the domain publishes no DMARC record, so nothing ties the From address to anything.
MailDingo's verdict is "not fully authenticated", not "suspicious": nothing contradicts the sender, there's no Reply-To trick and no look-alike domain. But nothing proves it either, and that's exactly the gap a fraudster exploits with fake invoices. Check any change of bank details by phone, using a number you already have.
The Subject is Q-encoded in ISO-8859-1 (f=FCr is "für"), and the Date header leaves out the day of the week, which RFC 5322 allows.
The analysis
Produced by the same code that runs in the analyser.
Check carefully
Not fully authenticated
Nothing proves the From address (example.com) is genuine. Many small senders are simply misconfigured, but be careful with anything that asks you to act.
- Fromexample.com
- Sent from198.51.100.200
- Hops2
- In transit1 s
Red flags 1
- MediumSPF softfail and no valid DKIM
The envelope domain says this server probably isn't one of its senders (softfail), and no DKIM signature backs the message up. Often just a misconfigured sender, but nothing proves who sent it. Learn more show in headers
Authentication
Checked by mx1.example.net, 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.
The From domain publishes no DMARC record, so the receiver had no way to judge the From address.
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 probably shouldn't send its mail ("~all"), but asks receivers not to reject outright.
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.
Other checks
The sending IP's reverse DNS name points back to it.
Alignment with the From address
- SPF example.com softfailSPF softfail, 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
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-26 09:15:07 UTC (sender's clock +0100)
- +1 s
- +1 smx1.example.netfrom web17.webhost.test
198.51.100.2002026-10-26 09:15:09 UTC (+0100 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.
First to last server: 1 s. Reading delays
The headers 13 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.