Hard Reject, Delivered Anyway: The Three-Relay Chain That Bypassed a Bank's DMARC p=reject

The email said there was a new message waiting in the recipient's secure mail account. It came from a sender address at the bank's own domain. It included a "Click here" link to log into the Secure Mail Center, personalized with the recipient's actual email address. A confidentiality disclaimer sat at the bottom. Clean, professional, unremarkable.

Every authentication check failed. SPF failed. DKIM was absent entirely. DMARC returned fail with an oreject action, the hardest rejection signal a domain owner can publish. Microsoft's own anti-spoofing engine flagged it as CAT:SPOOF with a composite authentication failure (compauth=fail reason=000). The message still reached four mailboxes.

Three Hops, Zero Authorization

The Received headers told the story in reverse. The final relay that handed the message to Microsoft Exchange Online Protection was srr2.dnsexit[.]com (IP 89[.]39[.]149[.]107), a commercial SMTP relay service based in Romania. Before that, the message passed through gw2.cammew[.]com (IP 64[.]182[.]209[.]149), a privately operated Postfix gateway with no association to any recognized email security vendor. The originating hop was an AWS EC2 instance: ec2-18-224-225-58.us-east-2.compute.amazonaws.com (IP 18[.]224[.]225[.]58).

None of these hosts are authorized senders for the impersonated bank's domain. The bank runs its own nameservers (ns1, ns2, ns3 on its own TLD), has been registered since 2018, and maintains SPF records that explicitly do not include any of these three IPs. The attacker built a relay chain from disposable cloud compute, through a private gateway, into a commercial relay, knowing the message would fail authentication at every checkpoint.

According to the Microsoft Digital Defense Report 2024, spoofing and impersonation remain among the top techniques in credential-harvesting campaigns, with financial services as the most frequently targeted vertical. This case follows that pattern precisely.

Why oreject Did Not Stop Delivery

DMARC p=reject is supposed to be the nuclear option. When a domain publishes this policy, it instructs every receiving server to refuse messages that fail alignment. The oreject designation in Microsoft environments carries the same intent. The Authentication-Results header in this message explicitly stated: dmarc=fail action=oreject header.from=.

Yet the message reached four mailboxes before IRONSCALES quarantined all four copies. Microsoft's Forefront anti-spam report assigned SCL:5 (spam confidence level above threshold) and SFV:SPM (spam filtering verdict), but the message was not rejected at the transport layer. It was accepted, processed, and delivered to junk.

This is the gap between policy and enforcement. DMARC is an advisory protocol. The domain owner publishes a preference, but the receiving infrastructure decides whether to honor it. In complex M365 environments with transport rules, third-party filtering, and layered mail flow configurations, strict rejection can be downgraded to quarantine or junk folder delivery. The message is not "blocked." It lands. And if a user checks junk, or if a mail rule moves it, the credential-harvesting link is one click away.

The Verizon 2024 DBIR found that credentials were involved in over 50% of breaches, with phishing as the primary acquisition vector. A credential page that survives DMARC rejection and lands in a mailbox is a live threat, regardless of which folder holds it.

The Credential Harvest: Mimicking Legitimate Portal Architecture

The harvesting links pointed to hxxps://114915272[.]securebanksolutions[.]com/mail/?brand=114915272&group=114915272. The numeric subdomain pattern is significant. Legitimate secure email portal providers use per-tenant numeric subdomains to route recipients to the correct institution's branded portal. The attacker replicated this pattern exactly, making the URL structure familiar to anyone who has used a real bank secure mail system.

The email body reinforced the illusion. It presented the recipient's actual bank email address as their "Username" and listed the full URL as the "Web Address" to log in manually. This personalization maps to MITRE ATT&CK T1598.003 (Phishing for Information: Spearphishing Link), where the attacker tailors the lure with victim-specific details to increase click probability.

Automated URL scanners returned clean verdicts on every link in the message. The domain securebanksolutions[.]com was not on major blocklists at the time of delivery. This is consistent with IRONSCALES research across 1,921 organizations showing that SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month, with credential-harvesting pages on clean or newly provisioned domains accounting for a significant share of those misses.

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

The Silent Co-option of a UCaaS Provider

One detail that most automated analysis would overlook: the Message-ID header. This message carried the identifier <114915272.1758828603.199659653@revation[.]com>. Revation Systems is a legitimate UCaaS company that provides secure communications platforms (including encrypted email) to financial services and healthcare organizations. The attacker either used Revation's infrastructure at some point in the message composition, forged the Message-ID header directly, or leveraged a system that stamps Revation's domain automatically.

The practical consequence is that Revation's domain now appears in the header artifacts of a phishing campaign. Threat intelligence feeds that index Message-ID domains will associate revation[.]com with this attack. Abuse reports filed by the targeted organization could reference Revation. The company's identity has been silently co-opted without any indication they were involved.

This is a supply chain artifact that most detection systems ignore entirely. The Message-ID domain is not evaluated by SPF, DKIM, or DMARC. It exists in a header field that serves no authentication function, making it a cost-free impersonation vector for attackers.

The Relay Chain Trail

The Authentication Stack Has a Delivery Problem

This attack did not exploit a vulnerability. It exploited the distance between authentication verdict and enforcement action. SPF failed. DKIM was absent. DMARC instructed rejection. The composite authentication score returned failure. Microsoft's own anti-spoofing classifier identified the message as CAT:SPOOF. Every signal pointed to a forged message.

The message delivered anyway, to four mailboxes, because mail flow architecture can override authentication verdicts. CISA's email authentication guidance emphasizes that publishing DMARC p=reject is necessary but not sufficient: receiving organizations must also configure their mail infrastructure to honor those policies without exception. Across the IRONSCALES community of over 35,000 security professionals, this pattern repeats: domain owners invest in publishing strict authentication policies, but the receiving infrastructure's enforcement varies based on configuration complexity, legacy rules, and vendor-specific implementation decisions.

The FBI IC3 2024 report documented $12.5 billion in reported losses from internet crime, with phishing and spoofing among the top complaint categories. Attacks like this one, where every authentication check fires correctly but delivery still occurs, represent the gap between protocol design and operational reality.

DMARC tells the world what should happen. It cannot guarantee that it will.