Between August 3 and 5, 2026, Microsoft Threat Intelligence tracked more than a million emails hitting enterprise inboxes across the United States, each one built around the same pitch: a ServiceNow annual subscription invoice, an urgent ask from the company’s own CEO, and a nearly $50,000 ACH transfer waiting to be approved. The domains behind roughly 87.7 percent of that volume were sending from the United States. None of it needed a spoofed domain to get there. It went out through real companies’ real email infrastructure, authenticating exactly as it should.
A Convincing Package, Not a Broken Header
The email itself did the work a header trick usually has to do elsewhere. Threat actors impersonated each target company’s CEO, CFO, or president in the sender display name, the reply-to display name, and the signature block, then asked accounts payable staff to process the ACH payment described in an attached invoice. That invoice was not a generic template. It carried ServiceNow’s branding, a specific invoice number, a billing date, and a “BILLED TO” section addressed to the actual target company. Beneath it sat a fabricated forwarded email thread, built to look like the impersonated CEO and a ServiceNow representative had already discussed the purchase, so the accounts payable recipient was walking into a conversation that appeared to already have consensus behind it. Microsoft found no evidence ServiceNow itself, or any of the other brands named in the lures, was compromised or involved.
Real Accounts, Real Domains, Real Authentication
The infrastructure choice is what makes this campaign worth a second look. Rather than standing up lookalike domains to send from, the operators routed the million-plus messages through multiple accounts at a legitimate bulk email delivery service, with sending addresses tied to real, unrelated businesses: [email protected], [email protected], [email protected], among others. Mail sent through those accounts authenticates against those domains’ own SPF and DKIM records, exactly as it would for any of that platform’s legitimate customers, because it is, mechanically, exactly that. Two supporting domains, service-nowinc[.]com and domainlify[.]net, both registered July 31, existed only to receive replies if a victim wrote back, not to carry the message’s authenticated identity. DMARC alignment checks the domain in the visible From header against the domain that actually sent the mail. Here those two facts matched. The deception lived entirely in the display name sitting next to an accurate, aligned address, a field DMARC was never built to evaluate.
The AI Fingerprints, and Why They Do Not Matter to DMARC
Microsoft’s researchers flagged several signals consistent with generative AI having a hand in building the templates: verbose HTML comments labeling each section of the invoice and thread, unusually uniform formatting across the sample set, heavy use of banner-style separators, and consistent em-dash usage throughout the copy. Researchers were careful to note that these indicators establish AI involvement in template construction, not how much of any individual email’s content a model actually drafted. Either way, the technique sits one layer above authentication. Whether a human or a model wrote the fake ServiceNow invoice, the message still needed a domain to send from, and it used one that was entirely entitled to send it.
Why DMARC Was Never the Layer Watching for This
This campaign is not a new species of authentication bypass so much as a reminder of what DMARC was scoped to check in the first place: does the domain in the From header match a domain authorized to send that mail. It says nothing about whether the display name sitting beside that address matches a company’s actual CEO, whether an attached invoice is genuine, or whether a forwarded thread underneath it ever happened. A bulk sending platform with thousands of legitimate customer accounts is, by design, going to pass SPF and DKIM for every one of them, honest and hijacked alike. That is a different failure mode than the compromised marketing-platform breach that let one attacker reach 138 client accounts and forge notices through several fintech brands at once, or the self-spoofed header trick that made phishing mail look like it came from the recipient’s own address. Here, no compromise of the sending accounts appears necessary at all: an attacker only needs an account, a plausible sender name, and a document convincing enough to survive a rushed read in accounts payable.
What This Means for Your Program
Give accounts payable a verification step that does not depend on the inbox. Any ACH or wire request tied to a new vendor relationship, or a sudden change to an existing one, should require a callback to a phone number pulled from an internal system, not one found in the email itself. DMARC passing is not evidence the request is real.
Watch for display-name mismatches, not just domain mismatches. A rule flagging when a sender’s display name matches an executive’s name but the authenticated domain does not match any domain your finance team has transacted with before catches exactly this pattern, even when SPF and DKIM are clean.
Treat a forwarded thread inside an email as unverified until proven otherwise. A screenshot or quoted conversation embedded in a message is text, not evidence. It carries no authentication of its own and should never be the thing that moves a payment request from suspicious to approved.
Remember that DMARC’s job ends at the domain, not the deal. A domain can hold a strict DMARC policy and never see a spoofed message reach an inbox, while a completely different, fully authenticated domain sends the invoice fraud that empties a bank account. Both outcomes are consistent with DMARC doing exactly what it was built to do.
The Takeaway
A million emails reached enterprise inboxes over three days without a single one needing to fail SPF, DKIM, or DMARC to get there. The operators picked infrastructure that authenticates cleanly by default and built a document convincing enough that the authentication check was never the thing standing in their way. DMARC verified the domain on every message correctly. It was never asked, and was never built, to verify the invoice.
DMARC confirms a domain is authorized to send. It has no way to tell you whether that domain belongs to a bulk sender whose other customers are being impersonated to defraud your finance team. Excello Mail gives you continuous, plain-language visibility into your real authentication posture, so you know exactly where DMARC’s coverage ends and the rest of your defense needs to begin. Sign up for free to Excello Mail and see your actual authentication picture today.