It Failed Three Auth Checks, Then Got Whitelisted

A hosted filtering relay recorded three authentication failures on one message. Reverse DNS failed. SPF failed. DMARC failed. Then, a few lines down the same header block, the same relay wrote a whitelisted classification, an evidence value of sender, and X-Recommended-Action: accept.

The sender was forged. It was the recipient organization's own domain, arriving from an external IP that the domain does not authorize. The checks caught exactly that. The decision recorded immediately after them keyed on the identity those checks had just rejected.

The message then re-entered through the organization's own on-premises Exchange 2019 server, left again through its own outbound host, and reached Microsoft 365 with spf=pass, dmarc=pass, compauth=pass reason=100 and SCL:-1. Microsoft wrote X-MS-Exchange-ExternalInOutlookResult: IsInternal. Four mailboxes at a privately held UK industrial firm received it inside six minutes.

Whitelisted on the strength of the identity that just failed

The relay's log of the inbound hop is unambiguous. Received-SPF: fail states that the forged domain does not designate the origin IP as a permitted sender. An X-SPF-Result header repeats it. An Authentication-Results-Original line records iprev=fail, spf=fail and dmarc=fail together, and a second such line repeats the SPF failure.

Then the reputation stage. Class: whitelisted. Evidence: sender. Recommended action: accept.

Be precise about what that is. The relay publishes its own abuse contact in the headers, which is how we know it is a legitimate third-party filtering service, not attacker infrastructure. It is a bystander. Whether an allow-list entry, a trust rule covering domains whose mail it handles, or something else produced the accept is not in the record, so no cause is claimed here.

The point is not that something failed to notice. The failure record and the accept decision coexist in one header block, unreconciled, because they come from two stages that never compare notes.

Two more hops, both through the organization's own mail path

The Received chain resolves cleanly. External IP to the hosted relay, running Exim 4.94.2. Relay to the on-premises Exchange 2019 server on a private internal address, named in the preserved organization headers. Exchange out through the organization's own webmail host into Microsoft 365.

By that final hop the handing-off IP was the organization's own outbound server, an authorized sender for its own domain. SPF passed. DMARC aligned, and on SPF alone, because the message carried no signature at all: dkim=none (message not signed).

A fail-then-pass delta across a relay is a pattern this series has covered, where a perimeter secure email gateway (SEG) relays a message inward and the downstream system scores the relay instead of the origin. Two things differ here. No third-party security gateway sat in the delivery path at all, so the laundering ran through infrastructure the organization operates itself, at two consecutive stages. And the first hop did not miss the forgery. It cleared it.

One more artifact from the Microsoft side: the Forefront report records PTR:InfoDomainNonexistent for the final relaying host, meaning no valid reverse DNS on the box that handed the message off, and compauth still returned pass reason=100. A message classified as internal also sits outside the scope of external-sender tagging by construction.

A previous-hop Authentication-Results header is normally a trap, because anyone can write one. This message inverts that: the previous-hop line is the only truthful authentication record in the file. Other self-spoof cases in this series end in an authentication failure at delivery. This one ends in a clean pass on every line a triage analyst reads.

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

The kit gave itself away where authentication could not

Set the headers aside and the message is sloppy. The visible subject line contains the message's own Message-ID header value, pasted in verbatim with a US-format timestamp appended. Each of the four recipients got a variant carrying that copy's own Message-ID and send time. The same value appears again inside a fake PDF filename in the body. There is no attachment.

The shell is a DocuSign clone: a green banner announcing that all parties have signed the completed document, a document card, and the real DocuSign corporate address in the footer. The imitated logo never renders, because the image reference is a single hash character. The card lists the recipient's own domain and own mailbox as the document signer, reinforcing the self-spoof visually too.

A fake signing-method block tells the reader to click an Access Documents button and enter a 33-character hex security code. No such button exists anywhere in the email. The only working control is a "VIEW COMPLETED DOCUMENT" anchor pointing at a shortener whose entire URL path is a percent-encoded emoji sequence, zero-width joiner included. That link scanned Clean and was never resolved, so no destination is claimed here.

This is a Spearphishing Link delivery (T1566.002) built on impersonation of the target's own identity. Themis, the Adaptive AI analyst, returned an automated label of Credential Theft at 86 confidence, with community insight recording high confidence from similar incidents. No human verdict is recorded on this incident, which surfaced through a scanback.

Indicators of Compromise

Thirty-nine incidents, zero safe verdicts

Domain-level history is what turns a structural argument into a confirmation. The sender history for that forged domain against this organization shows 39 incidents recorded since March 2025, all scanned, none truncated. Thirty-seven were auto-resolved malicious. One carries a human malicious verdict, on a different incident from the same forged domain. Zero were ever marked safe, by a human or by automation. Zero release requests were ever filed.

The forged local parts are mostly role mailboxes: a general enquiries address 25 times, a no-reply address 10 times, then accounts, careers and a few others once each. Pretexts rotate through fake DocuSign notices, fake Microsoft security alerts, password renewal prompts and account suspension threats.

That is an operator working one domain patiently. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and credentials in 39% across the full kill chain, with phishing the initial access vector in 16%. The Microsoft Digital Defense Report 2024 documents the same shift toward identity-first intrusion that borrows trusted infrastructure instead of breaking it.

Score the decision, not just the verdict

An authentication result and a delivery decision are two different records, and one control can produce both in the same header block without reconciling them. When a reputation stage keys on sender identity, forgery is precisely the input it cannot evaluate.

Three things to instrument. Alert on any hop where an authentication failure is followed by an accept or allow decision on the same message. Treat internal classification as a statement about the last routing hop, not about origin, especially where an on-premises server re-injects mail into the cloud. And downgrade a DMARC pass resting on SPF alone with no DKIM signature, because it says nothing about the From header a user sees.

IRONSCALES platform data shows gateways missing an average of 67.5 phishing emails per 100 mailboxes each month, and the 36,000+ security professionals across 18,000+ organizations on the platform see the same trend: the messages that survive are the ones that authenticate. As CISA notes in its guidance on stopping the phishing attack cycle, and as NIST frames phishing, the goal is borrowed trust. Here it was borrowed twice from the target itself, and handed over by a control that had already written down the truth.