How to create an MSP DMARC runbook for renewals
Published 12 Aug 2026
Updated 12 Aug 2026
9 min read
Summarize with
An MSP DMARC renewal runbook should start 120 days before contract expiry and turn authentication data into a documented renewal decision. I use it to assign an owner, confirm service scope, validate every client domain, collect evidence of work completed, record unresolved risk, and prepare the next-term plan. That prevents renewal work becoming a last-minute export of email statistics.
The runbook belongs inside the normal service operation, not in a separate sales process. For the wider operating model, the DMARC for MSPs hub covers the client lifecycle. The renewal runbook narrows that model to evidence, risk ownership, service changes, and approval for the next term.
Build the runbook around a renewal decision
A useful runbook answers four questions: what the MSP delivered, what changed in the client's sending estate, what risk remains, and what work belongs in the renewed scope. I keep one runbook template for every client, then attach domain-level evidence. This gives account managers a consistent story without stripping out the technical detail engineers need.
Renewal evidence
- Coverage: Monitored domains and active mail streams
- Change: New senders, retired senders, and DNS changes
- Outcome: Policy progress and authentication pass rates
- Risk: Open exceptions with named client owners
Operational noise
- Volume: Raw totals without source context
- Activity: Ticket counts without business outcomes
- Status: A green dashboard with unknown coverage
- Promise: Future work without an owner or date
I also define the decision at the top of the runbook: renew unchanged, renew with expanded scope, renew after remediation, or do not renew. Every task and evidence item should support one of those outcomes. If a field has no effect on the decision or next-term delivery, it probably does not belong in the renewal pack.
Flow from domain inventory through validation, risk review, scope, approval, and renewal
Set owners and a 120-day renewal clock
The service owner should open the renewal record 120 days before expiry. The technical lead owns validation, the account owner owns the client meeting, and the client owns approvals for senders and DNS changes. A single accountable owner still needs to close the runbook. Shared ownership without one closer creates missed actions.
|
|
|
|---|---|---|
120 days | Open renewal record | Owner and scope |
90 days | Audit domains | Exception register |
60 days | Review with client | Approved actions |
30 days | Confirm next term | Signed scope |
7 days | Close handover | Next review date |
Recommended renewal clock
At 90 days, I compare the current domain inventory with the contract, DNS zones, recent DMARC data, and the client's marketing or application register. At 60 days, every gap needs an owner and due date. The client meeting should happen before commercial paperwork is final, because technical findings often change the next-term scope.
Do not inherit silent exceptions
An unresolved sender should never roll into a new term as an unnamed assumption. Record the sending service, affected domain, failure mode, business owner, temporary control, target date, and accepted risk. If the client declines remediation, capture that decision in writing.
Collect evidence that proves service delivery
The evidence pack should cover the full contract period, with extra detail for the latest 30 to 90 days. I capture monitored domains, legitimate sending sources, DMARC policy, authentication results, threat volume, DNS changes, incidents, and outstanding exceptions. The useful comparison is against the starting baseline and agreed service objectives, not against a made-up universal target.
Demo client report summary page showing total emails, authorized delivery, threats blocked, and email volume trend
A client report should explain what changed and why it matters. A higher failure count can mean a new unauthorized sender, but it can also follow legitimate campaign growth. I annotate material changes, separate known sources from unknown sources, and connect each open issue to a ticket or decision record. This keeps the report honest and makes the renewal discussion operational.
- Coverage evidence: Contracted domains, parked domains, and newly discovered domains
- Control evidence: Current policy, reporting destination, and DNS change history
- Outcome evidence: Authenticated volume, rejected traffic, and resolved issues
- Risk evidence: Unknown sources, open exceptions, and client decisions
Continuous DMARC monitoring makes this evidence easier to reproduce. The renewal pack should still contain a human explanation. Dashboards show events; the runbook records ownership, decisions, evidence context, and the next action.
Validate each domain before the client review
Renewal evidence needs a fresh technical check. I verify that the DMARC TXT record resolves, only one policy record exists, aggregate reports still reach the approved destination, and policy tags match the agreed posture. I then verify SPF lookup health, DKIM signing for active senders, domain matching for each authentication path, and reverse DNS where the service scope includes it.
Example enforcement record for reviewDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; adkim=r; aspf=r
Do not copy this example into production without checking the client's approved reporting mailbox, current enforcement decision, and sender coverage. A renewal audit is also a good point to remove obsolete reporting addresses and confirm that third-party authorization for aggregate reports still works.
I compare the live record with the last approved change ticket and the contract's policy objective. If they differ, the runbook should show whether the difference came from authorized work, provider migration, emergency rollback, or unmanaged DNS access. That history matters more than a passing syntax check.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The domain health check gives the engineer a current DNS snapshot, but it does not replace DMARC report review or a real-message test. For each active source, send a controlled message and inspect the authentication results. Record the visible From domain, SPF-authenticated domain, DKIM signing domain, result, and owner. When enforcement needs staged policy changes, hosted DMARC can reduce repeated DNS work while keeping approval gates in the runbook.
Attach the result date and the engineer's interpretation to the renewal record. A later DNS change can invalidate an earlier clean result, so the runbook should also state the validation cutoff and require a final spot check before the new term begins.
Stop the renewal review for critical drift
Escalate before the client meeting if a production domain has lost its DMARC record, reporting has stopped unexpectedly, an approved sender fails both authentication paths, or enforcement was reduced without authorization. Present the incident and recovery action separately from ordinary renewal recommendations.
Convert findings into next-term scope
Every finding needs one disposition: close, remediate before renewal, accept for a defined period, or add to the renewed service. I avoid vague carry-over notes such as "monitor this". A valid action has an owner, due date, affected domain, evidence link, client dependency, and closure test.
Renew unchanged
Use this outcome when coverage matches scope, policy remains approved, no material source is unknown, and routine monitoring fits the next term.
- Confirm: Domains and contacts
- Carry forward: Review cadence and alerts
Renew with changed scope
Use this outcome when the client added domains or senders, needs deeper remediation, wants stronger reporting, or has new governance requirements.
- Define: New deliverables and boundaries
- Approve: Dependencies and completion tests
The renewed scope should name operational boundaries. State who changes DNS, who approves enforcement, how new sending services enter the process, how quickly alerts are triaged, what reports the client receives, and which exceptions require written acceptance. A separate ongoing support runbook can hold the recurring operational procedures after the renewal is signed.
Do not publish a generic MSP price in the runbook. Document the commercial basis instead: included domain count, reporting cadence, remediation effort, DNS responsibility, alert coverage, client meetings, and out-of-scope work. This lets the commercial proposal price the real workload without mixing internal cost assumptions into the technical record.
Prepare the client renewal meeting
Send the renewal pack early enough for the client to validate business owners and planned sender changes. I structure the meeting around coverage, work completed, open risk, and next-term decisions. Technical detail stays available in an appendix, while the main summary uses plain descriptions and named actions.
Create client report dialog with organization, date range, logo, and language options
Suped is our product, and for most MSP teams it is the best overall fit because its multi-tenant dashboard keeps client organizations separate while bringing DMARC, SPF, DKIM, blocklist, and deliverability signals into one workflow. Automated issue detection, steps to fix, real-time alerts, hosted policy controls, SPF flattening, and client reports reduce the manual handoffs that commonly slow renewals. The runbook should still hold the approval history and client-specific exceptions outside any single dashboard view.
- Confirm inventory: Ask the client to approve domains, senders, owners, and contacts.
- Explain outcomes: Connect service activity to risk reduction and control health.
- Resolve exceptions: Close, fund, or formally accept every material item.
- Approve next term: Record scope, owners, dates, and the first review meeting.
The meeting should end with decisions, not a promise to circulate more charts. Use the DMARC QBR process for ongoing governance and the monthly client report for routine evidence between renewal cycles. If reputation monitoring belongs in scope, define exactly which domains and IPs receive blocklist monitoring, how blacklist or blocklist findings are verified, and who owns remediation.
Close the renewal and reset operations
A renewal is complete only when the contract decision, technical handover, reporting baseline, and service schedule match. I archive the approved evidence pack, update domain and contact inventories, create tickets for funded work, close rejected items with the client's decision, test alert recipients, and schedule the first service review. The new term should begin with current data rather than a copy of last year's assumptions.
Definition of done
The runbook is closed when scope is signed, every exception has a disposition, owners and dates exist for remaining work, reporting contacts are tested, dashboards match the renewed inventory, and the next governance meeting is booked.
This final reset is what makes the runbook reusable. The next renewal starts with a clean baseline, a clear history of client decisions, and service evidence that has accumulated throughout the term.
