An email's visible From line is typed by whoever sent it. The headers underneath are written by the servers that carried it, and they are much harder to forge. Paste them here to see SPF, DKIM and DMARC results, the full relay chain with timing, the display-name and reply-to tricks behind most payment fraud, and a passive risk read on every link in the body.
You've used your free checks for today. Create a free account to keep going — it takes about thirty seconds.
Each mechanism's actual result, from the receiving server's own Authentication-Results header, with the raw segment so you can see what was evaluated rather than trusting a green tick.
Every hop the message took, newest first, with the delay each one added. Non-monotonic timing, impossible geography and unexpected first hops all surface here.
Display name versus real address, Reply-To pointing somewhere other than From, Return-Path disagreeing with both, and lookalike sending domains — the mechanics of invoice redirection.
Every URL the message carries, each with a reputation read taken offline — no outbound request is made, so nothing tells the sender you looked.
Start here, not with SPF. SPF breaks whenever a message is forwarded and DKIM breaks whenever a mailing list rewrites the body — both fail constantly on legitimate mail. DMARC is the domain owner's own policy about what should happen when the authenticated domain doesn't match the one you can see. A DMARC failure means the organisation whose name is on the message says this isn't theirs.
Perfect authentication on a lookalike domain is the single most common shape of invoice fraud. exarnple.com passes SPF, DKIM and DMARC beautifully — for exarnple.com. Read the sending domain character by character, and be especially careful with rn/m, l/I, and any domain with an extra hyphen.
A Reply-To that differs from From is not automatically wrong — ticketing systems and mailing lists set it constantly. But when the From is a supplier's real domain and the Reply-To is a free webmail address or a domain registered last month, you are looking at the mechanism, not a coincidence.
Read the hops from the bottom up: the message should start somewhere plausible and travel forward in time. Delays of hours between adjacent hops, a chain that goes backwards, a first hop on a residential connection, or a message that claims a corporate origin but entered through a consumer relay — each is worth explaining before you act on the content.
Headers describe delivery, not intent. A message that passes every check can still be a fraud sent from a real, compromised mailbox — and account takeover is now common enough that “the headers were clean” is not a defence. Equally, a message that fails SPF may just have been forwarded by a colleague.
The headers also cannot verify the attachment. If the ask is a payment change, an invoice, or a signed document, the file itself is where the answer is — and that is what a document scan is for.
Nothing is saved. The free tools hold your input for the length of the request and drop it with the response — no stored report, no archived file, no record of the URL, the message or the filename. The only thing we keep is an anonymous count so the daily allowance means something, and it is a number, not an identity.
Everything you see comes from deterministic analysis: public registration records, live DNS and TLS handshakes, header parsing and PDF structure. The same engines answer the same way whether or not you have an account.
Paste a link. Get registration age, DNS and mail records, the live certificate, security headers and a corroborated safety verdict.
Check a linkUpload a PDF. See saved revisions, values an earlier version carried, hidden layers, and the structural traces an edit leaves behind.
X-ray a PDFRelated, not the same — and the difference decides which control stops it.
What to do when a supplier emails asking you to update their account.
What an AP team should check before the payment run.
In Gmail, open the message, use the three-dot menu and choose "Show original". In Outlook on the web, open the message, then More actions and "View message source". In Apple Mail, View then Message then Raw Source. Paste whatever you get — headers alone are enough, and the whole message works too.
SPF says the sending server was allowed to send for that domain. DKIM says the message carries a valid cryptographic signature from the domain. DMARC is the domain owner's policy about what to do when the first two disagree with the visible From address. DMARC is the authoritative one: SPF and DKIM break routinely on forwarded and mailing-list mail, but a DMARC failure means the domain owner's own policy disowns the message.
The ones the sender writes can — From, Reply-To, display name and Date are all attacker-controlled. The ones added by receiving servers along the way cannot be rewritten retroactively, which is why the relay chain is the part worth reading. A chain that jumps timezones, goes backwards in time, or starts at a residential connection is telling you something the From line will not.
No. Authentication proves the message really came from the domain it claims — and an attacker who registers a lookalike domain will pass every one of those checks for their own domain. This is exactly how most invoice-redirection fraud works: perfectly authenticated mail from a domain that is one character off the real one.
No. It is parsed in memory during the request and discarded with the response. Nothing is written to a report or a log of what was analyzed. Redact anything you would rather not send over the wire anyway — the analysis works on headers alone.
A free account adds full forensic scans of the invoice, contract or statement the email was carrying.