A Green Pass Proves Less Than You Think: Reading a Phishing Email Header, audio
Listen to this guide, voiced by Andrew.
The Message That Passed Every Check
A short email arrives from someone at a software company you have heard of. It names your organisation, asks one friendly question about winning more clients, and ends with “let me know if irrelevant”. There are no links and no attachments. Your mail provider shows SPF pass, DKIM pass and DMARC pass.
Most people read that and relax. The checks did their job and they still tell you very little, because they answer a narrower question than the one you are asking. This guide walks through what each check actually says, where in the header to look instead, and what to do with the result. The examples come from two real cases we looked at in September 2026. Domain names are replaced with placeholders ending in .example, and the people and businesses involved are not named.
What the Three Checks Answer
| Check | The question it answers | The question it does not answer |
|---|---|---|
| SPF | Is the sending server allowed to send for the domain in the envelope sender? | Is that domain the company it looks like? |
| DKIM | Was this message signed by a key that the domain in d= controls, and is it unaltered? |
Who controls that domain? |
| DMARC | Does the domain in the visible From address line up with an SPF or DKIM pass? | Whether the From domain is trustworthy |
All three confirm that a domain authorised a message. None of them says whether you should trust the domain. An attacker who registers sales-tool8.example can publish a perfect SPF record, sign with DKIM and set a DMARC policy of none, and every check passes for the attacker’s own domain. In the first case the real company had a strict DMARC policy of reject, and it was never engaged, because the mail never claimed to be from the real company’s domain anywhere a machine reads. The impersonation lived in the display name and the company name in the signature.
A green pass on a lookalike domain is what a well-built impersonation looks like.
Where to Look Instead
Open the full header, not the summary. Most mail clients call it “view source”, “show original” or “view headers”.
1. Compare three names. The display name, the address in From: and the address in Return-Path:. A display name can say anything. The domain after the @ is the identity that matters, and Return-Path shows who the sending system believed was responsible.
2. Read the domain, then look it up. A registration lookup over RDAP gives the registrar and the creation date. In the first case the sending domain was four months old and the company it named has existed for years. A young domain that claims an old company is a strong signal on its own.
3. Check the DNS of the sender and of the real company side by side. Compare nameservers, mail servers, SPF and DMARC. A real company’s domains tend to look alike. The impersonator’s looked like a different organisation entirely, with a different DNS host, a different mail platform and a weak DMARC policy.
4. Look for siblings. If the domain ends in a digit, try the neighbours. In the first case the sender used the eighth in a numbered series, and all nine domains existed, with the same nameservers, the same registrar and the same style of mail host. That pattern means a sending fleet built so that domains can be burned as they get blocked, and it is rarely a coincidence.
5. Trust only your own provider’s verdict. The Authentication-Results header is written by the server that received the mail. The topmost one is yours. Lines further down were written by earlier hops and can be forged by the sender. RFC 8601 describes this trust boundary.
6. Look at how it was submitted. In a Received line, ESMTPSA means the sender logged in to submit the message. That is normal for a real mailbox and says nothing good or bad by itself. It becomes interesting together with the next point.
When the Pass Is Real and the Mail Is Still Bad
The second case had the opposite shape. The mail came from a small business’s own domain. DKIM verified against that domain’s key and the message was submitted with a login. Nobody forged anything. The business’s mailbox had been taken over and was being used to send a fake sign-in page.
A valid signature from a domain proves that something with access to that domain’s mail system sent the message. It does not prove that the owner did. Here the right reading was that the domain’s owner was a victim, and the right action was to tell them. Treat the pass as evidence about who sent it and then ask the next question, which is whether the content is what that sender would ever send. A sign-in link in mail from a plumber is not.
A Message With No Payload
The first case had no link, no attachment and 231 bytes of plain text. That makes it look harmless, and it may be ordinary cold sales mail from a careless vendor. It is also how a two-stage approach opens: a reply confirms that the address is live and read by a person, and the link or document arrives in the second message. We could not tell which it was, and we did not need to. The advice is the same either way.
One small tell was worth recording. The sender’s own address was spelled one way in the From line and another in the address its own DMARC reports were sent to. People who build fleets at scale make small mistakes like that, and real staff rarely misspell their own address.
A Routine You Can Repeat
- Do not reply and do not click. Replying is what a first-stage message is buying.
- Open the full header and compare display name, From domain and Return-Path.
- Look up the From domain’s registration date and registrar over RDAP.
- Compare its DNS with the real company’s.
- Check for numbered or near-identical sibling domains.
- Read your own provider’s
Authentication-Results, and only that one. - If a pass is genuine, ask whose mailbox it was and whether that is something they would send.
- Report it, and keep the original message as a file, not a forward.
Reporting It
Tell the company being impersonated, because they can act on their own brand. Tell the registrar of the sending domain, whose abuse contact is in the RDAP record. Tell the mail platform that carried it. If a legitimate business’s mailbox was used, tell that business and give them the headers, because they may not know.
Abuse desks do not agree on a format. In our experience some want the original attached as an .eml file, some want the headers pasted as plain text, and some accept only a web form. Read the desk’s own instructions first. Also remember that a delivered report is not the same as a filed one, so check for a reply or a ticket number.
What We Did Not Do
We looked at DNS and public registration records and at the headers of the messages we had received. We did not click anything and we did not reply.
What This Guide Cannot Tell You
DNS and registration data change, and everything above describes what we measured in September 2026. A sibling series that exists today may be gone next month. The tests reduce your uncertainty but cannot prove intent. If a message asks for money, credentials or a decision, verify it through a channel you already trust, such as a phone number you looked up yourself.
Sources
- RFC 7208, Sender Policy Framework (SPF)
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8601, Message Header Field for Indicating Message Authentication Status
- RFC 9082 and RFC 9083, Registration Data Access Protocol (RDAP) query format and JSON responses
Standards text governs. Where this guide and an RFC disagree, the RFC is right and we want to hear about it.