Photo by Chris Ried on Unsplash
Most DMARC records on the public internet are wrong.
Not invalid — wrong. They parse fine. They just don’t do what the person who set them up thought they were doing. The most common problem: a record with p=none and no rua=, sitting in DNS for two years, doing absolutely nothing.
This is the guide for setting one up properly the first time, with a record you can copy, the tags you actually need to understand, and the three mistakes that will brick your legitimate mail flow if you skip them.
If you’d rather skip the explanation and just generate a record, our free Email Authentication Checker has a built-in DMARC generator at the bottom of the page. Fill in the form, copy the result, paste it into your DNS. Done in two minutes.
Otherwise — here’s what’s going on.
The TXT record that ties SPF and DKIM together
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. The name is a mouthful. The job is simple: when a recipient checks your email against SPF and DKIM, DMARC tells them what to do if either one fails — and where to send reports about it.
The record itself is a DNS TXT record published at a specific subdomain: _dmarc.yourdomain.com. Receiving servers look it up there.
A minimal valid DMARC record looks like this:
v=DMARC1; p=none;That’s it. Two tags. A version declaration and a policy. It’s valid. It’s also useless — it tells receivers “if SPF or DKIM fail, do nothing, and don’t tell me about it.” Which is the equivalent of installing a security camera that doesn’t record.
The version tag (v=DMARC1) is fixed. Don’t change it. Every other tag adds real behavior.
The 8 tags you might use (and what each does)
You’ll see references to 11+ tags floating around online. Most of them are either deprecated or so rarely needed they aren’t worth memorizing. Here are the eight that matter, ordered roughly by how often you’ll touch them.
p= — policy. What receivers should do with mail that fails DMARC. Three values:
none→ take no action, just monitor.quarantine→ send to spam/junk folder.reject→ bounce outright before delivery.
Start at none. Always. We’ll get to why.
rua= — aggregate reports. Where receivers send daily aggregate reports of DMARC pass/fail data. Format: rua=mailto:dmarc@yourdomain.com. This is the tag that turns DMARC from “do nothing” into “tell me what’s actually happening.” Without it, you’re flying blind.
pct= — percentage. What percent of failing mail to apply the policy to. Default is 100. Use lower values (e.g., pct=25) when transitioning from quarantine to reject — apply the stricter policy to only a quarter of mail first, monitor, then ramp up.
sp= — subdomain policy. Policy to apply to mail from subdomains (marketing.yourdomain.com, noreply.yourdomain.com, etc.). Defaults to the same value as p=. Set explicitly when you want different behavior for subdomains.
aspf= and adkim= — alignment modes. How strict to be about matching the From header domain to the SPF/DKIM domains. Values are r (relaxed, default) or s (strict). Relaxed lets subdomains match the parent domain — strict requires an exact match. Almost everyone wants relaxed. Strict will break legitimate mail from your CRM, your transactional sender, and your help desk.
ruf= — forensic reports. Per-failure reports sent in real time. Almost no major receivers send these anymore due to privacy concerns. Don’t waste a tag on it.
fo= — failure reporting options. Granular control over when forensic reports get generated. Same deal as ruf — rarely useful in practice.
A safe starting record (copy this)
If you have no DMARC record today, start here:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100;Replace dmarc@yourdomain.com with an inbox you actually monitor. (Pro tip: use a mailbox dedicated to it. Aggregate reports come in as XML attachments and there can be dozens per day from different providers.)
That record does three things:
1. Declares DMARC enabled. 2. Tells receivers to take no action on failing mail — yet. 3. Asks for daily aggregate reports so you can see what’s failing and why.
This is the most important step in the DMARC rollout sequence. You’re collecting data before you start enforcing. Most failures will be from systems you forgot about — that abandoned newsletter platform, the CRM nobody told you was sending invoices, the legacy server you decommissioned but didn’t remove from your SPF.
Let it run for two to four weeks. Read the aggregate reports. Find every legitimate sender that’s failing alignment. Fix their setup — either add them to SPF or get DKIM working. Then you can tighten the policy.
Where to publish it
This trips up roughly half the people who try DMARC for the first time.
The record goes at a TXT record on _dmarc.yourdomain.com. Not on yourdomain.com. Not on dmarc.yourdomain.com. The exact name is _dmarc — with the underscore.
If you use Cloudflare DNS, the UI strips the trailing domain in the form. Type _dmarc in the name field; Cloudflare will store it as _dmarc.yourdomain.com. Same pattern for most other providers.
If your DNS provider asks for a “fully qualified name,” type _dmarc.yourdomain.com in full.
The value is the record itself, with or without surrounding quotes (most providers handle either). TTL of 3600 (one hour) is fine while you’re iterating. Drop it to 300 if you expect to change the record several times in a row.
To verify it published correctly, do a TXT lookup: dig TXT _dmarc.yourdomain.com from a terminal, or use any DNS lookup tool. The record should come back exactly as you typed it.
The three biggest DMARC mistakes
We’ve seen these three patterns wreck legitimate mail flows enough times to call them out specifically.
1. Going straight to p=reject on day one. This is the worst mistake. You publish a strict policy without first auditing what’s failing alignment. The next day, the survey tool your support team uses gets all its emails rejected by Gmail because it sends through a third-party domain that isn’t in your SPF and doesn’t sign with DKIM aligned to you. Nobody mentions it for three weeks because it’s email — people just assume it didn’t go through.
Don’t do this. p=none for at least a month before tightening. Even then, ramp through pct=10 → pct=25 → pct=50 → pct=100 over weeks, not days.
2. Skipping rua=. A DMARC record without rua= is theater. You’ve published the record but you have no visibility into whether anything is passing or failing. You won’t know your CRM is failing alignment until a customer asks why they stopped getting receipts. Set up an inbox, add it to rua=, and check it. The reports are XML but free aggregators (Postmark’s DMARC Digest, dmarcian, Valimail) parse them into readable dashboards.
3. Forgetting subdomains. If p= is set but sp= isn’t, subdomains inherit the parent’s policy. So marketing.yourdomain.com ends up under p=reject if you set the parent to reject. If marketing is sending through Mailchimp without proper alignment, every campaign gets bounced. The fix: explicit sp= set to a looser policy until you’ve verified subdomain senders are aligned. sp=none while you transition, then bring it in line with p=.
Going from p=none to p=reject (without breaking your mail)
The rollout has a rhythm. Use it.
Weeks 1–4: Monitor. Publish p=none; rua=mailto:.... Read the reports. Identify every sender failing alignment. Fix them one by one — add them to SPF, enable DKIM, get them sending through your authenticated infrastructure.
Weeks 5–8: Quarantine, gradually. Move to p=quarantine; pct=25. Twenty-five percent of failing mail now goes to spam. Watch the reports. If a legitimate sender is still failing, it’ll surface as user complaints. Fix it, then bump pct= to 50, then 75, then 100.
Weeks 9+: Reject. Same gradual ramp with p=reject. Start at pct=25, give it a week, bump up. By the time you hit p=reject; pct=100, you’ve had three months of data showing nothing legitimate is failing. The policy is now actually protecting you.
This is slower than people want. It is also the only way to do it without taking out your own legitimate mail flow. The senders who skip the ramp are the ones we get called to debug six weeks later.
Generate it, then check it
If you’ve made it this far, you understand DMARC better than most people who’ve published a record. The next step is to publish one — and to verify it’s doing what you think.
Our free Email Authentication Checker generates a valid DMARC record from a form (policy, reporting address, percentage, subdomain handling) and checks your existing SPF, DKIM, and DMARC in one place. No signup. Runs in your browser.
But DMARC is the second half of deliverability, not the first. Even with perfect authentication, a dirty list will torch your sender reputation faster than DMARC can defend it. Authentication proves you are who you say you are. It doesn’t help if who you say you are is sending to thousands of dead addresses.
Verify 100 emails free → — clean the list, then publish the DMARC record. In that order.
