Overview
Introduction
SPF and DKIM each verify one piece of a message's legitimacy on their own, but neither one tells a receiving mail server what to actually do when a check fails, or where to report the results, which is the gap DMARC closes.
This tool looks up a domain's DMARC record and breaks its tags apart individually, so a missing policy or an out-of-range percentage is obvious at a glance instead of buried in one long string.
What Is DMARC Record Checker?
A DMARC DNS record lookup and validator that queries _dmarc.<domain> for a TXT record starting with v=DMARC1 and decodes its policy, alignment, and reporting tags.
It's part of this site's DNS & Domain Tools collection, alongside the DKIM and SPF checkers that cover the other two legs of email authentication; the DNS lookup is a real, live query to a public resolver.
How DMARC Record Checker Works
The domain is queried as _dmarc.<domain> for a TXT record, and any records starting with v=DMARC1 are collected; more than one is flagged since only one is valid per RFC 7489.
The record's semicolon-separated tags (p=, sp=, pct=, rua=, ruf=, adkim=, aspf=, fo=) are parsed individually, and each is checked against its allowed values: p= and sp= must be none, quarantine, or reject; pct= must be an integer 0-100; adkim= and aspf= must be r or s.
When To Use DMARC Record Checker
Use it right after publishing a DMARC record, to confirm it parses the way you intended before mail receivers start acting on it.
It's also useful for auditing a domain you don't control, like checking whether a vendor sending mail on your behalf has published a policy strict enough to trust.
Often used alongside DKIM Record Checker and SPF Record Checker.
Features
Advantages
- Validates tag values against RFC 7489's allowed set instead of just showing the raw string, catching typos like p=qurantine that would otherwise silently fall back to no policy.
- Flags the specific, common misconfigurations (missing policy, out-of-range percentage, duplicate records, no report address) rather than requiring you to know what to look for.
Limitations
- Only validates the record's syntax and tag values; it doesn't verify that a domain's actual outgoing mail passes SPF or DKIM alignment.
- Doesn't fetch or interpret actual DMARC aggregate (rua) or forensic (ruf) reports, only whether an address is configured to receive them.
Examples
Best Practices & Notes
Best Practices
- Roll a new DMARC policy out gradually: start at p=none with rua= configured to monitor reports, then move to quarantine and finally reject once you've confirmed legitimate senders aren't failing alignment.
- Set adkim=s and aspf=s (strict alignment) only once you're certain every legitimate sending source uses a From: domain that exactly matches its SPF/DKIM domain, since strict mode is unforgiving of subdomain mismatches.
Developer Notes
Tag parsing splits on ';' and the first '=' in each segment, mirroring the DKIM checker's approach, since values like rua= can themselves contain '=' inside a mailto: URI's query string that a naive split("=") on every occurrence would corrupt. Only TXT records whose text starts with 'v=DMARC1' are counted toward the duplicate-record check, so unrelated TXT records at the same name (uncommon, but possible) don't produce a false 'multiple records' warning.
DMARC Record Checker Use Cases
- Verifying a DMARC record was published correctly right after configuring it
- Auditing whether a domain's DMARC policy is strict enough (quarantine/reject) to actually stop spoofed mail, versus a monitoring-only none policy
- Checking that an rua= reporting address is present before assuming DMARC failures are being tracked anywhere
Common Mistakes
- Publishing a second DMARC record instead of editing the existing one, which most receivers treat as invalid DMARC entirely rather than merging the two.
- Jumping straight to p=reject without first running p=none and reviewing aggregate reports, which can silently block legitimate mail from a sending source that wasn't accounted for.
Tips
- Check SPF and DKIM for the same domain alongside DMARC, since a reject policy only matters once both underlying checks are configured to actually pass for legitimate mail.