The Vendor Inquiry That Failed SPF Before It Passed DKIM

A message reached three mailboxes at a residential home-services company carrying a vendor-registration question and nothing else. No attachment. No credential form. No invoice, no payment instruction, no link to anything the sender controlled. It introduced a salesperson at a surveying company, said the sender had identified the recipient organization as a possible supplier, and asked to be pointed at whoever handles vendor registration and onboarding. It asked politely, in four short sentences.

By the time it was delivered it carried a verified DKIM signature, an SPF pass, a DMARC result, and a composite authentication pass, all on a real Australian business domain that has been operating under the same registrant for years. Every automated signal said ordinary business mail. A human analyst quarantined it across all three mailboxes anyway.

The reason sits in the header stack, one hop earlier than most reviews ever look.

Where the Authentication Actually Broke

The delivered authentication results were clean. SPF passed on a Microsoft 365 outbound address belonging to the sending domain, DKIM verified against a signature for that same domain, and the composite authentication check passed with a reason code that reflects a legitimate signed message from a known domain.

The preserved ARC chain told a different story about the same message. At the earliest recorded hop, before any trusted relay had touched it, the results were spf=fail, dkim=none because the message was not signed at all, and dmarc=none. The address that submitted it, 45[.]62[.]170[.]243, had no reverse DNS record. That submission claimed to be from the Australian domain and had no cryptographic right to do so.

Between those two states, the message transited the sending domain's own outbound path and picked up a genuine signature there. That is the pattern consistent with a mailbox being driven by someone who should not have it: the tenant's signing infrastructure treats the message exactly as it treats every real message the mailbox sends, because from the infrastructure's point of view it is one. The record shows the effect, not how the mailbox was reached, whether by stolen credentials, an exposed connector, or something else.

This inversion is the part worth internalizing. A failure at the last hop before a recipient is usually noise. Security appliances rewrite bodies after signing, and a resulting body-hash failure says nothing about intent. A failure at the first hop is the opposite: it describes the original act of submission. Reading only the delivered header block hides that completely, which is why account takeover detection has to reason about behavior and history rather than the final authentication verdict. Stolen credentials were the single most common initial action in the 2024 Verizon Data Breach Investigations Report, present in 38 percent of breaches, and this is what they look like once they are in use.

A Reply Path Aimed at a Different Company

The visible sender was a mailbox on the Australian domain. The display name was a first-and-last-name persona that did not correspond to that mailbox at all. It corresponded to the local part of the Reply-To address, which sat on an entirely separate domain, kennedysurveying[.]com.

That apex domain resolves to Microsoft-hosted name servers, and it was roughly fifteen months old when the message arrived. Every reply the recipients might have typed would have left the compromised mailbox's thread silently and arrived somewhere the attacker was positioned to read. The compromised mailbox only had to survive long enough to open the conversation.

Nothing about this violates DMARC. Alignment is evaluated against the visible From domain, as specified in RFC 7489, and the Reply-To header is outside that evaluation entirely. A message can pass every published check and still send its answers to a stranger.

See Your Risk: Calculate how many threats your SEG is missing

Dozens of Hidden Lines and a Borrowed Signature

Beneath the short ask sat roughly five dozen empty container elements, each marked hidden from assistive technology, and then a nested block styled to render as a quoted reply. That block carried a complete corporate signature belonging to an unrelated third party: a name, a job title, an office address, a phone number. None of it had any relationship to the sender, the recipient, or the surveying pretext. It was filler, borrowed from elsewhere to make a four-sentence cold email render as the tail of an established thread.

The links inside that padding pointed at an unrelated corporate website and at Microsoft's own phishing-awareness pages. All of them scanned clean, because all of them were real. Reputation scoring on outbound links finds nothing when the links are not the attack.

Reconnaissance Is the Payload

There was no prior correspondence between this sender and any mailbox at the recipient organization, and none with the organization at large. First contact, and the only request was a routing question.

That is the cheapest stage of a business email compromise attempt and the hardest one to justify blocking. Nobody loses money to a question. But knowing which named person owns vendor registration converts a generic later attack into a targeted one, delivered into a thread that already has history behind it. Pretexting is the top social-engineering pattern in the 2024 DBIR, with a median transaction of roughly 50,000 dollars, and the FBI's 2023 Internet Crime Report put reported business email compromise losses near 2.9 billion dollars. None of those attempts began with the invoice. They began with somebody learning who to send it to, which is why business email compromise defense has to treat the harmless-looking first message as part of the same event.

Why Automated Triage Read It as Bulk Mail

Worth stating plainly: automated triage on this incident bucketed the message as spam, and community resolution history on similar incidents agreed with that reading with high confidence. Sender-behavior signals looked like mass mailing. Themis surfaced the message on a recipient-sensitivity recommendation rather than a stated phishing-confidence figure, and the record carries no phishing percentage for it.

That is a fair reading from the outside. A cold vendor inquiry with clean links, valid authentication, and no ask beyond a contact name is statistically far more likely to be low-grade sales outreach than the opening move of a fraud attempt. The discriminator was not in the content. It was in the ARC chain and the reply path, and it took a human analyst reading both to approve quarantine across the three affected mailboxes. Our Adaptive AI is built around exactly that loop, where analyst judgment on ambiguous mail feeds back into how the next similar message is scored.

Controls That Catch a Zero-Payload Probe

Read the whole ARC chain, not the delivered verdict. A pass at the trusted hop sitting on top of a bare failure at the original submission is a specific, describable condition, and it is worth an alert on its own.

Alert on reply-path divergence. A first-time external sender whose Reply-To domain differs from the From domain deserves scrutiny, and the case is stronger when the reply domain is young or when the display name matches the reply address instead of the sending one.

Make vendor onboarding a verified process, not an email thread. Route registration requests through a published form or a known contact, and confirm any new supplier relationship out of band. CISA's phishing guidance and the NIST definition of phishing both frame the goal the same way: remove the attacker's ability to make a request feel routine.

Indicators of Compromise

MITRE ATT&CK Mapping