DMARC Record Checker

Paste a raw DMARC TXT record (the value you copy from your DNS zone) and get an instant breakdown of every tag in plain English. The checker validates structure, flags common misconfigurations — such as p=none with no reporting address, or a missing sp on domains with subdomains — and gives you an overall verdict on whether your policy actually protects against spoofing.

How to use the DMARC Record Checker

Copy the TXT record value from your DNS zone (it starts with v=DMARC1) and paste it into the field above. Click Check Record.

The tool parses every semicolon-separated tag and explains what each one does. It then runs the following validations:

• v= first: RFC 7489 requires v=DMARC1 to be the very first tag. If your record starts with anything else it will be silently ignored by mail receivers.
• p= required and valid: The policy must be none, quarantine, or reject. Missing p= invalidates the whole record.
• rua/ruf format: Must be valid mailto: URIs (or https: URIs). A bare email address without the mailto: prefix is invalid.
• pct range: Must be 0–100. Values outside this range are non-conforming.
• adkim/aspf values: Must be r (relaxed) or s (strict). Any other value is ignored.

After the tag breakdown you get an overall verdict: Monitoring (p=none), Partial Enforcement (quarantine), or Full Enforcement (reject). A p=none policy is monitoring-only and offers no spoofing protection — it is the right starting point but not a destination.

Understanding DMARC tag meanings

A DMARC record is a semicolon-delimited list of tag=value pairs. The only required tags are v=DMARC1 (which must appear first) and p= (the policy). Everything else is optional and defaults to specific values when omitted: pct=100, adkim=r, aspf=r, fo=0, and sp inherits the value of p when absent. These defaults matter — a record with only v=DMARC1; p=quarantine still applies 100% of the policy at relaxed alignment to all messages including from subdomains.

The most common misconfiguration is leaving a record at p=none indefinitely. This provides visibility but zero protection — a spoofed message sails straight through to the inbox. It is appropriate as a starting point while you identify all legitimate sending sources via aggregate reports, but should be treated as a temporary state. Similarly, omitting rua= from a p=none record is the worst of both worlds: no protection and no visibility. Check your records regularly — organisational changes (new ESPs, new sending domains) can break DMARC alignment months after a policy is set.

The sp= tag controls policy for subdomains separately, which is important for organisations that have mail.example.com or news.example.com sending email. If you want aggressive enforcement on the root domain but still have subdomains in setup, you can set p=reject sp=none to enforce the root while monitoring subdomains. Conversely, if subdomains should never send mail, sp=reject on a p=quarantine root blocks spoofing of all those subdomains immediately.

Common use cases

• Verify your record before going live — confirm the TXT value you are about to publish is syntactically valid and has the tags you intended before it is visible to all receivers.
• Audit existing domains — check every domain you own (including parked and inactive domains) for missing or weak DMARC policies that attackers could exploit.
• Diagnose deliverability issues — if mail is being quarantined unexpectedly, check whether pct is below 100 or alignment is stricter than your signing infrastructure supports.
• Compliance check — confirm p=reject is in place with a valid rua address, which is required by frameworks such as PCI-DSS v4.0 and CISA guidance.
• Validate third-party records — before trusting a vendor’s claim that they have set up DMARC on your domain’s behalf, paste their record here and verify every tag.