Learn · For MSPs
How MSPs manage DMARC across client domains
Setting up DMARC for one domain is a project: publish a record, watch the reports, align the senders, tighten the policy. Doing it for a client book is a different job entirely — thirty domains means thirty sender inventories, thirty policy states, thirty sets of DNS credentials in various states of lost, and a drift surface thirty times wider. This article is about what actually changes at scale, and what's worth systematizing before domain number four.
Why this landed on MSPs at all
For years DMARC was something security-conscious enterprises did. Three things pushed it down-market, straight onto the desks of whoever runs IT for small businesses:
- Mailbox providers made it mandatory. Google and Yahoo have required DMARC from bulk senders since early 2024, and Microsoft applied the same bar to Outlook in 2025. A client whose newsletter suddenly lands in spam has a DMARC problem whether or not they know the acronym.
- Insurers and frameworks ask. Cyber-insurance questionnaires and small-business security baselines increasingly include email authentication as a named control. The renewal form arrives at the client; the question arrives at you.
- Invoice fraud got industrialized. Business email compromise routinely starts with a spoofable domain. A client at
p=none— or with no record at all — is lending their letterhead to whoever wants it, and the incident response lands on the MSP either way.
The result: DMARC went from a nice-to-have to a service line. The MSPs treating it that way are getting paid for it; the rest are doing the incident cleanup for free. (How to charge for it is its own article.)
What changes between one domain and thirty
Nothing about the standard changes — alignment, policies and reports work identically. What changes is the operational shape:
| Concern | One domain | A client book |
|---|---|---|
| DNS access | You have it | Spread across registrars, web agencies, and a founder's personal GoDaddy login from 2014 |
| Sender inventory | One list, mostly known | Every client has an ESP, a CRM, a payroll system and a scanner-to-email box you've never heard of |
| Policy state | One dial to remember | Thirty dials at different stages — some at none, some mid-quarantine, some at reject |
| Report volume | A few XML files a day | Hundreds — reading them by hand stops being a chore and starts being fiction |
| Drift | Occasional | Statistically constant — someone, somewhere in the book, changed a record this week |
The DNS-access problem, and the one-touch fix
Ask any MSP what the slowest part of a client DMARC rollout is and the answer is never the standard — it's getting a TXT record changed in DNS you don't control. The client's zone might live with their web agency, who batch changes monthly. Policy tightening under classic TXT records means going through that pipeline at every step: none, quarantine at 25%, quarantine at 100%, reject. Four change requests per client, multiplied by the book.
This is the strongest argument for hosted DMARC in an MSP context: point each client's _dmarc at the monitoring provider with a single CNAME, once, during onboarding — and every subsequent policy change happens in the dashboard, instantly, without touching client DNS again. The four-change-request problem becomes a zero-change-request problem, and the web agency never enters the loop.
Worth knowing: hosted DMARC is often gated behind top-tier plans elsewhere. Canny Pigeons includes it on every plan, free tier included — which also makes it a cheap thing to trial on one friendly client before committing the book.
Sender inventories: every client has a surprise
The first two weeks of aggregate reports on any client domain reliably surface senders nobody mentioned during onboarding: the payroll provider mailing as the client's domain, the CRM's notification engine, the photocopier. Each one needs a decision — align it, migrate it to its own domain, or let enforcement block it — and each unaligned ESP is a future ticket if you tighten the policy before catching it.
At scale, two things keep this tractable. First, sender identification by name rather than raw IP — recognizing "Mailchimp" takes a second; recognizing 198.2.128.15 takes a lookup, per row, per client. Second, threat intelligence on the unknowns: an unrecognized IP that's a flagged VPS in a bulletproof-hosting ASN is a spoofer to block, not a vendor to chase. The distinction is the difference between a five-minute weekly review per client and an afternoon.
Drift is a book-wide constant
On one domain, DNS drift is an occasional event. Across thirty client domains, it's a weekly one somewhere: a client's marketing hire edits SPF for a new tool, a site migration drops the _domainkey records, someone "simplifies" a policy back to p=none. Under enforcement, drift either re-opens spoofing or bounces the client's own invoices — and both versions arrive as an urgent ticket with your name on it.
The operational answer is daily automated re-checks of every domain's DMARC, SPF, MX and DKIM records, with a diff emailed when something actually changed. That turns drift from "discovered during the incident" into "noticed the next morning" — which, across a whole book, is the difference between running a service and running a lottery.
Reporting: the part clients actually see
Most of this work is invisible when it goes well — which is a commercial problem, because clients don't renew line items they never see working. The fix is per-domain reporting: each client domain gets its own dashboard with its senders, its policy state and its history, clean enough to screen-share in a quarterly review or hand the client a read-only login to. "Here's everyone who sent as your domain last month, here's what we blocked" is a renewal conversation that runs itself.
The short version
Manage DMARC across a client book the way you manage patching: one repeatable onboarding playbook, hosted DMARC so you touch client DNS exactly once, automated monitoring and drift alerts across every domain, and per-client reporting so the work is visible. The standard is the same as for one domain — the operation is what you're actually building.