The DMARC Audit Guide for MSPs: Domain Inventory, Sender Remediation, and Client Reporting

Phase 1: Define scope — domain inventory and stakeholder roles

Before touching any DNS records, establish a complete picture of what you're auditing. Most clients underestimate how many domains they actually have.

Domain inventory checklist

• Primary business domain (e.g., company.com)
• Secondary domains: regional variants (.co.uk, .de), brand domains, acquired company domains
• Product or campaign domains
• Subdomains used for email: mail.company.com, billing.company.com, app.company.com
• Parked or inactive domains — these still need DMARC protection to prevent spoofing

For parked domains that don't send email, the correct DMARC approach is to publish a reject policy with no RUA address: v=DMARC1; p=reject;. This blocks spoofing with zero monitoring overhead.

Stakeholder mapping

Identify who in the client organisation can approve DNS changes, who owns the various email-sending platforms, and who needs to receive the audit output. Getting the right contacts upfront prevents the audit from stalling when you need to remediate a sender that belongs to the marketing team's vendor.

Phase 2: DNS baselining — current DMARC, SPF, and DKIM posture

For every domain in scope, record the current state before making any changes. This is your baseline for rollback and for the "before" picture in the client report.

Phase 3: Build a sender catalog

The sender catalog is the core deliverable of the audit phase — a documented list of every service that sends email on behalf of the client's domain. Sources for building it:

• DMARC aggregate reports (after 2–4 weeks of p=none) — the most complete source; shows every IP that sent email claiming the domain
• Stakeholder interviews — ask IT, marketing, sales, and finance what tools they use that send email
• Email header analysis — look at real emails from the client's domain and check the Return-Path and DKIM d= signatures
• SaaS tool inventory — review active software subscriptions for anything with email capabilities

For each sender, document: the service name, sending IP ranges, SPF mechanism (if any), DKIM selector (if any), volume, and alignment status. The alignment status column is what tells you what needs fixing before you can advance policy.

Phase 4: Configure RUA/RUF reporting and data retention

RUA vs RUF

• RUA (aggregate reports) — sent daily or hourly as XML summaries of all DMARC traffic. Primary data source for audit and ongoing monitoring. Safe to enable immediately.
• RUF (forensic/failure reports) — sent per-message when DMARC fails. May contain message headers and sometimes body content. Privacy considerations apply — check local regulations before enabling, particularly for EU clients.

For most MSP audits, RUA alone is sufficient. Configure a dedicated reporting address so reports flow into your DMARC monitoring platform rather than the client's inbox.

Data retention

DMARC aggregate reports have compliance value — they document that email protection was in place on specific dates. Retain at least 12 months of reports. For clients subject to PCI DSS, HIPAA, or similar frameworks, verify the retention period against their specific requirements.

Phase 5: Alignment diagnostics

The key distinction is relaxed vs strict alignment:

• Relaxed alignment (default) — the authenticated domain can be a parent domain of the From: header domain. So mail.company.com passes alignment for company.com.
• Strict alignment — the authenticated domain must exactly match the From: header domain.

For most clients, relaxed alignment is appropriate. Strict alignment (adkim=s; aspf=s;) is worth considering for high-value domains where the tighter control justifies potentially rejecting edge-case legitimate mail.

In aggregate reports, look for the disposition and policy override breakdowns. Sources with consistently high pass rates in relaxed mode but failures in strict mode indicate they're relying on subdomain alignment — a useful signal for senders that might need DKIM configured directly on the From: domain.

Phase 6: Third-party sender remediation

Every sender in the catalog that isn't passing alignment needs to be remediated before you advance beyond p=none. Remediation typically takes one of five forms:

Phase 7: Policy design and safe rollout plan

With all senders remediated, design the policy rollout. Document it before making any changes — this becomes part of the client deliverable.

Recommended rollout cadence:

• Weeks 1–4: p=none, rua= configured, baseline data collection
• Weeks 5–6: p=quarantine; pct=10 — low blast radius, watching for unexpected failures
• Weeks 7–8: p=quarantine; pct=100 — full quarantine, monitoring spam folder carefully
• Weeks 9–10: p=reject; pct=25 — partial rejection, final safety net
• Week 11+: p=reject; pct=100 — full enforcement achieved

This 11-week timeline is conservative. For clients with simple sender environments (e.g., Microsoft 365 only), you can compress the schedule. For clients with complex multi-sender environments, give yourself more time at each stage.

Phase 8: Client-ready reporting and compliance documentation

The audit culminates in a deliverable the client can understand and reference for compliance.

Initial audit report contents

• Domain inventory with pre-audit DMARC posture for each domain
• Risk summary: which domains were vulnerable, what spoofing would have been possible
• Sender catalog: all identified senders, their alignment status, and remediation applied
• Actions taken: DNS changes made, with before/after record values
• Rollout plan: timeline to full enforcement

Ongoing monthly report contents

• Current DMARC policy per domain
• Pass rate trends over the month
• New senders identified (and action taken)
• Threats blocked (volume of rejected/quarantined messages)
• Policy advancement progress toward enforcement target

The monthly report is what justifies the ongoing service fee. Quantified outcomes — "937 spoofing attempts blocked this month" — make the value concrete and provide compliance evidence for clients who need it.

Related reading