A security-aware person received an email. It had a verified sender checkmark. SPF passed. DKIM passed. DMARC passed with the strictest possible policy. The sending infrastructure was legitimate. No header analyzer on the market would have flagged it.
It was also a social engineering attack.
This write-up breaks down how it worked, why every technical trust signal was meaningless in this context, and what the limits of header-based analysis actually are. I built a header analyzer. This is the case that broke it — on purpose.
The authentication picture
Running the headers through analysis produced a clean bill of health across every standard check:
The email originated from a real IP range belonging to a major platform.
It was signed by a legitimate sending domain. The DMARC policy was
p=REJECT — the strictest setting, meaning the domain owner
actively rejects spoofed mail. BIMI was configured, which is why
the verified checkmark appeared in the client UI.
The analyzer scored it near zero risk. It was correct by every metric it was designed to measure.
What the email actually was
The platform in question operates a business tools ecosystem that allows companies to send partnership and access requests to other users through an official notification system. Those notifications arrive as fully authenticated emails — because they are sent by the platform's own mail infrastructure.
An attacker created a legitimate account on this platform. They then sent a partner access request to the target's email address through the platform's own tooling. The platform dutifully delivered an authenticated notification email on their behalf.
The attacker did not spoof anything. They used the system as designed. The checkmark was real. The threat was real. These two things are not mutually exclusive.
The attack chain
The hidden text trick
The email body contained a block of text rendered in a 1-pixel white font on a white background. Invisible to the human reader. Fully readable by spam filters.
The hidden text contained a disclaimer — essentially stating that the named program was official, but any other similar program was not, and that users should only approve requests from trusted parties.
This serves two functions simultaneously. It seeds spam filter keyword analysis with legitimate-looking content, improving deliverability. And it provides legal plausible deniability — the warning was technically present. You just couldn't see it.
Why the checkmark made it worse
BIMI — Brand Indicators for Message Identification — was designed to let domain owners display a verified logo next to authenticated emails. The intent is to help users identify legitimate senders.
In this case it performed the opposite function. The checkmark suppressed the instinct to scrutinise. A suspicious-looking email triggers caution. A verified, professional-looking email from a platform the target nominally has history with triggers compliance.
The checkmark did not indicate the email was safe. It indicated the email genuinely came from the platform's servers. These are not the same thing. The attack lived inside the platform, not in the delivery mechanism.
What header analysis can and cannot do
| Check | What it tells you | What it doesn't tell you |
|---|---|---|
| SPF | Sending server is authorised by the domain | Whether that domain is being abused |
| DKIM | Email wasn't modified in transit | Whether the content is malicious |
| DMARC | Domain owner enforces auth policy | Whether the sender is trustworthy |
| BIMI | Logo is registered to the sending domain | Whether the email's intent is legitimate |
| Spam score | Heuristic risk based on content patterns | Platform-native social engineering |
| IP reputation | Known bad actor infrastructure | Legitimate infrastructure used maliciously |
Header analysis is a transport-layer discipline. It answers the question: did this email arrive from where it claims? It cannot answer: is the thing this email is asking you to do legitimate? Those are different questions. This attack only required the first answer to be yes.
The targeting failure worth noting
The target in this incident had no active account on the platform. The dormant asset the attacker was attempting to access via a third party was not associated with the target's email address. The attacker bulk-blasted harvested emails without verifying account relationships.
This is operationally sloppy. It also means the campaign is running at scale. Sloppy targeting is a volume play — send enough requests, some percentage of recipients will have the relevant access and will click approve without reading carefully.
The checkmark does the conversion work. The attacker doesn't need precision. They need throughput.
Indicators to watch for
Since headers won't save you here, the signals to look for are at the application and content layer:
- Notification emails for platforms you don't actively use
- Partner or access requests you didn't initiate
- Any email asking you to approve sharing of assets or permissions
- Requests from entities with generic or program-sounding names
- "Third party" or "not affiliated" disclaimers anywhere in the email — especially if hard to find
- A verified checkmark on an email you weren't expecting
If you receive one of these
Do not click through to review the request via the email link. Navigate to the platform directly and check pending requests from there. Reject anything you didn't initiate. Report the requesting account to the platform's trust and safety team — the requesting account ID will be visible in the platform's partner settings UI, not in the email itself.
If you have dormant accounts on major platforms with assets attached — pages, ad accounts, payment methods — log in and audit your partner and app permissions. Dormant assets are high-value targets precisely because their owners aren't watching.
Where this leaves header analysis
Header analysis is still worth doing. It catches spoofing, misconfigured senders, and a wide class of commodity phishing that represents the majority of malicious email volume. The tool I built catches all of that correctly.
What it doesn't catch — what nothing at the header layer catches — is an attacker who has correctly understood that the trust infrastructure of email can be fully satisfied while the attack itself runs one layer up. Platform-native social engineering is immune to transport-layer analysis by design.
That's not a failure of the tooling. It's the correct scope of what the tooling can claim. Knowing where a tool's guarantees end is as important as knowing what it catches.
The email passed every check. That was the attack.
← Back