MSP Guide
DMARC for MSPs
How to monitor, report, and enforce DMARC across client domains without breaking their mail or burning your team's time.
1. Why MSP DMARC Is Different
Single-domain DMARC is straightforward: one domain, one team, one set of senders. You publish a record, monitor reports, fix alignment, enforce. The scope is manageable.
MSP DMARC is a different problem. You're managing dozens or hundreds of domains across different clients, each with their own sending ecosystems, risk tolerances, and levels of technical sophistication. A law firm with two senders and a marketing agency with fifteen SaaS tools need fundamentally different approaches — but your team needs to manage both efficiently.
This requires portfolio-level visibility (how are all my clients doing?), per-client isolation (each client sees only their own data), and a rollout model that doesn't require your team to babysit every domain individually. Manual DMARC management breaks down past about 10-20 domains. Beyond that, you need tooling designed for multi-tenant operations.
2. The MSP DMARC Workflow
Every client domain goes through the same five stages. The discipline is in following the sequence and not skipping steps, even when a client pushes for faster enforcement.
Onboard
Add the client's domains, verify ownership (typically via DNS TXT record), and publish initial DMARC records with p=none and rua= pointing to your monitoring platform. Use the DMARC checker to verify the records are published correctly.
Discover
Collect aggregate reports for 2-4 weeks per domain. Identify every service sending as the client's domain. Classify each sender as authorized (the client knows about it and wants it), unknown (needs investigation), or malicious (someone spoofing the domain). This discovery phase is where you build the sender inventory that drives all future decisions.
Remediate
Fix SPF includes for missing senders, configure DKIM signing for services that support it, and resolve alignment issues. This is where most of the work lives. Each third-party sender has its own DKIM setup process, and some don't support it at all. Document what's configured and what's not — you'll need this when deciding whether to enforce.
Enforce
Move through quarantine to reject using pct= ramp. Monitor for delivery issues at each step. Roll back if needed — it's a DNS change, not a commitment. The goal is reaching p=reject with zero impact on legitimate mail.
Maintain
Ongoing monitoring. New senders appear when clients adopt new tools. Services change their sending infrastructure. DNS records drift when someone edits them without understanding the impact. DMARC is not set-and-forget — it's an ongoing service, which is exactly what makes it a good MSP offering.
3. Common MSP Pitfalls
These are the mistakes we see MSPs make when they start offering DMARC services:
Copying the same SPF record across clients
Each client has different senders. A one-size-fits-all SPF record either includes services the client doesn't use (expanding the attack surface) or misses services they do use (causing delivery failures). Every SPF record should be tailored to the actual sender inventory for that domain.
Enforcing too fast to hit a project deadline
When enforcement causes legitimate mail to be blocked, the client loses trust in the MSP — not in the protocol. The pressure to ship fast is real, but the cost of breaking a client's email is higher than the cost of taking an extra two weeks in the monitoring phase.
Not tracking SPF lookup counts
SPF has a hard limit of 10 DNS lookups. Clients with many SaaS services (each adding an include: to SPF) easily hit this limit, causing a permerror that effectively disables SPF entirely. You need to track lookup counts across your portfolio and use SPF flattening or restructuring when clients approach the limit.
Ignoring subdomains
Clients may have dozens of subdomains — some actively used for email, some for web applications, some abandoned entirely. Abandoned subdomains without DMARC records are prime spoofing targets. Attackers know that most organizations protect their primary domain but forget about old.clientdomain.com. Audit subdomains during onboarding.
Manual reporting that doesn't scale
Exporting CSVs and emailing them to clients works for five domains. It doesn't work for fifty. Clients need self-service access to their own data, or automated branded reports delivered on a schedule. If reporting is a manual process, it becomes the bottleneck that limits how many domains you can manage.
4. What Makes a Tool MSP-Ready
Not every DMARC platform is built for MSP operations. Here's what to evaluate:
Multi-tenant architecture
Client domains must be isolated. Your team sees the full portfolio; each client sees only their own data. This isn't a nice-to-have — it's a requirement for any MSP managing client data. Shared dashboards where clients can see each other's domains are a non-starter.
Branded reporting
Reports should carry your MSP brand, not the tool vendor's. When a client receives a DMARC status report, they should see your company name and logo. This positions you as the expert, not as a reseller of someone else's dashboard.
Portfolio dashboard
A single view across all client domains showing enforcement status, risk level, and pending action items. You need to know at a glance which clients are at p=none, which are enforcing, and which have new issues. Use tools like the domain score checker for quick assessments.
Enforcement simulation
The ability to preview what would happen at quarantine or reject before changing DNS. This prevents client-impacting mistakes and gives you a concrete deliverable to review with the client before each enforcement step.
Per-domain pricing
MSPs manage many domains with small teams. Per-seat pricing penalizes efficiency. Per-domain pricing aligns the cost with the value delivered to each client and makes it straightforward to build your own pricing on top.
PSA/RMM integration
Ticketing and alerting should feed into your existing operational stack — ConnectWise, Autotask, Datto, or whatever you use. DMARC issues that require action should create tickets automatically, not sit in a separate dashboard waiting for someone to notice.
API access
Automate onboarding, reporting, and status checks. If adding a new client domain requires logging into a web UI and clicking through forms, it won't scale. API access lets you integrate DMARC management into your existing client onboarding workflows.
5. Revenue Model Considerations
DMARC monitoring is a recurring service, not a one-time project. This is one of its strengths as an MSP offering: domains need ongoing monitoring, senders change, compliance requirements evolve, and enforcement needs to be maintained.
Common pricing models for MSP DMARC services:
- Per domain per month: Clean, predictable, easy for clients to understand. Typical MSP charges range depending on the level of service — monitoring-only is cheaper, full enforcement management commands a premium.
- Bundled with email security: DMARC as part of a broader email protection package that includes spam filtering, phishing protection, and security awareness training. Higher total value, harder to unbundle.
- Compliance package: DMARC monitoring as part of a compliance offering — particularly relevant for clients subject to PCI DSS, NIST frameworks, or cyber insurance requirements.
The key economics: your underlying platform cost per domain needs to leave room for your margin. If the tool costs most of what you charge, the service isn't sustainable. Look for volume pricing that improves as your portfolio grows, and white-label options that let you own the client relationship completely.
6. Building the DMARC Practice
Start with your highest-risk clients: those with the most email volume, the strongest compliance requirements, or the most to lose from a spoofing attack. Financial services, healthcare, and legal firms are typical starting points.
Use those initial engagements to build your playbooks. Document the onboarding process, the discovery report template, the remediation checklist, and the enforcement decision criteria. Every client is different in their senders, but the workflow is the same.
Once you have a repeatable process, roll it out across the portfolio. The goal is that onboarding a new client domain takes hours, not days. The discovery phase still takes 2-4 weeks (you're waiting for report data), but the setup work to get there should be fast and templated.
Selling tip: The discovery report is your best sales tool for enforcement projects. Run a client at p=none for a few weeks, then present what you found — unauthorized senders, failed authentication, potential spoofing activity. Most clients are surprised by what's sending as their domain. That surprise converts to an enforcement engagement.
FAQ
How many domains can an MSP realistically manage?
With the right tooling, hundreds. A purpose-built MSP platform with portfolio dashboards, automated reporting, and enforcement workflows lets a small team manage a large domain portfolio. Without it, manual DMARC management becomes impractical past 10-20 domains — you spend all your time in spreadsheets instead of doing the actual work.
Should MSPs offer DMARC as a standalone service or bundle it?
Both work, and many MSPs do both. Standalone DMARC appeals to clients who already have email security and need help specifically with authentication. Bundling DMARC with broader domain protection — DNSSEC, MTA-STS, dangling DNS detection — adds more value and makes the service stickier. Clients are less likely to churn when you're providing a comprehensive domain security layer.
What if a client doesn't have DMARC at all?
Start with a monitoring-only deployment: publish p=none, collect reports, present findings. This is low-risk for the client (nothing is blocked) and high-value for you (you now have data). The discovery report — showing who's sending as their domain, including senders they didn't authorize — often sells the enforcement project on its own.
How do I explain DMARC to non-technical clients?
Focus on the outcome, not the protocol: "DMARC prevents anyone else from sending email that looks like it comes from your domain. Without it, anyone can forge your company name in an email to your customers, partners, or employees." Skip SPF, DKIM, and alignment unless they ask. Clients care about the risk (spoofing) and the solution (protection), not the mechanism.
What compliance frameworks require DMARC?
PCI DSS 4.0 requires anti-phishing controls, and DMARC is the primary technical control for domain spoofing prevention. NIST 800-177 recommends DMARC for federal email. The ASD Essential Eight (Australia) includes email authentication. NHS DSPT (UK health sector) requires it. US BOD 18-01 mandates DMARC for federal agencies. Increasingly, cyber insurance underwriters are asking about DMARC enforcement status during policy renewals.
Can I white-label DMARC monitoring for my clients?
Some platforms support white-label or branded portals where clients log in to see their own data under your MSP brand. This is important if you want to own the client relationship rather than reselling a vendor's dashboard. Evaluate whether the platform lets you customize the domain, branding, and client-facing reports before committing.
Built for MSP operations
SpoofSentry gives MSPs portfolio visibility, branded client reporting, enforcement simulation, and per-domain pricing. See how it works for multi-domain management.