# DMARC QBR reporting

> Use a repeatable DMARC QBR reporting workflow to turn aggregate-report evidence into client decisions, owners, exceptions, and follow-up.

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](https://www.rfc-editor.org/info/rfc9990/) provide grouped receiver observations that make this review possible.

## Quick takeaways

- Review the same evidence set for every client, but do not apply one policy target to every domain.
- Keep observed report facts separate from the MSP's recommendation and the client's approval.
- Assign an owner and due date to every accepted action, exception, and unanswered sender question.
- Treat new sources and sustained failures as investigation prompts, not proof of a legitimate sender or root cause.
- Use the next QBR to confirm whether the action register changed the evidence, rather than reporting activity alone.

## 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](https://www.rfc-editor.org/info/rfc9990/) defines aggregate reporting as XML receiver feedback for a policy domain and observed policy configuration. Use the separate [DMARC aggregate report format guide](/learning/dmarc-aggregate-report-format) 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.

```yaml
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](https://www.rfc-editor.org/info/rfc9989/). If the portfolio still needs a baseline inventory, use the [MSP email-security assessment guide](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client) before treating a QBR as the first discovery exercise.

![DMARC QBR reporting flow that separates receiver observations, service recommendations, client decisions, and the dated action register.](/images/editorial/dmarc-qbr-reporting/dmarc-qbr-reporting-workflow.png "3200x1800")

*Source: Original deterministic workflow visual based on the [RFC 9990 aggregate-reporting model](https://www.rfc-editor.org/info/rfc9990/). [Open the full-size workflow visual](/images/editorial/dmarc-qbr-reporting/dmarc-qbr-reporting-workflow.png).*

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](/learning/dmarc-report-analyzer-open-source).

### 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](https://docs.palisade.email/guides/fixing-authentication-issues/) 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](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=dmarc-qbr-reporting)

For a broader service design and portfolio context, visit [Palisade for managed service providers](/for-managed-service-providers).

## Sources and further reading

- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/info/rfc9990/)
- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/info/rfc9989/)
- [Palisade documentation: fixing authentication issues](https://docs.palisade.email/guides/fixing-authentication-issues/)

## Frequently asked questions

### What should a DMARC QBR report contain?

A DMARC QBR report should contain the review period, policy domain, grouped aggregate-report observations, the MSP's recommendation, client decisions, owners, due dates, and exceptions. Keep the evidence separate from the recommendation so the client can see what was observed and what still requires approval.

### Should every client have the same DMARC QBR score?

No. A shared report structure is useful, but a single score can hide different sender inventories, business constraints, and policy states. Use comparable evidence fields and decision records, then set client-specific priorities with the client approver.

### Can aggregate reports prove that a sender is legitimate?

No. Aggregate reports show grouped receiver observations about message sources and authentication outcomes. They can identify a source that needs investigation, but sender ownership and business authorization require evidence from the client or the sending service.

### When should an MSP escalate a QBR finding?

Escalate when an unfamiliar source has meaningful volume, an authentication failure recurs on a critical sending path, or a proposed policy change could affect legitimate mail. Bring the report evidence, relevant change history, and a clearly defined client decision to the escalation.

### Does Palisade change DNS or DMARC policy during a QBR?

No. Palisade can analyze DMARC aggregate-report data and prioritize authentication remediation work, but a human must review evidence and approve any DNS, sender, or policy change. The client remains responsible for authorizing changes to its environment.