How to Validate a DMARC Record Before You Publish It (Tag by Tag)

A DMARC record only works if it parses the way the standard says it should, and the cheapest time to find a mistake is before you publish it. The format is defined in RFC 7489, which we read for this post on 9 November 2026. Section 6.3 says the v and p tags must be present and must appear in that order, and that unknown tags must be ignored. That last rule is the dangerous one: a misspelled tag does not produce an error, it is skipped.

The free DMARC record validator checks a pasted record tag by tag against those rules and returns errors, warnings and notes, and the host name to publish it at. Below is what it checks and why.

Validate a DMARC record →

Where the record lives

Section 6.1 of the standard says domain owner preferences are stored as DNS TXT records in subdomains named _dmarc. For example.com the record is a TXT record at _dmarc.example.com. Type your domain into the validator's optional field and it prints that host name. Many DNS panels add the domain for you, so you enter only _dmarc in the name box; if yours does not, a name that ends up as _dmarc.example.com.example.com is the classic mistake.

To see what is live right now, how to check a domain's DMARC record shows the lookup, and DMARC record not found lists the usual reasons it is missing.

The tags, and what the validator checks

Tag	Meaning	Allowed values and default (RFC 7489 section 6.3)
v	Version	Must be DMARC1 and must come first
p	Policy for the domain	none, quarantine or reject; required; must come second
sp	Policy for subdomains	Same values; if absent, p applies to subdomains
adkim	DKIM alignment	r (relaxed) or s (strict); default r
aspf	SPF alignment	r or s; default r
pct	Share of failing mail the policy applies to	Whole number 0 to 100; default 100
rua	Where aggregate reports go	Comma-separated list of URIs
ruf	Where failure reports go	Comma-separated list of URIs
fo	Failure report options	Default 0
ri	Report interval	32-bit unsigned integer of seconds; default 86400
rf	Report format	Default afrf

The validator flags as errors the things that make a receiver ignore or misread the record: a missing v, a v that is not DMARC1, a missing p, a p that is not in second place, and a value outside the allowed set, such as p=quarantined or pct=150. It flags as warnings things like a duplicated tag or a rua address that is not a mailto: URI. It flags as notes things that are legal but worth knowing: p=none is monitoring only, there is no rua so no reports will arrive, pct is under 100, or a tag it does not recognise.

The mistakes that matter most

1. v not first. A leading space, a BOM from a paste, or a quote character in front of v=DMARC1. Receivers discard a record that does not begin with a valid version tag.
2. p not second. People put rua before p out of habit. The standard says v and p appear in that order.
3. Smart quotes or stray characters from a document. The validator accepts quoted or split strings the way a receiver joins them, and flags what is left.
4. A typo in a tag name. adkimm=s is an unknown tag and is ignored, so you get relaxed alignment and no error.
5. rua without mailto:. Receivers must support mailto: for report URIs, so use rua=mailto:name@yourdomain.com.
6. Two records. Section 6.6.3 says that if the remaining set contains multiple records, policy discovery terminates and DMARC is not applied to the message. If a past setup left one behind, you now have none in effect. The zone file audit lists duplicates in a pasted zone.

A sensible starting record

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

It has the two required tags in the right order and asks for aggregate reports. Run it through the validator, publish it, and read the reports for a few weeks before tightening. DMARC record examples shows variations, and moving from none to reject covers the path. Reading DMARC aggregate reports explains what arrives.

What DMARC cannot tell you

DMARC answers one question: when a message claims to be from your domain and fails SPF and DKIM alignment, what should the receiver do? It cannot tell a receiver whether the recipient exists, and it cannot reduce your bounces. A domain at p=reject with a clean authentication setup can still send to a list full of dead addresses and still be judged on the bounces.

So treat the two as separate jobs with separate tools:

• Authentication (SPF, DKIM, DMARC): set once, validated with the DNS tools, rechecked when you add a sending service.
• List quality: repeated every campaign, handled by verification.

SPF, DKIM and DMARC explained shows how the first three relate, and what is DMARC alignment covers the adkim and aspf settings.

Before you send from a newly authenticated domain

1. Validate the DMARC record with the validator.
2. Check each DKIM key with the DKIM key length checker.
3. Verify the list at /verify. Suppress invalid addresses for good.
4. Send valid rows first. Send risky rows in a small, slower group afterwards.
5. Read the first aggregate reports when they arrive.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.