How to build an MSP DMARC runbook for ongoing client support
Michael Ko
Co-founder & CEO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
11 min read
Summarize with
An MSP DMARC runbook needs to define exactly how client domains are onboarded, monitored, remediated, reported on, and escalated after the first DNS record is published. The runbook should cover SPF, DKIM, DMARC, reporting addresses, source ownership, alert thresholds, monthly client reporting, and policy changes, because ongoing support fails when DMARC is treated as a one-time DNS task.
I structure the service around repeatable operations: discover every sending source, validate authentication, fix domain-matching problems, move policy in stages, and keep watching for new vendors or broken mail flows. For MSPs, that process has to work across many clients without relying on one engineer remembering the story behind each domain.
Suped fits this workflow when an MSP needs a multi-tenant DMARC platform with source visibility, automated issue detection, alerting, client reporting, hosted DMARC, hosted SPF, SPF flattening, blocklist monitoring, and deliverability context in one place. The practical value is operational consistency: the same support motion can be applied to a five-person client, a multi-domain client, or a client that changes marketing tools every quarter.
Define the service scope first
The runbook should start by separating what the MSP owns from what the client owns. DMARC touches DNS, identity, marketing platforms, billing systems, CRMs, ticketing systems, websites, and sometimes shadow IT. Without a scope boundary, every failed source becomes an argument about who should chase the vendor.
For a managed MSP DMARC service, the MSP should usually own the runbook, monitoring, DNS change requests, issue triage, client reporting, and policy recommendations. The client should own business approval for enforcement, vendor access, sender decommissioning, and internal decisions about whether a tool still needs to send mail.
- Scope: List covered domains, subdomains, parked domains, lookalike domains, and sending domains before work starts.
- Access: Record who controls DNS, mail platforms, marketing platforms, ticketing systems, and vendor admin portals.
- Change control: Define who approves TXT, CNAME, DKIM, SPF, DMARC, MTA-STS, and BIMI-related changes.
- Reporting: Set reporting cadence, recipients, success metrics, exception handling, and escalation contacts.
Do not start enforcement until the client has confirmed the business owner for every material sender. A mail source can pass SPF but still fail DMARC domain matching, and a legitimate vendor can stop sending correctly after a branding, DNS, or account change.
Build the onboarding checklist
Onboarding is where the runbook either becomes scalable or turns into ticket noise. I use one checklist for every client so the first support month produces a clear source inventory, not a pile of disconnected DMARC reports.
Flowchart showing an MSP DMARC onboarding sequence.
|
|
|
|---|---|---|
Domain list | MSP | Inventory |
DNS access | Client | Admin |
SPF review | MSP | TXT |
DKIM review | MSP | Selectors |
DMARC report | MSP | RUA |
Policy plan | Both | Approval |
Use this as the minimum onboarding checklist for each client domain.
The first DNS change should usually be a DMARC monitoring record at _dmarc with policy set to none. That gives the MSP data before enforcement. If the client already has DMARC, preserve the existing policy unless the record is broken or the reporting destination needs to change.
Starter DMARC monitoring recorddns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@example.com;" " fo=1; adkim=r; aspf=r; pct=100"
Create the source inventory
The source inventory is the center of the runbook. Every IP, platform, and vendor seen in DMARC reports needs one status: approved, unknown, retired, malicious, or pending client confirmation. This avoids the common MSP problem where the same failing sender gets investigated again each month.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
In Suped, MSP operators can switch between client organizations, review domain status, inspect email volume, and keep client work separated. That matters because a support runbook should reduce cross-client context switching and keep the evidence for each client clean.
- Approved: The sender has a named business owner and passes SPF or DKIM with DMARC domain matching.
- Unknown: The sender appears in reports but no client owner has confirmed why it sends mail.
- Retired: The source used to be valid but should no longer send on behalf of the domain.
- Malicious: The traffic is not authorized and should be blocked as policy moves to enforcement.
A good source inventory stores more than a vendor name. Capture the platform, sending domain, DKIM selector, SPF include, return-path domain, business owner, ticket reference, first seen date, last seen date, and current status.
Standardise SPF and DKIM fixes
Most ongoing DMARC tickets come down to the same few technical causes: SPF includes missing, SPF lookup limits exceeded, DKIM not enabled, DKIM selector wrong, forwarding breaking SPF, or the sender using a domain that does not match the visible From domain. The runbook should turn each cause into a repeatable fix path.
SPF path
- Check: Confirm the domain has one SPF record and the sender is included.
- Limit: Count DNS lookups before adding another include.
- Match: Verify the return-path domain matches the visible From domain.
DKIM path
- Enable: Turn on DKIM signing in the sending platform.
- Publish: Add the selector record or CNAME supplied by the vendor.
- Verify: Send a test message and confirm DKIM passes for the visible From domain.
Hosted SPF is useful for MSPs because client DNS access is often slow, fragmented, or controlled by another provider. With hosted SPF, the client publishes a stable include once, then the MSP manages approved senders in the platform. Suped also supports SPF flattening so MSP teams can reduce lookup-limit problems while keeping the record maintainable.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The runbook should require a health check after every sender change. That check should confirm DMARC exists, SPF resolves correctly, DKIM selectors are valid, and domain matching is visible in real messages rather than assumed from a vendor setup screen.
Hosted SPF patterndns
example.com. TXT "v=spf1 include:spf.example-hosted.net -all"
Set monitoring and alert rules
Monitoring should tell the MSP what changed, what broke, and what needs a ticket. Raw aggregate reports are not enough. The runbook should define which signals create tickets, which signals go into the next client report, and which signals need immediate escalation.
Suggested operational thresholds
Use these thresholds as a starting point, then adjust for each client after baseline traffic is known.
Healthy
95-100%
Approved senders pass DMARC checks and volume is stable.
Watch
90-94%
A known sender has intermittent failures or a low-volume unknown source appears.
Ticket
80-89%
A material sender fails domain matching or a new source sends meaningful volume.
Escalate
<80%
Client mail flow is affected or spoofing volume increases sharply.
In Suped, real-time alerts and automated issue detection can turn DMARC failures into support actions instead of manual report review. For client-facing managed services, DMARC monitoring should be tied to named workflows: new sender review, approved sender failure, policy readiness, spoofing spike, and recurring authentication drift.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
The alert owner should not always be the senior engineer. A good runbook lets first-line support identify whether a source is approved, whether the issue is SPF, DKIM, or domain matching, and whether the next action is a DNS change, vendor change, or client confirmation.
Create alert categories that map directly to tickets. Avoid alerts such as "DMARC failed" without source, volume, affected domain, and next action. A noisy alert becomes invisible after the second week.
Stage DMARC policy changes
A safe MSP runbook does not jump every client straight to p=reject. Enforcement should follow evidence. The MSP needs enough reporting history to know which legitimate sources exist, which sources pass DMARC checks, and which unknown sources can be blocked without disrupting business mail.
Policy staging model
A staged model helps support teams explain risk reduction without hiding unresolved senders.
Monitor
Quarantine
Reject
For many clients, the cleanest sequence is p=none, then p=quarantine with a partial percentage, then full quarantine, then p=reject. Some clients can move faster, especially if they have a small and stable sender list. Others need a longer monitoring phase because franchises, branch offices, or acquired brands introduce sources the central team does not know about.
Quarantine stagedns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25;" " rua=mailto:reports@example.com; adkim=r; aspf=r"
Reject stagedns
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100;" " rua=mailto:reports@example.com; adkim=s; aspf=s"
Hosted DMARC can reduce operational friction when MSPs need to stage policy changes across many domains without waiting for DNS access on every small adjustment. With hosted DMARC, Suped lets the DNS record point to managed configuration so policy staging can be handled from the platform after the initial setup.
Write the ticket playbooks
The runbook should include ticket playbooks for the cases support sees repeatedly. These playbooks keep work consistent and reduce escalation to senior staff. Each playbook should include detection criteria, evidence to attach, first response, technical fix, validation method, and closure note.
|
|
|
|---|---|---|
New sender | Unknown | Confirm owner |
SPF fail | No include | Update SPF |
DKIM fail | No signature | Enable DKIM |
Misalign | Pass mismatch | Fix domain |
Spoofing | Unauthorized | Enforce |
Use compact playbooks so support can move quickly without guessing.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's issue view is useful here because it ties the problem to steps to fix and lets the operator verify the change. That is the difference between a monitoring report and a support process: the MSP needs a next action, not just an authentication status.
A closure note should include the source name, affected domain, root cause, DNS or platform change, validation result, and whether the client source inventory was updated.
Add reporting and client governance
A DMARC service needs client reporting that makes progress visible without forcing the client to interpret XML, authentication headers, or DNS syntax. The monthly report should show policy, volume, approved sources, unresolved sources, spoofing attempts, fixed issues, and the next policy recommendation.
Create client report dialog with organization, date range, logo, and language options
Suped's client reports support this part of the runbook by packaging evidence for the client conversation. For MSPs, this helps show operational work that otherwise stays hidden inside tickets, DNS records, and internal notes.
- Health: Current DMARC policy, pass rate, authenticated volume, and unresolved authentication issues.
- Sources: Approved platforms, new senders, retired senders, and sources waiting for client confirmation.
- Risk: Unauthorized traffic, spoofing patterns, blocklist or blacklist concerns, and exposed domains.
- Next step: Recommended DNS changes, vendor fixes, sender decommissioning, or policy movement.
Governance also needs an exception process. If a client refuses to fix a source or cannot identify an owner, the MSP should record the risk and avoid silently delaying enforcement forever. The client can choose to accept a longer monitoring period, but that decision should be visible.
Include security and deliverability checks
DMARC is the core of this runbook, but MSP support should also watch adjacent signals. A client can have correct DMARC and still have deliverability trouble because an IP or domain lands on a blocklist (blacklist), a forwarded stream breaks authentication, or a vendor changes infrastructure without warning.
Infographic showing the main checks in MSP email authentication monitoring.
For MSPs, blocklist and blacklist monitoring should not be a separate manual habit. It should sit next to DMARC evidence so a support operator can see whether authentication failure, reputation, or sender configuration explains a client complaint.
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 same rule applies to test messages. When a source is fixed, validate with a real email where possible. Header results and aggregate reports tell different parts of the story. The runbook should use both before closing a client ticket.
Use the right operating model
The best operating model depends on the MSP's client base, but the runbook should avoid heroic manual work. A spreadsheet can work for a few domains during discovery. It breaks when the MSP needs alerts, source history, policy staging, client separation, repeatable reports, and evidence for many organizations.
Manual model
- Fit: Useful during a small proof of concept or one-off cleanup.
- Risk: Depends on manual review and undocumented engineer context.
- Limit: Hard to scale across many clients and domains.
Managed platform model
- Fit: Better for recurring client support and service delivery.
- Control: Centralises monitoring, alerts, reports, and remediation steps.
- Scale: Supports repeatable workflows across multiple organizations.
Suped is the stronger practical choice for most MSP teams because the product is built around multi-client operations, not just domain-level checking. The useful combination is DMARC monitoring, hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, alerting, automated issue detection, blocklist monitoring, and client reports in the same workflow.
A runbook is only useful if the team follows it under pressure. Keep steps short, require evidence, make ownership explicit, and use tooling that turns failures into clear support actions.
The runbook that works
An MSP DMARC runbook should be operational before it is ambitious. Start with a clean domain inventory, publish reporting, build the source inventory, fix SPF and DKIM domain matching, stage policy changes, create ticket playbooks, and report progress every month. That gives the client safer enforcement and gives the MSP a service that can scale.
The strongest runbooks make every recurring problem boring: a new sender has an owner check, a failed DKIM source has a vendor fix path, a policy change has approval criteria, and a blocklist or blacklist hit has a reputation workflow. Suped supports that operating model by combining monitoring, remediation guidance, hosted controls, alerts, and MSP reporting in one platform.
