It only takes one look at a real DMARC record to realize why people hesitate.
p, sp, pct, rua, ruf, fo, ri, rf...
It's not hard once it clicks. It's just that every tag looks equally important when you're new to it, and DNS is an unforgiving place to experiment.
This is a field guide: what each tag actually does, what tends to go wrong in production, and a few copy/paste-safe starting points.
If the basics of DMARC itself are still fuzzy, start with What is DMARC?. This post assumes the DMARC record already exists in DNS and the question is: "what should it say?"
Here's a record that is intentionally boring: it turns reporting on, doesn't reject anything yet, and avoids the tags that tend to surprise people.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld; fo=1Why this works as a first step:
p=none means "measure first".rua=... means "send aggregate reports" (this is where the value is).fo=1 increases failure reporting sensitivity a bit (useful when trying to spot misalignment or broken DKIM early).From there, the usual path is to watch reports and tighten policy gradually. If a staged rollout is the goal, A (sane) DMARC setup process for busy domains matches how this tends to go in real orgs.
One quick reassurance: A "correct" DMARC record isn't the one with the most tags. It's the one that matches the way mail is actually sent for the domain.
There are more DMARC tags than the ones in this post, but these are the ones that show up in almost every practical setup.
p (policy for the organizational domain)p is the headline policy: what receivers should do when a message fails DMARC for the domain in From:.
p=none = take no enforcement action (still send reports)p=quarantine = treat failing mail as suspicious (often spam/junk)p=reject = refuse failing mail (or drop it hard enough that it may as well be refused)Two operational realities worth saying out loud:
1) p=reject is not a magic shield. DMARC only affects receivers that evaluate DMARC, and it only applies when the message fails DMARC.
2) Tight policies punish alignment mistakes. If SPF passes but DMARC fails, it's usually because SPF authenticated a different domain than the one in From:. The short, practical explanation is in DMARC alignment: From vs Return-Path (strict vs relaxed).
Templates:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.tld
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.tldsp (policy for subdomains)sp is "subdomain policy". It only applies to subdomains of the organizational domain.
Example: if the record is published for _dmarc.example.com, then sp influences what receivers do for mail that claims to be from anything.example.com (like billing.example.com), when that subdomain doesn't publish its own DMARC record.
If sp is omitted, receivers fall back to p.
Common pattern:
p=reject for the main domainsp=none while subdomains are still being cleaned upv=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.tldDon't use sp as a substitute for managing subdomains. It's a useful lever, but subdomains with real sending (marketing, support, transactional) usually deserve explicit DMARC records of their own.
pct (percentage of failing mail to apply policy to)pct is intended as a rollout dial: apply the requested policy action to only a percentage of failing messages.
Example:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.tldIn theory, 25% of DMARC-failing mail gets quarantined, 75% gets treated as if p=none.
In practice, treat pct as a hint rather than a safety net.
Some receivers don't implement it strictly, and different mailbox providers can interpret the exact "25%" in different ways (per-message, per-source, per-time window). It's useful, but it's not a substitute for doing the work of making SPF/DKIM align before turning on enforcement.
If the idea is "turn on quarantine/reject, but gently", a rollout plan like DMARC setup stage 3 — test & adjust is usually safer than leaning on pct alone.
rua (aggregate report destination)rua is where aggregate reports go. These are the XML reports that tell you, in bulk, which sources passed/failed and why.
You can provide one or more mailto: URIs:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld,mailto:dmarc-reports@yourdomain.tldYou may also see size modifiers like !10m on rua addresses:
rua=mailto:dmarc@yourdomain.tld!10mThat's a request to receivers about maximum report size. Some honor it, some ignore it.
rua is the tag where you should put your domain's email address provided by DMARCPal.
ruf (forensic / failure report destination)ruf is for message-level failure reports (sometimes called "forensic" reports). These can include redacted samples, headers, or other per-message details depending on receiver policy.
This tag has two big caveats:
1) Many large mailbox providers do not send (or severely limit) forensic reports due to privacy and abuse considerations. 2) When they are sent, they can contain sensitive information.
Because of that, ruf is often omitted entirely in modern deployments unless there's a specific need and a safe place to process those reports.
If ruf is used, pair it with rf=afrf (format) and a carefully chosen fo value (trigger conditions):
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld; ruf=mailto:dmarc-failures@yourdomain.tld; rf=afrf; fo=1Be careful with ruf: It's easy to enable and surprisingly hard to manage well. If a compliance or privacy program exists, loop it in before turning this on.
Because ruf is not used by most email providers and to keep your privacy in check, DMARCPal does not work with ruf tags. Don't use your DMARCPal report address in a ruf tag.
fo (failure reporting options)fo controls when failure reports are generated (mostly relevant to ruf, but it also influences how some ecosystems think about failure visibility).
Common values:
fo=0 (default) = generate a failure report when both SPF and DKIM fail to produce a DMARC passfo=1 = generate a failure report when either SPF or DKIM fails (more sensitive)fo=d = report when DKIM failsfo=s = report when SPF failsIf ruf isn't enabled, fo doesn't usually change day-to-day operations. Still, fo=1 is a decent choice during early rollout because it tends to surface "almost working" configurations faster.
ri (report interval)ri asks receivers how often to send aggregate reports, in seconds.
The default is 86400 (once per day). Many receivers ignore non-default values and send daily anyway, so treat ri as a preference.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld; ri=86400If you're tempted to set ri lower to get reports faster, it often backfires: more messages, more attachments, more operational noise.
rf (report format for forensic reports)rf applies to ruf and tells receivers what format to use for failure reports.
In most deployments, rf=afrf is the only value that matters.
v=DMARC1; p=none; ruf=mailto:dmarc-failures@yourdomain.tld; rf=afrfIf ruf isn't used, rf is usually omitted.
These are not the only valid records. They're just patterns that tend to behave predictably.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tld; fo=1This aligns with DMARC setup stage 2 — survey & adjust: get visibility, find all real senders, fix alignment.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.tldRaise pct gradually as confidence increases.
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.tldThis is the "done" posture for many production domains. It matches the intent of DMARC setup stage 4 — protect.
If the record starts to feel like a Christmas tree, come back to two questions:
1) Where should reports go? (rua, and here's wher you put your DMARCPal email address) 2) What should happen to mail that fails DMARC? (p, optionally sp)
Everything else is either about rollout (pct) or edge-case reporting (ruf, fo, rf, ri).
And if there's one quiet rule that keeps teams out of trouble: don't turn on p=reject until every legitimate sender is either DKIM-signing with the right domain or using an aligned envelope sender. (Again, alignment is the whole game: DMARC alignment: From vs Return-Path (strict vs relaxed).)