A tag-by-tag reference for the DMARC DNS record as defined in RFC 7489 (and draft DMARCbis). Every field documented with its permitted values, default behaviour, interactions, and real-world examples drawn from UK business deployments. Bookmark this page when you need to audit, understand or refine an existing DMARC record.
v and padkim and aspfsppctrua, ruf, riforfA DMARC record is a single DNS TXT record published at _dmarc.yourdomain. The content is a semicolon-separated list of tag-value pairs. A typical production record:
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; pct=100;
rua=mailto:[email protected]; fo=1"The tags can appear in any order. Whitespace around the separators is tolerated. Tag names are case-insensitive though convention is lowercase.
v and pv — versionMust be the first tag. Must have the value DMARC1. No other versions exist. A record without v=DMARC1 first is not a DMARC record and is ignored by receivers.
v=DMARC1p — policySpecifies what receivers should do with messages that fail DMARC alignment from the domain itself (not subdomains — see sp for subdomain policy). Three permitted values:
| Value | Behaviour | Typical use |
|---|---|---|
none | No enforcement. Messages deliver normally. Reports generated. | Initial monitoring. |
quarantine | Failing messages go to recipient's spam folder. | Intermediate enforcement. |
reject | Failing messages rejected at SMTP level. | Full enforcement. |
The tag is required. Any other value makes the record invalid.
adkim and aspfadkim — DKIM alignment moder (relaxed, default) — the DKIM signing domain must share the organisational domain with the From: header domain. bounce.firm.co.uk aligns with firm.co.uk.s (strict) — the DKIM signing domain must exactly match the From: domain.aspf — SPF alignment moder (relaxed, default) — the envelope sender's organisational domain must match the From: organisational domain.s (strict) — exact match required.Strict alignment is more secure because it forecloses subtle sub-domain-based spoofing. Relaxed is more forgiving of legitimate complex mail flows. Modern hardened deployments (including epost.plus) publish adkim=s; aspf=s; mainstream UK deployments leave both relaxed.
spSets the DMARC policy for messages claiming to come from any subdomain that does not itself publish a DMARC record. If absent, subdomains inherit the parent's p= policy.
Common uses:
sp=reject on parent to lock down all subdomains by default.sp=quarantine on parent when marketing subdomains have different risk tolerances than the main domain.sp=none on parent to explicitly allow subdomain mail even when parent is at p=reject.pctA value from 0 to 100 (default 100). Specifies what percentage of failing messages the policy applies to. The remainder falls through to the next-weakest policy:
p=reject; pct=25, one in four failing messages is rejected; the other three are treated as p=quarantine.p=quarantine; pct=25, one in four failing messages is quarantined; the other three are delivered normally.Use pct for gradual rollouts: start at a low value, monitor, increase. A typical rollout path is p=quarantine; pct=25 → 50 → 100, then p=reject; pct=25 → 50 → 100.
rua, ruf, rirua — aggregate report address(es)A comma-separated list of URIs to send daily aggregate (XML) reports to. Almost always mailto: URIs:
rua=mailto:[email protected]Multiple addresses allowed:
rua=mailto:[email protected],mailto:[email protected]Third-party DMARC services often require you to add their address alongside your own. Always include at least one address — DMARC without reporting is half-deployed.
Sending reports to an address at a different domain (e.g. rua=mailto:[email protected] when the DMARC record is on firm.co.uk) requires authorisation: the receiving domain must publish a matching TXT record at firm.co.uk._report._dmarc.dmarc-service.uk confirming it accepts reports for firm.co.uk. Most DMARC service providers automate this.
ruf — forensic report address(es)Per-message failure reports. Most large providers do not send these due to privacy concerns. Rarely populated in practice. Same format as rua.
ri — reporting interval (seconds)Default 86400 (one day). Requests reports to be generated at the specified interval. Receivers are not required to honour the request; most send daily regardless.
foControls when forensic reports are generated (if at all). Four permitted values, specified as a colon-separated list:
fo=0 (default) — generate a forensic report only if both SPF and DKIM fail to produce aligned passes.fo=1 — generate a forensic report if either SPF or DKIM fails to produce an aligned pass. Most useful for granular diagnostics.fo=d — generate a forensic report when DKIM fails (regardless of alignment).fo=s — generate a forensic report when SPF fails.Practical recommendation: fo=1. Even though most receivers do not actually send forensic reports, the declaration of intent is useful.
rfSpecifies the report format. Default (and effectively only) value is afrf (Authentication Failure Reporting Format). Rarely necessary to include; the default is universal.
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Enforcement: none. Reporting: to a single mailbox. First record published during initial rollout.
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=quarantine; pct=25; adkim=s; aspf=s;
rua=mailto:[email protected]; fo=1"Enforcement: quarantine on 25% of failures, others delivered. Strict alignment on both SPF and DKIM. Reporting to one mailbox. Mid-rollout state.
_dmarc.firm.co.uk. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; pct=100;
rua=mailto:[email protected],mailto:[email protected]; fo=1"Full reject, strict alignment, dual reporting. The steady-state record for a domain with complete sender authentication.
_dmarc.parked.co.uk. IN TXT "v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s;
rua=mailto:[email protected]"Combined with a null SPF (v=spf1 -all) and null DKIM (*._domainkey.parked.co.uk IN TXT "v=DKIM1; p="), this locks the parked domain against any spoofing.
_dmarc.epost.plus. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s;
rua=mailto:[address]@in.mailhardener.com"Maximum enforcement with Mail Hardener processing aggregate reports. Exemplary for UK deployment.
When you take over management of an existing UK domain, audit the DMARC record:
dig TXT _dmarc.yourdomain should return exactly one record starting with v=DMARC1.p= set? What is the value? Is it appropriate for the current deployment maturity?adkim and aspf set? If absent, relaxed is assumed. Is that appropriate?sp= set? Is it consistent with the parent's p=?pct= below 100? If so, is the rollout actively being managed or has it stalled?rua= present and pointing at a live mailbox? Is someone actually processing the reports?rua= or ruf= points at a third-party domain, is the authorisation TXT published?pct and p interact unexpectedlyAt p=quarantine; pct=25, the spec says 25% of failing mail should be quarantined and 75% delivered. At p=reject; pct=25, 25% is rejected and 75% falls through to p=quarantine-equivalent behaviour. This cascading fallback is not always visible to the domain owner unless they look at DMARC aggregate reports specifically for the dispositions column — some receivers combine them in ways that obscure the actual enforcement ratio.
If you publish adkim=s but your DKIM signer is using d=bounce.firm.co.uk while your From: is [email protected], DKIM alignment fails under strict mode. A common deployment bug: switching from relaxed to strict alignment without first verifying every signer's d= exactly matches the From: domain. Always audit with aggregate reports before tightening.
sp= inheritance rulesIf a subdomain publishes its own _dmarc.subdomain record, that record takes precedence — the parent's sp= does not apply. This is frequently surprising: administrators publish sp=reject on the parent, expecting all subdomain spoofing to be blocked, then discover a legacy subdomain has its own record at p=none that overrides.
rua authorisationIf your record contains rua=mailto:[email protected] and the third-party domain has not published an authorisation TXT at yourdomain._report._dmarc.third-party-service.uk, reports may silently not arrive. Every DMARC processing service documents this requirement; follow their setup guide precisely.
A record like "v=DMARC1;" (missing p=) is invalid. Receivers either skip DMARC entirely for that domain or apply a default of p=none — behaviour varies. Always include p=.
The IETF's DMARCbis draft (expected to become an RFC sometime after 2026) refines DMARC without breaking existing records. A few tags are being deprecated:
pct= — being removed in favour of explicit tree-walk mechanics. Current behaviour stays for backward compatibility.ri= — rarely honoured by receivers; documented as historical.rf= — only one format ever existed; documented as historical.For UK businesses, the practical impact is nil — existing records continue to work exactly as they do today. DMARCbis does not invalidate anything you publish now.
| Scenario | Relaxed | Strict |
|---|---|---|
| From: [email protected], DKIM d=firm.co.uk | Align | Align |
| From: [email protected], DKIM d=mail.firm.co.uk | Align | Not align |
| From: [email protected], DKIM d=firm.co.uk | Align | Not align |
| From: [email protected], DKIM d=notfirm.com | Not align | Not align |
| Record | Effect on failing mail |
|---|---|
p=none | All delivered, reported |
p=quarantine; pct=50 | 50% to spam, 50% delivered |
p=reject; pct=25 | 25% rejected, 75% to spam (cascade) |
p=reject; pct=100 | All rejected |
Q: Does tag order in the DMARC record matter?
A: Only v=DMARC1 must be first. The rest can be in any order. Conventional ordering is v, p, rua, ruf, alignment, sp, pct, fo.
Q: Can I publish multiple DMARC records?
A: No. Two TXT records starting with v=DMARC1 at _dmarc.domain is an error. Receivers either pick one arbitrarily or (more commonly) ignore both.
Q: What happens if I publish v=DMARC1 with no other tags?
A: The record is invalid — the p= tag is required. Receivers ignore the record.
Q: Can DMARC tags have whitespace between them?
A: Yes, whitespace around the semicolons is tolerated. Convention is a single space.
Q: If I omit sp=, what happens to subdomain mail?
A: Subdomains inherit the parent's p=. Explicitly setting sp= makes the intent clear and allows subdomain-specific policy.
Q: Can I use pct=0 to disable enforcement while keeping reporting?
A: Yes, though it is unusual. A cleaner way to achieve the same effect is p=none.
Q: What is the maximum length of a DMARC record?
A: DNS TXT records are limited to 255 characters per string; longer records must be split across multiple strings. DMARC records are typically well under 400 bytes, so size is rarely a concern.
Q: Do I need to quote rua addresses?
A: The whole TXT record should be quoted (a DNS syntax convention). Within the record, rua=mailto:... is not individually quoted. Most DNS UIs handle this automatically.
Q: If I set fo=1, will I actually receive forensic reports?
A: Rarely. Most large receivers (Google, Microsoft, Yahoo) do not send forensic reports due to privacy concerns. Setting fo=1 is a declaration of intent but not a guarantee of delivery.
Q: Can I ignore aggregate reports and rely on spot-checks?
A: Strongly discouraged. Aggregate reports are the single most useful visibility tool DMARC provides — missing senders, forwarder failures and spoofing attempts all surface first in aggregate reports. Use a processing service; do not ignore.
Q: What is the smallest DMARC record I can publish for a UK sole trader?
A: v=DMARC1; p=none; rua=mailto:[email protected]. Three tags, minimal policy, self-addressed reports. Perfectly valid.
Q: Does the pct tag affect the sp policy?
A: The percentage applies to the parent policy only. Subdomain enforcement under sp is full — if sp=reject, subdomain failures are rejected at 100%, not at the parent's pct rate.
Q: If I set fo=1:d:s, does that produce more reports than fo=1?
A: In theory yes — the colon-separated values combine conditions. In practice the difference is moot because few receivers send forensic reports at all.
Q: My DMARC record has an adkim but no aspf. Is that correct?
A: Technically valid — the missing tag defaults to relaxed. For clarity, publish both explicitly with their intended values. Omitting tags is a common source of audit confusion.
Q: How do I verify my DMARC record parses correctly?
A: Use a DMARC record validator — MXToolbox, Hardenize, NCSC Mail Check (for UK public sector), or the checkdmarc Python tool. The validator reports each tag's value and flags any syntactic problems.
Q: Does the order of alignment tags matter?
A: No. adkim=s; aspf=s and aspf=s; adkim=s are equivalent.
Q: Can I use rua with an HTTP URL instead of mailto?
A: Technically RFC 7489 allows other URI schemes, but in practice only mailto: is supported. HTTP reporting was never implemented by major receivers.
Q: What happens if my rua inbox is full or unavailable?
A: Aggregate reports bounce. Receivers do not retry. The gap in reporting is silent — monitor your mailbox health and have alerting for bounces.
Q: Is there any reason to use p=none permanently?
A: Only during very long rollouts on complex infrastructures, or on deliberately-monitored domains where you want visibility without enforcement. At steady state, p=none is equivalent to having no DMARC enforcement at all — attackers can freely spoof your From: domain.
Q: Can DMARC be published at a hostname other than _dmarc?
A: No. The name _dmarc is fixed by the RFC. Publishing at any other name means receivers do not find the record.
Q: If I want different policies for different subdomains, do I need to publish separate _dmarc records at each subdomain?
A: Yes. The sp= tag on the parent applies to subdomains that do not have their own record. To give a subdomain a specific policy different from the parent's sp=, publish _dmarc.subdomain.firm.co.uk with that subdomain's policy.
Q: Does the v=DMARC1 value ever change?
A: No. Like SPF (v=spf1), the version has been stable since inception. DMARCbis preserves this.
Q: What is the one tag UK public sector domains must always include?
A: rua= — reporting is explicitly required by NCSC Mail Check and GOV.UK mail policy. Domains without rua= fail the UK public sector baseline.
Q: Does rua accept multiple addresses, and if so what does each receive?
A: Yes — comma-separated. Every address listed receives the same aggregate report. Useful when you want reports to go both to your own mailbox for archiving and to a dedicated DMARC processing service for analysis.
Q: Can I put a URL in rua that fetches reports instead of emailing them?
A: The RFC permits non-mailto URIs but no major receiver ever implemented HTTP delivery. In 2026, assume mailto is the only working option.
Q: What does !size after a mailto: URI mean?
A: Optional size limit in bytes. rua=mailto:[email protected]!10m asks receivers not to send reports larger than 10 megabytes. Rarely used; most reports are small.