Updated: 22 October 2026.
An email claims to come from a familiar organisation. The sender’s name looks right, the logo is convincing and the message asks for an urgent payment or login.
I would look at the headers, but I would not expect a single “pass” result to decide whether the message is safe.
Headers help answer questions about delivery and authentication. They do not establish that the sender’s request is legitimate or that the account has not been compromised.
Preserve the original message
I would start with the original message or its full source. A screenshot leaves out the routing and authentication details. An ordinary inline forward can also lose important evidence.
Before sharing headers, remember that they may contain addresses, internal hostnames, identifiers and other information. For a public discussion, I would use a carefully sanitised copy. For an investigation, preserve the original separately.
Establish which system is reporting the result
The Authentication-Results field can record checks performed by a receiving system. Its value depends on whether that system is trusted. An attacker can add a convincing-looking header to a message before sending it.
I would therefore begin at the trusted receiving side and identify the authentication results that belong to that environment. I would not accept every line saying spf=pass as evidence from my mail provider.
Routing headers need similar care. Received entries can help reconstruct the path, but entries outside the trusted boundary may have been supplied by an untrusted sender. Reading a list from bottom to top is not enough unless that boundary has been established.
Authentication results become useful evidence only after their trusted receiving source is established.
flowchart TD
A["Original email and full headers"] --> B{"Result from trusted receiving system?"}
B -->|No or unknown| C["Treat header claims as untrusted"]
B -->|Yes| D["Interpret SPF, DKIM and DMARC"]
C --> E["Seek trusted delivery evidence"]
E --> B
D --> F["Review actual domains and requested action"]
F --> G{"Credentials, money or sensitive data?"}
G -->|Yes| H["Verify through a known independent channel"]
G -->|No| I["Assess content and context"]
H --> I
Interpret authentication precisely
SPF evaluates whether the sending server is authorised for the relevant envelope-sender or HELO domain. It does not directly authenticate the display name shown in the inbox.
DKIM checks a domain’s signature over selected parts of the message. A successful check does not mean the content is honest or harmless.
DMARC connects authentication to the visible From domain through alignment. A pass can be useful evidence against certain forms of domain impersonation, but an attacker can use a domain they control or send from a compromised legitimate account.
I would compare the actual domains rather than rely on a familiar word in an address. A reply address that differs from the sender can be legitimate, but it should make sense for the business process.
Use the message context to decide the next step
Consider a fictional invoice email that passes authentication for a supplier’s real domain but asks for payment to a new bank account. Authentication does not verify the bank-account change. I would confirm it through a previously known contact method, rather than a telephone number introduced by that email.
Likewise, an authentication failure needs interpretation. Forwarding and message modification can affect results. Failure is a reason to investigate, not an automatic explanation of who sent the message.
A useful analysis states what the trusted headers support, what the message asks the recipient to do and which verification step remains. If the request involves credentials, money or sensitive information, I would pause that action until it has been independently confirmed.
