A reported message passes SPF, DKIM and DMARC - what does that prove during triage?

## The queue this question lives in A report-phish button in the mail client sends a copy of a suspicious message into a queue that an analyst works. Unlike a detection, nobody has claimed the message is malicious - a human found it odd. The first artefact you look at is the header block, and the most common junior mistake is to treat the sender-authentication line as the answer rather than as one piece of evidence. ## What a pass actually asserts The three checks answer questions about **domains and integrity**, not about intent: - An SPF pass says the machine that handed the message to your mail server is listed by the envelope sender's domain as allowed to send for it. - A DKIM pass says a signature over a set of headers and the body validates against a key published by the signing domain, so those parts were not altered after signing. - A DMARC pass says the domain in the visible `From` line lines up with one of the above, and the domain owner's published policy was satisfied. Every one of those statements is about the **sender's domain**. None of them is about whether a human should trust the message. The protocols were built to stop one thing - a stranger putting *your* domain in the `From` line - and they do that well. They were never able to say whether a domain that legitimately authenticated is run by someone who means you harm. ## The two directions people get wrong **Pass does not mean safe.** Two everyday cases produce fully authenticated malicious mail. First, the attacker's own domain: registering a plausible name, publishing SPF and DKIM records and signing outbound mail costs nothing and is the default on every bulk-sending platform, so most competent phishing arrives with a clean result. Second, and worse, a **compromised legitimate mailbox** at a supplier or a colleague: that mail is sent by the real infrastructure of the real domain, so it authenticates perfectly, and the authentication result is simply irrelevant to the verdict. **Fail does not mean malicious.** A message forwarded by a mailing list or an alumni-style relay is re-sent from a host the original domain never authorised, and body modifications such as an appended list footer invalidate the signature. Newsletters relayed through a third party fail for the same reason. If you close reported messages as malicious because a check failed, you will be wrong most of the time. ## How far you can trust the rest of the header block The `Received` chain is prepended by each machine that handles the message, newest first. Only the hops added **by your own boundary and inward** are trustworthy; everything below them is text written by whoever sent the mail and can be fabricated wholesale to invent a plausible path. Read the chain to find where the message entered your estate and from what address, and treat the earlier lines as claims. The `From` display name is free text chosen by the sender and matches nothing - a message whose display name is a director's and whose address is a webmail account is a classic. A `Reply-To` pointing at a different domain from `From` is where a reply-chasing lure gives itself away. One more practical point: an inline forward from a reporter's mail client usually rewrites or drops the original headers, so the copy you receive can be useless for this read. The value of a report button over a manual forward is that it submits the original message intact. ## What the result is actually for Use it to fix the identity of the thing you are judging. Once you know the message genuinely came from `invoices-example.net`, the useful questions start: when was that domain registered, have we ever received or sent mail there, does the URL in the body live on the same infrastructure, does the request in the message - change these bank details, approve this application, open this document - make sense from this sender, and above all, who else in the estate received it. The verdict comes from those answers. The authentication line only tells you whose name to type into them.