DMARC
The Revenue MSPs Leave on the Table When a Protected Domain Gets Weaponized Elsewhere
November 6, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Most MSPs treat a published DMARC record at p=reject as a finish line. The client's domain stops showing up in spoofing complaints, the quarterly report shows a green checkmark, and the engagement moves on to the next ticket. That checkmark, however, measures only one thing: whether mail claiming to be from the client's domain aligns with SPF or DKIM. It says nothing about whether the sending infrastructure behind that alignment is still under the client's control.
That distinction is where revenue quietly disappears. When a client's authenticated domain, mailbox, or sending platform is compromised and then used to attack a third party, the MSP is left managing a reputational and operational mess that was never scoped, never billed, and often never even detected until a partner, vendor, or law enforcement contact calls to ask why trusted mail from the client's domain just delivered a credential-harvesting link.
Why does a domain with DMARC enforced still get used to attack other organizations?
DMARC was built to stop exact-domain spoofing, not to verify that every account authorized to send on a domain's behalf is still in honest hands. As one vendor explainer puts it plainly, DMARC "stops domain spoofing but cannot stop lookalike domains, compromised legitimate accounts, or social engineering," which is exactly why it remains effective even after the sending account itself has been taken over. A compromised mailbox, a hijacked marketing platform, or a stolen API key for an email service provider will still pass SPF and DKIM, because the authentication machinery is checking the wrong question.
The IETF's own specification for DMARC, RFC 7489, describes the protocol as a mechanism for policy distribution that lets domain owners express handling preferences for messages that fail authentication. It was never designed to validate the integrity of the sender's account, only the alignment between the visible From header and the SPF or DKIM result. Security researchers have documented this gap directly: attackers who gain access to a trusted platform's infrastructure can send mail that "inherit[s] the platform's authenticated infrastructure" and clears every check a receiving gateway relies on.
How attackers turn a trusted client domain into someone else's problem
Once an attacker controls a mailbox, OAuth-connected app, or ESP account tied to a DMARC-enforced domain, they have something far more valuable than a spoofable name. They have a sending identity that security gateways at other organizations have been trained to trust, because gateways treat a SPF/DKIM/DMARC pass as a strong positive signal by default.
From there the abuse pattern is consistent across incidents. The compromised account sends what looks like a routine vendor notification, invoice, or file-share link to the client's partners, customers, or supply chain contacts. Because the mail genuinely originates from legitimate infrastructure, it sails past authentication checks at the recipient's organization, and the burden shifts entirely to behavioral detection, something most inboxes still handle poorly. Federal agencies have warned about exactly this dynamic at nation-state scale: a joint advisory from the FBI, the U.S. Department of State, and the NSA documented how threat actors exploited improperly configured DMARC policies to send spearphishing email that appeared to come from legitimate organizations, a tactic that becomes even more dangerous once the underlying account itself is compromised rather than merely spoofed.
For an MSP, the client's domain reputation is now doing damage at another company, one the MSP has no contract with, no visibility into, and no ability to remediate directly. The MSP's own client becomes the subject of abuse complaints, blocklist entries, and partner distrust, none of which were part of the original managed-security scope.
What does this actually cost the MSP, beyond the obvious cleanup hours?
The direct cost is the incident response time nobody pre-approved: rotating credentials, auditing mail rules, reviewing OAuth grants, and coordinating with the affected third party. The larger cost is structural. It is the retainer that assumed "DMARC deployed" meant "email risk handled," the renewal conversation that now centers on what the MSP missed, and the referral that never happens because a partner organization associates the client's domain with a phishing incident.
Business email compromise remains one of the most expensive categories of cybercrime by dollar loss, and it keeps growing. The FBI's Internet Crime Complaint Center recorded over 21,000 BEC complaints in 2024 alone, with reported losses of $2.77 billion in that single year, part of a decade-long climb that has pushed cumulative BEC losses past $17 billion since 2015. When a client's domain is the vector, even indirectly, the MSP sits uncomfortably close to that liability conversation, whether or not the contract explicitly covers it.
There's also a deliverability cost that compounds quietly. Google's own sender guidelines make clear that bulk senders must authenticate with SPF, DKIM, and DMARC to maintain reliable inbox placement, and a domain flagged for abusive sending patterns, even temporarily, can see legitimate client campaigns throttled or rejected while the mess gets sorted out. That's billable marketing and operations impact landing on the MSP's desk with no corresponding line item.
Where the monitoring gap actually lives
Most MSPs check DMARC policy existence and alignment status once during onboarding and rarely again. The signals that would catch a compromised sender hiding inside an otherwise-compliant domain live in the DMARC aggregate reports themselves, and those reports go unread far more often than they're reviewed.
A handful of patterns in those reports tend to precede the kind of incident described above:
- A sudden increase in passing messages from sending IPs or third-party services the client never provisioned or has since stopped using.
- New DKIM selectors or
d=values appearing in aggregate data that don't match any known marketing platform, CRM, or helpdesk integration. - Authenticated volume spikes from a subdomain that isn't actively managed, a common sign of shadow IT or an abandoned SaaS connector still holding valid credentials.
| Signal in DMARC reports | Likely cause | Why it matters for the MSP |
|---|---|---|
| Unrecognized passing source IP | Compromised mailbox or stolen API key | Mail is authenticated and will reach third parties undetected |
| New DKIM selector, unknown platform | Unauthorized or forgotten SaaS connection | Expands attack surface outside the MSP's visibility |
| Volume spike on dormant subdomain | Abandoned service still holding valid credentials | Classic entry point for infrastructure abuse |
Catching these requires someone, or some system, actually parsing the XML aggregate reports on a recurring basis rather than glancing at a pass/fail dashboard once a quarter. That ongoing review is itself a billable service most MSPs are currently giving away for free by not offering it at all.
Turning the blind spot into a line item
The fix isn't a new protocol. It's operationalizing the one already deployed. MSPs that build continuous DMARC report monitoring, DKIM selector auditing, and sending-source anomaly alerts into their managed offering are selling a service that directly addresses the gap between "authenticated" and "under control." That's a different conversation than the initial DMARC rollout, and it's one clients will pay for once they understand what's actually at stake for their partners and their own reputation.
Getting a client to that baseline starts with the deployment itself. ActiScan's getting-started guide walks through publishing and validating SPF, DKIM, and DMARC records correctly, which is the prerequisite for any meaningful anomaly detection layered on top. From there, ongoing monitoring for unexpected sending sources and DKIM changes becomes a tier an MSP can package and price rather than an afterthought buried in a flat-rate retainer, and ActiScan's pricing page outlines how that monitoring scales across a multi-client book. MSPs evaluating whether their current stack catches these signals can start with a free account through the signup page and run it against a client domain today.
DMARC enforcement is necessary and it works for what it was built to do. But treating it as the end of the email security conversation, rather than the start of an ongoing monitoring relationship, is how MSPs end up absorbing incident costs they never priced in, while leaving a recurring revenue opportunity sitting unclaimed in reports nobody opened.