How to build an MSP DMARC runbook for ongoing client support
Updated on 14 Aug 2026: We updated this runbook for RFC 9989 and added a practical client offboarding procedure.
An MSP DMARC runbook needs to define exactly how client domains are onboarded, monitored, remediated, reported on, escalated, and handed over after the first DNS record is published. The runbook should cover SPF, DKIM, DMARC, reporting addresses, source ownership, alert thresholds, client reporting, and policy changes, because ongoing support fails when DMARC is treated as a one-time DNS task.
The service should use repeatable operations: discover every sending source, validate authentication, fix domain-matching problems, move policy in controlled stages, and watch for new vendors or broken mail flows. RFC 9989 now defines DMARC, RFC 9990 covers aggregate reporting, and RFC 9991 covers failure reporting. For MSPs, the process has to work across many clients without relying on one engineer remembering the history behind each domain.
Suped fits this workflow when an MSP needs multi-tenant 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 process 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, sending domains, and the required p, sp, or np policy 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, plus the rollback owner.
- Reporting: Set reporting cadence, recipients, service levels, 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 alignment, 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. Use one checklist for every client so the first support month produces a clear source inventory, not a pile of disconnected DMARC reports.
MSP DMARC onboarding flow for domains, reporting, sender discovery, fixes, and policy.
|
|
|
|---|---|---|
Domain list | MSP | Inventory |
DNS access | Client | Admin |
SPF review | MSP | TXT |
DKIM review | MSP | Selectors |
DMARC report | MSP | RUA |
RUA authorization | MSP | DNS |
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. When the RUA address uses another domain, verify that the report receiver has published the required external authorization record before treating onboarding as complete.
Starter DMARC monitoring recorddns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@example.com;" " adkim=r; aspf=r"
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 DMARC through SPF or DKIM identifier alignment.
- 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, current status, and review date.
Standardise SPF and DKIM fixes
Most ongoing DMARC tickets come down to the same technical causes: SPF includes missing, SPF lookup limits exceeded, DKIM not enabled, DKIM selector wrong, forwarding breaking SPF, or the authenticated identifier failing to 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 authorized.
- Limit: Count DNS lookups before adding another include.
- Match: Verify that the return-path domain has the required DMARC relationship with 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 that the DKIM signing domain has the required DMARC relationship with 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 Suped. Suped also has 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 identifier alignment 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. Use both percentage and absolute message volume so a small noisy source does not outrank a failing business-critical sender.
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 identifier alignment 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 identifier alignment, and whether the next action is a DNS change, vendor change, or client confirmation. Each alert class should have a response target and an escalation target in the service-level agreement.
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 policy changes with rollback gates
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 checkpoints
Each bar shows the active policy state for the selected rollout scope, not message sampling.
Monitor
Pilot subdomain
Quarantine
Reject
RFC 9989 made the pct tag historic, so do not use partial percentages as the rollout control. Keep p=none while approved sources are being fixed. Then test a low-risk domain or subdomain, schedule full p=quarantine in a change window, validate real traffic and support tickets, and expand the scope after a complete reporting cycle. Move to p=reject only after client approval, with the previous record and rollback condition attached to the change ticket.
Quarantine stagedns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine;" " rua=mailto:reports@example.com; adkim=r; aspf=r"
Reject stagedns
_dmarc.example.com. TXT "v=DMARC1; p=reject;" " rua=mailto:reports@example.com; adkim=r; aspf=r"
RFC 9989 adds t=y as policy test mode, but receivers using older DMARC processing can ignore that unknown tag and apply p=quarantine or p=reject as written. Do not use t=y as the only safety or rollback control while receiver support is mixed.
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 in Suped after the initial setup. Change approval and rollback evidence still belong in the client ticket.
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, closure note, and target response time.
|
|
|
|---|---|---|
New sender | Unknown source | Confirm owner |
SPF fail | Auth or lookup error | Repair and test |
DKIM fail | Missing or invalid signature | Enable or repair |
Misalignment | Pass without DMARC | Fix identifier domain |
Spoofing | Unauthorized source | Assess enforcement |
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 ties a 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. Use the quarterly business review for enforcement approval, accepted risks, service scope changes, and sender inventory ownership.
Create client report dialog with organization, date range, logo, and language options
Suped's client reports package the evidence needed for the client conversation. For MSPs, this helps show operational work that otherwise stays 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 a longer monitoring period, but the decision, review date, and approving contact 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.
MSP monitoring checks for DMARC reports, SPF, DKIM, policy, and blocklists.
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 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: Useful for recurring client support and service delivery.
- Control: Centralises monitoring, alerts, reports, and remediation steps.
- Scale: Supports repeatable workflows across multiple organizations.
For MSP teams that need multi-client operations, Suped combines DMARC monitoring, hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, alerting, automated issue detection, blocklist monitoring, and client reports in the same product workflow. This keeps client separation, remediation evidence, and reporting under the same operating process.
A runbook is useful only 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.
Plan client offboarding and handover
Define DMARC offboarding in the service scope before a client leaves. The published DNS policy continues after the contract ends, but the MSP's report address, platform access, alert routes, and support ownership cannot remain open indefinitely. Set the handover date, receiving owner, data retention period, and final validation method in one ticket.
- Freeze changes: Pause non-essential policy changes and record the last approved DMARC record.
- Export evidence: Provide the domain inventory, source inventory, current policy, open exceptions, and recent reports.
- Transfer reporting: Replace the MSP-controlled RUA destination and verify that reports reach the new authorized receiver.
- Transfer ownership: Name the person responsible for alerts, policy approval, sender changes, and emergency rollback.
- Close access: Remove delegated access, stop MSP alerts, apply the agreed data retention rule, and save completion evidence.
Keep the current enforcement policy unless the client approves a controlled change. Offboarding is not a reason to weaken p=reject or leave an MSP-controlled RUA address in DNS after monitoring ends.
Keep the runbook operational
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 identifier alignment, stage policy changes with rollback gates, create ticket playbooks, report progress every month, and maintain a handover path. That gives the client safer enforcement and gives the MSP a service that can scale.
The strongest runbooks make every recurring problem routine: 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 with monitoring, remediation guidance, hosted controls, alerts, and MSP reporting in one platform.
