DMARC QBR reporting: an MSP decision workflow

By Taylor TabusaAugust 12, 202610 min read

Ask AI to explain

In brief

DMARC QBR reporting gives MSPs a reusable way to turn aggregate-report evidence into client decisions, owners, exceptions, and dated follow-up.

DMARC QBR reporting: an MSP decision workflow

DMARC QBR reporting should turn each client's aggregate-report evidence into a dated decision record. Separate what receiving systems observed from the MSP's interpretation, then document the client decision, owner, next action, evidence boundary, and review date. This gives an MSP a repeatable way to keep authentication exposure visible across tenants without treating report counts as proof of sender authorization, delivery, or business impact.

At a glance

Quick takeaways

DMARC aggregate reports record grouped receiver observations for a policy domain and reporting period.
An unfamiliar source needs investigation. It is not proof that a sender is legitimate or unauthorized.
A QBR finding should separate observed evidence, MSP recommendation, client decision, owner, and review date.
The client approves business risk and changes to DNS, sender configuration, or the DMARC policy.
A public DMARC record check confirms a published record, but does not prove the production sending path or a receiver's private handling decision.
Quarterly review rules in this article are a Palisade operating framework, not an RFC requirement.

Operating context and ownership

This workflow is for MSPs, MSSPs, and multi-tenant IT teams that must convert recurring DMARC evidence into client decisions. RFC 9990 defines DMARC aggregate reporting as XML feedback sent by reporting receivers for a policy domain. A report includes metadata, published policy information, grouped source observations, policy evaluation, and SPF or DKIM results.

Aggregate reports show what a reporting receiver observed. They do not establish that a client authorized a sender, explain every root cause, reveal a receiver's private reputation decision, or prove inbox placement. An MSP recommendation is therefore different from protocol evidence.

Set the operating boundary before the first QBR:

The MSP service lead prepares the evidence packet, maintains the action register, and coordinates follow-up.
The authentication specialist interprets reported authentication and alignment outcomes.
The client approver accepts business risk and authorizes scoped changes.
The DNS host publishes approved DNS records.
The sender owner controls the relevant ESP, application, CRM, or mail service configuration.
The receiving mailbox provider makes its own handling decision for each message.

The Palisade MSP workflow provides broader context for operating DMARC across client portfolios. A QBR does not replace an incident process. Use the agreed client escalation path when a suspected mail-flow issue needs immediate action.

Keep these states distinct in every finding:

Observed fact: a receiver reported a source, message count, policy disposition, or authentication result.
MSP interpretation: the service team identified an investigation, remediation, or risk-acceptance question.
Client decision: an authorized role approved, deferred, declined, or accepted an exception.
Follow-up: a named owner has a specific action, evidence requirement, and review date.

Flow showing how DMARC aggregate observations become an MSP recommendation, client decision, assigned owner, and dated review — Source: Palisade.

Evidence to collect

Create one evidence packet and action register for each client. Fix the reporting window before comparing periods, and retain the original reports or a traceable export. A quarterly summary without supporting evidence is difficult to defend when a client asks why a recommendation was made.

Normalize these fields before the QBR:

Client and policy-domain scope, including excluded domains.
Reporting window, report sources, and known collection or coverage gaps.
Source identifier, observed message volume, and policy disposition.
header_from domain plus reported SPF and DKIM outcomes.
Sender changes since the prior review, including new or retired sources.
Unresolved failure clusters and the evidence boundary for each.
Current DMARC policy, policy-change proposal, and client decision.
Owner, escalation route, evidence links, next action, and next review date.

RFC 9989 defines the DMARC policy and alignment model. Use its terminology precisely. A reported alignment failure supports an investigation, but it is not a root-cause diagnosis until the MSP has evidence from the sender configuration or a real delivered message from the exact production path.

Use a portable quarterly evidence record in a PSA, ticket system, controlled spreadsheet, or client report:

YAMLyaml

client: "Example Manufacturing"
domain: "yourdomain.com"
evidence:
  reporting_window: "2026-04-01 through 2026-06-30"
  aggregate_reports: "Retained export reference"
  coverage_boundary: "Reports received for the stated window. Receiver-private decisions are unavailable."
  finding: "DKIM did not align with header_from for an observed source."
owner: "Client marketing operations"
next_action: "Identify the sending platform and provide a delivered-message sample."
review_on: "2026-07-31"

This is a Palisade-authored operating artifact, not a required RFC format or threshold. A DMARC record check can inspect the public DMARC record for one domain. It cannot show which sources sent during the quarter, establish sender authorization, monitor later changes, or expose a receiver's private delivery decision.

DMARC QBR record anatomy showing evidence, interpretation, client decision, owner, next action, and review date — Source: Palisade.

How to run the workflow

1. Prepare the client evidence packet

Owner: MSP service lead. Input: the agreed reporting window, normalized aggregate-report data, current DMARC policy, and prior action register. Output: a client-specific evidence packet with stated coverage boundaries.

Group observations by source and authentication outcome. Highlight changes that need a decision, such as a repeated new source, recurring alignment failure, overdue exception, or completed remediation that lacks later message evidence. Do not rank risk by report volume alone. A low-volume payroll or billing sender may need faster review than a high-volume marketing path.

2. Classify material items before the QBR

Owner: authentication specialist. Input: the evidence packet and available client sender inventory. Output: a classification and evidence boundary for each material item.

Use states such as known and healthy, known but unresolved, unknown, evidence-limited, and accepted exception. Record why an item has that state and what evidence would change it.

For example, aggregate data can establish repeated failed DKIM alignment. It cannot establish that the source is a legitimate client application. The next action may require client confirmation, sender-owner investigation, or a delivered-message sample after configuration work.

Platform selection and client review are separate decisions. The DMARC report analyzer comparison can help assess report-analysis options, but an analyzer does not assign a client owner or approve an exception.

3. Write decision-ready findings

Owner: MSP service lead. Input: classified evidence and technical interpretation. Output: a QBR action record that a client can approve or challenge.

Each finding should state the observed evidence, interpretation, practical consequence, recommendation, client decision required, owner, evidence link, and review date. "Fix DMARC" does not establish ownership or a completion test.

A useful finding can state that receivers repeatedly observed an unaligned DKIM result for a source, that the client must identify the sending platform, and that the sender owner must provide a new delivered-message sample after any proposed repair. The client may approve investigation, approve scoped remediation, accept a time-limited exception, or identify the source as unauthorized.

4. Record exceptions as client decisions

Owner: client approver, documented by the MSP. Input: a finding that cannot close before the QBR. Output: an exception with a review path.

An exception should name the affected domain or source, decision-maker, accepted risk, evidence gap, review date, and condition for reconsideration. A deferred item without a date is backlog, not an exception register.

Do not add an unfamiliar source to SPF or relax the DMARC policy to close a QBR action. Confirm the source, its business purpose, and its authentication path before proposing a change.

5. Validate completed actions on the same sending path

Owner: sender owner, reviewed by the MSP. Input: the approved remediation and a real message from the affected production path. Output: evidence that distinguishes published DNS from actual message authentication.

Validate applicable changes at four layers:

DNS: query the authoritative DNS server and at least one public resolver for the published record.
Vendor: confirm the sender's current authentication status in the sending platform.
Message: inspect a real delivered message from the exact production path and its Authentication-Results header.
DMARC: review later aggregate-report data after it accumulates.

A green vendor indicator is not proof that a delivered message used the configured signing or return path. A passing DNS lookup is not proof of future receiver handling. For a focused discussion of whether failure reports add useful operational evidence, see Are DMARC failure reports worth the trouble?.

Exceptions and escalation

Use an escalation path when the QBR cannot resolve the item through normal ownership:

Unknown source with material volume or business impact: ask the client to identify the sender and business purpose.
Known sender with failed alignment: assign the sender owner to investigate configuration and provide same-path message evidence.
Missing DNS authority or approval: move the item to blocked status and name the client decision-maker.
Business-critical sender without a safe test window: record a time-limited exception, rollback condition, and next review.
Receiver decision that conflicts with public evidence: use the mailbox provider's dashboard or message evidence. Aggregate reports cannot explain a private receiver decision.

The MSP maintains the evidence and makes the recommendation. The client owns authorization and risk acceptance. The DNS host, sender, and mailbox provider each control parts of the outcome that an MSP cannot unilaterally change.

Reporting and success measures

Use the QBR to compare evidence and decisions, not to present a universal security score. The quarterly client artifact can include:

Domains reviewed and reporting-window coverage.
New, resolved, and unresolved sources.
Repeated SPF or DKIM alignment outcomes that need investigation.
Current policy state and any approved or deferred policy decision.
Exceptions by owner, age, review date, and decision status.
Actions completed with DNS, vendor, message, and later report evidence.

Keep report counts attached to their context. A lower failure count may reflect fewer messages, incomplete report coverage, a changed sender mix, or a completed repair. Describe the observation and the decision it requires.

Reporting depth can also define the service commitment. The MSP DMARC management pricing guide explains how recurring reporting and remediation work affect a managed-service model.

Turn each client's DMARC evidence into an owned next step

A completed QBR record exposes the recurring work that remains across the portfolio: identifying sources, investigating authentication or alignment issues, prioritizing remediation, and following up with the right owner. Palisade is agentic DMARC software. Its DMARC Agent analyzes aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets.

Start with Palisade

Palisade does not authorize client senders, make DNS or DMARC-policy changes, replace client approval, or guarantee delivery or inbox placement.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

What should a DMARC QBR report include?

A DMARC QBR report should include the policy-domain scope, reporting window, evidence coverage, observed sources, authentication and alignment outcomes, current policy state, unresolved exceptions, named owners, client decisions, next actions, and review dates. Keep observed facts separate from MSP recommendations.

Can DMARC aggregate reports prove that a sender is authorized?

No. Aggregate reports can show that a reporting receiver observed a source and its reported authentication outcome. Client confirmation, sender configuration evidence, and a real message from the production path are needed to establish whether a source is legitimate.

Who approves a DMARC policy change in an MSP QBR?

The client approver should authorize a DMARC policy change because the client owns the business risk. The MSP can prepare evidence, recommend a scoped change, document a rollback condition, and validate the result after approval.

How should an MSP handle an unknown DMARC source?

Record the source as unknown, preserve the report evidence, and assign client confirmation as the next action. Do not add it to SPF, authorize it, or change the DMARC policy until the client and sender owner establish its purpose and authentication path.

Does a passing DMARC record check validate the QBR finding?

No. A public record check validates the currently published DMARC record. It does not show which senders used the domain during the reporting window, whether they authenticated on the production path, or how a receiving mailbox provider handled a message.

How often should MSPs run DMARC QBRs?

Quarterly is a useful operating cadence for a managed portfolio, but it is a service-framework choice rather than an RFC requirement. Review urgent authentication failures and mail-flow incidents through the active escalation process instead of waiting for the next QBR.

Turn DMARC findings into a managed fix path

Start in Palisade.

Get started

Share this article

Written by

Taylor Tabusa

Co-Founder & Head of Business Development, Palisade

Taylor Tabusa is the co-founder and Head of Business Development at Palisade, helping managed service providers turn email security into a practical, valuable service.