DMARC

The Phishing Template Loophole: Why DMARC-Enforcing Clients Still Get Breached

October 21, 2026

Ric Hall, CRO— AI-assisted and reviewed prior to publication.

A controller at a 40-person logistics firm gets an email from the CFO's real name, a familiar signature block, and a domain that looks exactly right at a glance. The client's domain sits at p=reject. Every authentication header on the inbound message reads "pass." The wire transfer still goes out, because the message never claimed to come from the client's domain at all. It came from a domain the attacker registered three days earlier, one character off, with its own clean SPF and DKIM records built specifically to pass.

This is the scenario MSPs need to be able to explain before a client asks why their expensive email security "failed." The short answer: DMARC enforcement protects only the exact domain string in the From header. It does nothing to stop a registered, authenticated lookalike domain, and attackers now harvest real internal email addresses to make those lookalikes nearly indistinguishable from the real thing.

Why Does a DMARC Pass Still Let Phishing Through?

DMARC was never built to catch this. The protocol checks whether the domain in the visible From address aligns with a domain that passed SPF or DKIM, and that's the entire job. The IETF's own specification for the protocol lists its boundaries explicitly, stating that evaluation of anything other than the RFC5322.From domain is specifically out of scope for the standard.

That means an attacker who registers cl1ent-domain.com or clientdomain-inc.com, points its own MX records at infrastructure they control, and publishes their own SPF and DKIM for that domain will pass DMARC every time, because DMARC is only checking the lookalike domain against itself. The client's enforcement policy is irrelevant. The mail was never forged to look like it came from their real domain in the first place. It only looks that way to the human reading it.

How Harvested Addresses Turn a Generic Template Into a Targeted Lure

The reason this loophole has gotten sharper over the past few years is not the domain registration trick itself, which is old. It is the quality of the target list feeding it. Attackers now routinely scrape real internal addresses before they ever send a message, using open-source tools that pull names and formats from search engines, breach dumps, and company websites.

Security researchers documenting phishing reconnaissance note that email addresses are frequently harvested from LinkedIn, company websites, data breach dumps, and prior campaigns, with automation tools enumerating entire address books against a single target domain before a campaign ever launches. That harvested list does two things for the attacker. It tells them the organization's email naming convention, so the lookalike domain's addresses follow the same pattern as the real one. It also tells them exactly who to target, meaning the controller, the AP clerk, or the office manager who actually approves payments.

A few years ago, a lookalike phishing email was a generic template sent in bulk, riddled with tells. Today the same template arrives addressed correctly, references a real coworker by name, mimics the real signature format, and lands from a domain that is one keystroke away from correct. None of that content is something DMARC inspects, because the specification was deliberately scoped to domain alignment and nothing else.

Exact-Domain Spoofing vs. Lookalike Domain Abuse

The confusion MSPs run into most often is clients assuming DMARC enforcement is a general phishing shield. It is worth laying the two scenarios side by side, because the fix for one does nothing for the other.

CISA's own phishing guidance for defenders reflects this same split, recommending that organizations implement internal mail and messaging monitoring specifically because users can be phished without the security team ever seeing a failed authentication check. That guidance exists because the agency's earlier directive on email hardening, which told federal agencies to move to enforced DMARC, was never framed as a complete phishing solution. The accompanying CISA Insights brief on email and web security was explicit that attackers may spoof a domain to send a phishing email that looks like a legitimate email, framing DMARC as one control among several, not the perimeter.

What Should an MSP Actually Be Monitoring For?

The honest answer is that DMARC enforcement and lookalike domain monitoring are two separate disciplines that happen to share the word "DMARC" in casual conversation. A client at p=reject has solved exact-domain spoofing. They have not touched the much larger surface of domains that merely resemble theirs.

Closing that gap takes three things working together, and none of them are optional if an MSP wants to credibly claim the client is covered against this class of fraud.

• Aggregate and forensic report review to confirm the client's own domain enforcement is actually working as configured, not just set and forgotten.
• Lookalike domain and newly-registered-domain monitoring, since mail providers themselves now build detection around exactly this pattern. Google Workspace's advanced protection settings include a control specifically built to protect against incoming messages from domains that appear visually similar to your company's domains or domain aliases, which is an admission by the platform itself that domain similarity is a distinct detection problem from authentication.
• Internal address exposure awareness, so the client understands which of their own addresses are already circulating in harvested lists and how that shapes what a convincing lure will look like next.

This is also where an MSP's recurring scan cadence earns its keep. A one-time DMARC check at onboarding tells a client almost nothing about a domain registered against them last month. Continuous visibility is the only version of this that holds up, and it's the reason ActiScan's scanning runs on a schedule rather than a snapshot, something new technicians can be up and running on inside the getting-started guide in under an hour.

Turning the Gap Into a Service Conversation

For MSPs selling email security, this gap is not a liability to downplay, it is the clearest upsell argument available. A client who believes DMARC enforcement equals phishing protection is a client one convincing lookalike email away from a wire fraud loss and an uncomfortable call asking why the MSP didn't catch it. Framing domain monitoring as the natural next step after DMARC enforcement, rather than a separate upsell pitch months later, keeps that conversation proactive instead of defensive.

The financial stakes make the pitch easier than it used to be. The FBI's Internet Crime Complaint Center reported that business email compromise losses in the United States reached $3,046,598,558 in 2025, a category that overwhelmingly involves exactly this pattern of lookalike or compromised-account mail rather than crude domain forgery. That figure is not abstract risk language for a sales deck. It is the dollar amount a client's controller is one convincing email away from wiring out, and it is the number that justifies a monitoring line item on an invoice a client has already agreed covers "email security."

Positioning this correctly on a service menu means separating DMARC enforcement, which is largely a project with an end state, from lookalike domain monitoring, which is a subscription because the threat never stops regenerating. ActiScan's tiering on the pricing page reflects that split deliberately, so MSPs aren't stuck explaining why a client's "fully configured" DMARC record didn't stop a fraud attempt that was never DMARC's job to stop. A client who understands the distinction up front is far less likely to view a monitoring add-on as padding, and far more likely to view it as the piece that was missing the whole time. For MSPs who haven't formalized this as a distinct line item yet, setting up a scan profile through the signup page is the fastest way to see what's already circulating against a client's brand before a prospect's controller finds out the hard way.

None of this guarantees a client will never lose money to a convincing enough lure, and no vendor can promise that outcome honestly. What it does is close the specific, well-documented gap between what DMARC enforcement actually covers and what clients assume it covers, which is usually the gap that gets exploited first.