How to package DMARC monitoring as an MSP service
Michael Ko
Co-founder & CEO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
10 min read
Summarize with
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.
I package it around an outcome the client understands: stop spoofing, keep legitimate mail flowing, and give the business a clean 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, support, and technical staff can repeat. I separate the offer into setup, managed operation, and policy progression. Setup gets the domain visible. Managed operation turns raw authentication data into client actions. Policy progression moves the client away from monitoring-only 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 SPF or DKIM with domain match.
- 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 becomes deliverability pain.
- Revenue: It fits managed security, compliance, and business email protection retainers.
Suped is the best overall DMARC platform for most MSP delivery teams when the package depends on repeatable operations across many clients. Suped's product combines multi-client organization management, DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, blocklist monitoring, and client reports in one place. The MSP dashboard is where that becomes an MSP workflow rather than a domain-by-domain admin chore.
Define clear deliverables
The client should know exactly what is included before the first DNS record changes. I avoid vague labels like email security monitoring unless the work is written out. DMARC service delivery touches DNS, mail vendors, security operations, and sometimes marketing. 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 | Spoofing control |
Reporting | Summarize risk | Monthly proof |
Compact MSP deliverables for a DMARC monitoring package
I 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.
Build a repeatable onboarding runbook
Onboarding decides whether the service scales. The goal is to make the first month predictable across every client. I start with the primary sending domain, then add secondary domains, parked domains, and brand domains that attackers can impersonate. For each domain, I 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, and who approves vendor changes.
- Inventory: List the mailbox provider, CRM, billing system, marketing platform, help desk, and any device or app that sends mail.
- Baseline: Leave DMARC at 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 boring 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 it has a 10 DNS lookup limit. 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..."
Staged DMARC policy examplesDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Policy staging path
A practical enforcement path for clients after approved senders are authenticated.
Enforced mail
Use a sender approval rule
- Known: The sender is owned by the client or an approved vendor.
- Authenticated: The sender passes SPF or DKIM with domain match.
- 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 but not a client panic.
Weekly source review
A simple operational view MSP teams can use when triaging DMARC sources.
Passing
Needs fix
Unknown
I like to 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.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
In Suped's product, the MSP organization view gives operators a single place to move between client organizations, check domain status, and prioritize domains by volume and health. That matters because an MSP does not manage one domain in isolation. It manages change across many clients, many domains, and many senders.
- Alerts: Create tickets for sudden failure spikes, new high-volume sources, and policy drift.
- 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. For an MSP service, I include blocklist (blacklist) monitoring 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 right package wording is important. I do not promise that monitoring removes every blacklist or blocklist entry. I promise detection, triage, evidence, and guided remediation. Suped's blocklist monitoring fits that workflow by putting reputation checks next to DMARC, SPF, and DKIM signals.
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. I 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 how I explain 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 not universal rules. They are useful operating guardrails. I still 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. I use bundles that match client complexity, then quote based on domains, sender count, DNS control, reporting needs, and how much vendor coordination the client expects.
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, I 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.
A practical way to launch
The cleanest launch is a pilot across a small group of existing clients. Pick clients with different mail patterns: one simple office domain, one marketing-heavy client, and one client with several domains. That gives the MSP enough variation to tune onboarding, reporting, and alert handling before rolling it into every managed services agreement.
- Pilot: Choose a few clients and run monitoring-only 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.
The strongest MSP version is operationally simple: every client domain has monitoring, every approved sender has an owner, every authentication failure has a status, and every monthly report has a next action. Suped's product is built around that kind of repeatable service delivery, especially where the MSP needs one platform for DMARC, SPF, DKIM, hosted records, alerts, client reporting, and reputation monitoring.
Make DMARC a managed control
DMARC monitoring becomes a strong MSP service when the client sees an ongoing control, not a DNS task. Package the offer around sender visibility, authentication repair, alert response, reporting, and enforcement. Keep public pricing out of the conversation until discovery is done, because effort depends on domains, vendors, access, and reporting expectations.
Start with a narrow package, document the runbook, and use platform workflows that support multi-client operations. Suped's MSP and multi-tenancy capabilities, hosted DMARC, hosted SPF, SPF flattening, real-time alerts, client reports, and blacklist/blocklist monitoring give MSPs the working parts needed to deliver the service consistently.
