Domain
Tags
Reporting
Your record
How it works
Week 0 — p=none
Publish with a rua address. Change nothing else. Read the reports.
Week 2 — quarantine
Once reports show only your intended senders, failing mail goes to spam.
Week 4 — reject
Full enforcement, with np=reject alongside it. Spoofed mail is refused at the door.
Pick a policy
quarantine is the working default for sending domains. reject belongs on your brand domain.
Add a rua address
Without it you get enforcement and no visibility into who is sending as you.
Set alignment
Relaxed is right for nearly everyone. Strict requires an exact domain match with no subdomains.
Publish as TXT
Host _dmarc, type TXT, TTL 3600. Copy the record and paste it into your DNS provider.
What to publish, by domain type
A brand-new sending domain. One provider, no legacy senders, nothing to discover. Start at p=quarantine immediately — there is no monitoring period to serve because you already know exactly what sends from it.
An established corporate domain. Start at p=none with a rua address and leave it for two weeks. You are looking for the CRM, the helpdesk, the invoicing tool and the marketing platform that somebody set up years ago and nobody remembers. Tighten only once reports are clean.
Your primary brand domain. This is the one attackers actually spoof. It should end at p=reject, with np=reject alongside it to cover subdomains that were never created. Anything less leaves a gap that reject exists to close.
The tags people get wrong
pct is gone. It was a rollout dial — enforce on 10%, then 50%, then everything — but receivers applied it so inconsistently that RFC 9989 removed it. If you still have a record sitting at pct=10, that is a rollout somebody abandoned, and it reads as a full policy while enforcing on one message in ten.
sp is easy to forget because omitting it is usually correct — subdomains inherit p. The danger is setting it to none, which unlocks every subdomain while the root looks locked down.
ruf is mostly vestigial. Very few providers send forensic reports, and those that do may include recipient addresses, which brings privacy considerations. Most working setups leave it blank.
Updated for the 2026 DMARC standard
In May 2026 the IETF published RFC 9989, 9990 and 9991, replacing RFC 7489 which had defined DMARC since 2015. Records still start with v=DMARC1 and everything already published stays valid — but the tag set changed, and this generator produces records against the current spec rather than the old one.
pctis gone. It let you apply a policy to a share of failing mail, but receivers implemented it so inconsistently that only 0 and 100 behaved predictably. This generator no longer emits it.treplaces it. A binary testing flag —t=ytells receivers the policy is provisional and should not be enforced. It is the honest version of what a lowpctwas trying to express.npis new. A policy for subdomains that do not exist in DNS at all, which is the route used to spoof plausible-sounding addresses likebilling.yourdomain.comthat were never registered. No legitimate mail comes from a subdomain that does not exist, sonp=rejectis a low-risk addition on most domains.rfandriare deprecated too. Both were ignored in practice and have moved out of the core specification.
Receiver support for np and t rolls out gradually, so treat them as additions rather than replacements for a correct p and sp. If an existing record still carries pct, the DMARC checker will flag it.
Frequently asked questions
What TTL should I use for the DMARC record?
3600 seconds is a sensible default. Lower it to 300 while you are actively changing policy so mistakes can be rolled back quickly, then raise it once the record settles.
Can one rua address collect reports for many domains?
Yes, and for a sending fleet you should. Point every domain at the same mailbox. The one requirement is that if the address is on a different domain from the policy, that domain must publish an authorisation record — see the note in the DMARC checker FAQ.
Will DMARC break my cold email?
No — publishing DMARC does not restrict your own sending. It tells receivers what to do with mail that fails authentication while claiming to be from your domain. If your SPF and DKIM are correct, your own mail passes and is unaffected. The only way DMARC blocks your mail is if it was never authenticating properly to begin with, which is worth discovering.
Do I need a separate DMARC record for each subdomain?
Not usually. Subdomains inherit the parent policy, or the sp value if you set one. Publish a subdomain record only when that subdomain needs a different policy from the parent — for example a marketing subdomain you want to keep at quarantine while the root is at reject.
Does this generator still support the pct tag?
No, deliberately. pct was deprecated in RFC 9989 because receivers applied it inconsistently — in practice only pct=0 and pct=100 behaved predictably. If you were reaching for a low pct to stage a rollout, tick the testing option instead, which publishes t=y and tells receivers the policy is provisional.
Should I set np=reject?
On most domains, yes. np applies only to subdomains that do not exist in DNS, and no legitimate mail can originate from a subdomain that was never created — so rejecting it costs you nothing and closes a spoofing route that p and sp leave open. Leave it on inherit if you have unusual DNS where subdomains are created dynamically.
What is the difference between sp and np?
sp sets the policy for subdomains that exist — mail.yourdomain.com, news.yourdomain.com. np sets it for subdomains that do not exist at all. If np is unset it falls back to sp, and if sp is also unset it falls back to p.
Will an RFC 9989 record break older receivers?
No. The version tag is still v=DMARC1 and there is no DMARC2. Receivers that have not implemented the new specification ignore tags they do not recognise, so np and t are simply skipped while p, sp, rua and the alignment tags work exactly as before.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.