DMARC: The Complete Guide to the DMARC Record

The syntax of the _dmarc record

A DMARC record is a single TXT record published at the _dmarc subdomain of the domain to protect. A domain must carry only one — two records make the policy ambiguous, and receivers may ignore both.

_dmarc.example.com.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; adkim=s; aspf=r"

The value is a sequence of tag=value pairs separated by semicolons. v=DMARC1 must open the record — including under DMARCbis, which keeps this version identifier for backward compatibility. Here are the tags as defined by RFC 9989:

Tag	Purpose	Values	Notes
v	Protocol version	DMARC1	Required, first position — unchanged under DMARCbis
p	Domain policy	none, quarantine, reject	Required; applies to the domain and, by default, its subdomains
sp	Subdomain policy	none, quarantine, reject	Optional; overrides p for existing subdomains
np	Policy for non-existent subdomains	none, quarantine, reject	New in DMARCbis; targets subdomains that do not resolve
rua	Aggregate report destination	mailto: (one or more addresses)	Strongly recommended: without it, no feedback at all
ruf	Failure report destination	mailto:	Optional; rarely sent and often redacted
adkim	DKIM alignment mode	r (relaxed), s (strict)	Default: r
aspf	SPF alignment mode	r (relaxed), s (strict)	Default: r
t	Testing mode	y, n	New in DMARCbis; replaces the removed pct tag
psd	Public suffix domain marker	y, n, u	New in DMARCbis; mostly relevant to registries

Two DMARCbis changes deserve emphasis here. First, the pct tag — which claimed to apply the policy to a percentage of mail — has been removed: receivers interpreted it inconsistently, and it gave a false sense of gradual rollout. Its replacement is the testing mode t tag, binary and unambiguous: t=y signals that the policy is being trialed. Second, discovering the organizational domain — the basis of relaxed alignment — no longer relies on the Public Suffix List, an externally maintained file, but on the DNS Tree Walk: the receiver climbs the DNS tree itself, capped at eight queries. The result is deterministic and self-contained.

To start from a sound baseline rather than a blank page, ready-to-adapt record examples, provider by provider, are available on the blog.

The three policies: none, quarantine, reject

The p tag tells receivers what to do with a message that fails DMARC. The three values form a ladder, and the rung you choose changes everything:

• p=none — pure observation. Failing messages are delivered normally; only reports are generated. This is the mandatory starting point: it lets you inventory sending sources with zero risk to legitimate mail. But it protects nothing and no one — a domain at p=none remains fully spoofable.
• p=quarantine — failing messages are treated with suspicion, in practice routed to the spam folder. Protection becomes real: a spoofed email no longer reaches the inbox, but it remains retrievable, which limits the damage of a false positive.
• p=reject — failing messages are refused during the SMTP session. They are neither delivered nor stored: spoofing the exact domain becomes impossible at any receiver that honors the policy. This is the end goal, and the only level that actually stops phishing in the domain's name.

When should each be used? p=none during the inventory phase, as long as reports still reveal legitimate but unaligned sources. p=quarantine once the reports are clean, as a validation stage under real conditions. p=reject as the steady state, once quarantine has surfaced no incidents. The detailed comparison of the two enforcement levels — including the cases where an extended quarantine is justified — is covered in p=quarantine or p=reject: which to choose. Keep the principle in mind: none is a transitional state, not a destination. A domain that parks there for years documents its exposure without reducing it.

DMARC reports: rua and ruf

The "Reporting" part of DMARC is what makes deployment steerable. Without it, tightening a policy would mean flying blind; with it, every decision rests on observed data.

Aggregate reports (rua, specified by RFC 9990) are XML documents sent — typically daily — by receivers that handled mail claiming to come from your domain. Google, Microsoft, and Yahoo produce them at scale. Each report summarizes, per sending IP address: message volume, the SPF result, the DKIM result, alignment status, and the policy applied. They contain no message content and no recipient addresses — statistics only. They are the raw material of any deployment: they reveal the forgotten sending services (marketing platform, CRM, invoicing tool) that must be aligned before tightening. Their structure and interpretation are detailed in reading DMARC aggregate reports.

Failure reports (ruf, RFC 9991) are different: sent per event, at the moment of a failure, they contain excerpts of the affected message. They promise fine-grained diagnostics but rarely deliver: most large receivers do not send them, or heavily redact them, for privacy reasons — a real message can contain personal data. In practice, a deployment is steered with aggregate reports; failure reports are an occasional complement, to be requested with full awareness. The differences, use cases, and precautions of the two channels are compared in rua vs ruf: which reports to request.

A rua address should appear in every record, from day one and whatever the policy. If reports are sent to a third-party domain (an analysis provider, for instance), that domain must publish an external authorization record confirming it agrees to receive them.

The deployment path: from p=none to p=reject

Deploying DMARC is an iterative process in which every step is validated by the reports. The proven sequence:

1. Publish p=none with a rua address. No impact on mail; collection begins. Allow two to four weeks to get a representative picture, including billing cycles and monthly sends.
2. Inventory the sources. The reports reveal every IP sending in the domain's name. Classify them: legitimate services to align, unknown services to investigate, outright spoofing.
3. Align every legitimate source. Add senders to the SPF record and enable DKIM with an aligned signing domain at each sending provider. This is the longest step — it depends on the cooperation of teams and vendors.
4. Move to p=quarantine. Once the reports show all legitimate mail is aligned. DMARCbis's t=y testing mode lets you declare the tightening as experimental while you verify that no forgotten source would fall through.
5. Move to p=reject. After a few weeks of quarantine without incident. Report monitoring then continues as routine: a new source appears every time a team adopts a new tool.

The objective criteria that indicate a domain is ready to climb one rung — alignment rate, stability, subdomain coverage — are gathered in the eligibility checklist from p=none to p=reject, and the full journey, pitfalls included, in getting to p=reject without breaking your email. Before anything else, check the actual state of your current record with our free DMARC analyzer: published policy, alignment, syntax errors — the starting point should be measured, not guessed.

DMARCbis in brief

DMARCbis is the complete revision of the standard, published by the IETF as three RFCs: 9989 (the protocol), 9990 (aggregate reporting), and 9991 (failure reporting). Together they replace RFC 7489 from 2015 and move DMARC, for the first time, to Proposed Standard status — the standards track, where the original text was merely informational.

The essentials fit in four points:

• Full backward compatibility. Records still start with v=DMARC1; an existing record remains valid without modification.
• pct removed, t introduced. Percentage-based rollout disappears in favor of a binary testing mode, more honest and uniformly interpreted.
• np and psd introduced. The first locks down non-existent subdomains, a favorite target of spoofers; the second flags public suffix domains.
• The DNS Tree Walk replaces the Public Suffix List. Organizational domain discovery becomes native to DNS, deterministic, and identical at every receiver.

For the full analysis of the new standard — its genesis, the working group's debates, the consequences for the ecosystem — see DMARCbis explained. And if you are wondering what actually needs to change in an existing record, the short answer is "very little": the how-to fits in should you migrate to DMARCbis? — remove a now-inert pct, consider np=reject, and that is about it.

Edge cases: subdomains and parked domains

Subdomains inherit the organizational domain's p policy by default — unless an sp tag decides otherwise, or the subdomain publishes its own _dmarc record. This flexibility is useful (a transactional sending subdomain can tighten before the root domain does), but it is also a classic blind spot: a p=reject on the root combined with sp=none leaves every subdomain spoofable. DMARCbis adds the np tag for an even more insidious case: non-existent subdomains. Nothing stops an attacker from sending as payroll.example.com even if that name has never existed in your zone — and since no legitimate service can depend on it, np=reject can be published with zero risk, often long before the root is ready. The full interplay of the three levels — p, sp, np — and their inheritance traps is covered in the DMARC subdomain policy.

Parked domains — owned but never sending email — are the other blind spot. Precisely because nobody watches them, they are ideal spoofing targets: the recipient has no reason to distrust a domain you genuinely own. Protection is simple and immediate, since there is no legitimate mail to preserve: p=reject from the start, an SPF record of v=spf1 -all authorizing no sender, no DKIM, and a null MX to signal that no mail is expected. The complete procedure, record by record, is described in protecting a parked domain. A well-kept domain inventory applies this lockdown to every dormant domain in the portfolio — it is the best effort-to-protection ratio in the whole program.

FAQ

Does DMARC replace SPF and DKIM?

No. DMARC does not work without them: it builds on their results and adds alignment with the From: domain, then the policy and the reports. A message passes DMARC if SPF or DKIM succeeds with an aligned domain. The three standards are therefore deployed together: SPF and DKIM first, DMARC to bind them to the visible address and make the whole thing enforceable.

Can a domain publish more than one DMARC record?

No. A domain must carry a single TXT record at _dmarc. If several records starting with v=DMARC1 coexist, receiver behavior is undefined — most ignore them all, which leaves the domain without a policy while it believes itself protected. Any change must be merged into one single record.

Does the pct tag still exist?

No. DMARCbis (RFC 9989) removed pct, whose "apply the policy to a percentage of mail" semantics were interpreted differently from one receiver to the next. It is replaced by the t tag, a binary testing mode: t=y signals that the policy is being trialed. A leftover pct in an existing record is simply ignored by up-to-date implementations — removing it keeps the record clean.

How long does it take to go from p=none to p=reject?

It depends on how many services send in the domain's name. A simple domain, with one mail platform and one or two sending tools, can be locked down in a few weeks. An organization with dozens of sources — marketing, CRM, invoicing, support — should count in months, the time it takes to align every provider. Realistic phase-by-phase timelines are detailed in how long it takes to reach p=reject.

Does p=none protect a domain against spoofing?

No. At p=none, messages that fail DMARC are delivered normally: the policy asks receivers to take no action. p=none exists to observe — an indispensable stage, but a domain that stays there indefinitely remains as spoofable as a domain with no DMARC at all. Protection begins at p=quarantine and becomes complete at p=reject.

What happens if a domain has no DMARC record at all?

Receivers find no policy and handle the mail using their own heuristics alone: an email spoofing the domain can perfectly well land in the inbox. The domain also receives no reports, hence no visibility into fraudulent use of its name. There is a deliverability effect on top: major mailbox providers now require a DMARC record from bulk senders — its absence penalizes legitimate mail too.