Building a DMARC record means choosing a policy (none, quarantine, or reject), a reporting address, and how strict SPF/DKIM alignment should be - then publishing the result as a TXT record at _dmarc.yourdomain.com.
The tags that make up a DMARC record
A DMARC record (RFC 7489) is a single TXT record made of semicolon-separated tag=value pairs. Only two tags are required; everything else has a default that applies if you omit it.
- v=DMARC1 - the version tag, required, always exactly this value, always first
- p=none|quarantine|reject - required, the policy applied to mail that fails SPF or DKIM alignment for this domain
- sp= - optional, a separate policy for subdomains; without it, subdomains inherit p=
- rua=mailto:... - optional but strongly recommended, where aggregate reports get sent
- ruf=mailto:... - optional, where per-message forensic reports get sent
- pct= - optional, defaults to 100, what percentage of failing mail the policy applies to
- aspf= and adkim= - optional, both default to r (relaxed), how strictly SPF/DKIM alignment is checked
Choosing a policy: none, quarantine, or reject
The policy tag is the one decision that actually changes mail delivery. It is also the one most worth getting in the right order, since a wrong policy on day one can quarantine or reject legitimate mail nobody has tested yet.
| Policy | What receivers do | When to use it |
|---|---|---|
| p=none | Nothing changes - mail is delivered as it would be without DMARC | Always the starting point, so reports can be collected before anything is enforced |
| p=quarantine | Failing mail is routed to spam/junk instead of the inbox | Once aggregate reports show no legitimate sender failing |
| p=reject | Failing mail is refused at the SMTP level | After a quarantine period with clean reports and no false positives |
Setting a rollout percentage with pct=
The pct= tag lets a policy apply to only a fraction of failing mail, expressed as a whole number from 1 to 100. Receivers apply p= to that percentage of messages that fail alignment and fall back to a lighter treatment for the rest - this is how a quarantine or reject policy gets phased in gradually instead of switching on for every message at once.
Leaving pct= out is equivalent to pct=100: the policy applies to all failing mail. A generator that always emits pct=100 explicitly, or omits the tag entirely, produces the same effective record - receivers treat a missing pct= as 100 per RFC 7489.
Reporting addresses: rua and ruf
DMARC without a rua address is a policy with no feedback loop - the domain owner never learns which servers are sending mail that fails alignment, or whether a legitimate sender is about to be blocked.
- rua - aggregate reports, one daily XML summary per receiving provider covering every message evaluated against the domain. This is the report worth setting up before touching the policy tag.
- ruf - forensic reports, one message per failure with headers attached. Most large mailbox providers stopped sending these years ago over privacy concerns, so an empty ruf field is normal, not a mistake.
- Multiple addresses are allowed for either tag, separated by commas - useful for sending copies to both an internal mailbox and a third-party DMARC report analyzer.
- Each address needs the mailto: scheme; a plain email address without it is not valid syntax in the record.
Alignment: aspf and adkim
Passing SPF or DKIM is not enough on its own - the domain that check authenticates also has to align with the visible From: address, and the aspf/adkim tags set how exact that match must be.
- r (relaxed) - the default for both tags. A subdomain of the From: domain counts as aligned: mail sent from news.example.com aligns with a From: address at example.com.
- s (strict) - the authenticated domain must match the From: domain exactly, with no subdomain tolerance.
- aspf and adkim are set independently. A domain can run strict SPF alignment with relaxed DKIM alignment, or any other combination.
- Relaxed alignment is the common default because it tolerates mail sent through subdomains (marketing platforms, transactional mail services) without extra SPF includes or DKIM selectors for each one.
Reading the generated record
A record built from p=quarantine, sp= left as "same as policy", rua set to one address, pct= at 50, and both alignment tags left relaxed renders as a single line:
- v=DMARC1; p=quarantine; adkim=r; aspf=r; pct=50; rua=mailto:dmarc-reports@example.com
- Tag order in the output follows v, p, sp, adkim, aspf, pct, rua, ruf - receivers parse by tag name, not position, so a different order in a hand-edited record is equally valid.
- The sp= tag only appears when a subdomain policy is explicitly chosen; leaving it on "same as policy" omits the tag, since an absent sp= already falls back to p= for every subdomain.
- A pct= value is only meaningful alongside p=quarantine or p=reject - under p=none nothing is being enforced, so there is no fraction to stagger.
Publishing the record
The record goes in the DNS zone as a TXT record, not on the domain itself - the host name is always _dmarc.yourdomain.com, with the underscore prefix and no separate priority or weight fields like an MX or SRV record needs.
Most authoritative nameservers accept the value with or without surrounding quotes; check the zone file syntax your DNS host expects, since some strip semicolons if the value is not quoted. After publishing, allow for the TTL and any provider-side propagation before a fresh lookup reflects the new record.
FAQ
What is the safest policy to start a DMARC record with?
p=none. It changes nothing about mail delivery and simply turns on reporting, so every legitimate sender using the domain shows up in aggregate reports before any enforcement begins. Publishing p=quarantine or p=reject as a first record risks blocking mail from services nobody has audited yet.
Do I need both rua and ruf?
No. rua (aggregate reports) is the one that matters for almost every domain - it is what shows which servers send mail as the domain and whether they align. ruf (forensic, per-message reports) has been dropped by most major mailbox providers over privacy concerns, so many current records only carry rua.
What happens if I leave pct= out of the record?
The policy applies to all failing mail, exactly as if pct=100 had been set explicitly. The tag exists to reduce that percentage during a staged rollout, not to increase it - values above 100 are not valid.
Can I set a different policy for subdomains than for the root domain?
Yes, with sp=. A record at _dmarc.example.com with p=reject and sp=none would reject failing mail claiming to be from example.com directly while leaving subdomains like mail.example.com unenforced - useful when subdomains are still being brought into alignment separately.
Should aspf and adkim be strict or relaxed?
Relaxed (r) is the default and works for most domains, since it tolerates mail authenticated from a subdomain of the From: address. Strict (s) is worth setting only when every sending source authenticates from the exact root domain and there is a specific reason to close the subdomain gap.
Why does the generated record put sp= right after p= instead of at the end?
DMARC receivers parse each tag by its name, not its position in the string, so tag order has no effect on how the record is interpreted. Grouping sp= next to p= in the output is purely for readability when reading the record back later.
Related tools
- Verify the published record resolves correctly and check aggregate reports against the policy that was set
- Build the matching SPF record that DMARC's aspf alignment check evaluates
- Generate the DKIM keypair and record that DMARC's adkim alignment check evaluates
- Query the raw TXT record at _dmarc.yourdomain.com once it has been published