Is a DMARC checker enough for an MSP audit?

No. A checker can document the published record, but it cannot establish every sending source, client authorization, or the authentication result of a specific delivered message.

Should an MSP add every source in an aggregate report to SPF?

No. A report observation needs client or sender-owner confirmation first. An unknown source belongs in an exception record until the responsible party can classify it.

Who approves a DMARC policy change?

The client owner or an explicitly delegated approver should approve the change. The MSP can supply evidence, a recommendation, and a retest plan.

What closes a DMARC audit finding?

Only a recorded decision and a retest that addresses the original evidence should close it. A DNS change, an approval, or a dashboard status alone does not prove the finding is resolved.

DMARC audit template for MSPs

An MSP DMARC audit should create a per-client decision record, not just a DNS scan. Record the scoped domains, public DMARC/SPF/DKIM evidence, aggregate-report observations, known senders, client confirmation, finding owner, approval state, and retest result. That distinction matters because DMARC validates aligned domain identifiers and publishes a handling preference, but neither a passing lookup nor a report row authorizes a sender or a DNS change.

At a glance

Quick takeaways

Use one worksheet per client and domain scope, with an owner for every open finding.
Keep public DNS, aggregate-report observations, and client authorization as separate fields.
Treat a DMARC checker as evidence of the published record, not proof of every production sender.
Record a recommendation separately from approval and from the post-change retest.
Move completed sender governance into an MSP email sender inventory, rather than reopening the audit for each review.

Operating context and ownership

This template is for the first DMARC-specific assessment of a client portfolio. It narrows the broader client email security assessment to evidence that supports a DMARC remediation decision. It does not replace sender onboarding, policy rollout, or the recurring client review described in DMARC QBR reporting.

The MSP may collect evidence, classify a finding, and recommend a next action. The client decides whether a sender is legitimate and approves business-risk changes. The DNS host publishes records, while a sending provider controls its own signing and return-path configuration. Mail receivers choose their own final handling: RFC 9989 says a receiver can honor a domain owner's requested handling, but is not required to do so. That is why the worksheet records an approval and retest rather than promising a delivery outcome.

Evidence to collect

Use these fields for each scoped domain. They are a Palisade operating framework, not fields required by an RFC.

Scope and ownership: client, domain, business owner, technical approver, DNS change owner, and review date.
Public configuration: observed DMARC record, p value, alignment modes, rua destination, SPF record, and DKIM selectors known from the client or a delivered message.
Observed mail evidence: aggregate-report date range, sending IP or source label, count, SPF/DKIM/DMARC result, and a link or ticket reference for the evidence. RFC 9990 defines the aggregate-report format; it is evidence about receiver observations, not a complete inventory of every sender.
Authorization and finding: client-confirmed, unknown, retired, or disputed sender state; finding severity; the owner who must decide or act; and the recommendation.
Decision and retest: approval status, approved change reference, retest method, result, and the next review date.

Keep the worksheet portable so it can live in a ticket, PSA, or version-controlled runbook. Do not put mailbox content, customer addresses, private keys, or full unredacted message headers in a shared portfolio record.

DMARC audit record anatomy groups scope, technical evidence, authorization, decision, approval, and retest fields so an MSP does not confuse an observation with client approval — Source: Palisade original deterministic operating diagram. The grouping is a reusable operating recommendation, not an RFC-required form. Open the full-size diagram.

YAMLyaml

client: <client-name>
domain: <author-domain>
scope_status: in-review
public_dmarc: <observed TXT record or absent>
report_window: <YYYY-MM-DD through YYYY-MM-DD>
observed_sender: <source label or IP reference>
authorization: client-confirmed | unknown | retired | disputed
finding: <specific evidence-backed gap>
decision_owner: <client approver | sender owner | DNS owner>
recommendation: <proposed action, not an applied change>
approval_status: pending | approved | declined
retest: <DNS, delivered message, or report evidence>
review_on: <YYYY-MM-DD>

DMARC audit flow separates scoped evidence from client authorization, then tracks a recommendation through approval and retest, with unknown senders routed to an exception record — Source: Palisade original deterministic operating diagram informed by RFC 9989 and RFC 9990. It shows an MSP workflow, not a protocol requirement. Open the full-size diagram.

How to run the workflow

1. Set the client and domain boundary

List the domains and subdomains the client wants assessed, then name the business owner, technical approver, and DNS change owner. Record exclusions such as a divested brand or a vendor-managed subdomain. A missing owner is itself a finding because the MSP cannot infer authorization from DNS.

2. Capture public DNS evidence

Use the DMARC checker to record the published DMARC TXT record, policy, and reporting destination. Capture SPF and available DKIM evidence as separate fields. SPF authorizes a domain's use by a client IP during SPF evaluation, subject to the mechanism and lookup rules in RFC 7208; it does not establish that a business owner approved a particular application.

Do not change the record while collecting a baseline. A public lookup cannot reveal every sender, prove which team owns a service, or show the authentication result of a delivered message.

3. Add report and message observations

Where aggregate reports are available, add the reporting period, source, volume, and the reported SPF/DKIM/DMARC results. Mark each source as report-observed, not automatically authorized. For a disputed or business-critical path, request a redacted delivered-message sample and compare the receiver-added authentication evidence with the public record.

RFC 9989 explains that a DMARC pass requires aligned SPF or DKIM, and it also cautions that a pass does not guarantee inbox placement. Treat a failing observation as a finding to investigate, not as proof that the source is malicious or the root cause is known.

4. Ask the client to classify each source

Ask the client or designated system owner whether each observed source is legitimate, retired, unknown, or disputed. Capture the answer and the accountable person. If no one can confirm a source, create an exception rather than silently adding it to SPF or treating it as safe.

This is the multi-client step a simple audit lacks. The same IP or source label can mean different things for two clients, and an MSP should not carry an authorization decision across tenants.

5. Write an evidence-backed recommendation

State the exact gap and proposed action. For example: "The domain publishes p=none; two client-confirmed senders have no recorded aligned DKIM result; collect delivered-message evidence and enable the sender's custom DKIM before proposing a policy change." Keep the policy recommendation separate from any applied DNS value.

For a stronger policy, route the work to a documented safe DMARC policy rollout. The audit provides the decision record; it is not permission to enforce.

6. Record approval and retest evidence

After the authorized owner accepts a change, save the change reference and retest the same evidence layer that produced the finding. Re-query DNS for a record change, inspect a new delivered message for an authentication finding, or review a later report period for an observed-source finding. Record the result, reviewer, and next review date. If the result does not resolve the finding, reopen it with the new evidence instead of marking the audit complete.

Investigate this with your coding agent

Use this only when the worksheet or a report-normalization script lives in a repository. Prepare a redacted fixture with no customer domains, message content, credentials, or private keys.

Agent handoff

Copy the prepared prompt

Give this to a coding agent that can inspect the relevant repository or configuration source of truth.

Problem: The audit worksheet does not consistently require a decision owner, approval status, and same-path retest for every DMARC finding.
Evidence: A redacted worksheet fixture and the repository's existing audit-template schema or report-normalization tests.
Repository scope: Inspect only the version-controlled audit-template, schema, parser, and associated tests.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access client systems, cross tenant boundaries, secrets, production DNS, or active incidents.
Requested output: Identify missing required fields, propose the smallest schema or template diff, include test updates and a rollback note, and list any ambiguous field mapping.
Verification: Run the repository's template or parser tests against the redacted fixture and show the expected validation result.
Stop if: Customer data, credentials, a production mutation, or a client approval is required, or the fixture cannot distinguish observation from authorization.

Human approval required: Review the proposed diff and verification plan before allowing changes. Do not paste secrets, private keys, API tokens, unredacted headers, or customer data.

Exceptions and escalation

Create an exception when a source lacks a confirmed owner, report evidence conflicts with the client inventory, a sender cannot demonstrate aligned authentication, or a client cannot approve a safe test window. Each exception needs the evidence, impact context, requested decision, owner, and review date.

Escalate a business-critical sender to the client approver and sender owner before any policy change. Escalate unclear DNS control to the client relationship owner. The MSP can recommend a hold, a test, or remediation sequencing; it should not authorize a sender or accept residual client risk on the client's behalf.

Reporting and success measures

Keep a client-facing audit summary limited to the scope, confirmed and unknown sources, open findings by owner, approval state, and retest status. Review the shared portfolio queue for overdue exceptions and findings without a decision owner. Do not turn those fields into a universal protection score: they show the state of the audit record, not a guarantee about all mail.

Check the public record before you open a finding

Run the scoped domain through Palisade's DMARC checker to capture the public record used in the worksheet. Start there when the gap is unknown or the published policy needs confirmation.

Check a DMARC record

A public record check cannot identify every production sender, approve a change, inspect private report data, or prove why a specific message reached a mailbox.

Continue recurring sender review across client domains

A completed public lookup and one audit baseline still do not show which production sources later fail alignment, which client adds a new sender, or which portfolio exceptions are overdue. Palisade's DMARC Agent analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and detects when a domain appears ready for the next policy stage. A human reviews the evidence and applies any DNS or policy change.

Start with Palisade

Palisade does not authorize a client sender, change external DNS without human approval, control a receiving mailbox provider, or guarantee delivery.

Evidence