DMARC Record Examples: 12 Copy-Paste Records, Explained Tag by Tag

A working DMARC record is a single TXT record at _dmarc.yourdomain.com. The minimum useful version is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The 12 examples below go from that starting point to full enforcement, plus the special cases (subdomains, domains that never send mail, third-party report services, failure reports), with every tag explained.

Every record here can be built or adapted in our DMARC generator, which handles p, sp, pct, rua and strict alignment. Add the other tags by hand. Once it's live, confirm what receivers see with the DMARC checker.

A note on standards. The tag definitions below come from RFC 7489, the 2015 specification nearly every receiver implemented, and RFC 9989, which replaced it in May 2026. Where the two differ, the example says so. If you're deciding when to move between these records, that's covered in moving DMARC from p=none to p=reject. This post is the reference.

The tags at a glance

Tag	Meaning	Default	Status
v	Version, must be DMARC1 and must come first	Required	Both RFCs
p	Policy for the domain: none, quarantine, reject	none if missing (RFC 9989)	Both
sp	Policy for existing subdomains	Inherits p	Both
np	Policy for non-existent subdomains	Inherits sp, then p	RFC 9989 (from RFC 9091)
rua	Where to send aggregate reports	None, so no reports	Both
ruf	Where to send failure reports	None	Both
fo	When to generate failure reports	0	Both
adkim / aspf	DKIM / SPF alignment: r relaxed or s strict	r	Both
pct	Percentage of failing mail the policy applies to	100	RFC 7489 only; removed in RFC 9989
t	Testing mode: y or n	n	RFC 9989 only
ri, rf	Report interval, failure report format	86400, afrf	RFC 7489 only; removed in RFC 9989
psd	Marks a public suffix domain	u	RFC 9989; not for ordinary domains

Both RFCs say unknown tags must be ignored, which is why old and new tags can safely sit in the same record.

Monitoring records

1. The starting record

v=DMARC1; p=none; rua=mailto:dmarc@example.com

• v=DMARC1: identifies the record. RFC 9989 says this tag "MUST be the first tag in the list".
• p=none: no change to how failing mail is handled. You're asking for data, not enforcement.
• rua=mailto:dmarc@example.com: receivers that send reports will email daily aggregate XML files here. RFC 9989 is explicit that without rua, receivers "MUST NOT generate aggregate feedback reports".

Use this the day you start. A p=none record with no rua is the least useful DMARC record there is: it meets the Gmail and Yahoo "at least p=none" requirement and tells you nothing.

2. Monitoring with two report destinations

v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:x7k2@reports.dmarc-vendor.example

• rua takes a comma-separated list. Here, one copy goes to your own mailbox and one to a report-parsing service, which turns the XML into something readable.

Aggregate reports arrive as compressed XML from every participating receiver, every day. Above a few thousand messages a day, few teams read them raw.

3. Monitoring with strict alignment

v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc@example.com

• adkim=s: the DKIM d= domain must exactly match the From domain. mail.example.com no longer aligns with example.com.
• aspf=s: the same for the SPF (envelope sender) domain.

Most domains should leave both at the relaxed default. Strict alignment breaks every platform that signs or bounces through a subdomain of yours. Run it at p=none first so the reports show what would fail.

Enforcement records

4. Quarantine a percentage (RFC 7489 style)

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

• p=quarantine: failing mail should be treated as suspicious, usually meaning the spam folder.
• pct=25: RFC 7489 says receivers "MUST NOT enact the requested policy" on more than 25% of failing mail. The other 75% gets the receiver's normal filtering.

This is the record most older guides recommend. RFC 9989 removed pct because, in its words, it "was usually not accurately applied, unless the value specified was either 0 or 100". A receiver on the new standard ignores it and applies p=quarantine to everything that fails.

5. Quarantine in testing mode (works under both standards)

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc@example.com

• t=y: RFC 9989 testing mode. The receiver applies the policy "one level below" what you published, so quarantine becomes none.
• pct=0: the RFC 7489 equivalent. Failing mail is not subject to quarantine and gets local classification instead.

Both readers end up roughly at "don't quarantine yet, but report". This is a dress rehearsal you can publish before record 6.

6. Full quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

With no pct or t, the defaults (100 and n) apply: all failing mail is quarantined.

7. Reject in testing mode

v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc@example.com

• t=y with p=reject means quarantine under RFC 9989.
• Under RFC 7489, mail excluded from reject by pct "SHOULD" be treated "as though the 'quarantine' policy applies".

Both standards agree here exactly, which makes this the safest step between records 6 and 8.

8. Full reject

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

• p=reject: receivers are asked to refuse failing mail during the SMTP conversation. Nothing is delivered, so nobody can rescue a false positive from a spam folder.

Keep rua here. Reports are how you notice a new tool someone in marketing connected without setting up DKIM.

Subdomain records

9. Reject on the main domain, softer on subdomains

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

• sp=quarantine: applies to existing subdomains (news.example.com, billing.example.com) without their own DMARC record. Both RFCs say that if sp is absent, subdomains get the p policy.

Useful when the main domain is clean but a subdomain still has a sender you haven't fixed. Go the other way (p=quarantine; sp=reject) if your subdomains are tightly controlled and the main domain isn't yet.

10. Block made-up subdomains

v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com

• np=reject: RFC 9989's policy for subdomains that don't exist in DNS, such as secure-login.example.com. It "applies only to non-existent subdomains", not to real subdomains or the domain itself.

Since nothing legitimate can send from a subdomain that doesn't exist, np=reject is usually safe long before p=reject is. Receivers that don't recognise np ignore it and fall back to sp, then p.

11. A subdomain with its own record

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

A record published directly on a subdomain wins for that subdomain. Note that sp inside a subdomain's own record is ignored; both RFCs say so, because subdomain policy is read from the organizational domain's record.

12. A domain that never sends mail

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s

For parked domains and domains used only for websites. Every message claiming to be from them is fake, so reject everything. Pair it with an SPF record of v=spf1 -all (no server may send) so receivers have a clear SPF fail as well. Adding rua is optional. It shows you who is spoofing the domain, which is interesting but rarely actionable.

Reporting variations

Sending reports to a third-party service

When the rua address is on a different organizational domain from yours, receivers check that the destination agreed to receive your reports. RFC 7489 (section 7.1) and its successor RFC 9990 describe the check: the receiver looks for a TXT record built from your domain, _report._dmarc, and the destination's domain.

example.com._report._dmarc.dmarc-vendor.example.  TXT  "v=DMARC1"

The reporting service publishes this, not you. If reports aren't arriving at a vendor, look this record up first. RFC 7489 also allowed a size limit suffix such as !10m on report addresses. RFC 9989 removed it, so leave it off new records.

Asking for failure reports

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1

• ruf: where to send per-message failure reports.
• fo=1: generate a report if any mechanism fails to produce an aligned pass. The default fo=0 reports only when all fail. fo=d and fo=s request DKIM-specific or SPF-specific failure reports.

Expect few. Receiver support for failure reports is much patchier than for aggregate reports, and RFC 9991, which now defines them, warns they "may contain Personally Identifiable Information". Use a mailbox with restricted access.

Mistakes we see in real records

• Two DMARC records on one name. Publish exactly one TXT record starting v=DMARC1 at _dmarc. RFC 7489 says that if discovery finds multiple records, "DMARC processing is not applied", so two records are as good as none.
• Record on the wrong name. It goes at _dmarc.example.com, not example.com.
• v=DMARC1 not first. Both RFCs require it as the first tag.
• rua without mailto:. A bare email address isn't a valid URI.
• Quotation marks and semicolons copied wrong. Many DNS panels add the outer quotes for you. Curly quotes pasted from a document will break the record.
• Jumping straight to p=reject. Without a period of reports at p=none, you won't know which of your own tools fail.

For a broader view of how these records sit alongside SPF and DKIM, see SPF, DKIM and DMARC explained. For how other companies have set theirs, our DMARC adoption study shows which policies 200 SaaS companies publish.