DMARC Policy: From Monitoring to Full Enforcement

What DMARC Does

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS-published policy that tells receiving mail servers how to handle messages that fail SPF and DKIM authentication. Without DMARC, each receiver makes its own decision about unauthenticated mail -- most will deliver it anyway. DMARC gives domain owners explicit control: monitor, quarantine, or reject messages that fail verification. It also provides a reporting mechanism so you can see exactly who is sending email as your domain, whether authorized or not.

DMARC Record Syntax

A DMARC record is a DNS TXT record published at _dmarc.example.com. Here is a fully specified example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-ag@example.com; ruf=mailto:dmarc-fo@example.com; adkim=r; aspf=r; pct=100;

Each tag controls a specific behavior:

• v=DMARC1 -- Required. Identifies the record as DMARC version 1. Must be the first tag.
• p -- Required. The policy applied to messages that fail authentication. Values: none (monitor only), quarantine (deliver to spam), reject (drop the message).
• sp -- Subdomain policy. Overrides p for mail sent from subdomains. If omitted, subdomains inherit the parent domain's policy. Set this explicitly if your subdomains have different sending patterns.
• rua -- Aggregate report destination. A mailto: URI where receivers send daily XML summaries of authentication results. You can specify multiple addresses separated by commas.
• ruf -- Forensic report destination. A mailto: URI for per-message failure reports. Most large receivers do not send these (see limitations below).
• adkim -- DKIM alignment mode. r for relaxed (subdomain of the "From" domain matches), s for strict (exact domain match required). Default is r.
• aspf -- SPF alignment mode. Same values as adkim. Default is r.
• pct -- Percentage of failing messages the policy applies to, from 1 to 100. Messages outside the percentage fall back to the next lower policy (reject falls back to quarantine, quarantine falls back to none). Default is 100.

Step-by-Step Deployment

Phase 1: Monitor with p=none

Start by publishing a record that collects data without affecting mail delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Leave this in place for at least 2-4 weeks. During this period, aggregate reports will reveal every source sending mail as your domain -- your primary mail server, marketing platforms, transactional email services, CRM tools, helpdesk software, and any unauthorized senders. Use a DMARC report analyzer (free options include URIports, Postmark's DMARC tool, or dmarcian's free tier) to parse the XML into readable dashboards.

While monitoring, fix every legitimate sender:

• Add missing senders to your SPF record.
• Enable DKIM signing for every authorized service.
• Verify that each sender's "From" domain aligns with your authenticated domain.

Phase 2: Quarantine with pct Ramp-Up

Once all legitimate senders pass authentication consistently, begin enforcement gradually. Move to p=quarantine with a low percentage:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;

This sends only 10% of failing messages to spam. The remaining 90% are treated as p=none. Monitor reports closely for any legitimate mail that gets quarantined. If nothing breaks after a week, increase the percentage in stages: 25, 50, 75, then 100.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com;

Hold at full quarantine for at least 1-2 weeks before moving to reject.

Phase 3: Full Reject Enforcement

With confidence that all legitimate mail passes authentication, deploy the final policy:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r;

You can optionally ramp pct here as well (starting at pct=10 for reject while the remainder falls back to quarantine), though most organizations that have done a thorough quarantine phase move directly to full reject. Continue monitoring aggregate reports permanently to catch configuration drift, new senders, or infrastructure changes.

Aggregate Reporting (rua)

Aggregate reports are XML files sent daily (sometimes more frequently) by receiving mail servers. They contain:

• The reporting organization and the date range covered.
• Your published DMARC policy at the time of evaluation.
• Per-source-IP rows showing: the sending IP, the count of messages, the policy applied, SPF and DKIM authentication results, and SPF and DKIM alignment results.

These reports do not contain message content or subject lines. They are statistical summaries. The XML schema (https://dmarc.org/dmarc-xml/0.1) is verbose and not human-friendly -- processing them manually is impractical at scale. Use a dedicated DMARC reporting service or an open-source parser to aggregate the data across all receivers.

To receive reports for a domain that differs from the rua address domain, publish a DNS authorization record. For example, if your DMARC record sends reports to reports@monitoring.com, the domain monitoring.com must publish:

example.com._report._dmarc.monitoring.com. IN TXT "v=DMARC1"

Without this record, receivers will silently discard the reports.

Forensic Reporting (ruf)

Forensic reports (also called failure reports) contain details about individual messages that failed authentication, including headers and sometimes redacted body content. In theory, they provide the granularity needed to diagnose specific failures.

In practice, forensic reporting has significant limitations:

• Most major receivers do not send them. Gmail, Yahoo, and Microsoft either ignore the ruf tag entirely or send heavily redacted versions.
• Privacy concerns. Forensic reports can contain PII from message headers (sender names, recipient addresses, subject lines). GDPR and similar regulations make some receivers unwilling to transmit this data.
• Volume. For domains receiving spoofed traffic, forensic reports can generate enormous volumes of data that overwhelm inboxes.

If you configure ruf, use a dedicated mailbox and expect inconsistent coverage. Do not rely on forensic reports as your primary feedback mechanism -- aggregate reports are far more reliable.

Alignment Modes: Relaxed vs. Strict

Alignment determines how strictly the authenticated domain must match the "From" header domain.

Relaxed alignment (adkim=r, aspf=r): The authenticated domain (SPF's MAIL FROM or DKIM's d= tag) must share the same organizational domain as the "From" header. For example, if the "From" address is user@example.com, a DKIM signature with d=mail.example.com passes relaxed alignment because both share example.com.

Strict alignment (adkim=s, aspf=s): The authenticated domain must exactly match the "From" header domain. Using the same example, d=mail.example.com would fail strict alignment against From: user@example.com.

Recommendation: Start with relaxed alignment. It accommodates legitimate subdomain sending patterns (e.g., your transactional service signing as notifications.example.com). Only tighten to strict if you have a specific security requirement and have confirmed that every sender signs with the exact "From" domain.

Common Issues and Fixes

Stuck on p=none Indefinitely

This is the most common DMARC failure mode. Organizations publish a monitoring record, never analyze the reports, and leave p=none in place for years. This provides zero spoofing protection. Fix: set a deadline. Commit to a 90-day timeline from p=none to p=reject. Assign an owner. Use a DMARC reporting tool to automate analysis. With Google and Microsoft now requiring DMARC, staying at p=none also risks deliverability problems.

Missing rua Tag

A DMARC record without rua provides no visibility. You are flying blind -- enforcing a policy (or monitoring) without any feedback on what is passing or failing. Always include an rua address, even if you use a third-party service to receive the reports.

Subdomain Policy Gaps

Without an explicit sp tag, subdomains inherit the parent domain's policy. This seems safe but creates problems in two directions. If your parent is p=reject but a subdomain legitimately sends mail with different infrastructure, that mail gets rejected. Conversely, if you forget that unused subdomains inherit p=none from a monitoring-phase parent, attackers can spoof anything.example.com freely. Audit your subdomains explicitly and set sp to match your security posture.

Third-Party Sender Failures After Enforcement

A newly onboarded SaaS tool starts sending email as your domain but was never added to SPF or configured for DKIM. After moving to p=reject, those messages are silently dropped. Fix: establish a process where any new vendor that sends email on your behalf must be cleared through DNS configuration before going live. Monitor aggregate reports continuously, not just during initial deployment.

DNS Propagation Delays

DMARC record changes are subject to DNS TTL caching. If you need to roll back a policy change quickly, set a low TTL (300-600 seconds) on your _dmarc TXT record before making changes. Once your policy is stable at p=reject, you can raise the TTL.