DMARC Record: The Setup That Survives Multi-Domain Sending

Most DMARC guidance still tells you to enforce gradually by publishing p=quarantine; pct=25 and stepping the percentage upward. That advice describes a tag the current specification retired. The IETF published the updated DMARC standard on 20 May 2026, and RFC 9989 lists pct as historic while adding a different mechanism for the same job.

If you run outbound from a handful of sending domains alongside your primary company domain, that change matters more to you than to most senders, because you are publishing and maintaining a record on every one of them. This is what the record contains now, what each tag does, and what a portfolio of domains needs that a single domain does not.

Where the record lives, and the mistake that costs a week

A DMARC record is a DNS TXT record published at _dmarc in front of the domain it governs. For acme.com the hostname is _dmarc.acme.com, and the single most common setup failure is publishing the record at the root domain instead, where nothing will ever look for it.

The record for a domain that has just started monitoring looks like this:

_dmarc.acme.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

Two tags are doing all the work there. v=DMARC1 has to come first. p= states what you want receivers to do with mail that fails, and none means report and deliver as normal. rua= is the address that aggregate reports are sent to, and a record without it is publishing a policy while asking for no evidence about whether the policy is correct.

The current tag set

p= takes none, quarantine or reject. Which one to run while sending outbound is a real decision with consequences in both directions, and we treat it separately in quarantine versus reject.

sp= sets a policy for subdomains, overriding p= for them. One caveat is easy to miss: RFC 9989 notes that sp "will be ignored for DMARC Policy Records published on subdomains of Organizational Domains", so it is a tag for the organizational domain to publish, not for every name in the zone.

np= is new, imported into the standard from the earlier RFC 9091. It sets a policy for subdomains that do not exist. Attackers reach for non-existent subdomains precisely because they are the part of a domain nobody publishes records for, so a strict np=reject costs nothing and closes a real gap.

adkim= and aspf= control how strictly authentication results align, meaning how strictly the authenticated domain has to match the visible From address, with r for relaxed as the default and s for strict. Relaxed allows a subdomain to satisfy the parent, which is usually what a company with several sending systems wants.

t= is the replacement for the part of pct that was worth keeping, and its behaviour is worth quoting because it is not obvious from the name. It is a "DMARC policy test mode", and the specification is precise about the effect: "if the policy is quarantine and the value of the t tag is y, a policy of none will be applied to failing messages; if the policy is reject and the value of the t tag is y, a policy of quarantine will be applied." One level below what you published, on everything, rather than the full policy on a sample.

psd= flags a record published by a public suffix domain, which is a registry-operator concern rather than a sender one.

fo= controls when failure reports are generated, and ruf= is where they go. Both are worth leaving out of a first record. Failure reports contain identifying detail drawn from real messages, so turning them on is a data handling decision as much as a technical one, and the aggregate reports answer the questions you actually have at the start.

There is one naming collision worth carrying in your head, because both halves of it appear in DNS records you will be editing on the same afternoon. A t=y in a DKIM key record means the domain is testing DKIM and tells receivers to treat those messages as unsigned. A t=y in a DMARC record means policy test mode and softens enforcement by one level. Same letter, same value, two unrelated specifications, and the DKIM record in practice covers its side.

pct=, rf= and ri= are historic. An existing record carrying them keeps working, because receivers ignore tags they do not recognise rather than rejecting the record, so there is no urgency to strip them. There is every reason not to build a new rollout plan around them.

pct=25, now historicRFC 7489

• Full policy applied to a sample of failing mail
• Operational experience showed values other than 0 and 100 were applied inconsistently
• Receivers vary in how they interpret it

t=y, currentRFC 9989

• One level below the published policy, applied to all failing mail
• quarantine behaves as none, reject behaves as quarantine
• Reporting is unaffected

Setting one up, in the order that works

Start by finding out who sends as you. Every system that puts your domain in a From address counts: the mail platform, the CRM, the invoicing tool, the helpdesk, the marketing platform, and every outbound sending domain you own. A record published before that inventory exists is a record you will have to walk back.

Publish p=none with a rua address next, on the organizational domain and on each sending domain. This is the monitoring stage and it is the only stage that generates evidence about the sources you missed. Getting those reports to arrive has its own failure modes, and DMARC aggregate reports covers the cross-domain authorisation record that silently blocks them.

Then read what arrives until the picture stops changing. You are looking for legitimate sources that fail, which is usually a third party signing with its own domain rather than yours. The six causes of DMARC failure puts them in order of likelihood, and the fixes are on the sender's side rather than in the record.

Move to enforcement only when the sources you recognise all pass. Our page on the DMARC policy not enabled warning covers what sitting at p=none does and does not buy you, including the part where it satisfies bulk sender requirements while protecting nobody from spoofing.

Before you call a DMARC record done

• ✓Yes: The hostname is _dmarc.yourdomain.com and not yourdomain.com
• ✓Yes: rua= names a shared mailbox that will outlive whoever set this up
• ✓Yes: np= is published on the organizational domain
• ✓Yes: Every sending domain has its own record, not only the primary one
• ✓Yes: Any pct= left in the record is understood to be historic rather than load-bearing
• ✕No: The record was copied from another domain without changing the rua address

What changes when you send from more than one domain

DMARC is published per domain and there is no inheritance across domains you happen to own. acme.com and try-acme.com are unrelated as far as every receiver is concerned, even under one registrar account, so a portfolio of sending domains is a portfolio of records.

Three practical consequences follow.

The first is that a strict policy on the primary domain does not protect the others, and a permissive policy on the others does not endanger the primary. That independence is useful. Outbound domains can carry a different policy from the domain your finance team invoices from, deliberately.

The second is that reporting has to be designed rather than accumulated. Pointing every domain's rua at one shared mailbox is the sensible default and it needs the cross-domain authorisation record published on each sending domain, not only on the first one you set up.

The third is that alignment gets more interesting as domains multiply. SPF stops contributing once a domain crosses the ten DNS lookups that RFC 7208 allows, a limit that SPF records for cold email covers in detail, and at that point DMARC is resting entirely on DKIM. Worth knowing before it happens rather than during.

A fourth consequence is administrative rather than technical, and it is the one that decays. Records get published during a launch and then nobody owns them. A domain that leaves your inventory keeps its record, a domain that joins often does not get one until somebody notices mail failing, and the rua address on a record published two years ago points at a mailbox belonging to someone who has left. Reviewing the set on a fixed schedule costs very little and is the only thing that keeps the portfolio honest.

One further change in RFC 9989 is easy to miss and can flip a passing domain to failing. DMARC now "relies solely on SPF validation of the MAIL FROM identity", with no fallback to the HELO identity. Mail that was passing DMARC via HELO alone is not passing any more.

Where we sit on this

We authenticate every sending domain before it carries a single message, and we send one message per campaign, so a domain that fails authentication does not get a second attempt at the same person under a different pretext. That makes the record part of the launch rather than part of the debugging, which is the same reasoning behind buying more sending infrastructure than a campaign needs.

If you would rather not maintain DNS records across a domain portfolio yourself, we run the sending infrastructure as part of the engagement.

The short version

Publish at _dmarc.yourdomain.com, start at p=none with a working rua, inventory who sends as you before you enforce anything, and add np= while you are there. Treat pct= as historic and use t=y if you want a softer landing, remembering that it applies one level below your policy to everything rather than your full policy to a sample. Every sending domain needs its own record, and none of them inherits anything from your primary domain.

Specification behaviour verified as of August 2026 against RFC 9989 and RFC 7208. Verify current receiver behaviour with the mailbox providers you send to before relying on it.