DMARC Enforcement Migration Playbook

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the policy layer that ties SPF and DKIM together — it tells receivers what to do when a message claims to be from your domain but doesn't pass authentication, and reports back so you can monitor abuse. The enforcement values are none (monitor only), quarantine (send to spam), and reject (refuse outright). Most senders publish p=none and never migrate up — leaving themselves exposed to spoofing. This playbook covers the staged migration to enforcement, the AcelleMail-side audits, and the gotchas that catch operators on first migration.

The 2024 Gmail + Yahoo bulk-sender rules made DMARC mandatory for any sender doing > 5,000 messages/day to consumer mailboxes — p=none is the minimum acceptable, but p=quarantine or p=reject is the goal. Reject is also a strict requirement for BIMI logo display in Gmail Inbox.

Phase 1 — Publish DMARC at p=none with reporting#

Start with the monitoring-only policy:

TXT  _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-forensic@example.com; aspf=r; adkim=r; pct=100"

The components:

• v=DMARC1 — version (mandatory).
• p=none — policy: do nothing, just report.
• rua= — aggregate report mailbox (daily summaries from receivers).
• ruf= — forensic report mailbox (per-message failure reports; less common).
• aspf=r, adkim=r — relaxed alignment (allow subdomain alignment).
• pct=100 — apply policy to 100 % of mail (for p=none this doesn't matter; relevant for staged rollout in phase 3).

Configure receivers to deliver RUA reports. Gmail and Yahoo are conservative — they only send aggregate reports (RUA), not per-message forensics (RUF). Microsoft delivers RUF in some cases.

Wait 7-30 days. Receivers send daily aggregate XML reports. Process them.

Phase 2 — Ingest + audit aggregate reports#

The XML format is verbose; processing tools:

• dmarcian (dmarcian.com) — paid SaaS with dashboard, $20-100/month for medium senders.
• Postmark DMARC Digests — free, weekly email summaries.
• Self-hosted — parsedmarc (Python) ingests XML, stores in Elasticsearch or PostgreSQL.

What to look for in 7-30 days of reports:

For each sending source listed in the reports:
  - Is it authorized? (Yes/No)
  - SPF authentication: PASS/FAIL/temperror
  - DKIM authentication: PASS/FAIL
  - SPF alignment: aligned / not-aligned
  - DKIM alignment: aligned / not-aligned

Common findings:

The "unauthorized source" finding is the critical one. Common legitimate causes:

• A SaaS tool you forgot about (Salesforce, HubSpot) sending as your domain without proper auth
• Forwarding (auto-forward from your domain to gmail breaks SPF; mail still authenticates via DKIM though)

Investigate and resolve before going to phase 3.

Phase 3 — Migrate to p=quarantine (with pct=)#

Once aggregate reports show 95 %+ of authorized traffic aligning, migrate to enforcement gradually with pct:

T+0 days:  p=quarantine; pct=10
T+7 days:  p=quarantine; pct=25  (if reports still clean)
T+14 days: p=quarantine; pct=50
T+21 days: p=quarantine; pct=75
T+28 days: p=quarantine; pct=100

The pct field tells receivers to apply the policy to only that percentage of unauthenticated messages. Lets you stage the impact gradually — at pct=10, 10 % of spoofed traffic goes to spam; the other 90 % is treated as p=none (monitor only). If a report surge reveals a missed legitimate source, you can roll back without 100 % of legitimate mail being affected.

Watch every aggregate report during this phase. Any new "unauthorized but legitimate" source needs to be added to SPF or DKIM before going to higher pct.

Phase 4 — Migrate to p=reject#

Once p=quarantine; pct=100 has been clean for 14+ days:

T+0:  p=quarantine; pct=100  →  p=reject; pct=10
T+7:  p=reject; pct=25
T+14: p=reject; pct=50
T+21: p=reject; pct=75
T+28: p=reject; pct=100

p=reject is the strongest enforcement — receivers refuse outright, not even quarantine. This unlocks BIMI logo display in Gmail.

AcelleMail-side audits#

Aligned mail from AcelleMail requires:

1. SPF aligned: AcelleMail's Return-Path must use a domain whose SPF authorizes the sending IP, AND that domain must align with the From: header. Per app/Model/SendingDomain.php, AcelleMail's Return-Path is configurable; ensure it matches the sending domain.
2. DKIM aligned: AcelleMail's DKIM signing domain (d= tag in the DKIM-Signature header) must match the From: header domain.

Run a test:

# Send to mail-tester.com or check-auth@verifier.port25.com
# Check the reply — both SPF and DKIM should report aligned + pass.

If alignment fails, the most-common cause is AcelleMail signing with a different d= than the customer's From: domain — happens in shared-domain configurations. Configure each customer's SendingDomain to use their own DKIM signing domain.

Rollback path#

If migration breaks legitimate mail:

# Immediate rollback to monitor-only
TXT  _dmarc.example.com  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Wait 24-48 hours for receivers to re-cache. Then investigate aggregate reports for the missed-alignment source, fix authentication, and restart phase 3.

Subdomain DMARC#

A common gotcha: _dmarc.example.com covers example.com and unspecified subdomains. Specific subdomains have their own policy:

• _dmarc.mail.example.com — applies to mail.example.com only.
• If _dmarc.mail.example.com doesn't exist, receivers fall back to _dmarc.example.com's sp= (subdomain policy) value if present, otherwise to the parent's p= value.

For multi-tenant AcelleMail with customer subdomains, decide policy per subdomain. Most operators publish _dmarc.example.com with p=reject; sp=reject; to apply enforcement uniformly.

BIMI bonus — once on p=reject#

BIMI (Brand Indicators for Message Identification) lets you display your logo in Gmail's inbox view. Requires:

• DMARC at p=quarantine or p=reject with pct=100.
• A trademarked logo + Verified Mark Certificate (VMC) from a CA — typically $1,000-1,500/year (DigiCert or Entrust).
• A BIMI DNS record pointing at the SVG logo location.

The cost is significant; the visual differentiation in Gmail mobile is meaningful for B2C brands. See BIMI with VMC cost walkthrough.

Related reading#

• SPF Record Deep Dive — DMARC depends on SPF
• DKIM Key Rotation Playbook — DMARC depends on DKIM
• Complete DNS Setup for Email Sending — first-time setup
• BIMI with VMC Cost Walkthrough — bonus for p=reject
• Sender Reputation Monitoring Stack — DMARC reports as one signal

FAQ#

How long does the full migration take?#

8-12 weeks of staged rollout from p=none to p=reject; pct=100. Don't rush — the value of DMARC is preventing legitimate mail from going to spam due to spoofing. Migration that breaks legitimate mail is worse than no migration.

What about forwarding (auto-forward from my domain to gmail)?#

Auto-forwarding breaks SPF (the forwarder rewrites the envelope sender). DKIM survives forwarding. With aligned DKIM, DMARC still passes. As long as your messages have aligned DKIM, forwarding doesn't trigger DMARC failures.

Can I skip aggregate reports?#

You can, but you're flying blind. Aggregate reports are how you discover unauthorized sources before enforcement breaks them. Always ingest at least the first 30 days.

What's the difference between aggregate (RUA) and forensic (RUF)?#

RUA: daily XML summary of all auth results per sending source. Sent by all major receivers.

RUF: per-message detailed failure report (includes original message snippet). Privacy-sensitive; Gmail + Yahoo + most don't send these.

DMARC + AcelleMail multi-tenant considerations#

For multi-tenant AcelleMail (one host serving many customers' sending domains), each customer publishes their own DMARC record. The host operator's responsibility:

• Ensure each customer's SendingDomain has aligned DKIM — AcelleMail's per-domain DKIM signing handles this if configured.
• Ensure each customer's From: aligns with their Return-Path — see the alignment section in the SPF article.
• Provide each customer guidance on publishing DMARC — at minimum p=none with a rua= mailbox they monitor.
• Prepare aggregate-report ingestion infrastructure — at least one operator-side dmarcian or parsedmarc instance that customers can opt their reports into. Otherwise customers receive opaque XML files they don't know how to read.

Without this, customers will publish DMARC without monitoring it, miss alignment failures, and eventually file a support ticket asking why their mail is going to spam — when the answer is buried in DMARC reports they never opened.

Migration timeline summary#

Don't rush. Each step gives receivers cache time to learn the new policy. Skipping accelerates breakage.