DMARC QBR reporting

DMARC QBR reporting is a quarterly operating review for an MSP that turns each client's aggregate-report evidence into decisions, owners, and dated follow-up. It is not a presentation of raw DMARC counts. Use a consistent record to separate observed sender and alignment data from recommendations, then obtain client approval before changing DNS, sender configuration, or DMARC policy. RFC 9990 aggregate reports provide grouped receiver observations that make this review possible.

Operating context and ownership

This workflow is for an MSP that owns the recurring review process while each client retains authority over its sending services, DNS changes, and acceptable business risk. The service lead prepares the record, an email-authentication specialist validates report evidence, and the client approver accepts, defers, or declines changes. A sender owner, such as marketing, IT, or an application vendor, supplies context for a source that is not already known.

The reporting standard does not require a quarterly business review, a score, or a policy target. Those are Palisade operating recommendations for making a multi-client service review repeatable. The technical evidence is narrower: RFC 9990 defines aggregate reporting as XML receiver feedback for a policy domain and observed policy configuration. Use the separate DMARC aggregate report format guide when a team needs to validate fields or ingestion before relying on a dashboard view.

Evidence to collect

For each client, freeze the review period and normalize only the evidence needed for a decision. Retain the original reports and identify the reporter, policy domain, reporting interval, source, message count, disposition, header_from, SPF and DKIM outcomes, and any known sender owner. The report can show grouped receiver observations; it cannot, by itself, authorize an unfamiliar service or prove why an individual message was delivered or rejected.

client: "Northwind Manufacturing"
review_period: "2026-04-01 through 2026-06-30"
domain: "example.invalid"
evidence:
  new_source: "192.0.2.44"
  observed_dmarc_result: "fail"
  message_count: 186
owner: "Client marketing operations"
recommendation: "Confirm the sending platform and its aligned DKIM domain."
client_decision: "pending"
next_action: "Open a sender-ownership investigation."
review_on: "2026-07-31"

The record above is a reusable example, not a DMARC record or a threshold prescribed by the standard. A technical reviewer should also compare material cases with the current policy and alignment rules in RFC 9989. If the portfolio still needs a baseline inventory, use the MSP email-security assessment guide before treating a QBR as the first discovery exercise.

Use the action register as the boundary between review and change. It preserves what the report observed, what the MSP recommended, what the client approved, and what must be checked next quarter.

How to run the workflow

1. Build one evidence packet per client

The service lead fixes the review window, pulls the normalized report evidence, and attaches the prior action register. Group sources by their observed identity and outcome, not merely by message volume. A new source, a recurring alignment failure, or a policy change can enter the packet, but each needs context before it becomes a remediation request.

2. Classify every material item before the client meeting

The authentication specialist labels each item as known and healthy, known but unresolved, unknown, or evidence-limited. Record why it belongs in that category and what would change the classification. For example, a report row can establish a repeated outcome, while a sender owner or delivered-message header may be needed to determine the legitimate sending path. Teams evaluating their reporting stack can compare that evidence model with an open-source DMARC report analyzer.

3. Turn findings into client decisions

For every unresolved item, write a short recommendation, the evidence behind it, the client decision needed, an accountable owner, and a due date. Give the client distinct choices such as investigate a sender, approve a scoped configuration change, accept an exception for a defined period, or close a disproved issue. Do not present an MSP recommendation as a client approval.

4. Record exceptions with an expiry and a return path

An exception is useful only when it names the affected domain or sender, the risk accepted, the approving client role, its expiry, and the evidence needed to revisit it. An indefinite exception becomes an unreviewed backlog item. If a client cannot identify a sender, keep the item open as unknown rather than adding it to SPF or relaxing DMARC policy.

5. Close the QBR with a dated action register

The service lead sends the completed record to the client and opens work only for approved actions. Preserve the evidence snapshot, decision, owner, and due date together. At the next review, compare the new reporting period with this register to determine whether the observed condition changed, whether an exception expired, and whether a pending owner still needs a decision.

Exceptions and escalation

Escalate immediately when the evidence points to an unfamiliar source with meaningful volume, a recurring authentication failure on a business-critical path, or a policy change that could affect legitimate mail. The escalation owner is the client approver for risk and change authorization, with the sender owner supplying service-specific facts. The MSP's role is to present the evidence, explain the possible authentication consequence, and propose a reversible next investigation where possible.

Do not infer compromise from an unknown IP alone, and do not treat a single receiver's aggregate report as a complete traffic inventory. Ask for corroborating sender records, change history, and where needed a delivered-message header. A client decision to defer work should be recorded as an exception with a review date, not silently removed from the report.

Reporting and success measures

A useful QBR report has three views: portfolio triage for the MSP, a client decision record, and a follow-up register. Portfolio triage helps schedule specialist time. The client record explains what was observed and what requires approval. The action register tracks whether a named owner resolved, deferred, or disproved the item.

Measure the workflow by evidence quality and closed decisions, not by a universal pass-rate target. Useful measures include the number of material items with an owner, the number of open exceptions with a future review date, and whether prior approved actions have a subsequent evidence check. These are service-management measures, not DMARC requirements or guarantees of delivery.

Make portfolio reviews actionable

If recurring report review leaves your team with a growing set of sender and alignment questions, Palisade's DMARC Agent can analyze aggregate-report data, identify sending sources and authentication issues, and create prioritized remediation tickets. It does not make DNS or DMARC-policy changes, decide that a sender is authorized, replace client approval, or guarantee delivery.

Start with Palisade

For a broader service design and portfolio context, visit Palisade for managed service providers.