DMARC Said Reject. The Invoice Arrived Anyway.

The invoice was real. That is the part worth sitting with.

A national insurance and employee-benefits brokerage services firm received a $500.00 invoice that Stripe itself had generated, from a genuine Stripe transactional sending address. It carried nine links, every one wrapped by the recipient's gateway, every one returning a clean verdict. Several have screenshots on file showing exactly what you would expect: a normally rendering Stripe invoice page.

The attack was in the memo line. It read as an auto-debit notice for a Norton antivirus subscription renewal, and offered a phone number to call in order to cancel or modify the charge. That phone number is the payload. Everything around it is real infrastructure.

It landed in the inbox of the firm's chief executive, after the receiving platform had already recorded that the message failed DMARC against a policy of p=reject.

A Fraudulent Merchant Account on a Real Platform

There is no attacker-built invoice template here, no cloned billing portal, no lookalike domain in the sender. The attacker registered a Stripe merchant account under a garbled business name and used the platform's ordinary invoicing feature to bill a stranger. The sending address is a legitimate Stripe transactional one, with the fraudulent merchant's account identifier embedded in it.

That inverts the usual detection model. A gateway looking for the fake finds nothing fake. The brand is not impersonated in the sender, because the brand is genuinely sending, and the destinations are the real billing pages for a real, payable invoice. The only fabricated element is a claim about what the charge is for, and claims are not something a URL scanner scores.

The second diversion is the Reply-To, pointing at rexogo3744@moondyal[.]com, a privacy-shielded domain registered more than two years before the attack. That aging matters, because the reflex heuristic here is domain age and this domain clears it. Any written reply leaves the Stripe channel and lands with the attacker.

Where Two Valid Signatures Broke

At origin, the message authenticated perfectly. The earliest recorded hop, logged before any relay touched it, shows it arriving straight from Amazon SES with SPF passing on bounce[.]stripe[.]com, DKIM passing for header.d=stripe.com, DKIM passing again for header.d=amazonses.com, and DMARC passing under p=reject; sp=reject; pct=100. Two valid signatures: one from the platform that generated the invoice, one from the service that transmitted it.

By the time the message reached the recipient's edge, both were broken. The delivered authentication results read dkim=fail (body hash did not verify) header.d=stripe.com and dkim=fail (body hash did not verify) header.d=amazonses.com.

Read that failure mode carefully. Not a missing key. Not an expired selector. Not a syntax error. The body hash did not verify. The bytes changed between signing and delivery.

They changed because the message did not travel from Amazon SES to the brokerage directly. It passed through an intermediary domain, billb[.]shop, which owned every routing header by the end: an SRS-rewritten Return-Path on that domain, four sequential addressees on it (LINDA_Pc41@billb[.]shop through LINDA_Pc44@billb[.]shop), and a Microsoft 365 outbound IP that was SPF-authorized for it.

So the final SPF result is a pass, on the wrong domain. spf=pass smtp.mailfrom=billb[.]shop, on a message whose visible sender is stripe.com. A dashboard that reads "SPF: pass" and stops there sees a healthy message.

How the mail got from those relay-domain addressees into an executive's mailbox is not something the record explains, and guessing at a mechanism would be inventing evidence. What is documented is that a routing hop sat in the middle, and whatever it did was enough to invalidate a hash.

A Reject Policy Only Helps If the Receiver Enforces It

With both signatures broken and SPF aligned to the relay instead of the sender, DMARC had nothing left to pass on. The delivered result is dmarc=fail action=oreject header.from=stripe.com, with composite authentication returning compauth=none reason=460.

Stripe publishes a hard reject policy. The receiving platform evaluated the message against it, failed it, and logged the rejection action.

Then the message went to the inbox.

That gap is the whole lesson, and it is uncomfortable for anyone who has presented a DMARC rollout as a finished control. A policy is a request, and RFC 7489 describes what a domain owner can ask a receiver to do. It cannot compel any receiver to do it. Allow lists, connector rules, relay exemptions, and routing overrides all sit above the policy decision. When a receiver logs oreject and delivers anyway, the policy worked as designed and the enforcement layer did not.

The Pretext Was Boring on Purpose

The lure asks for nothing unusual. A $500 antivirus renewal is small enough to be plausible and large enough to be worth a phone call. The invoice carried a due date roughly a month out, which is how genuine subscription billing reads, and the subject line was the platform's own template. The sender was a first-time correspondent for the organization.

No verdict engine was going to resolve the authentication contradictions here, because the verdicts disagreed with each other. That is where behavioral analysis earns its keep. Themis, the IRONSCALES Adaptive AI SOC analyst, weighs the shape of a message rather than a single stamp: a first-time sender, a Reply-To on one unrelated domain, a Return-Path on another, authentication that degraded in transit, and a phone number standing in as the only real call to action. The incident resolved as phishing, though not before the message had reached the mailbox.

Attack Chain and MITRE Mapping

• Spearphishing attachment (T1566.001): A clean, scannable PDF invoice rode along as the document artifact. See MITRE ATT&CK T1566.001.
• Spearphishing link (T1566.002): Nine genuine Stripe payment and invoice links carried the credibility. See MITRE ATT&CK T1566.002.
• Impersonation (T1656): A brand-name antivirus renewal pretext layered onto a genuine payment platform's template. See MITRE ATT&CK T1656.
• Defense evasion: Transit modification at a relay domain broke both DKIM body hashes and realigned SPF to the relay, converting a hard DMARC failure into a delivered message.

Invoice and payment pretexts remain the expensive end of email crime. The 2024 Verizon Data Breach Investigations Report puts pretexting, mostly business email compromise, as the leading social-engineering type, with a median transaction around $50,000, and the 2023 FBI IC3 Internet Crime Report counted roughly $2.9 billion in reported business email compromise losses.

Closing the Relay Gap

• Compare authentication across hops, not just at the end. A message that passed DKIM at origin and fails the body hash at delivery is describing its own tampering. Almost nobody is looking at that delta.
• Ask which domain SPF passed for. A pass on a relay unrelated to the visible sender is a mismatch dressed as a success.
• Treat enforcement as a configuration audit, not a DNS record. Publishing a policy and honoring an inbound one are different projects. Review the overrides, connectors, and allow lists that can outrank a policy check, which is the layered inspection gap SEG augmentation exists to cover.
• Score behavior when verdicts conflict. CISA's phishing guidance makes the same case for defense in depth: no single check should be load-bearing.

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

Indicators of Compromise

One More Thing

Somewhere in a delivery path you probably cannot fully draw, a rule you inherited is quietly outranking a policy someone published. Worth asking what happens on your side of the wire when a message fails DMARC. If the answer is "we log it," that is not enforcement, it is bookkeeping.