This Bank Phish Failed DMARC, Then Passed It

The same phishing email failed SPF and DMARC at the perimeter and passed both one hop later. Nothing about the message changed. Only the IP that handed it off did.

That is the core trick in a "mailbox storage full" campaign we pulled from IRONSCALES platform data, aimed at several employee mailboxes inside a regional bank. The attacker spoofed the bank's own IT-notification address, and by the time the message reached Microsoft 365 it carried a clean Authentication-Results line. Anyone reading only that final verdict would have concluded the message came legitimately from the bank. It did not.

A quota warning from the bank's own "IT Notification"

The lure was mundane, which is exactly why it works. The subject read "MaiIbox Storage Quota Limit Exceeded," a homoglyph trick that swaps a capital I for the lowercase l in "Mailbox." A human reads it normally. A literal keyword filter looking for the correctly spelled word never trips. This is textbook Masquerading (MITRE ATT&CK T1036).

The From header displayed "IT Notification" over a support address at the bank's own domain, and the message went to multiple internal recipients at once. This is an own-domain spoof, not a third-party lookalike, which is a distinct impersonation technique (T1656). Employees are trained to trust internal IT notices, and internal mail often inherits routing and allow-listing that external senders never get. That trust is the whole point of picking the target's own domain.

How the gateway relay laundered the authentication result

Here is the part worth slowing down on.

The bank routes inbound mail through a perimeter secure email gateway (SEG), in this case Mimecast, before it lands in Microsoft 365. At the first hop, the gateway evaluated the message against the IP it actually arrived from. That IP was not authorized to send for the bank's domain, DKIM was absent, and the result was an outright SPF failure and a DMARC failure. By the letter of the policy, this message should have been dead on arrival.

Then the gateway relayed it inward. At the second hop, Microsoft 365 evaluated authentication against the IP that handed the message off, which was now the gateway itself. Because the bank publishes its gateway as an authorized sender for its own domain, SPF passed and DMARC aligned. The message body, the spoofed From, and the malicious intent were identical at both hops. Only the evaluated IP changed, and with it, the verdict flipped from fail to pass.

This is reputation-based authentication laundering. The final DMARC result reflects the trusted relay's reputation, not the original message's legitimacy. Authentication is a per-hop measurement, and reading only the last line throws away the exact signal that exposes the attack.

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

The origin hidden behind a working reverse-DNS record

The originating host looked plausible on a quick glance. Its PTR record resolved to off-ntbackup.moonjaws[.]com, a clean-looking reverse-DNS entry that suggests a real backup or infrastructure host. But the parent domain, moonjaws[.]com, is NXDOMAIN. There is no forward record behind it. The attacker configured a working reverse-DNS entry to dress up an IP whose actual domain does not resolve at all, a small piece of theater aimed at anyone who eyeballs the Received chain and stops at the PTR.

The fake verified banner and the "Clear Storage" trap

The body did the psychological work. It rendered a green "This sender has been verified" banner, built as ordinary HTML inside the message, plus a storage progress bar pushed near the limit and a prominent "Clear Storage" call to action. None of that is a real trust signal. It is a picture of one, drawn to imitate the safety cues users have learned to look for.

The CTA links were rewritten by the gateway's own URL protection, which paradoxically made them look safer. Underneath the rewrite, the destination matched a known mailbox-quota credential-phishing kit designed to capture Microsoft credentials. Clicking is User Execution of a malicious link (T1204.001), the final step in a Spearphishing Link delivery (T1566.002). The kit domain has since gone NXDOMAIN, typical of throwaway credential-harvesting infrastructure that lives for a single campaign.

Indicators of Compromise

Where reputation stops and behavior starts

Signature-based controls had every reason to wave this through. The final auth line was clean, the CTA was a rewritten and reputation-scored link, and the sender matched an internal domain. Themis, our Adaptive AI, is not scoring the last-hop verdict. It reads the full hop-by-hop story: a first-hop SPF and DMARC failure that only resolved after a relay, an origin whose forward domain does not exist, a homoglyph subject, and an in-body banner mimicking a trust cue that no mail client actually produces. Any one of those is a soft signal. Stacked, they describe an attack.

This is the gap that gateways structurally leave open. IRONSCALES platform data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes each month, and the messages that get through are increasingly ones that pass authentication cleanly. Phishing was present in 15% of breaches in the 2024 Verizon Data Breach Investigations Report, and stolen credentials were involved in 38%, the top initial action. The Microsoft Digital Defense Report 2024 documents the same shift toward identity-first attacks that exploit trusted infrastructure rather than obvious malware.

Financial institutions are a favorite target precisely because their mail is so tightly governed. When the controls are strict, attackers stop trying to break them and start borrowing them. The 35,000+ security professionals across 17,000+ organizations who use IRONSCALES see this pattern constantly: legitimate rails, illegitimate cargo.

Reconstruct the whole chain, not the last line

The defensive takeaway is narrow and durable. Never trust a single, final Authentication-Results line. Reconstruct the full ARC and Received chain and compare the first hop to the last. A message that fails SPF or DMARC at the perimeter and only passes after a security gateway relays it is not legitimate. It is laundered. Treat any material auth-result delta between the first and last hop as its own risk signal, and pair it with content behavior rather than reputation alone. As CISA notes in its guidance on stopping the phishing attack cycle, and as NIST frames phishing at its root, the goal is always to borrow trust you have not earned. Here the attacker borrowed it twice: once from the bank's own domain, and once from the gateway meant to protect it.