Why DMARC-Passing Emails Can Still Be Phishing

A DMARC pass confirms that a message's sending domain matches its authentication records. It does not confirm the message is safe. When attackers send from a real, compromised mailbox, every authentication check passes correctly because the account genuinely belongs to a trusted sender.

Key takeaways

What does DMARC actually check?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) checks whether an incoming message's "From" domain aligns with the domain that passed SPF or DKIM validation. It was built to stop domain spoofing, where an attacker fakes a company's domain in the sender field without controlling any part of its infrastructure.

AegisAI's technical guide on SPF, DKIM, and DMARC architecture covers how these three protocols interact and why each one answers a narrow question about infrastructure, not content.

What is trust hijacking?

Trust hijacking describes attacks that originate from a genuinely compromised, authenticated account rather than a spoofed one. The attacker does not need to forge anything. They log into a real mailbox, often through stolen credentials or a session token, and send messages that pass every authentication check because they are, technically, legitimate mail from that domain.

This matters because most inbound filtering still weights sender reputation heavily. A message from an established domain with a clean sending history and a valid DMARC pass looks like the safest possible email. If that account has been hijacked, those same signals make the attack more effective, not less.

Why did compromised-account attacks rise so sharply?

AegisAI's report tracked this shift closely. The sender-compromise rate for AI Dragnet attacks rose from 0.2% to 7.7% in one quarter. The report describes this as "the largest single behavior change this report tracks."

The same data shows these attacks were also harder to catch once an account was taken over:

This pattern lines up with broader industry reporting on credential-based attack methods. Microsoft's Q2 2026 email threat landscape report describes a rise in credential phishing and CAPTCHA-gated campaigns designed to harvest the logins that make account takeover possible in the first place. The FBI's Internet Crime Complaint Center has also published an advisory on the Kali365 phishing kit, which it describes as hijacking Microsoft 365 accounts through impersonation of trusted cloud productivity services, a direct feeder into the kind of compromised-sender attacks AegisAI's report tracks.

Why can't reputation-based filtering catch this?

Traditional filtering logic treats sender reputation as a strong positive signal: known domain, clean history, valid authentication, deliver to inbox. That logic assumes the account itself is trustworthy, which is exactly the assumption trust hijacking exploits.

Once an account is compromised, every reputation signal it carries becomes a liability rather than a safeguard. The sender's history, authentication record, and prior trusted exchanges all work in the attacker's favor.

This is consistent with what AegisAI has documented elsewhere about detection gaps. The analysis in half of AI phishing reaches the inbox shows that authentication-passing status alone is a weak predictor of whether a message is actually safe.

What can catch a compromised account that authentication can't?

Since authentication cannot distinguish a legitimate sender from a hijacked one, detection has to look at what the message is actually doing.

This is the function of AegisAI's Zero-Day Reasoning approach: investigating the content and context a compromised account cannot fake, rather than relying on the authentication status it can pass by default. This approach is particularly relevant to business email compromise, where the entire attack depends on the message looking exactly like it came from someone the recipient already trusts.

How does this fit into account takeover protection?

Trust hijacking and account takeover are two sides of the same problem. The takeover is the initial compromise. The trust hijacking is what the attacker does with the access afterward, sending authenticated phishing from inside a real account.

AegisAI's account takeover protection approach is built around this connection, monitoring for the behavioral signs of compromise and the downstream messages a compromised account sends, rather than treating authentication as the final checkpoint.

Does adding this protection require changing mail routing?

No. AegisAI deploys through an API-based integration into Microsoft 365 or Google Workspace, which means it inspects mail inline without requiring MX record changes or rerouting mail through a new gateway. AegisAI's guide on rolling out DMARC without breaking mail flow covers related considerations for teams managing authentication policy alongside layered detection.

FAQ

See the full data

AegisAI's State of the AI Attack report covers the full set of findings on compromised-account attacks, filter evasion rates, and why authentication alone can no longer carry the weight of a detection strategy. Book a demo to see how Zero-Day Reasoning evaluates mail that authentication alone would pass through.