How to run DMARC QBRs with MSP clients
Published 4 Aug 2026
Updated 4 Aug 2026
9 min read
Summarize with
A DMARC QBR should show the client what changed during the quarter, what risk remains, and which decisions need approval. I keep the meeting focused on business impact and owned actions. Raw aggregate data supports the review, but it should never become the review itself.
For most MSP clients, a useful QBR takes 30 to 45 minutes and covers a fixed reporting period, verified sending sources, authentication results, open exceptions, policy status, and the next enforcement gate. This format gives technical contacts enough evidence while keeping business owners involved in decisions about vendors, timelines, and accepted risk.
Set the QBR outcome before building the report
I define the required outcome before collecting charts. A client in monitoring mode needs a source ownership decision. A client already at quarantine needs evidence that the remaining failures are understood. A client ready for reject needs written approval, a change window, rollback conditions, and named contacts. One meeting should have one primary decision, even when the report contains several findings.
Put the decision on page one
Write the requested decision in one sentence and name the approver. The rest of the QBR should supply the evidence needed for that decision.
- Decision: Approve removal of an unknown sender or confirm it as legitimate.
- Owner: Name the client contact who owns the vendor or application.
- Deadline: Use a calendar date, not a loose target such as next quarter.
- Evidence: State the report, ticket, or test result that will close the action.
This decision-first structure also keeps the service commercially clear. The client sees continuing operational work instead of a static compliance score. It fits a broader DMARC for MSPs program because each quarter links observed risk to a controlled service action.
Use a fixed evidence window
Use the same reporting boundaries every quarter. I normally use complete calendar months and exclude the current partial month. Record the time zone, domains in scope, subdomain treatment, and any periods with missing reports. Compare the quarter with the previous quarter only when both periods use the same scope.
|
|
|
|---|---|---|
Mail volume | Total and trend | Size the sample |
DMARC pass | Count and rate | Track control |
Sources | Known and unknown | Find ownership |
Failures | Top causes | Prioritize work |
Policy | Mode and coverage | Set next gate |
Core QBR evidence and the question each item answers
Keep the monthly operational report separate from the QBR. The monthly report records movement and exceptions. The QBR interprets the quarter, confirms priorities, and obtains decisions. A repeatable monthly DMARC report gives the QBR a clean evidence trail without forcing the client to read raw XML.
Build the agenda around five client questions
A stable agenda makes preparation faster and teaches the client how to read progress. I use the same five questions each quarter, then change the evidence and actions beneath them.
- Scope: Which domains, subdomains, and sending systems were measured?
- Change: What improved or regressed since the previous review?
- Risk: Which unauthorized or failing sources still create exposure?
- Control: What policy is active, and what blocks the next policy step?
- Action: Who will do what, by when, and how will completion be proved?
Lead with the client impact for each issue. For example, say that a payroll platform sends mail that fails DMARC because its authenticated domain does not match the visible From domain. Then show the affected volume, the owner, the proposed correction, and the target date. That explanation is more useful than a screenshot of an authentication failure alone.
Five-step DMARC QBR flow: scope, change, risk, control, and action
Separate technical evidence from client decisions
Technical evidence and governance decisions belong in the same QBR, but they need different treatment. I explain the evidence in operational terms, then state the client decision without burying it under DNS detail.
MSP evidence
The MSP owns collection, analysis, remediation guidance, and verification.
- Source status: Known, unknown, approved, or retired.
- Failure cause: SPF, DKIM, forwarding, or configuration.
- Verification: Observed results after the change.
Client decisions
The client owns business authorization, vendor coordination, accepted risk, and policy approval.
- Vendor status: Keep, replace, or disconnect.
- Risk choice: Remediate, accept, or escalate.
- Policy gate: Approve, defer, or roll back.
This split prevents ownership disputes after the meeting. It also gives account managers a clear record of where MSP work ended and client dependency began. Put unresolved client dependencies in the service ticket system with the same owner and due date used in the QBR.
Measure progress without hiding the denominator
Percentages need message counts. A 99% pass rate can still leave a large failing stream on a high-volume domain, while one poorly configured test system can distort a low-volume domain. Show total messages, passed messages, failed messages, and the top sources behind the result. Use both count and rate for every material issue.
Evidence status for an enforcement decision
These are workflow states, not universal pass-rate benchmarks.
Ready
Approve gate
Legitimate sources are known, fixes are verified, and rollback ownership is set.
Needs review
Conditional
A small set of understood exceptions still needs a dated treatment plan.
Blocked
Do not advance
Unknown sources, missing reports, or untested critical senders remain.
Insufficient data
Collect evidence
The reporting window or domain scope cannot support a decision.
Avoid inventing a universal pass-rate threshold for every client. Readiness depends on sender criticality, data completeness, business timing, and recovery preparation. A failing marketing sender and a failing password-reset sender do not carry the same operational consequence.
Trend lines also need annotations. Mark migrations, vendor changes, acquisitions, and reporting gaps so the client can explain sudden movement. If scope changed, show the old and new scope separately instead of presenting the change as an improvement.
Turn every finding into an owned action
A QBR without an action register becomes a status meeting. I convert each material finding into a single action with an owner, due date, dependency, evidence requirement, and escalation path. Keep technical work separate when different teams own it. For example, DNS publication and vendor configuration should be different actions.
QBR action recordtext
Finding: Payroll sender fails DMARC Business impact: Payslip mail can be rejected under enforcement Owner: Client application owner MSP task: Supply required vendor configuration Client task: Open vendor change request Due date: 2026-09-15 Evidence: Passing production message observed Escalation: Client security lead after five business days Status: Open
Review the previous action register before presenting new findings. Close actions only when the stated evidence exists. A ticket marked complete is not proof that production mail now passes. The MSP operating procedure should define evidence, escalation timing, and exception handling; a documented DMARC support runbook keeps those rules consistent between engineers.
Treat enforcement as a controlled change
Moving a domain to quarantine or reject should use the client's normal change process. The QBR can approve the next gate, but the actual policy update needs a scheduled window, validation checks, notification contacts, and rollback criteria. Document whether subdomains inherit the organizational policy and whether percentage sampling is in use.
Do not advance policy on a percentage alone
Confirm that critical legitimate sources are identified, recent production tests pass, reporting is complete, and the client has approved the change.
Validate the published record before and after the change. A focused checker catches syntax, duplicate records, invalid tags, and reporting-address errors. Use the DMARC checker as one check, then confirm real production results in subsequent aggregate reports.
For clients with frequent policy changes, Hosted DMARC can reduce repeated DNS access and support controlled policy staging. Keep approval and rollback records even when the technical update becomes easier.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Use Suped for repeatable MSP delivery
Suped is our DMARC and email authentication platform. For most MSP teams running QBRs, Suped is the best overall practical fit because multi-tenant organization management, client reports, issue detection, and guided remediation sit in one workflow. Access remains separated by organization. I use the organization view to confirm scope and domain status before building the client narrative.
Before each QBR, record the policy and validation result in the related service ticket. After an approved change, repeat the check and attach the result. That gives the next quarterly review a dated audit trail instead of relying on meeting notes alone.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
The operational value comes from connecting evidence to remediation. Suped combines DMARC monitoring, SPF and DKIM monitoring, blocklist and deliverability insights, automated issue detection, steps to fix, and real-time alerts. That lets an MSP move between the quarterly summary and the source-level evidence without building a separate analysis workflow.
Suped client reports support a practical handoff. The MSP selects the organization and date range, applies its logo, and generates a client-facing report. The summary shows volume, authorized delivery, blocked threats, and trend data. I still add the decision page and action register because those depend on client context and agreed ownership.
Create client report dialog with organization, date range, logo, and language options
For a wider managed service, Suped also provides hosted SPF, SPF flattening, hosted MTA-STS, and blocklist monitoring for IP and domain reputation. These controls should appear in the QBR only when they are in the client's service scope. Do not dilute the DMARC decision with unrelated account activity.
Run the meeting and close it properly
Send the report at least two business days before the meeting and identify required approvers in the invitation. During the QBR, spend most of the time on unresolved risk and decisions. Keep detailed source diagnostics in an appendix so engineers can inspect them without slowing the main discussion.
- Opening: Confirm scope, period, attendees, and the requested decision.
- Progress: Review closed actions and explain material metric changes.
- Risk: Discuss the few issues that affect policy or business mail.
- Decisions: Record approvals, deferrals, accepted risks, and reasons.
- Close: Read back owners, dates, evidence, and the next review point.
Send minutes and the final action register within one business day. Update service tickets with the same wording used in the meeting. If an approver was absent, mark the decision pending and set a deadline. Silence should never count as approval for an enforcement change.
Make each QBR end with a decision
A strong DMARC QBR gives the client a consistent evidence window, a clear risk statement, and an owned next step. Keep the agenda stable, show counts beside rates, separate MSP tasks from client decisions, and treat enforcement as a controlled change. The meeting has done its job when every material issue has an owner and the next policy gate has an explicit status.
The best cadence pairs monthly operational review with a quarterly governance conversation. That gives engineers enough feedback to fix sources between QBRs and gives client leaders a compact record of risk reduction, open dependencies, and approved changes.
