DMARC Record Setup: A Correct Example and How to Check It

What a DMARC Record Actually Does

A DMARC record is one line of DNS text, and that deceptive simplicity is why so many of them do nothing. You publish a TXT record, the tools go green, and you assume spoofing is handled. It usually isn’t — either the policy is set to observe-only and no one is reading the reports, or the record is enforcing a policy against mail that was never set up to pass it. Both failures are silent. That’s the trap worth understanding before you touch DNS.

Here is the thing to internalize first: DMARC has no opinion of its own. It does not inspect message content, it does not run a blocklist, it does not decide whether mail “looks like spam.” All it does is ask a narrow question — did SPF or DKIM pass, and does the domain that passed line up with the domain a human sees in the From: header? — and then tell the receiver what to do when the answer is no. That alignment check is the entire point. A message can pass SPF for some marketing vendor’s domain and still fail DMARC for yours, because the vendor’s domain isn’t your domain.

So a DMARC record does two jobs. It publishes a policy (what receivers should do with mail that fails), and it turns on reporting (so those receivers mail you daily XML summaries of who is sending as you). The reporting is the part people underuse and the part that actually makes DMARC safe to deploy.

A Correct Starting Record

Do not start at enforcement. The single most common way to break your own email is to publish p=reject on day one, before you know which legitimate services send on your behalf. Start here:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

That’s a complete, valid record. Piece by piece:

• v=DMARC1 — required, and must be first. Without it the receiver doesn’t recognize the record as DMARC and ignores the whole thing.
• p=none — the policy. none means “watch, don’t act”: receivers still send you reports but deliver failing mail normally. This is monitoring mode, and it’s where every deployment should begin.
• rua=mailto:[email protected] — where aggregate reports go. This is what makes the whole exercise worth doing. Point it at a mailbox you’ll actually read (or a report-parsing service).

From there the honest rollout is: publish p=none, read the aggregate reports for a few weeks until you can see every legitimate source and confirm it’s aligned, then raise the policy to quarantine, then to reject. That progression — and when it’s safe to move — is its own topic; see the DMARC none vs quarantine vs reject guide.

A few optional tags you’ll see and should understand:

• sp= sets a separate policy for subdomains. If omitted, subdomains inherit p.
• adkim= / aspf= control alignment strictness: r (relaxed, the default) allows a matching organizational domain; s (strict) demands an exact match. Leave them relaxed unless you have a specific reason.
• np= (new in 2026) sets policy for non-existent subdomains — the ones with no A/MX records at all, which attackers love to spoof. Closing that gap used to be impossible without wildcards.

What Changed in 2026 (and Why Your Old Advice Is Wrong)

In May 2026, DMARC finally graduated from an Informational document to a Standards Track protocol: RFC 9989 obsoletes the original RFC 7489 from 2015 (with RFC 9990 and 9991 covering the aggregate and failure report formats). Your existing v=DMARC1 records keep working — this is backward compatible — but a lot of the copy-paste advice still floating around now teaches things the standard removed.

The one that matters most: pct is gone. For a decade, pct=10 was the recommended way to phase in enforcement — apply the policy to only 10% of failing mail, then ramp up. It was implemented inconsistently across receivers and often ignored, so DMARCbis removed it (along with the little-used rf and ri tags). The replacement for staged rollout is the t tag: t=y marks the record as testing, t=n (the default) means enforce for real. If a generator or blog post hands you a record with pct= in it, it’s written to a version of DMARC that no longer exists.

The other quiet change is under the hood: receivers no longer consult the externally-maintained Public Suffix List to figure out your organizational domain. They walk up the DNS tree, checking each parent label for a DMARC record. You don’t publish anything different for this — but it’s why subdomain policy behaves more predictably now, and why the new np tag exists.

Top 3 Reasons Your DMARC “Isn’t Doing Anything”

1. The record exists but SPF/DKIM aren’t aligned. DMARC is a verdict on top of SPF and DKIM. If your legitimate mail passes SPF for a sending platform’s domain but not for yours, it fails alignment — and at p=none you’ll never notice, because failing mail is still delivered. This is exactly why you read the reports before enforcing.
2. You’re at p=none forever. Monitoring mode protects nobody. It’s the on-ramp, not the destination. A record stuck at p=none for a year is a record that has told the world’s receivers “do nothing about mail that forges my domain.” The whole value is in eventually reaching quarantine or reject.
3. No rua, so you’re flying blind. A record with a policy but no reporting address gives you a policy you can’t validate. You have no way to see which sources would be affected before you enforce, so raising the policy becomes a guess. Always publish rua.

Diagnose with DechoNet

• Email Check — run it against your domain to see SPF, DKIM, and DMARC together, parsed and validated. It flags a missing or malformed DMARC record, a policy still at none, and alignment problems in the sources it can see — the fastest way to confirm your record says what you think it says.
• DNS Lookup — check the raw TXT record at _dmarc.yourdomain directly. Confirm there’s exactly one record, that it begins with v=DMARC1, and that there isn’t a stray second DMARC record (which invalidates both). This is the ground truth beneath any DMARC checker.

Setup and Verification Checklist

• Confirm SPF and DKIM are set up and aligned for every legitimate sender first. DMARC without them just fails everything.
• Publish one TXT record at _dmarc.yourdomain starting with v=DMARC1; p=none;.
• Include a rua=mailto: address you will actually monitor. This is not optional if you ever intend to enforce.
• Verify it resolves: a DNS lookup should return exactly one v=DMARC1 string. Two records means no policy.
• Wait for aggregate reports to arrive (a day or two), then read them until you recognize every sending source.
• Only then raise the policy: none → quarantine → reject, watching reports at each step.
• Drop any pct= tag from records you copied from old guides; use t=y for a testing signal instead.

When to Escalate

• If reports keep showing a legitimate source failing alignment and you can’t fix it (a SaaS platform that won’t let you set up DKIM on your domain, say), that’s a sender-side configuration problem — take it to that vendor before you enforce, or your enforcement will bounce real mail.
• If you operate a public suffix domain (a registry, a large multi-tenant platform where independent parties hold subdomains), the psd tag and organizational-domain rules get materially more complex — read RFC 9989 directly rather than relying on generic guidance.