DMARC Said Reject. A Quarantine Release Delivered It Anyway

The message that landed in a shared accounts-payable mailbox at a financial-advisory firm had no attachment, no link, and no tracking pixel. It had also already been caught. Microsoft's antispam engine quarantined it on August 13, 2026, on the strength of an authentication verdict that could hardly have been cleaner: SPF failed, there was no DKIM signature at all, and DMARC failed against a sending domain that publishes an enforced reject policy. Six days later, the same message was sitting in the inbox.

The lure was unremarkable. The sender alias read Accounts Receivable Team | Collection Center over a spoofed accounting-brand notification address, and the subject was a reply-styled RE: Copy of Invoice 10192710852 with the recipient's own domain appended. Intuit and QuickBooks spoofs are a well-worn category, and the brand is not what makes this case worth reading. The delivery path is.

The Original Verdict Left No Room For Interpretation

The original inbound evaluation, preserved in the message's original authentication-results header, is about as decisive as email authentication gets. SPF failed for the sending IP 209[.]222[.]82[.]241, a commercial hosted outbound relay. DKIM was recorded as none, so there was no signature to evaluate. DMARC failed, with the recorded action noted as an override.

The first ARC hop preserves that evaluation and spells out the policy it was measured against: reject for the organizational domain, reject for subdomains, applied to all mail. No sampling window, no carve-out, no monitoring mode. The brand had done the work.

That combination is normally treated as a hard backstop against spoofing, and it is worth being precise about why it is not. RFC 9989, the current DMARC specification, lets a domain owner request a disposition for mail that fails authentication. What a receiving system does with that request is a local decision, and receivers routinely apply their own overrides. Here the observable outcome was not a refusal at the SMTP layer. It was quarantine, one step softer than the policy asked for, and the step that made everything afterward possible: a refused message cannot be released, and a quarantined one can.

The Header Trail After Quarantine

Three headers on the delivered copy establish that it is a resubmission, not an original delivery. The Exchange generated-message-source header carries the value Antispam Quarantine Agent, the auto-submitted header carries auto-generated, and a quarantine resubmit timestamp header is present, which a normally delivered inbound message does not carry at all.

Two further headers attribute the release: a resent-from header and an Exchange forwarding-loop header both name the same internal mailbox at the firm. Taken together, the record establishes that the message was programmatically resubmitted out of quarantine and that the action is associated with an internal account.

It is equally important to be clear about what those headers do not establish. They do not distinguish an end-user self-service release from an administrator action, and nothing in the record speaks to why it happened. Someone with an overdue-invoice notice in quarantine and an accounts-payable job to do is an ordinary explanation, but that is an inference, not evidence. The mechanic is the finding, not the motive.

The Released Copy Looked Better Authenticated Than The Original

There is a second-order effect worth flagging, because it inverts the signal a downstream control reads. After the resubmission, a later ARC hop records a DKIM pass belonging to the recipient organization's own internal forwarding domain, generated by the re-signing along the release path.

So the copy that reached the inbox carries a DKIM pass. Any control, rule, or analyst reading only the most recent authentication result sees a signed message, while the original failure survives one layer down, in the original authentication-results header and the first ARC set. A message that was correctly caught can end up looking better authenticated than it ever was. That is an argument for treating DMARC monitoring and enforcement as something you audit end to end, including what happens to mail after a verdict has been recorded.

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

The Entire Attack Surface Was One Reply Address

Pull the message apart and there is almost nothing in it. No attachments. No links. No embedded images. The body is a short, generic outstanding-invoice collection notice, signed off by a collections analyst persona, with a single contact address repeated twice.

That address, accounts@ap2-linkedin[.]com, is also the reply-path value, which routes any response away from the spoofed brand entirely. The domain ap2-linkedin[.]com was created on April 16, 2026 through Dynadot behind a privacy service, making it roughly four months old when the message was sent. It has no relationship to the accounting brand being spoofed and, despite the string, none to LinkedIn. The prefix reads as accounts-payable shorthand, the only audience it needs to convince.

This is what should worry anyone leaning on payload analysis: no attachment to sandbox, no URL to reputation-check, no redirect chain to unwrap. The 2026 Verizon Data Breach Investigations Report puts phishing behind 16% of breaches as an initial access vector and the human element in 62% of them, and cases like this are why those two figures move together. The 2025 FBI IC3 report recorded $3,046,598,558 in reported business email compromise losses, and reply-driven invoice fraud with no technical payload is a well-established route into that total. CISA phishing guidance stresses reporting and out-of-band verification precisely because there is often nothing for a scanner to find.

Detection has to come from the shape of the message rather than its contents: a brand spoof with no signature, a reply path on an unrelated recently registered domain, a first-contact sender writing to a shared finance alias, and an invoice pretext with no thread behind it. Our Adaptive AI flagged it as invoice phishing at 86% confidence on that basis, with community reputation matching against resolutions of similar incidents across 36,000+ security professionals across 18,000+ organizations.

Where A Policy Verdict Stops Being A Guarantee

The takeaway is that this chain contains two separate softenings, and only the first usually gets audited. The sender published an enforced reject policy; the receiver recorded an override to quarantine. Then the quarantine was resubmitted. Neither step is a DMARC bypass, a broken policy, or an attacker defeating a control. Both are ordinary, documented behaviors of a mail platform. Stacked, they turned a correct block into a delivered invoice fraud attempt.

Four things follow. Treat quarantine release as a privileged action for any message whose recorded verdict was a DMARC failure against an enforced policy, not a self-service convenience. Alert on the resubmit headers: a resubmit timestamp on a message with a failing original verdict is high-confidence and trivially matchable. Detect divergence between a spoofed brand in the sender field and an unrelated reply-path domain, since that pairing was the whole attack. And handle the human side in process: any new remittance contact or payment instruction gets verified through a channel already on file, never one supplied in the message.

MITRE ATT&CK Mapping

Indicators of Compromise

The enforcement worked. The release undid it. Wherever a recorded policy failure can be reversed after the fact, a published policy describes an intention rather than an outcome, and the only thing left between the two is whether something in the stack can still read the message for what it is.