Current policy evidence · read-only DNS

Free DMARC checker and policy explainer.

Find the policy that applies to a From domain, see whether it is direct or inherited, and understand alignment, subdomain handling and public report destinations using the current DMARC standard.

Check a DMARC policy

Inspect a From domain

See the policy a receiver can discover.

Enter the domain shown after @ in the visible From address. The checker performs a bounded RFC 9989 policy walk and reads public TXT records.

Use a public domain or complete business email address—not a DNS host name beginning with _dmarc, server IP or mailbox password.

Public DNS check. We read the DMARC policy published for this domain and explain the settings we find. Nothing is changed.

Read the result correctly

A policy check is not a message verdict.

Alignment needs a real message

DMARC passes when SPF or DKIM passes and its authenticated domain aligns with the visible From domain. DNS policy alone cannot prove that.

Policy is a preference

None, quarantine and reject communicate requested handling for DMARC failures. Receivers can consider local policy, indirect flows and other evidence.

Failure reports need privacy review

Message-specific reports can expose headers or content containing personal or confidential information. Many receivers decline to send them.

Current standards

The policy, tree-walk and tag explanations follow RFC 9989; reporting follows RFCs 9990 and 9991.

Read RFC 9989

DMARC questions

What this public check can establish.

Does this prove that my email passes DMARC?

No. It checks the discoverable DNS policy, not a message. Use a real message's Authentication-Results header and aggregate reports to assess SPF or DKIM pass and alignment.

Does p=reject force every receiver to reject a failure?

No. It expresses the domain owner's requested handling. Receiving systems can apply local policy and consider other evidence, including the risks of indirect mail flows.

Why does the checker warn about pct?

RFC 9989 marks pct as historic after inconsistent real-world sampling. This checker does not treat a legacy percentage as reliable current policy coverage; the current standard defines t=y for test mode.

Can this tool prove a reporting mailbox works?

No. It can parse the public URI and check a clearly external destination's authorization record. It cannot confirm that a mailbox exists, accepts reports or is actively monitored.

Should I switch straight to p=reject?

Not from this result alone. First identify every legitimate sender, validate aligned SPF and DKIM on representative mail, review aggregate reports and keep a tested rollback plan.