The SPF Failure That Vanished Before Delivery

Four mailboxes at a global engineering and construction consultancy received the same message one morning: an approval statement, sent from a business partner they had legitimately corresponded with before. The body was short. It carried one small PNG that scanned clean and one link, rendered as "VIEW DOCUMENT."

Nothing about the sender was fake. The domain was real, properly configured, and signing with its own DKIM key. The mailbox belonged to a person the recipients knew.

The interesting part sits in the authentication headers, and it is not what a one-line summary would tell you. Partway down the delivery chain, this message genuinely failed SPF. By the time it reached the mailbox, the delivered result read as a clean pass on all three checks.

The Sender Was a Compromised Partner, Not Attacker Infrastructure

Start with what this case is not. There is no lookalike domain here, no freshly registered typosquat, no consumer mailbox wearing a corporate display name. The sending organization is a functioning business with its own DKIM selector and a paid corporate email-signature deployment, which is not the profile of throwaway infrastructure. Its Microsoft 365 account was taken over and used to mail a partner.

That is vendor email compromise, and it removes almost every artifact a filter likes to grade. Domain age is irrelevant, because the domain is older than the relationship. Sender reputation is intact, because the sender earned it honestly. Correspondence history is real, because the two organizations actually work together. The 2024 Verizon Data Breach Investigations Report puts stolen credentials at the top of initial breach actions, involved in 38 percent of breaches, and this is what that number looks like once it reaches a supply chain: the credential theft happens at one company and the phishing email is delivered by that company's own legitimate mail flow.

Where the SPF Failure Actually Happened

The partner runs a hosted email-signature service, the kind that appends corporate branding, disclaimers, and contact blocks to outbound mail centrally rather than per client. To do that, the service has to receive the message, modify it, and send it onward. Its processing markers are all over the headers, including a message-processed flag and two latency values from the signature imprint step.

That relay is where the chain breaks. The connection into the next hop came from an Exclaimer signature-insertion relay, IP 20[.]233[.]10[.]24, announcing itself as uae1[.]smtp[.]exclaimer[.]net. That IP is not authorized in the sender domain's SPF record. So the check did exactly what it is supposed to do and returned a failure. It is visible in Received-SPF as a fail, in the Exchange authentication results as spf=fail against that connecting IP, and in the intermediate ARC set as spf=fail while DKIM and DMARC still held.

This is a configuration gap, not an attack. Plenty of organizations authorize a middleware vendor to touch their outbound mail and never add that vendor to their SPF record, because delivery keeps working and nothing appears to be wrong.

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

ARC Carried the Earlier Pass Across the Modifying Hop

Read the chain in order and the shape becomes clear. At the point of composition, inside the partner tenant, the first ARC set records a clean sweep: SPF pass, DKIM pass with the sender domain signing, DMARC pass. At the signature relay, the second set records the failure described above. At delivery, the third set matches a final Authentication-Results header that reads SPF pass, DKIM pass, DMARC pass with no action taken, and composite authentication at a full pass.

ARC is the reason those three views coexist, and it is working precisely as designed. Mailing lists, security gateways, and signature services legitimately alter messages in transit and break the original alignment defined in RFC 7489, which is a real operational problem for anyone enforcing DMARC. ARC exists so a trusted intermediary can attest to what the authentication looked like before it interfered. Microsoft trusted the attestation, so the earlier pass carried forward.

The result is worth stating carefully, because the sloppy version of this story is wrong. This message did not fail authentication and slip through anyway. The composite verdict the receiving side acted on was a legitimate pass. What is remarkable is that the chain contained one genuine, real failure, created by trusted corporate middleware and then absorbed by the trust framework built to accommodate that middleware. Anything reading only the final summary, which is most tooling and nearly every analyst under time pressure, sees no anomaly at all.

The Payload Was a Project on an AI Website Builder

The link went to a project path on youware[.]app, an AI and no-code website-builder platform, with a companion live-preview subdomain under yw[.]app for the same project. A content delivery network sat in front of it, and our own scan of the destination returned the platform's human-verification interstitial rather than the rendered page, so what the visitor ultimately saw is not something we can describe. The hosting choice, though, is the point.

There is no purpose-registered attacker domain in this case. Registering one produces exactly the artifacts defenders score: a creation date measured in days, privacy-shielded ownership, no history. Building the page inside a legitimate site builder produces none of them. The URL inherits the platform's domain and reputation, the project can be stood up and abandoned in minutes, and blocking it means making a decision about a service that other customers use legitimately. The Microsoft Digital Defense Report 2024 tracks this steady migration of attacker hosting onto trusted platforms, and generative site builders are the newest place to do it cheaply. MITRE ATT&CK still classes it as spearphishing via link, regardless of who owns the certificate.

What Was Left to Detect

Add up what a payload-centric pipeline had to work with. Authentication: pass. Sending domain: legitimate and established. Attachment: a clean image. Link destination: a mainstream hosting platform. Relationship: genuine, with prior mail between the two organizations.

What remained was behavior. Themis, the IRONSCALES Adaptive AI analyst, models each mailbox as a set of relationships rather than a queue of files, so a known partner asking for something the partner does not normally ask for is an evaluable event even when every artifact is clean. The incident resolved automatically as phishing, and across the four affected mailboxes the recorded outcome was mitigation with no manual action taken.

What To Take From This Case

Two practical items. Inventory every service authorized to modify your outbound mail and confirm its relays are represented in your SPF record, because a hop-specific failure is invisible to you while staying perfectly visible to your partners. Then make sure your detection surface includes intermediate hop results, not only the final authentication summary, since that is the only place the anomaly in this message ever appeared.

Then the human control, which CISA phishing guidance and the NIST definition of phishing point at from different directions: an approval request from an established partner deserves the same out-of-band verification as one from a stranger, because a compromised partner mailbox is a stranger writing with a trusted pen.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

An authentication summary is a conclusion, not a record. This one was accurate, and it still hid the only strange thing that happened to the message. Check back tomorrow.