DNS Tools
EMAIL AUTHENTICATION

DMARC Checker

Enter a domain to find its DMARC record, including one inherited from a parent. The policy and the reporting destinations are assessed independently, because one does not affect the other.

Run DMARC check

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What DMARC is and what this tool reads

DMARC (RFC 7489, with the newer tree-walk discovery of RFC 9989) ties SPF and DKIM to the visible From domain. A receiver checks whether SPF or DKIM passed and whether the passing domain aligns with the From domain. The domain owner's record, published as TXT at _dmarc.DOMAIN, says what to do when neither does: p=none, p=quarantine or p=reject, and where to send reports.

The tool queries _dmarc at the domain you enter and walks up toward the organisational domain until it finds a record, so a subdomain without its own record shows the parent's policy and says it was inherited. Each step of the walk is displayed with its result.

How to read the result

Two findings are produced and they are deliberately separate. The policy finding describes what the record asks receivers to do. The reporting finding describes whether reports can actually arrive at the destinations in rua and ruf.

A policy of p=none is a monitoring policy. It requests reports without asking receivers to act on failures, which is the correct first stage of a rollout. It is not a fault by itself, and it does not mean reporting is working. Reporting depends on destinations, not on the policy value. The effective settings table also shows sp (subdomains), np (non-existent subdomains), pct, and the alignment modes adkim and aspf, where r is relaxed and s is strict.

External report destinations are authorised separately

If a rua or ruf address is on a different organisational domain, RFC 7489 section 7.1 requires that destination to opt in. The receiving domain publishes a TXT record at example.com._report._dmarc.REPORTING-DOMAIN containing v=DMARC1. Without it, compliant receivers drop the reports.

This is why a domain can have a perfectly valid p=none record and still receive nothing: the policy is fine, the reporting destination is not authorised. The tool checks each external mailto address and lists it as authorised, not authorised, or unchecked because DNS failed. Destinations in the same organisation need no authorisation. https destinations are not authorisation-checked here.

Common DMARC problems

  • No record anywhere in the walk. Every level answered and none had a record. The domain has no published policy.
  • More than one DMARC record at a name. All are discarded, so the domain behaves as if it had none.
  • Missing or invalid p=. A record without a valid policy tag is not usable.
  • Reports to an unauthorised external address. The record is valid, but the reports never arrive.
  • Invalid report URI. Report addresses must be mailto URIs; a plain address or misspelt scheme is invalid.
  • Enforcement before alignment. Moving to reject while a legitimate sender fails both SPF and DKIM alignment will block that sender's mail.
  • Out-of-range values. pct must be 0 to 100, and adkim and aspf must be r or s.

How to move DMARC forward safely

Prerequisites: working SPF and DKIM for the main sending systems and a mailbox or service that can process aggregate reports. Operational risk: stronger policies make receivers reject or junk mail from any sender you forgot. Rollback: lower the policy back to the previous value; remember receivers cache the record for its TTL, so keep the TTL modest while changing.

  1. Publish v=DMARC1; p=none; rua=mailto:[email protected] and, if the mailbox is on another domain, publish its authorisation record there first.
  2. Collect aggregate reports for several weeks and identify every legitimate source.
  3. Fix SPF or DKIM alignment for each legitimate source that fails.
  4. Move to p=quarantine with a low pct, raise it in steps, then move to p=reject when reports are clean.
  5. Re-run this check after each change and confirm the policy and reporting findings.

Limits

The tool reads DNS only. It does not see mail flows, so it cannot tell you what percentage of your mail passes. It does not test np against a real non-existent name, and it does not authorisation-check https report endpoints. A DNS failure at any level is reported as unknown rather than as no record.

Frequently asked questions

Is p=none a failure?

No. It is the monitoring stage. It asks for reports but requests no action on failing mail. It simply does not protect against spoofing yet.

Why am I not receiving DMARC reports with a correct record?

If the rua address is on another domain, that domain must publish the authorisation TXT record under _report._dmarc. Also check the mailbox exists and that senders actually send aggregate reports for your volume.

What is the difference between rua and ruf?

rua requests aggregate reports, summaries of results by sending source. ruf requests failure reports about individual messages, which many receivers do not send.

Does a subdomain need its own record?

Not necessarily. Without one, the parent's record applies, using sp if present. A subdomain record overrides it.

What does pct do?

It applies the policy to only that percentage of failing messages. It exists for gradual rollout; the rest are treated as with the next lower policy.

Can DMARC stop all phishing that uses my brand?

No. It covers exact-domain spoofing in the From header. Look-alike domains and display-name tricks are outside its scope.

Written by DNS Tools editorial · Last updated 2026-10-09