DMARC Record Checker

How the DMARC check works

Enter a domain and the tool performs a live DNS lookup of the _dmarc.<domain> TXT record, then grades the policy it finds. It reads the key tags — p (policy), sp (subdomain policy), rua (aggregate reports), pct (coverage), and alignment settings — and tells you in plain English whether your domain is actually protected or merely monitoring.

From monitoring to enforcement

A record at p=none is the most common — and most dangerous — finding: it looks like DMARC is "set up," but spoofed mail still lands. Move toward p=reject deliberately: confirm your SPF and DKIM are aligned for every legitimate sender first, then tighten the policy. Build a correct record with the DMARC generator. Learn the terminology in the email spoofing and business email compromise glossary entries.

DMARC record tags explained: a tag-by-tag reference

Every DMARC record is a single TXT string of semicolon-separated tags. Running a DMARC record lookup shows you the raw string; this reference decodes what each tag controls so a DMARC analyzer report is readable at a glance.

• v is the version and must be the first tag, always v=DMARC1. If it is missing or misspelled, receivers ignore the record entirely.
• p is the policy for the From-header domain: p=none (monitor only), p=quarantine (send failing mail to spam), or p=reject (refuse it at the gateway).
• sp is the policy applied to subdomains. If absent, subdomains inherit p; set it explicitly (for example sp=reject) to control them independently.
• pct is the percentage of failing mail the requested policy is applied to, valid from pct=0 to pct=100. The remaining messages get the next-lower action (reject falls back to quarantine, quarantine to none), so pct=0 means effectively none of the mail receives the requested policy. pct=100 is the default and the goal.
• rua lists the addresses that receive aggregate XML reports (typically daily, at the interval requested by ri), as mailto: URIs (for example rua=mailto:[email protected]). These reports reveal every source sending as your domain.
• ruf lists addresses for per-message forensic (failure) reports. Support is limited and reports may contain redacted headers, so many receivers never send them.
• adkim sets DKIM alignment strictness: adkim=r (relaxed, default) requires the DKIM d= domain and the From domain to share an Organizational Domain (so subdomains align); adkim=s (strict) requires the d= domain to exactly equal the From domain.
• aspf sets SPF alignment strictness: aspf=s (strict) requires the SPF-authenticated domain (the RFC5321.MailFrom / envelope-from domain) to exactly equal the From header domain; aspf=r (relaxed, default) requires only that their Organizational Domains match.
• fo sets failure-reporting options: fo=0 (default) reports only when both SPF and DKIM fail, fo=1 reports when either fails, fo=d on any DKIM failure, fo=s on any SPF failure.
• rf names the forensic report format, effectively always rf=afrf (the Authentication Failure Reporting Format defined in RFC 6591).
• ri is the requested interval in seconds between aggregate reports, defaulting to ri=86400 (24 hours). Receivers treat this as a hint, not a guarantee.

Use this alongside the SPF checker and DKIM checker, since DMARC alignment only passes when SPF or DKIM authenticates against the same domain your recipients see in the From header.

DMARC misconfigurations this checker flags

DMARC record validation is less about syntax and more about whether the record actually blocks spoofing. These are the specific problems the analyzer surfaces, ranked by how much exposure they leave open:

• No record at all: nothing is published at _dmarc.<domain>, so receivers have no policy to enforce and anyone can send as your domain. This is the baseline state exploited in email spoofing and business email compromise.
• p=none mistaken for real protection: the record exists and reports flow, but failing mail is still delivered. Monitoring is a starting point, not a defense.
• Missing rua: with no aggregate reporting address you are blind to which servers send as your domain, so you cannot safely tighten the policy without breaking legitimate mail.
• pct left below 100 indefinitely: partial coverage is fine during rollout, but any value under pct=100 permanently leaves a share of spoofed mail on the policy you are trying to escape.
• Missing sp: without a subdomain policy, an attacker can spoof invoices.<domain> or any unused subdomain even when the root domain is at p=reject.
• Syntax errors: a stray space, a missing semicolon, v=DMARC1 not first, or an invalid mailto: can make receivers discard the whole record so no policy applies.
• More than one _dmarc TXT record: publishing two DMARC records is a protocol violation, and per RFC 7489 receivers that find multiple records apply none of them, silently disabling your protection.