How to create an MSP DMARC runbook for renewals
Published 12 Aug 2026
Updated 20 Oct 2026
11 min read
Summarize with
Updated on 25 Oct 2026: We updated the renewal runbook for current DMARC standards, contract notice deadlines, and client handoffs.
An MSP DMARC renewal runbook should start around 120 days before contract expiry, or earlier when the contract's notice deadline requires it, and turn authentication data into a documented renewal decision. 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.
Keep the runbook inside the normal service operation so service evidence feeds the renewal decision. 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. Use 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
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.
MSP DMARC renewal workflow covering inventory, validation, risk review, scope, approval, and renewal
Set owners and contract renewal deadlines
The service owner should open the renewal record around 120 days before expiry, earlier if needed to reach a decision before the notice deadline. Record the contract expiry date, non-renewal notice deadline, automatic renewal terms, and procurement lead time. Give the notice deadline its own calendar task and owner. 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 |
Suggested timeline before contract expiry; move milestones earlier to meet notice deadlines
At 90 days, 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. Capture monitored domains, legitimate sending sources, DMARC policy, authentication results, reported DMARC failures, DNS changes, incidents, and outstanding exceptions. Record the report date range, reporting receivers, and collection gaps. Compare equivalent periods against the starting baseline and agreed service objectives, and calculate legitimate-sender pass rates separately from unknown-source traffic.
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, forwarding, or a sender configuration error. An unknown source stays unclassified until its owner and message path are investigated. 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: Messages passing DMARC, receiver-reported dispositions, and resolved issues
- Risk evidence: Unknown sources, open exceptions, and client decisions
The receiver-reported dispositions defined in RFC 9990 describe policy handling for reported traffic. They do not measure inbox placement or prove that every rejected message was unauthorized. Aggregate reports arrive after a reporting period, so define the service-level agreement (SLA) response clock from report receipt or alert creation.
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. Verify that the applicable DMARC TXT record resolves, only one DMARC policy record exists at that DNS name, aggregate reports still reach the approved destination, and policy tags match the agreed posture. Check inherited policies for subdomains as well. Then verify SPF lookup health against the 10-term DNS lookup limit, including nested includes, and check 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; 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. RFC 9989 makes the pct tag historic, so the example omits it. Remove legacy pct tags through change approval and stage enforcement by approved domains or subdomains instead of relying on percentage sampling. The p=quarantine policy requests handling of DMARC failures; receiving systems still make the delivery decision. A renewal audit is also a good point to remove obsolete reporting addresses and confirm that third-party authorization for aggregate reports still works.
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, including forwarding paths used by the client. Record the visible From domain, SPF-authenticated domain, DKIM signing domain, result, and owner. DMARC passes when at least one successful SPF or DKIM check has the domain match required by the policy. For p=reject, confirm working DKIM so delivery does not depend solely on SPF. 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 DMARC because neither authentication path passes with the required domain match, 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. 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. Reaching p=reject does not remove ongoing work such as sender changes, DKIM key rotation, DNS drift, and incident triage. 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. 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 DMARC reporting and email authentication platform. Its multi-tenant MSP dashboard keeps client organizations separate, while client reports provide domain coverage and authentication results for the renewal pack. Use those reports to identify issues for the client meeting and attach agreed actions to tickets. Keep approval history and client-specific exceptions in the runbook.
- 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.
Record the meeting's decisions and assign each follow-up action before closing it. 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 (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. 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 a verified reporting baseline.
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.
Plan offboarding when the client does not renew
A decision to move to self-management or another MSP needs a documented handoff. A published DMARC policy stays in DNS after the contract ends, but reporting destinations and hosted SPF dependencies still need an active owner. Agree the transition date and receiving technical contact before cancelling access.
- Export the domain inventory, approved senders, policy and DNS change history, open exceptions, and agreed report history to a client-approved location.
- Transfer the rua reporting destination and any required external reporting authorization. Verify that the receiving owner gets aggregate reports before removing the old destination.
- Replace or transfer hosted DMARC and SPF dependencies before the subscription ends, then verify DNS and test legitimate mail. Keep the approved enforcement policy unless the client authorizes a change.
- Record client acceptance, revoke access on the agreed date, and apply the contracted retention and deletion schedule to report data.
Do not reset p=reject to p=none simply because the service ends. If the client declines continued monitoring, document who owns future sender changes and the accepted loss of reporting visibility.
Frequently asked questions
Start around 120 days before contract expiry, or earlier if the notice deadline or procurement process requires it. Record the non-renewal deadline separately so the client can decide before an automatic renewal takes effect. Leave time to reconcile domains, investigate source changes, assign exceptions, and agree the next-term scope.
Use one accountable service owner. Technical engineers can own validation and the account manager can own the meeting, but one person should track completion, chase client dependencies, and close the record.
Include the domain inventory, active senders, policy history, authentication results, material incidents, resolved work, unknown sources, open exceptions, client decisions, and proposed next-term actions. Record reporting dates and collection gaps, then compare equivalent periods with the agreed baseline and scope.
Review the ongoing work required by the client's sending estate. Sender changes and DNS drift still need monitoring and response after p=reject. Renew for a defined service scope, or transfer those responsibilities to a named client owner through a documented handoff.
Give each issue a disposition: remediate before renewal, add it to the new scope, accept it for a fixed period, or close it as no longer relevant. Record the owner, due date, temporary control, and client approval.
No. A dashboard supplies current and historical evidence. The runbook adds contract scope, decision history, named ownership, client dependencies, exception handling, approvals, and the operational reset for the next service term.
