DMARC Record Guide: Syntax, Policy Tradeoffs, RUA / RUF, and SPF / DKIM Alignment

What DMARC Is, and Why It Exists

SPF and DKIM on their own are useful but raw: a passing SPF check confirms the sending IP was on the approved list, and a passing DKIM check confirms the message has not been tampered with, but neither makes a statement to the receiver about what to do when other people send mail claiming to be from your domain. DMARC closes that gap. It is the policy protocol — a single DNS TXT record you publish at _dmarc.yourdomain.com — that ties SPF and DKIM together, asks receivers to require the authenticated domain to align with the visible From: domain, and tells receivers exactly what to do when both checks fail.

A canonical DMARC record looks like this:

_dmarc.yourdomain.com  TXT
  v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

This says: deliver mail for yourdomain.com according to RFC 7489, treat any message that fails SPF AND DKIM alignment as failing DMARC, route it to the spam folder (p=quarantine), apply the policy to 100% of failing mail (pct=100), and send daily aggregate reports to dmarc@yourdomain.com (rua=mailto:…). Every tag the record carries controls a different piece of that pipeline; the rest of this guide walks through each one.

The Full RFC 7489 Tag Reference

DMARC records are a semicolon-separated list of tag=value pairs. Every RFC 7489-compliant record starts with v=DMARC1 and then carries one or more of the tags below. Two tags are required ( v= and p=); every other tag is optional but production senders typically carry rua=, pct=, and most senders will eventually want sp= (subdomain policy) and adkim= / aspf= (alignment modes).

v=DMARC1 (required, version identifier). Every DMARC record must start with this exact literal v=DMARC1 — anything else, including a future version with a different number, fails parsing immediately and the record is ignored. Receivers will treat malformed, missing, or unknown-version records as a DMARC PermError, equivalent to a record that is not present at all.

p=none / quarantine / reject (required). The domain policy. The p= tag tells receivers what to do with mail that authenticates against neither SPF nor DKIM. none = monitor only, take no enforcement action. quarantine = send to spam folder or quarantine queue. reject = refuse at SMTP and bounce the message back to the sender. p applies to messages using the apex domain (yourdomain.com) in the visible From: header.

sp= (subdomain policy). The sp= tag specifies the policy for messages using a subdomain (anything.mail.yourdomain.com, bounces.yourdomain.com, *.yourdomain.com) in the visible From: header. sp defaults to the value of p if not specified. Most production senders escalate p=quarantine at the apex while keeping sp=reject on subdomains — the subdomain policy catches abuse faster because transactional and marketing subdomain streams tend to break alignment first.

rua= (aggregate reporting URI). The rua= tag points at the URI (almost always a mailto: URI) where receivers send aggregate reports — XML files delivered daily that list every IP that sent mail claiming to be from your domain, the count from each IP, and the per-IP SPF and DKIM pass / fail rate. Without rua you are flying blind on what is sending on your behalf and what is failing alignment.

ruf= (forensic reporting URI). The ruf= tag subscribes you to forensic reports — per-message failure copies that include the original headers and (often) a redacted body. Forensic reports are honoured by a subset of receivers (most prominently Microsoft); Gmail and Yahoo have largely deprecated them in favour of the aggregate feed. Most production senders leave ruf empty once the policy is at p=reject, but on the ramp to p=reject the per-message forensic copies are the fastest signal when a real legitimate source is getting caught in the new policy.

pct= (percentage applied). The pct= tag is the ramp knob. It tells receivers what percentage of failing mail the policy applies to. pct=100 means full enforcement. pct=10 means 10% of failing mail gets the policy, 90% is treated as if the policy was p=none. The safe ramp is p=quarantine at pct=10 for a week, then pct=50, then pct=100, then escalate to p=reject at the same steps.

adkim= / aspf= (alignment modes). Both tags control whether alignment is relaxed (the default) or strict. adkim=r = relaxed DKIM alignment (the d= domain must match the visible From: domain OR be a parent of it). adkim=s = strict DKIM alignment (the d= domain must match the visible From: domain exactly). The same applies to aspf for SPF and the MAIL FROM envelope domain. Relaxed alignment is the right starting mode for most senders; strict is appropriate only when you control every sending source and can guarantee exact-domain alignment on both arms.

fo= (failure reporting options). The fo= tag controls when a forensic (ruf) report is generated. fo=0 (default) generates a ruf report only when neither SPF nor DKIM alignment passes. fo=1 sends a ruf report if either SPF or DKIM fails alignment. fo=d generates a ruf report only on DKIM signature failure (regardless of alignment). fo=s generates a ruf report only on SPF failure (regardless of alignment). Most production senders leave fo=0 as the default; raising to fo=1 is a useful diagnostic setting when you are still investigating which arm is breaking alignment.

ri= (report interval). The ri= tag suggests an interval in seconds between aggregate reports. Most receivers ignore the tag and deliver daily; setting ri=86400 documents the intended daily cadence but is not enforced.

The Policy Tradeoff Ladder: p=none → quarantine → reject

DMARC has three policy levels. Each level is a stricter escalation: more aggressive enforcement on messages that fail authentication, more visible response to spoofers, more risk to any legitimate source that is not aligned with your brand domain. The safe ramp is to start at the lowest level and only escalate once your RUA reports confirm that every legitimate sender is aligned.

p=none — monitor mode. Receivers still evaluate SPF and DKIM alignment, still send RUA aggregate reports to your rua URI, and still record the pass / fail verdict on every received message — but they take no enforcement action even when both arms fail. p=none is the only safe starting policy. It lets you read the RUA feed for 2–4 weeks, identify every legitimate sender (every ESP you actually use, every transactional platform, every SMTP relay), and confirm that every one of them is aligned with your brand domain. Without p=none, you cannot collect the dataset that tells you what is sending on your behalf.

p=quarantine — partial enforcement. Receivers still deliver RUA reports, but messages that fail alignment are routed to the spam folder (or the receiver's quarantine queue) instead of the inbox. The recipient still receives the message; it is just visually demoted from Primary to Junk on a missed-alignment failure. p=quarantine is the right operational policy for most production senders — it stops spoofers from hitting the inbox while still allowing conversation with the receiver when a misconfigured legitimate source occasionally lands a message in spam instead of rejection. The natural next step is p=quarantine with pct=100.

p=reject — full enforcement. Receivers refuse any message that fails alignment at SMTP — the message never reaches the recipient, the sender receives a 5.x.x bounce code, and the receiver's spam pipeline is never even invoked. p=reject is the most aggressive policy and the strongest protection against spoofers impersonating your domain; it is also the riskiest for any legitimate sender you did not configure correctly. Production senders only switch to p=reject after a long stable ramp at p=quarantine and after audit-confirming that every legitimate sender is fully aligned.

The practical ramp. Two-week intervals work for most production senders. Start at p=none with a rua= address — read RUA reports and confirm every legitimate sender is aligned. Move to p=quarantine at pct=10 for one week — read RUA reports and confirm no legitimate source is failing alignment. Move to pct=50 for one more week, then pct=100. Switch to p=reject at pct=10 for a week, then pct=100. Every step is gated on the data, never on the calendar.

How SPF / DKIM Alignment Actually Works

Alignment is the requirement that the domain authenticated by SPF or DKIM matches — or is a parent of — the visible From: domain. It is the single most important rule DMARC enforces and the most common point of failure for new senders.

SPF alignment. SPF checks the envelope sender (the domain in the MAIL FROM address used during the SMTP handshake). For SPF alignment to hold under relaxed mode (the default aspf=r), the SPF domain (the envelope-sender domain, or any parent of it) must match the visible From: domain, or be a parent of it. MAIL FROM: bounces.mail.yourdomain.com aligned with From: alerts@mail.yourdomain.com is a relaxed-mode pass; the same pair under aspf=s (strict) is a fail because bounces.mail.yourdomain.com is not the same string as mail.yourdomain.com.

DKIM alignment. DKIM signs the message with a domain in the d= field of the DKIM-Signature header. For DKIM alignment to hold under relaxed mode (the default adkim=r), the d= domain must match the visible From: domain OR be a parent of it. DKIM alignment is more resilient than SPF alignment in production because the d= domain does not change between intermediaries — it stays attached to the message through forwarding, scanning, and list-manager rewrites.

The dual-pass requirement. DMARC passes when EITHER SPF alignment passes OR DKIM alignment passes. Receivers do not require both — but production senders want both to pass for the resilience: SPF can break on forwarding, and DKIM signatures occasionally fail on intermediate rewrites. Configure both arms against the same brand subdomain (and ensure the envelope-sender domain and the d= signing domain both align with the visible From: domain) so a single-arm failure does not break DMARC.

When both arms fail alignment, DMARC has nothing left to qualify the message and the p policy applies: none = monitor, quarantine = spam folder, reject = reject at SMTP. The pct percentage applies the policy only to a fraction of failing messages.

Subdomain Policy (sp=) — When Apex and Subdomain Need Different Rules

Most production brands send from both the apex (mail.yourdomain.com, hello@yourdomain.com) and several subdomains (mail.marketing.yourdomain.com from the marketing ESP, notifications.app.yourdomain.com from the transactional platform, bounces.yourdomain.com as a return-path). Each of those streams can have a different alignment posture, and a single misaligned stream can cascade into the same failure on the apex if the policy is uniform.

sp lets you set a different policy for subdomains while the apex policy is on a different ramp. p=quarantine; sp=reject is a common pattern: the apex is on a softer policy while high-volume, high-abuse-risk subdomains (shared ESP pools, marketing platforms, signup confirmation flows) are immediately on a strict policy. If a single subdomain starts misbehaving, that sp layer fights the abuse while the apex is still being ramped.

Asymmetric sp= containment. A sp=reject policy on the subdomain without a matching SPF / DKIM enforcement at the apex is the most subtle failure: messages from your subdomain that fail alignment will be rejected by receivers, but spoofers impersonating your apex will still be treated as p=none unless p is set at least at quarantine. The right pattern is to ramp both p and sp together over the same window — sp can lead p by a step but should never lag.

RUA Aggregate Reports: What They Tell You

rua reports are the most useful single diagnostic you can collect on a production domain. They are XML files delivered daily by Google, Microsoft, Yahoo, and most smaller mailbox providers to the mailto: URI in your DMARC record. Each report describes:

• The reporting receiver. Which provider the report came from, the org name, and the contact email.
• The reporting window. The exact start and end timestamps (UTC) for the slice of traffic in the report.
• Per-source-IP row entries with counts. Each <row> in the report lists a single IP that sent mail claiming to be from your domain and the message count from that IP.
• Per-IP SPF and DKIM pass / fail rates. Each row's policy_evaluated block lists the disposition (what the receiver did — none, quarantine, reject), the SPF result (pass / fail), and the DKIM result (pass / fail) for the messages from that IP. Read this to spot the dominant failure mode — every IP failing SPF while DKIM passes points to one upstream cause; every IP failing DKIM while SPF passes points to another.
• The authentication results breakdown. Whether alignment was strict or relaxed, and which identifier domain was used.

The cleanest diagnostic use of RUA is to look at the top IPs by message count and audit each one against your sending-platform inventory. An IP that is in your SPF record and is signing with a subdomain of your brand domain should produce a 100% DMARC pass rate. Anything else is a configuration deviation on the platform that owns that IP. The free DMARC checker resolves the published record against RFC 7489 syntax; the RUA feed is the empirical read of what the largest receivers are seeing against that record.

RUF Forensic Reports: When They Help, When They Hurt

ruf reports are per-message forensic copies delivered in real time when a specific authentication failure occurs. They contain the original Authentication-Results block, the original message headers, and (usually) a redacted body. The diagnostic signal is the richest available signal in email — you see exactly what the recipient saw.

The tradeoffs are non-trivial. ruf is honoured only by a subset of receivers (most prominently Microsoft). Gmail and Yahoo drop most ruf traffic. The ruf dataset is per-message — a noisy sender with a thousand failures per hour can produce a ruf inbox that is functionally unusable. And ruf reports carry the original message body — a privacy concern for any recipient-content-bearing mail flow that you would have to redline before forwarding to a third-party parser.

When to enable ruf. Enable ruf during the ramp to p=reject — the per-message forensic copies make it possible to see exactly which legitimate sender is failing alignment and get ahead of any production regression before the reject policy bounces the message entirely. Once the policy is at p=reject pct=100 and stable, most production senders remove ruf and rely on rua alone — the per-message volume is no longer worth the inbox cost.

Common DMARC Failure Modes (Transactional and Cold Outreach)

Every DMARC failure mode experienced by a production sender clusters into a small set of root causes. The dominant pattern in your RUA reports usually points at the underlying cause quickly — read the per-IP pass / fail verdict for the largest senders first.

Vendor-subdomain mismatch (umbrella failure). The single most common DMARC failure mode. Your mail server is in your SPF record, but the envelope sender uses a vendor subdomain (for example bnc.mailvendor.net — bounces) and your ESP signs DKIM with its own domain (d=mailvendor.net ) — neither aligns with your brand domain in the visible From: header. Fix: configure your sending platform to use a subdomain of your brand domain for both the envelope sender and the DKIM signing domain, then re-publish the SPF record to include the new subdomain. After the change expect a 2–4-week monitoring window before intensifying the DMARC policy.

SPF PermError: too many DNS lookups. SPF evaluation is capped at 10 DNS lookups; every include:, a:, mx:, exists:, and redirect= mechanism counts as one (and nested includes count too). The fix is to flatten the record into ip4: / ip6: ranges for sources you control, remove redundant includes, and consolidate sources that share an ESP under the same provider. SPF must resolve cleanly for DMARC to align, and a flat record is the fastest path back to a passing check.

DKIM signing with the wrong domain. Your sending platform signs outbound mail with d=mailvendor.net while the visible From: is From: hello@yourdomain.com — DKIM passes the signature verification on the mailvendor.net key but fails DMARC alignment because the d= domain does not match the visible From: domain. Fix: configure the platform to sign with a subdomain of your brand (d=mail.yourdomain.com), publish the matching DKIM public key at selector._domainkey.mail.yourdomain.com, and re-verify the signature with a real outbound email.

Two DMARC records at _dmarc. RFC 7489 specifies exactly one DMARC record per domain. If a second TXT record has been published at _dmarc.yourdomain.com — by accident, by a platform that pre-published one before you did, or by a Previous admin — receivers treat the result as a DMARC PermError and DMARC silently fails on every reception attempt. The fix is identical to the SPF duplicate case: merge into a single record and delete the duplicate.

p=none on a high-abuse surface. A marketing subdomain that is at sp=none will accumulate alignment failures from misconfigured acquisitions, partner-domain bounces, or signup-confirmation flows that spoof the brand domain on the recipient side. The fix is to set sp=quarantine or sp=reject on the subdomain while the apex stays at the lower policy.

Cold-outreach subdomain drift. A cold-outreach team sending from a dedicated subdomain (reach.yourdomain.com ) on a shared ESP pool that signs DKIM with d=espdomain.com fails DMARC alignment because the d= domain is neither the apex nor a parent of the visible From: domain. Fix: configure the cold-outreach platform to sign with d=reach.yourdomain.com (a subdomain of the brand apex), publish the matching DKIM key, and re-verify alignment with the free DMARC checker. Pair with sp=reject on reach so a misalignment bounces immediately rather than accumulating in the spam folder over weeks.

Transactional bounce handler misconfiguration. A bounce handler set up on bounces.yourdomain.com that is not in your SPF record and is not signing DKIM will appear in your RUA reports as a top sender with 100% DMARC failure. Fix: include the bounce IP in SPF (or the ESP's include: chain if the bounce is sent via the ESP), and add a DKIM signing entry that uses d=bounces.yourdomain.com on the bounce handler's outbound flow.

Rapid Triage Checklist

When a DMARC regression lands — in a misaligned RUA report, in a Gmail 5.7.x bounce, in a yellow SNDS colour shift, in a sudden drop in inbox placement on a transactional or cold-outreach stream — walk this list. Each entry pairs a symptom with the concrete next action.

• If your DMARC record is missing entirely. Publish a record at _dmarc.yourdomain.com with the smallest acceptable starting policy:v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100. This is the minimum configuration that satisfies the 2024 Gmail + Yahoo bulk-sender bar and lets the receivers begin delivering the daily RUA aggregate feed.
• If your RUA shows SPF and DKIM alignment both failing. Walk your sending-platform inventory. The most common root cause is the vendor-subdomain mismatch — your ESP is signing with its own domain rather than a subdomain of your brand. Fix: configure each platform to sign with a subdomain of your brand, include the sending IP / ESP's include: chain in your SPF record, and re-verify with the free DMARC checker before escalating the policy.
• If your RUA shows SPF failing while DKIM passes. The envelope-sender domain does not align with the visible From: domain, but the DKIM d= domain does. Fix the MAIL FROM configuration on each sending platform so the envelope sender uses a subdomain of your brand; alternatively, lean on the DKIM alignment until the MAIL FROM can be reconfigured.
• If your RUA shows DKIM failing while SPF passes. The DKIM signature is missing or the d= domain does not align with the visible From: domain. Fix: configure the platform to sign with a subdomain of your brand and publish the matching DKIM public key. Re-verify against the free DMARC checker plus a real outbound email; read the DKIM-Signature header to confirm the d= and s= fields.
• If you have published two DMARC records at _dmarc. RFC 7489 specifies exactly one DMARC record per domain — receivers treat two as a PermError. Merge your p / sp / rua / ruf / pct / adkim / aspf / fo tags into a single record and delete the duplicate.
• If p=quarantine is catching legitimate mail. Set pct=10 (apply to 10% of failing mail), identify the legitimate source in the RUA forensic feed, fix the alignment on that source, then ramp back to pct=100 once two weeks of clean data show no further failures.
• If you want to move from p=none to p=reject. Ramp p=quarantine pct=10 → pct=50 → pct=100 over 2–4 weeks; switch to p=reject at pct=10 → pct=50 → pct=100 over the same window. Every step is gated on the RUA feed showing alignment above 95% for every legitimate sender.
• If you send to Gmail / Yahoo at scale (~5,000+ / day). The 2024 bulk-sender bar requires DMARC at p=none or stricter, plus SPF, plus DKIM, plus a working List-Unsubscribe-Post: List-Unsubscribe=One-Click header (RFC 8058), plus a spam complaint rate below 0.1% in Postmaster Tools. A missing or permissive DMARC at this volume triggers throttling at Gmail and rejection at Yahoo. The full checklist is in the Gmail Bulk Sender Requirements guide.

Related Tools and Guides

• Free DMARC checker →
• SPF / DKIM / DMARC checker →
• DNS health check →
• Email header analyzer →
• SPF, DKIM, and DMARC Guide →
• Email Authentication Guide →
• How to Fix DMARC Failing →
• Gmail Bulk Sender Requirements →
• Email Reputation Guide →