How DMARC Works

The DMARC record

A DMARC record is a single DNS TXT record published at _dmarc. in front of your domain. Example:

_dmarc.example.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100; adkim=r; aspf=r; sp=reject; fo=1"

Field reference:

• v=DMARC1 — required version tag. Must be first.
• p=reject — policy for the apex domain. Values: none, quarantine, or reject.
• rua=mailto:dmarc@example.com — where to send aggregate reports. Can be multiple addresses, comma-separated.
• ruf=mailto:forensic@example.com — where to send forensic reports (rarely supported in 2026).
• pct=100 — what percentage of failing messages the policy applies to. pct=10 means 10% get the policy, 90% are delivered normally — useful for gradual rollouts.
• adkim=r — DKIM alignment mode. r = relaxed, s = strict.
• aspf=r — SPF alignment mode. r = relaxed, s = strict.
• sp=reject — subdomain policy. If unset, subdomains inherit p=.
• fo=1 — forensic options. 1 = generate report if any check fails; d = DKIM-only; s = SPF-only.

The three policy modes

The progression none → quarantine → reject is the only safe path. Skipping to reject without first running discovery and quarantine reliably breaks legitimate mail flows.

How alignment works in detail

Alignment is the connection between authentication and the visible sender. DMARC requires that at least one of SPF or DKIM authenticated successfully AND the authenticated domain aligns with the From: header's domain.

SPF alignment

SPF authenticates the envelope sender (MAIL FROM). DMARC alignment checks whether the MAIL FROM domain matches the From: domain.

• Relaxed (default): Organizational domain match. From: news@example.com with MAIL FROM: bounces@mail.example.com aligns — both belong to example.com.
• Strict: Exact match. From: news@example.com with MAIL FROM: bounces@mail.example.com does NOT align — the domains differ exactly.

DKIM alignment

DKIM authenticates the signing domain (the d= tag in the signature). DMARC alignment checks whether d= matches the From: domain.

• Relaxed (default): From: news@example.com aligns with DKIM d=mail.example.com — both belong to example.com.
• Strict: From: news@example.com only aligns with DKIM d=example.com exactly.

DMARC passes if any one DKIM signature aligns. A message can carry multiple signatures; only one needs to align.

Aggregate reports: what you actually get

Major receivers (Google, Microsoft, Yahoo, Comcast, etc.) send aggregate XML reports daily to the address in rua=. A report contains, for each combination of source IP and DMARC result:

• The sending IP and (often) reverse DNS name.
• Number of messages from that source in the reporting window.
• SPF result and the domain SPF checked.
• DKIM result and the signing domain.
• Whether each result aligned with the From: domain.
• The DMARC policy that was applied (none / quarantine / reject).

Reading raw aggregate XML is tedious. Use a parser: dmarcian, EasyDMARC, Postmark DMARC Monitoring, or a self-hosted tool like parsedmarc. They aggregate across days, group by sender, and flag failures. The reports are the single most valuable artifact during DMARC rollout — they show you every server in the world claiming to send as your domain.

The pct= ramp

The pct= tag lets you apply a policy probabilistically. p=reject; pct=10 means 10% of failing messages get rejected; the other 90% get the next-less-strict policy (so the next-less-strict for reject is quarantine). This is useful for cautious operators who want to test reject behavior on a small slice of traffic.

The pattern: pct=10 → pct=25 → pct=50 → pct=100 over several weeks. The aggregate reports show you whether legitimate mail is being affected at each step before you ramp further.

The relationship to subdomains

By default, subdomains inherit the apex domain's DMARC policy. If example.com has p=reject, then marketing.example.com also enforces reject. The sp= tag overrides this — p=reject; sp=none; enforces reject on the apex but only monitors subdomains.

This is critical during transitions. A common pattern: apex stays at reject for brand-spoof protection, but a new transactional subdomain runs sp=none while being set up. Once that subdomain's senders are aligned, drop sp= and let it inherit reject from the apex.

Common rollout mistakes

• Going straight to p=reject. Guaranteed to break some legitimate sender you forgot about.
• Not setting up rua=. Without aggregate reports, you have no visibility. You will not know which senders are failing.
• Setting rua= to a domain you do not control. Reports may be sent to a mailbox that does not exist; you silently lose all reporting.
• Using strict alignment when relaxed would do. Strict alignment is fragile. Use it only when you have a specific reason (e.g., domain takeover scenarios in high-security environments).
• Ignoring forwarded mail in reports. Aggregate reports will always show some failures from forwarded mail (because SPF fails on forwarding). This is expected. Focus on failures that are not forwarders.
• Forgetting subdomains. If you only protect the apex, attackers spoof subdomains. Use sp= to control subdomain behavior explicitly.

The Gmail/Yahoo 2024 minimum

The February 2024 sender requirements from Gmail and Yahoo mandate v=DMARC1; p=none at minimum for any sender exceeding 5,000 daily messages. The requirement is the existence of the record, not a strict policy — Google and Yahoo accept p=none as compliant. The deeper purpose is to ensure aggregate reports flow to the sender's specified rua= address so the sender has visibility into their own mail stream. A more restrictive policy (quarantine or reject) provides actual protection against spoofing but is not a Gmail/Yahoo requirement.

Frequently Asked Questions

What does p=none actually do?

p=none tells receivers to deliver the message normally even if SPF and DKIM both fail or do not align — but to send you aggregate reports about what happened. It is a monitoring-only mode. Use it for the first 2-4 weeks of any DMARC rollout to discover all legitimate senders before tightening to quarantine or reject. p=none is not a security setting; it does not protect your domain from being spoofed.

What is the difference between aggregate and forensic reports?

Aggregate reports (rua=) are XML summaries sent daily by receivers that show counts of messages per sending IP and their authentication results. They contain no message content — just statistics. Forensic reports (ruf=) are per-failure copies of the failing message itself, including headers and sometimes body. Forensic reports were widely supported initially but most major receivers stopped sending them due to privacy concerns. In 2026, aggregate reports are the practical reporting channel; do not rely on forensic.

What is the difference between relaxed and strict alignment?

Relaxed alignment (the default) matches at the Organizational Domain level — From: news@mail.example.com aligns with DKIM signed by example.com or any subdomain. Strict alignment requires an exact match — From: news@mail.example.com only aligns with DKIM signed by mail.example.com exactly. Most organizations use relaxed because it accommodates transactional providers signing with a subdomain. Strict is reserved for security-sensitive domains that never delegate signing.

How long should I stay at p=none before moving to quarantine?

Minimum 2 weeks, typically 4-6 weeks. The goal of p=none is to identify every legitimate source that sends mail from your domain. Aggregate reports arrive once per day per major receiver, so you need multiple weeks of reports to capture monthly invoices, quarterly newsletters, and other low-frequency senders. Move to quarantine only after consecutive weeks of clean reports — no legitimate senders failing alignment.

What is the sp= tag for?

sp= sets the subdomain policy separately from the main p= policy. For example, p=reject; sp=quarantine; means the apex domain enforces reject but all subdomains use quarantine. Without sp=, subdomains inherit the apex policy. The sp= tag is useful when you want strict protection on your main brand domain but a softer policy on transactional subdomains during rollout.