One Email, Two DMARC Identities, One Delivery Path

Two Authentication-Results Headers, Two Answers

Earlier this month, one message landed in one mailbox at a North American cloud communications and managed-voice provider. Two hops on its delivery path each stamped it with an Authentication-Results header. The two headers do not agree about who sent it.

The provider's own upstream inbound MTA wrote this: iprev=pass; spf=pass; dkim=none (no signature) header.i=unknown; dmarc=absent header.from= followed by a second, unrelated domain named only inside the display name. Its private summary headers said the same thing twice more, X-DMARC-STATUS: absent and X-SPF-FROM-STATUS: not_checked.

The final Microsoft 365 hop, evaluating the identical From header on the identical message, wrote this: spf=pass; dkim=none (message not signed) header.d=none; dmarc=bestguesspass action=none header.from= followed by the real envelope domain, plus compauth=pass reason=109.

One message. One From header. Two values for header.from=, and therefore two DMARC evaluations of two different identities. Whatever else is interesting about this email, that is the finding: a DMARC result is not a property of a message. It is a property of whichever domain the evaluating parser decided the From header named.

Four Header-Shaped Fields Packed Into One Display Name

The From header carried exactly one real, routable address: a mailbox at a small law practice that buys email hosting from the provider, which is the only reason the message crossed that MTA at all. Everything else in the header sat in front of that address, inside the display name, and every piece of it was shaped like something it was not:

• a brand-like label implying a shared legal-documents service
• a parenthesised second address, at a second and unrelated domain, in the position a real address would occupy
• the bare word internal, on a message the same stack had already tagged as external
• a bracketed pseudo do-not-reply token, formatted like an automated notification identifier

RFC 5322 treats a quoted display name as free text. It is never supposed to influence authentication, which binds to the address itself. But a display name with two address-shaped strings in it gives a tokenizer two candidates, and this one produced two answers on a single path.

The record does not let us watch that tokenizer run, so the causal mechanism stays an inference rather than a confirmed fact. What the record does show is strong: the divergent domain occurs nowhere else in the message, not as an envelope sender, not as a Return-Path, not as a Reply-To, not in the body. It exists only inside the display name, and the evaluator that picked it is the only one that did.

Three Parsers, Two Readings, and Nothing to Arbitrate

There was a third opinion on the path. The recipient's phishing-banner gateway emits a signed token summarising what it understood the message to be, and the decoded payload reads cleanly: the envelope mailbox recorded as the from address, and the entire pseudo-header construction retained, intact and inert, as the display name. That gateway tokenized the header correctly. So did Microsoft. Two of three parsers on one delivery path resolved the real sender, and one did not.

Normally a signature settles this. DKIM names a signing domain independently of how anything parses the From header, which is why DMARCbis, published as RFC 9989 in May 2026, treats DKIM and SPF alignment as two separate routes to the same identity assertion. Here, DKIM was none at every single hop, from the submission relay through the content filter to Microsoft. There was no cryptographic identity anywhere on the path, so each parser's own tokenization was the final word, and no downstream hop had any way to notice that an upstream hop had authenticated a different domain.

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

Why a Divergent Binding Is Worse Than a Failure

A DMARC failure is a result. It means an identity was resolved, a policy was retrieved, and the two did not match. That is a signal, and every alerting pipeline built in the last decade knows how to consume it.

This was not that. By that MTA's own account, the identity it selected had no policy to enforce, so it recorded dmarc=absent and moved on. The evaluation did not fail. It produced nothing at all. The domain it chose is also a dead end for a responder: it returns no registration data whatsoever, so it can be neither characterised nor attributed, and the only thing anyone can honestly say about it is that a header string mentioned it.

Meanwhile the downstream hop recorded a DMARC verdict against the real envelope domain, and anything reading only that hop, which is to say almost every SOC pipeline, saw a normal-looking evaluation. Both headers are true. They are simply about different domains. Nothing in a standard mail-security pipeline compares them, because nobody expected them to be comparable.

The visible lure was consistent with the header work. The rendered panel offered four named legal documents, none of which existed as an attachment, behind a single button, and every visible word was fragmented mid-word by zero-height inline tags at font-size:0px and interleaved invisible characters, so no intact keyword survived in the document text. That is texture. The identity divergence is the attack.

What to Change in Your Detection Logic

Four rules, all specific to this failure mode. First, alert whenever a From display name contains an address-shaped string. There is no legitimate construction that needs a second address there, which makes it a near-zero-false-positive signal and maps directly to spearphishing by link, T1566.002. Second, diff header.from= across every Authentication-Results header on the message and alarm on any disagreement. A divergence is proof that at least one evaluator authenticated a domain your user never saw. Third, treat absent as unevaluated, not as acceptable, and never inherit a pass from a hop that resolved a different identity. Fourth, require DKIM signing for every domain you host, because a signature is the only thing that can arbitrate a contested From parse.

No evaluator on this path was positioned to catch the divergence, because each of them only ever saw its own reading of the header. The 2026 Verizon Data Breach Investigations Report puts phishing at 16% of initial access vectors and the human element in 62% of breaches, which is the case for reading messages the way a person and a parser both would. CISA and NIST both frame phishing detection around the message as received rather than as authenticated. IRONSCALES flagged this one on language and structure alone, with no human report, no prior correspondence with the sender and no community signal to lean on, which is what our Adaptive AI is for when the authentication layer has quietly answered a question about the wrong domain. Managed enforcement of your own published policy, covered under DMARC management and monitoring, closes the half of this that is yours to close.

Indicators of Compromise

MITRE ATT&CK Mapping