Every Auth Check Failed. Filtering Was Skipped Anyway

A senior operating executive at an automotive-retail technology provider received a good-morning email one weekday, addressed by first initial, carrying a reference number and a document status update in the subject line. The subject read "Good morning [initial], Ref #12853 - Document Update - Status update for [company name]", with the employer's own name appended in lowercase. The sender alias read "Doc Booth" over an auto-generated, bounce-style address ending in songoven[.]com.

Everything below the subject line belonged to an airline. Not a rendering of one, an actual one.

The Body Was Somebody Else's Email

The footer carried the real copyright line of Delta Air Lines, its real headquarters street address, its real post office box, and the city and state where that head office sits. The recipient's own email address had been populated into that footer as a merge field, exactly where a genuine transactional message would place it. Above the footer sat the ordinary furniture of a real airline send: the loyalty program, current flight deals, the privacy policy, the preference centre. Dozens of those links resolved to the carrier's genuine domains, delta[.]com and its click-tracking host, and every one of them was clean.

One element did not belong. A button labelled REVIEW DOCUMENT, and a matching "message us" link, pointed at greg73[.]com. The platform's automated inspection returned a mixed verdict on that host, and the landing page was never captured.

One Grafted Link, Dozens of Genuine Ones

Most template clones we tear down work the other way around. A cloning tool ingests a real notification and rewrites every link in it, which is why the regulator badges, app store icons and legal disclosures in those messages all end up pointing at one attacker host. The trust furniture nobody clicks becomes the cheapest tell in the message.

This one inverted that. The furniture was left alone and exactly one destination was swapped, which changes what review feels like. Anyone hovering links here gets confirmation after confirmation that the mail is what it claims to be, because almost every link genuinely is, and gets a single chance to notice the graft. Phishing that ships a link rather than a payload needs only one destination to work, and everything else can be borrowed intact.

The Authentication Verdicts Were Real

At the final Microsoft 365 hop, the message failed everything. SPF returned softfail. DKIM failed with a body hash that did not verify against the signing domain. DMARC failed. Composite authentication scored none, with the reason code that accompanies an unauthenticated inbound message.

Those verdicts are genuine, and none of them describe the attacker. The address that produced the SPF softfail belongs to the recipient organization's own security gateway. That gateway received the message from a commercial bulk sending service, ran its own checks at receipt and recorded them as passing (a legitimate receipt-time attestation, not a deception), then relayed it into the tenant from its own address, which the sending domain had never authorized. Hence the softfail. A body hash that no longer verifies is consistent with content being modified somewhere in that transit. The failing signals were produced by the security appliance, not by whoever sent the mail.

There is a second layer of nothing happening here. The sending domain published its own DMARC record at the permissive setting, which under the DMARC specification requests no action at all on failure. Even a receiver reading the alignment result correctly had been asked, by the attacker's own policy, to do nothing about it. Knowing which of your inbound paths actually enforce a verdict is the point of DMARC management and monitoring, and the answer is rarely the one on the architecture diagram.

The Appliance That Broke Authentication Also Excused It

The same headers that record the triple failure also record the organization's spam confidence level set to minus one, the value that means skip filtering entirely.

That stamp was not a scoring mistake. It was a trust decision made about the connector, not about the message. Mail arriving over an organization's own gateway connector is commonly treated as pre-inspected, so the mailbox provider stands down rather than repeat work it assumes already happened. The consequence here is circular. The gateway inspected the message and passed it, then relayed it in a way that invalidated its authentication, and the provider skipped its own evaluation because the message came from the gateway. The failure verdicts were computed, written into the headers, and consumed by nobody.

Attackers do not need to defeat a gateway that a tenant has already agreed to trust unconditionally. This is the specific gap gateway augmentation exists to close: something has to evaluate the message after it clears the perimeter, on the assumption that the perimeter verdict may be stale, structurally broken, or simply skipped.

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

The Recipient Was Not Random

One mailbox received this, and it belonged to one of the company's most senior operating leaders. A borrowed airline template is plausible in that inbox, because travel mail is exactly what an executive skims at speed and forwards without reading closely.

Themis, the IRONSCALES Adaptive AI analyst, scored the message at 59 percent with credential-theft and vip-recipient labels. That verdict arrived after delivery, which in this architecture was the only place it could arrive, because the provider had been instructed not to look. An analyst approved the finding manually and the mailbox was quarantined. The 2024 Verizon Data Breach Investigations Report puts stolen credentials in 38 percent of breaches as the leading initial action, which is the outcome this message was shopping for.

What To Take From This Case

Inventory the inbound connectors that bypass filtering, and for each one name the control that is still evaluating authentication on that path. If the answer is the appliance that also rewrites the mail, the answer is nobody. And note what the skip-filtering stamp actually suppressed: not only an authentication verdict, but the content and behavioral inspection that never depended on authentication at all. Scoring the true originating address would have shown this message passing cleanly at its first hop, so the setting worth revisiting is the one that turned inspection off, not the one that decides whose address gets scored.

Then build the alert this case demanded and never got: a failing authentication verdict co-occurring with a filtering-skipped stamp. As both CISA phishing guidance and NIST frame it, authentication results open a review rather than replace one. That pairing should be nearly impossible in a healthy mail flow. Here it was routine, and it took a borrowed footer and one swapped button to turn it into an incident.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

Check what your trusted connectors are allowed to skip. Back tomorrow with the next teardown.