DMARC
The DMARC Blind Spot: Why Blocking Outbound Spoofing Isn't the Whole Job
October 5, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.
An MSP spends three months moving a client's domain from p=none to p=quarantine to p=reject. The aggregate reports finally come back clean, the sending sources are all accounted for, and the project gets marked complete in the ticketing system. Then a vendor calls the client's accounts payable team asking why an invoice "sent last week" from the CFO's own address was never paid, except the CFO never sent it, and the domain in question was the client's own, sitting at full DMARC enforcement the entire time.
That scenario is not a configuration failure. It is the predictable result of treating DMARC enforcement as a finish line instead of one half of a two-sided problem.
The core issue is this: DMARC enforcement only governs what happens when someone else's mail server receives a message claiming to be from your client's domain. It does nothing to help your client's own inbox detect when a competitor, fraud ring, or impersonator targets their customers, vendors, or staff using a lookalike domain, a compromised account, or a display-name trick that never triggers a DMARC failure at all.
What Does a DMARC Reject Policy Actually Stop?
A p=reject policy tells participating receiving mail servers to drop messages that fail SPF and DKIM alignment checks against the visible From domain. The DMARC specification in RFC 7489 defines this as a feedback and conformance mechanism built on top of existing authentication results, not a standalone content filter. When it works, it is effective at one specific job: preventing an attacker from forging the exact domain in question and having that forgery delivered at a cooperating receiver.
That is a meaningful win. The Cybersecurity and Infrastructure Security Agency's Binding Operational Directive 18-01 required federal agencies to reach p=reject specifically because, as the directive states, DMARC reporting gives an organization visibility into forgery attempts it would not otherwise receive. But the directive's scope, like the protocol's, stops at outbound authentication of the exact domain string. It says nothing about what the agency's own staff see when someone else's forged mail, or a lookalike domain, lands in their inbox.
Why Can a Competitor Still Impersonate a Client's Domain?
A competitor or threat actor can still impersonate a client's brand because DMARC alignment checks a narrow technical condition, not the full universe of impersonation techniques. Registering a one-character variant domain, using a display name that matches the real brand while sending from an unrelated address, or taking over a legitimate but poorly secured mailbox all bypass DMARC entirely, because none of them involve forging the protected domain's own authentication path.
Microsoft's own Defender for Office 365 documentation draws this distinction explicitly. Composite authentication checks SPF, DKIM, and DMARC together, but impersonation protection, mailbox intelligence, and user and domain impersonation safeguards are separate advanced features that are not enabled in the default policy for every tenant. A client can sit at DMARC p=reject and still have display-name impersonation and lookalike-domain detection switched off, because those two things live in entirely different parts of the mail security stack.
This is precisely the gap that shows up when a competitor registers a near-identical domain to poach a deal in progress, or a threat actor spoofs a client's brand to phish that client's own customers. The client's outbound DMARC record is irrelevant to either scenario. Nobody is forging the client's authenticated domain. They are borrowing its reputation from outside the perimeter DMARC was built to guard.
The Visibility Most MSPs Never Built
Most MSPs that implement DMARC stop at getting the policy to reject and walk away from the reporting pipeline that comes with it. That is a missed opportunity, because the aggregate reports generated under RFC 7489 are also where early signs of brand impersonation and domain abuse first surface, long before a client's finance team gets a fraudulent invoice.
The scale of the underlying exposure is not small. The FBI's Internet Crime Complaint Center recorded business email compromise losses of $2.77 billion across 21,442 incidents in 2024 alone, and BEC has remained the second-costliest cybercrime category it tracks for several years running. Most of those incidents do not involve a technical breach of the victim's own domain authentication. They involve convincing impersonation that a DMARC record was never designed to catch.
At the same time, industry adoption data suggests most domains have not even closed the outbound half of this problem. An analysis of 73.3 million domains found that as of December 2025, only 14.9% had published any DMARC policy and just 2.5% had reached the strict p=reject enforcement level, leaving the overwhelming majority with no visible record at all. For the MSPs whose clients have already crossed that line, the opportunity is to stop treating enforcement as the end state and start treating it as the entry point to a second, inbound-facing conversation.
What Inbound Protection Actually Requires
Closing the inbound gap means adding a distinct set of controls that work alongside, not instead of, outbound DMARC enforcement. The two jobs use different mechanisms, run on different schedules, and answer different questions for the client.
| Control | What it protects | What it cannot do |
|---|---|---|
| Outbound DMARC (p=reject) | Stops forged use of the exact client domain at cooperating receivers | Has no visibility into lookalike domains or impersonation of the brand elsewhere |
| Inbound impersonation protection | Flags display-name spoofing, newly registered lookalike domains, and unusual sender behavior aimed at the client's own mailboxes | Does not enforce anything on domains the client does not own |
| DMARC aggregate report monitoring | Surfaces unknown senders and authentication failures tied to the client's domain | Only shows activity that already touches the client's own DNS record |
Standing up the middle row is where most MSP engagements currently fall short. Microsoft's guidance is specific that spoof intelligence and basic anti-spoofing ship by default for cloud mailboxes, but the stronger controls that catch domain and user impersonation require a deliberate policy configuration decision, since the default anti-phishing policy does not turn on every available protection. Left untouched, a client can be fully DMARC-compliant outbound and still be running with impersonation protection effectively off.
Practical steps for an MSP closing this gap typically include:
- Auditing which inbound impersonation and mailbox intelligence features are actually enabled per client tenant, not assumed enabled because DMARC is at reject.
- Reviewing DMARC aggregate reports on a recurring cadence to catch unknown senders using the client's domain before they escalate into fraud attempts.
- Setting up lookalike-domain monitoring so a near-identical registration aimed at a client's brand is flagged while it is still new, not after a customer has already wired funds to it.
Turning the Gap Into a Service Line
For the growth side of an MSP's book of business, this gap is not a liability to apologize for. It is a second, clearly scoped service that most clients have never been pitched, because most vendors and most MSPs stop talking about email security the moment the DMARC project closes. Framing inbound impersonation monitoring as a distinct, recurring engagement, separate from the initial authentication rollout, gives an MSP a natural reason to re-open a conversation with every client it has already brought to enforcement.
The pitch does not require inventing new risk. It requires pointing at the same DMARC reports already flowing in and showing the client what they have never been shown: who else is trying to use their name, and what happens in their own inbox when somebody else's name shows up. ActiScan's monitoring is built around exactly that second half of the picture, and teams that are new to scanning for both sides of domain risk can move through the getting-started guide in a single sitting before extending it to a full client roster. Packaging that as a standing line item rather than a one-time project is covered in more detail on the pricing page, and MSPs who want to see what the inbound side of the dashboard actually surfaces before pitching it can create an account and run it against a live domain the same day.
None of this replaces a client's own security team or guarantees a particular compliance outcome. What it does is close the half of the spoofing problem that enforcement alone was never designed to touch, and give MSPs a second, defensible reason to bill for email security instead of treating the DMARC project as a one-time line item that quietly ages off the invoice.