How to Set Up DMARC in 2026: The Record, the Rollout, and Where to Stop

Setting up DMARC takes one DNS TXT record published at _dmarc.yourdomain.com, and the record is the easy part. The work that decides whether DMARC helps you or breaks your email is what happens after you publish it: reading the reports, finding the senders you forgot about, and choosing a policy you can actually live with. This guide covers the record, the rollout, and — the part most guides skip — where to stop.

One thing to know before you start. The DMARC standard changed in May 2026. RFC 9989, 9990 and 9991 replaced RFC 7489, and they removed the pct tag that almost every DMARC tutorial written before that date uses as the basis of its rollout plan. If you have read a guide that told you to ramp from pct=10 to pct=50 to pct=100, that method no longer exists in the standard. The section below on what changed explains what replaced it.

What DMARC does that SPF and DKIM do not

DMARC checks alignment — whether the domain that passed SPF or DKIM is the same domain your recipient sees in the From line. SPF and DKIM each answer a narrower question, and neither of them looks at the From address at all.

• SPF asks whether the sending server is allowed to send for the domain in the envelope's return-path. That return-path is invisible to your recipient.
• DKIM asks whether the message carries a valid cryptographic signature from some domain. That domain is also invisible to your recipient.
• DMARC asks whether either of those domains matches the visible From domain, and tells the receiver what to do when neither does.

This is why "everything passes but DMARC fails" is the most common confusion in email authentication. A message sent through a marketing platform can pass SPF for bounce.your-platform.com and carry a valid DKIM signature from your-platform.com, while the From line reads you@yourdomain.com. Both checks passed. Neither aligned. DMARC fails.

Alignment is also the entire security value of DMARC. Without it, anyone can pass SPF using their own domain and put your name in the From line. DMARC is the only one of the three that closes that gap.

What you need before you publish a DMARC record

Publish DMARC only after SPF and DKIM are working, because DMARC does nothing on its own — it evaluates the results of the other two. A DMARC record on a domain with broken authentication does not fix anything; it just starts reporting the breakage.

Three things need to be true first:

1. One SPF record, resolving under 10 lookups. A domain may publish exactly one SPF record. The check also has a hard ceiling of 10 DNS lookups across the whole include tree, and crossing it returns a PermError that most receivers treat exactly like having no SPF record at all. Count your real lookups — the number is usually higher than people expect, because each include: pulls in a record with its own includes.

2. DKIM signing enabled on every platform that sends as you. Every one: your mail host, your marketing platform, your helpdesk, your invoicing tool, your CRM. Each publishes its own selector. A platform you forget about is a platform that shows up as a failure later.

3. A mailbox ready to receive reports. Aggregate reports arrive daily as XML attachments, and on a busy domain there will be a lot of them. Use a dedicated address, not your main inbox.

Scan your domain to confirm MX, SPF and DMARC in one pass before you go further.

The DMARC record, tag by tag

A DMARC record is a TXT record published at the hostname _dmarc on your domain, containing semicolon-separated tag-value pairs. Here is every tag defined in the 2026 standard.

Tag	What it does	Default
v	Version. Must be DMARC1 and must come first	Required
p	What receivers should do with mail that fails: none, quarantine, or reject	none
sp	Policy for existing subdomains	Inherits from p
np	Policy for subdomains that do not exist	Inherits from sp, or p
rua	Where to send aggregate reports	None — no reports without it
ruf	Where to send per-message failure reports	None
adkim	DKIM alignment mode: r relaxed, s strict	r
aspf	SPF alignment mode: r relaxed, s strict	r
fo	Which failures generate a report	0
psd	Declares whether this is a public suffix domain: y, n, u	u
t	Test mode: y or n	n

Three of these are new in 2026 — np, psd and t. Three tags that appeared in older guides are gone: pct, rf and ri.

Relaxed alignment is the default and is what you want. Under relaxed, mail.yourdomain.com aligns with yourdomain.com. Under strict, it does not — the domains must match exactly. Strict alignment breaks more mail than it protects for most senders, and there is rarely a reason to set it deliberately.

fo=1 is worth adding even though the default is 0. The default only reports when everything fails. fo=1 reports when any mechanism fails, which is far more useful while you are still finding your senders — and finding your senders is the entire purpose of the monitoring phase.

Publish your first record

Your first record does three things: it collects data, it changes nothing about how your mail is handled, and it closes one spoofing route immediately.

Step 1 — Create the TXT record. In your DNS provider, add a TXT record. Set the host or name field to _dmarc. Some providers want the full _dmarc.yourdomain.com; most append the domain for you.

Step 2 — Set the value.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

Step 3 — Add np=reject if you never send from unused subdomains. Attackers spoof subdomains that were never set up, precisely because nothing is watching them. If no mail should ever come from invoices.yourdomain.com, saying so costs nothing and closes the route:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; np=reject

Step 4 — Save and wait for DNS. Propagation is usually minutes, occasionally up to 24 hours. There is nothing to restart and no queue to flush — the next message sent after the record resolves is evaluated against it.

Step 5 — Confirm it resolves. Scan the domain and check the record comes back exactly as you wrote it. A record that resolves with a typo behaves like a record that does not exist. If you would rather not hand-write the syntax, the SPF & DMARC generator builds both records from a short form.

Step 6 — Wait for reports. The first aggregate reports arrive within about 24 hours. Google, Yahoo and Microsoft all send them daily.

Step 7 — Read them. This is the step that matters, and it is the step most people skip. Upload a report and look for two things: senders you recognise that are failing, and senders you do not recognise at all.

Step 8 — Fix what you find, then leave it alone for several weeks. Every legitimate sender needs to pass and align before you tighten anything.

What changed in 2026, and why most DMARC guides are now wrong

RFC 9989, 9990 and 9991 were published in May 2026 and obsoleted RFC 7489, which had governed DMARC as an informational document since 2015. Three changes matter to anyone setting DMARC up today.

The pct tag was removed

pct is gone from the standard, along with rf and ri. For a decade the standard rollout advice was to publish p=quarantine; pct=10, then raise the percentage in stages so only a fraction of failing mail was affected at each step. That advice is now built on a tag that the specification no longer defines.

Publishing pct= will not break your record — unknown tags are ignored rather than treated as errors. But a receiver implementing the current standard will ignore it, and the protection you think a low percentage is giving you is not there. If your DMARC rollout plan is a pct ladder, you no longer have a rollout plan.

This is worth checking on your own domain today, because a pct value published two years ago is still sitting in a lot of DNS records, doing nothing, while its owner believes enforcement is being applied gradually.

t=y is what replaced it

The t tag is the supported way to soften a published policy, and it works by demotion rather than by percentage. When t=y is set, a receiver applies the policy one level below the one you published:

You publish	With t=y, receivers apply
p=quarantine	none
p=reject	quarantine

Reports keep arriving normally the whole time. The difference from pct is that the softening applies to all of your mail rather than a random slice of it, which makes the results readable — with pct=10 you were sampling, and a clean week told you very little.

The default is t=n, meaning the policy you publish is the policy you mean.

np, psd, and the DNS Tree Walk

The Public Suffix List is no longer how receivers work out your organisational domain. Under RFC 7489, a receiver checking mail.shop.yourdomain.com consulted an external list to decide where your organisational boundary sat. The standard never specified which list or how often to update it, so different receivers reached different answers about the same domain.

The 2026 standard replaces this with a DNS Tree Walk: the receiver queries progressively higher levels of the domain, up to a maximum of eight queries, looking for a DMARC record carrying psd=n or psd=y. The boundary is now something you declare in your own DNS rather than something an external list decides for you.

For most senders this changes nothing you need to configure. It matters if you run a domain that others register under, and it is the reason psd exists.

np is the practical addition. It sets a policy for subdomains that have never existed, separately from subdomains that do. Without it, a spoofer using billing.yourdomain.com falls under whatever sp or p says — which during your monitoring phase is none.

The rollout, without pct

The shape of a safe rollout has not changed. The lever has.

Phase 1 — Monitor. p=none with rua and fo=1. Nothing about your mail delivery changes. Read reports until you can account for every source sending as your domain. This is where the time goes, and it takes longer than people plan for — the standard itself notes it may take many months of reading aggregate reports before a domain owner can be confident every legitimate sender is authenticating properly.

Phase 2 — Fix. For each failing sender, work out whether it is yours. If it is, the fix is nearly always one of two things: a return-path on the platform's domain instead of yours, or DKIM signing with the platform's key instead of one you published. Both are configuration changes on the platform's side, not changes to your DNS. If the sender is not yours, you have found a spoofer, and DMARC is already doing its job by reporting it.

Phase 3 — Test enforcement. Publish p=quarantine; t=y. Receivers treat it as none, so nothing changes for your recipients, but you are now running the exact record you intend to enforce and can confirm it parses and reports as expected.

Phase 4 — Enforce. Remove t=y. Your quarantine policy is now live. Watch reports closely for two weeks; this is when a forgotten sender surfaces as complaints from real people.

There is no fixed timetable for this, and any guide that gives you one is guessing about your sending. The gate for each phase is the same: the reports are clean, and you can name every sender in them.

Where to stop: the p=reject question

Most DMARC advice treats p=reject as the finish line and everything short of it as incomplete. That framing comes largely from companies selling DMARC enforcement, and it is worth knowing what the standard actually says.

RFC 9989 tells receivers not to reject a message solely because your policy says reject. The wording is explicit: Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject", and should apply other knowledge and analysis instead — specifically to avoid rejecting legitimate messages sent in ways DMARC cannot describe, and to avoid harming the operation of mailing lists.

Two things follow from that.

The first is that p=reject is not the absolute switch it is sold as. Receivers weigh it alongside everything else they know about you. A domain at p=quarantine with strong reputation and clean reports is in a better position than a domain at p=reject with poor reputation.

The second is the mailing list problem, and it is real. Mailing lists routinely modify subject lines and bodies, which breaks the DKIM signature, and they resend from their own infrastructure, which breaks SPF alignment. A subscriber on a p=reject domain can find their list posts bouncing for everyone. The standard names this as a reason receivers should exercise judgement.

The standard does not tell you which policy to end on. It leaves that to you, based on how you send. What it does say is that the decision should come after you are satisfied every legitimate source is authenticating — which is a reports question, not a calendar question.

If your domain sends transactional and marketing mail from infrastructure you control, and nobody is posting to mailing lists from it, p=reject is reasonable. If your domain hosts staff mailboxes and those people participate in lists and forward mail, p=quarantine is a defensible place to stop and you should not be talked out of it.

Common mistakes

Publishing two DMARC records. Like SPF, one record per domain. Two records is a configuration error and receivers may ignore both.

Putting the record on the wrong host. It goes at _dmarc.yourdomain.com, not on the root domain. A DMARC record at the apex does nothing.

Setting rua and never reading it. A monitoring policy nobody monitors is a decoration. If the reports pile up unread for six months, you have not been in phase 1 — you have been doing nothing with extra steps.

Jumping straight to p=reject. The classic version of this is a domain that goes to enforcement on day one, and then discovers three weeks later that the invoicing system nobody thought about has been failing the whole time.

Assuming pct still works. Covered above, and worth repeating because it is now the single most common stale instruction in DMARC guidance.

Treating DMARC as a deliverability fix. DMARC is authentication and anti-spoofing. It is a requirement for bulk senders and it removes a category of problem — but a domain with a clean p=reject record and a 0.4% complaint rate still lands in spam. Authentication is necessary and nowhere near sufficient.

What this article deliberately leaves out

This covers the record and the rollout for a single domain. It does not cover the parts that need more room than a article can give:

• Domain architecture — running marketing, transactional and cold outreach on separate subdomains so one problem cannot take down the others
• The day-by-day implementation sequence, including what to change first when you are fixing a live domain that cannot afford downtime
• Reading aggregate reports at volume, when you have hundreds of source IPs rather than four
• What to do when enforcement surfaces a sender you cannot fix and cannot switch off

The Email Deliverability Playbook covers these across its 36 chapters, and includes a 14-day implementation plan that sequences the DNS work against live sending, a 100-point audit scorecard for checking a domain before and after, and a provider quick-reference card for the Gmail, Yahoo and Outlook rules. It is $29 as a PDF, with a 30-day refund.

Get The Email Deliverability Playbook →