Is this email phishing? A triage walkthrough.

#The first three minutes

Most phishing is caught by the same four questions, asked in the same order. The order matters, because each one is cheaper than the last and any of them can end the investigation.

1. Does the message ask for something that bypasses a normal process? Payment details changing, an urgent approval, a login on a link rather than a site you navigate to yourself.
2. Do the headers show the domain in the From line actually authorised this message?
3. Does every link point where its text says it points?
4. Is the attachment the kind of file it claims to be?

None of these needs a sandbox, a subscription or a ticket. They need the original message, which is the one thing people tend to destroy first by forwarding it.

#What the headers prove, and what they do not

Three mechanisms sit behind every modern claim about who sent a message, and they answer different questions.

That last column is the part people get wrong. SPF and DKIM operate on domains a recipient never sees. DMARC is the mechanism that ties one of those passes back to the address on screen, which is why a message can pass SPF and still be a forgery of the name you trust: the envelope and the visible From are simply different domains.

The verdicts appear in an Authentication-Results header. Reading them is straightforward once you know where they come from, and there is one trap.

Our email header analyzer does this matching, rebuilds the delivery path in order, and says in one line whether the message is consistent. It runs in the browser, so the headers of a message about your own company do not travel to a third party to answer the question.

#The sender line is two different things

An address in a mail header is a display name followed by the real address in angle brackets, and the display name is arbitrary text. That is not a flaw, it is the format working as specified, and it means a message can legitimately display as anything at all.

From: "accounts@bigbank.example" <billing@sender-example.net>

A mail client shows the part in quotes. The message came from the part in brackets. Most clients on a phone show only the display name, which is why this still works after thirty years.

Two more places the same trick appears:

• Reply-To. The message can display one address and send your reply to another. This is how invoice fraud keeps a conversation going from an address the victim never checks.
• A quoted display name containing an address. Some readers take the first address they find. Read the last one in angle brackets, which is the one that actually sent.

#Reading a link without opening it

Copy the link address rather than clicking it. Then read the host from right to left, because only the rightmost two labels decide who owns it.

https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com.secure-verify.example/auth
https://www.microsoft.com@collector.example/signin

The first is Microsoft. The second belongs to whoever registered secure-verify.example, who chose the rest to be read left to right. The third goes to collector.example, because a browser discards everything before an @ in the host, and always has.

Two further shapes are worth knowing:

• A link carrying a link. A parameter such as next= or redirect_uri= holding another URL turns a real service into a doorway. The message genuinely starts at a domain you trust and does not end there.
• Characters that are not the ones they look like. A Cyrillic small letter a is a different character from a Latin a and renders identically. Domains built from them are stored as xn-- names and displayed as the pretty form, which is the entire reason they are registered.

Our link checker takes a link apart, decodes the punycode so both forms are visible, finds the URL inside the parameter, and hands back a defanged copy for the ticket. It never fetches the link, which matters: a preview service that visits the page tells the sender their message was opened.

#The attachment

A file name is a label. The first bytes of a file are what an operating system actually acts on, and the two disagree more often in phishing than anywhere else.

• A file whose first two bytes are MZ is a Windows executable, whatever the name says. The same goes for %PDF, PK for anything zip based, and the rest of the short list of magic numbers.
• Windows hides known extensions by default, so invoice.pdf.exe is displayed as invoice.pdf, with a matching icon if the sender bothered.
• An archive with one file inside is not a compression decision. It is a way past a filter that inspects attachments.

#Three messages, three verdicts

The examples below are synthetic, written for this guide.

A forgery

DMARC fails at the receiving server. The display name is an address at a bank, the real sender is a different domain, Reply-To is a third. A link reads as the bank and points at a domain registered last week. Nothing here needs a fourth opinion: the sender is not who the message says, and that is decided.

A real message that looks wrong

SPF fails, DKIM passes, DMARC passes. The delivery path shows a mailing list in the middle. That is the normal outcome when a message is forwarded: the forwarder becomes the sending server, so SPF breaks, while the signature survives because the content did not change. A DMARC pass on a DKIM signature from the right domain is a pass.

A forgery that authenticates perfectly

Everything passes, because the attacker registered their own domain, published their own records and signed their own mail. Authentication proves the address is genuinely theirs. It says nothing about whether the name attached to it is one you have ever dealt with. This is the case that catches experienced people, and the only answer is the first question in this guide: what is the message asking for, and does the answer belong to a process you already have?

#If someone already clicked

Speed matters more than certainty here, and the order is worth agreeing before you need it.

1. Credentials first. If anything was typed into a page, change that password and end the sessions it protects. Resetting the password without revoking sessions leaves a signed-in attacker signed in.
2. Check for what came after. A new mail rule that forwards or deletes messages is the usual first act after an account takeover, because it hides the conversations that follow.
3. Collect the indicators once. Pull the addresses, domains, URLs and hashes out of the message and the logs in one pass, defanged, so they can be circulated without anyone clicking them. Our indicator extractor does that in the browser.
4. Tell the people who received it too. A phishing message is rarely sent to one person, and the second recipient is usually the one who acts on it.

#Making the next one harder

Triage is the part after prevention failed. Three changes move the most:

• Publish DMARC at enforcement. A domain at p=reject cannot be forged in the simple way, which removes the most convincing kind of message. Getting there means publishing SPF and DKIM first, reading a fortnight of reports, fixing the senders you had forgotten and only then tightening. Our SPF and DMARC tool reads what you have and writes what you need.
• Use phishing-resistant authentication where it counts. A code from an app is still something a person can be talked into typing into the wrong page. A hardware key or a passkey is bound to the site it was registered with, and cannot be handed to a lookalike.
• Make reporting easier than deciding. If the cost of asking is a raised eyebrow, people stop asking. The organisations that catch these early are the ones where forwarding a suspicious message to the right place takes one click and no explanation.