How to package DMARC monitoring as an MSP service
Updated on 14 Aug 2026: We updated this guide for the revised DMARC standards and added MSP ownership, service-level, renewal, and offboarding controls.
DMARC monitoring works best as an MSP service when it is packaged as a managed email authentication program, not a one-time DNS cleanup. The offer needs a clear onboarding process, sender discovery, DNS implementation, alert handling, monthly reporting, and a path to stronger DMARC enforcement.
Package it around an outcome the client understands: reduce unauthorized direct-domain use, keep legitimate mail flowing, and give the business a clear monthly view of who sends email for the domain. The technical work sits underneath that promise. Clients rarely buy DMARC monitoring because they want XML reports. They buy it because email identity has become another managed security control.
The sellable MSP version
The MSP service is a recurring control: discover senders, authenticate approved systems, alert on failures, report business risk, and move the domain toward enforcement when the data is clean.
Package the service, not just the DNS record
A good MSP package has a scope that sales and technical staff can repeat. Separate the offer into setup, managed operation, policy progression, and reporting. Setup gets the domain visible. Managed operation turns raw authentication data into client actions. Policy progression moves the client away from monitoring mode after legitimate mail has been verified.
- Setup: Add the client domain, publish the DMARC reporting address, confirm SPF and DKIM status, and document all known sending systems.
- Operation: Review authentication failures, classify new sources, notify the client only when a decision or vendor change is needed, and keep tickets tied to evidence.
- Progression: Move the policy through none, quarantine, and reject once approved senders pass DMARC through aligned SPF or DKIM.
- Reporting: Send a client-ready summary showing mail volume, authentication health, unauthorized sources, open fixes, and policy status.
One-time project
- Scope: Create DNS records, check the obvious senders, and hand over the configuration.
- Risk: New SaaS tools, marketing platforms, and finance systems appear after the project ends.
- Revenue: It creates a project fee but does not naturally renew each month.
Managed service
- Scope: Monitor every domain, handle alerts, maintain sender inventory, and manage enforcement.
- Risk: Change is expected, tracked, and turned into tickets before it causes mail delivery problems.
- Revenue: It fits managed security and compliance retainers.
Suped's product supports this delivery model with multi-client organization management, DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, blocklist monitoring, and client reports. The MSP dashboard turns those functions into an MSP workflow instead of a domain-by-domain administration task.
Define clear deliverables
The client should know exactly what is included before the first DNS record changes. Avoid vague labels like email security monitoring unless the work is written out. DMARC service delivery touches DNS, mail vendors, security operations, and marketing teams. That means the MSP package needs boundaries.
|
|
|
|---|---|---|
Discovery | Find senders | Sender list |
DNS | Publish records | Verified setup |
Monitoring | Review failures | Action tickets |
Policy | Stage enforcement | Published policy |
Reporting | Summarize risk | Monthly proof |
Compact MSP deliverables for a DMARC monitoring package
Also define what is not included. For example, an MSP package can include DNS guidance and vendor instructions, but exclude rebuilding a client's marketing automation setup unless that work is scoped separately. That protects margins and keeps the DMARC service from becoming unlimited vendor support.
Do not sell enforcement on day one
Starting at reject before sender discovery is complete creates avoidable mail loss. Start with monitoring, find legitimate sources, fix authentication, then stage enforcement with evidence.
Set roles, service levels, and renewal rules
Put operational ownership in the statement of work before onboarding. Name the MSP operator, client executive sponsor, DNS approver, and owners of sending systems. Define who can approve policy changes, who handles vendor fixes, and who receives urgent tickets. Give each person only the access needed for that role, and retain an audit log of administrative changes.
|
|
|
|
|---|---|---|---|
New high-volume source | Classify and open a ticket | Confirm its owner and purpose | Agreed triage window |
Authentication drop | Measure impact and escalate | Coordinate the sender or vendor | Severity-based response |
Policy or DNS change | Prepare, record, and verify | Approve the change window | Planned change window |
Renewal or exit | Review scope or prepare handoff | Approve scope or receiving contact | Contract notice period |
Example ownership and response matrix for the service schedule
At renewal, compare actual domain count, sender count, ticket volume, review cadence, and vendor coordination against the contracted tier. Confirm client contacts and role assignments, then record the next policy goal. This review keeps a simple account priced and staffed differently from one with frequent sender changes.
- Inventory: Export managed domains, approved senders, current policies, open issues, and change history.
- Reporting: Transfer the RUA destination and verify that the new report consumer receives aggregate reports.
- Hosted records: Replace or transfer hosted DMARC and SPF records before platform access ends.
- Access: Revoke MSP and client user access on the agreed date, then record the action in the final ticket.
- Retention: Apply the contracted export and deletion schedule to report data and client documentation.
Write the exit into the SOW
DMARC DNS records outlive the agreement. Define record ownership, report endpoint transfer, data export, access revocation, retention, and final verification before the service starts.
Build a repeatable onboarding runbook
Onboarding decides whether the service scales. The goal is to make the first month predictable across every client. Start with the primary sending domain, then add secondary domains, parked domains, and brand domains that attackers can impersonate. For each domain, check whether SPF exists, whether DKIM is active for each sender, and whether DMARC reports are flowing.
Flowchart showing MSP DMARC onboarding from adding a domain to staging policy
- Access: Confirm who controls DNS, who owns mail platforms, who approves vendor changes, and who receives security escalations.
- Inventory: List the mailbox provider, CRM, billing system, marketing platform, help desk, and every device or app that sends mail.
- Baseline: Leave DMARC in monitoring mode until report data confirms which systems are passing and failing.
- Fixes: Turn on DKIM, correct SPF includes, remove stale senders, and repair forwarding paths where the client controls them.
- Handoff: Give the client a sender inventory, open issues, policy plan, and a report date for the first review.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A broad domain health check belongs in the discovery step because it gives the MSP a fast view of DMARC, SPF, and DKIM before any client meeting. It also helps sales avoid overselling the current state. If the domain has no DKIM, a broken SPF record, or no DMARC record, the first milestone is visibility, not enforcement.
Standardize the technical implementation
The technical setup should be predictable and documented. A DMARC package needs standard record templates, clear policy rules, a change log, and a fallback plan. The MSP should know who approves each DNS change and how quickly the client can update records when a sender is failing.
Starter DMARC monitoring recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
That first record gets aggregate reports flowing. After the MSP has enough data, the service moves into authentication repair. SPF needs special care because terms that trigger DNS queries have a limit of 10 during one check. For clients with several vendors, hosted SPF can reduce repeated DNS tickets and keep sender changes inside a managed workflow.
Simple SPF and DKIM examplesDNS
example.com TXT "v=spf1 include:spf.vendor.example -all" selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIB..."
RFC 9989 made the pct tag historic, so do not stage a current deployment with pct=25 or another percentage. Use report evidence and controlled change windows to move whole policies through monitoring and enforcement. The t=y tag signals test mode, but it does not create a percentage rollout. RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting.
Current DMARC policy stagesDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Policy staging path
An ordered policy sequence for clients after approved senders are authenticated, not a percentage rollout.
Policy stage
A p=quarantine or p=reject record expresses the domain owner's requested handling for mail that fails DMARC. Each receiver retains discretion under its local policy, so client reporting should describe the published policy and observed results instead of promising universal blocking.
Use a sender approval rule
- Known: The sender is owned by the client or an approved vendor.
- Authenticated: The sender passes DMARC through aligned SPF or DKIM.
- Documented: The owner, vendor, purpose, and setup notes are recorded.
- Reviewed: A second person checks high-volume sources before policy enforcement.
Turn monitoring into operations
The recurring value of the service comes after setup. DMARC reports identify sources, but an MSP needs decisions. Each failure should become one of four outcomes: approved sender that needs a fix, unknown sender that needs client confirmation, unauthorized sender that stays unauthenticated, or forwarding noise that needs monitoring without a client escalation.
Weekly source review
A simple operational view MSP teams can use when triaging DMARC sources.
Passing
Needs fix
Unknown
Run a weekly technical review and a monthly client review. The weekly review is internal and ticket-focused. The monthly review is client-facing and outcome-focused. That split keeps clients out of raw telemetry but still proves the service is active. Route alerts into the existing ticketing workflow, and retain policy changes in the client audit log.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
In Suped's product, the MSP organization view gives operators one place to move between client organizations, check domain status, and prioritize domains by volume and health. An MSP manages ongoing change across client organizations while preserving separate access and reporting for each tenant.
- Alerts: Create tickets for sudden failure spikes, new high-volume sources, policy drift, and unexpected DNS changes.
- Ownership: Assign each source to the MSP, client IT, marketing, finance, or a vendor contact.
- Evidence: Attach pass rates, source names, sending IPs, and the affected domain to each ticket.
- Closure: Close issues only after fresh reports confirm the sender now passes authentication.
Add reputation and deliverability checks
DMARC is not the whole email health story. Include blocklist (blacklist) monitoring when it fits the MSP service because clients often notice reputation issues before they understand authentication failures. A domain can have correct DMARC and still struggle if sending infrastructure has poor reputation.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftThe package wording is important. Do not promise that monitoring removes every blacklist or blocklist entry. Promise detection, triage, evidence, and guided remediation. Suped's blocklist monitoring puts reputation checks next to DMARC, SPF, and DKIM signals in Suped's product.
Service boundary
Blacklist and blocklist monitoring should include detection and guidance. Remediation that requires changing customer mail content, list hygiene, or third-party vendor behavior should have its own scope.
Report business value without overloading the client
Client reports should not be a dump of authentication rows. Keep them short and decision-oriented. A strong report shows the current DMARC policy, volume trends, approved senders, failed sources, open tickets, and the next policy recommendation. If the client only reads one page, they should understand whether their domain is better protected than last month.
Create client report dialog with organization, date range, logo, and language options
Suped's client report workflow helps MSPs package the ongoing service. Operators can create branded reports with organization, date range, logo, and language options. That turns the technical review into a client artifact without asking engineers to rebuild the same slide or spreadsheet every month.
Client reporting thresholds
Example thresholds for explaining readiness for stronger DMARC policy.
Ready
95%+ pass
Approved mail is authenticated and unknown volume is low.
Watch
85-94%
Some approved senders still need fixes before policy changes.
Fix first
<85%
Sender discovery or authentication repair is still active.
These thresholds are operating guardrails, not universal rules. Review the actual source mix before changing policy. A small failure from a known test system is different from a high-volume finance platform that sends invoices.
Use a simple service menu
MSPs do not need public pricing tables to package the service. They need clear internal packaging. Use bundles that match client complexity, then quote based on domains, sender count, DNS control, reporting needs, and expected vendor coordination.
Baseline package
- Fit: Small clients with a primary domain and a short sender list.
- Work: DMARC setup, monitoring, core sender fixes, and monthly summary.
- Limit: Vendor coordination and complex enforcement changes need scoped work.
Managed package
- Fit: Clients with several domains, frequent SaaS changes, or compliance pressure.
- Work: Monitoring, alerts, hosted record management, reports, and policy staging.
- Limit: Mail platform migrations and content reputation work need separate ownership.
For MSPs building this for the first time, keep the entry package narrow and make expansion obvious. Add more domains, more frequent reviews, hosted DMARC, hosted SPF, MTA-STS, blocklist checks, executive reporting, or vendor coordination as the account grows.
Pilot the service before a full launch
The cleanest launch is a pilot across a small group of existing clients. Pick clients with different mail patterns, including a simple office domain, a marketing-heavy client, a client with several domains, and one that relies on several external senders. That gives the MSP enough variation to tune onboarding, reporting, and alert handling before adding the service to every managed services agreement.
- Pilot: Choose a few clients and run monitoring mode for the first reporting cycle.
- Template: Create ticket templates for new sender, failed SPF, failed DKIM, policy change, and blacklist or blocklist alert.
- Train: Give help desk staff a simple source classification guide and escalation path.
- Review: Compare alert volume, ticket time, client questions, and report quality after one cycle.
- Expand: Add the service to standard security packages once the workflow is repeatable.
A repeatable MSP service gives every client domain monitoring, every approved sender an owner, every authentication failure a status, and every monthly report a next action. Suped's product supports that workflow through multi-client organization management, hosted DMARC and SPF, sender analysis, alerts, client reports, and blacklist or blocklist monitoring.
