DMARC Checker

How this DMARC checker works

DMARC is the control that tells receivers what to do when mail using your visible From domain fails authentication and alignment. A domain with SPF and DKIM can still be spoofable if DMARC is missing or set to p=none. This checker reads the effective DMARC policy, applies current RFC 9989 discovery rules, and explains whether the scanned domain is spoofable, partially protected, or protected by policy.

The scanner does not stop at _dmarc.example.com. It performs bounded DNS Tree Walk discovery so a subdomain without its own DMARC record can inherit a parent policy. This is important for domains such as billing.example.com or alerts.example.com, where a direct record may be absent but an organizational domain record can still apply. The scanner also evaluates the p, sp, and np fallback chain so existing subdomains and non-existent subdomains are not mixed up.

DMARC p=none is monitoring only. It is useful at the start of a rollout because it lets you collect aggregate reports before enforcement. It is not blocking protection. p=quarantine is partial enforcement because failing mail can be placed into junk or spam. p=reject is the strongest published policy, but even then the tool uses careful wording because receiver behavior, forwarding, mailing lists, and local policy can affect final delivery decisions.

RFC 9989 also introduced or formalized behavior around tags such as t, np, and psd, while treating pct, rf, and ri as historic. This checker parses legacy tags when they appear, but it does not generate new rollout guidance based on deprecated pct sampling. Instead it recommends a safer modern rollout path: monitor, test enforcement readiness, quarantine, then reject after legitimate mail alignment has been confirmed.

Common DMARC mistakes this tool finds

• No effective DMARC policy after tree walk discovery.
• p=none used permanently instead of as a rollout stage.
• p=quarantine or p=reject weakened by t=y testing mode.
• Invalid p, sp, or np values that make enforcement unreliable.
• Non-existent subdomain policy gaps through np, sp, and p fallback.
• External report destinations that may require authorization.
• Multiple DMARC records at one lookup target.

DMARC remediation workflow

DMARC should be rolled out carefully. Start with monitoring so aggregate reports show which platforms are sending mail for the domain. Fix SPF and DKIM alignment for legitimate sources before moving to enforcement. After the mail stream is understood, move to quarantine or reject in a controlled way. A strict p=reject policy is powerful, but it should not be published blindly because misaligned business mail can be rejected by receivers.

Modern DMARC policy discovery uses DNS Tree Walk. This matters for subdomains because a policy may be inherited from a parent or organizational domain. Existing subdomains use sp when available, otherwise p. Non-existent subdomains use np when available, otherwise sp, otherwise p. This scanner surfaces inherited policy so the user can see whether the scanned name has direct policy or inherited protection.

Do not treat DMARC reports as optional. The rua address is how the domain owner sees authentication failures, third-party senders, forwarding patterns, and spoofing attempts. When using an external reporting provider, confirm that the destination is authorized to receive reports for your domain. Use a real mailbox or reporting address before publishing generated records.