Which DMARC tags are actually required?

Only two: `v=DMARC1` and `p`. Everything else is optional. But in practice you should always add `rua` for reporting, because without aggregate reports you have no safe way to advance your policy toward enforcement.

What's the difference between adkim/aspf 'r' and 's'?

'r' (relaxed) lets subdomains align with your organizational domain; 's' (strict) requires an exact domain match. Relaxed is the default and the right choice for most senders, strict alignment often breaks legitimate mail sent from subdomains.

Can I just start at p=reject for full protection?

You can, but it's risky without data. Any legitimate source that isn't SPF- or DKIM-aligned will be rejected the moment you do. Start at p=none with rua reporting, confirm every real sender aligns, then move to quarantine and reject.

DMARC Record Tags Explained: p, sp, pct, rua, ruf, adkim, aspf

VigilDog Team · October 7, 2026 · 6 min read

A DMARC record is a single line of text, but each tag inside it changes how the world treats mail claiming to be from your domain. Set `p=reject` too early and you bounce your own newsletters; leave `rua` off and you're flying blind. This guide explains every DMARC record tag in plain terms, what it controls, what values are valid, and the safe way to set it, so you can read and write a policy with confidence.

How DMARC fits with SPF and DKIM

DMARC doesn't authenticate mail on its own. It sits on top of SPF and DKIM and adds two things they lack: alignment and reporting. SPF checks that the sending server is authorized for the envelope domain; DKIM checks a cryptographic signature. DMARC asks a further question, does the domain that passed SPF or DKIM actually match the domain in the visible From: address? That match is 'alignment', and it's what stops a spammer from passing SPF for their own domain while displaying yours.

A message passes DMARC when at least one of SPF or DKIM passes and aligns with the From: domain. Only then do the policy tags below decide what happens to mail that fails.

How SPF, DKIM and DMARC verify an email

The policy tags: p and sp

p is the heart of the record, the policy for your main domain. It takes three values. p=none means 'monitor only': DMARC evaluates mail and sends you reports but asks receivers to take no action, so nothing gets blocked. p=quarantine asks receivers to treat failing mail as suspicious, typically routing it to spam. p=reject asks them to refuse it outright at the SMTP level. The whole point of a rollout is to move from none to quarantine to reject as your reports prove legitimate mail is aligned.

sp sets a separate policy for subdomains. If you omit it, subdomains inherit p. This matters more than people expect: attackers love spoofing invented subdomains like billing.yourdomain.com. If your root policy is still p=none but you never send from subdomains, setting sp=reject locks them down without risk to your live mail streams.

The rollout control tag: pct

pct (percentage) tells receivers to apply your policy to only a sample of failing mailpct=25 means 'apply the policy to 25% of failures, treat the rest with the next-lower policy'. It's a dial for gradual enforcement: you can move to p=quarantine; pct=10 and watch reports before ramping to 100%.

One honest caveat: pct behavior was simplified in newer DMARC guidance and not every receiver implements the partial sampling the same way. Treat it as a useful safety valve during a rollout, not a precise lever, and don't leave a record permanently at a low percentage thinking you're protected, a pct=10 reject policy leaves 90% of spoofed mail slipping through under the softer fallback. Our step-by-step p=reject rollout guide covers pacing this safely.

The reporting tags: rua and ruf

rua is the single most valuable tag when you're starting out. It's the address that receives aggregate reports, daily XML summaries showing which sending sources passed and failed DMARC for your domain. You write it as rua=mailto:dmarc@yourdomain.com. Without it you have no visibility into who sends as you, and you can never safely tighten p. Set this on day one, even while p=none.

ruf requests forensic (failure) reports: near-real-time copies of individual messages that failed. In practice most large receivers no longer send ruf reports for privacy reasons, so don't count on it, and because these can contain message content, weigh the privacy implications before requesting them. Aggregate reports via rua carry almost all the actionable signal.

The raw XML in aggregate reports is painful to read by hand. Paste your published record into our DMARC checker to confirm it parses correctly, and see how to fix SPF, DKIM, and DMARC when reports reveal a source that isn't aligning.

The alignment tags: adkim and aspf

adkim and aspf control how strict the domain match has to be, and each takes r (relaxed, the default) or s (strict). Relaxed alignment lets a subdomain match the organizational domain, mail signed by mail.yourdomain.com aligns with a From: of yourdomain.com. Strict alignment demands an exact match. Most organizations should stay on relaxed (r); it's more forgiving of normal infrastructure like transactional-email subdomains and rarely weakens real protection.

Only reach for adkim=s or aspf=s when you have a specific reason to forbid subdomain matching, and only after reports confirm all your legitimate senders sign or send from the exact organizational domain. Turning on strict alignment prematurely is a common way to quietly start failing your own mail.

Putting it together, a healthy starter record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; sp=reject; adkim=r; aspf=r. It monitors your main domain, reports everything, and already protects unused subdomains, a foundation you tighten as the data comes in.