Free DMARC Checker

A DMARC record is a public DNS policy for a domain’s email. It tells receiving servers how to handle messages that fail DMARC checks.

It reads the published record in full: the policy (p), subdomain policy (sp), alignment modes (adkim, aspf), reporting addresses (rua, ruf) and the failure and interval options (fo, ri). It also reports how many reporting destinations are configured, whether any is malformed or sits on another domain, and whether test mode is on.

No. When sp is absent, subdomains inherit the main policy, so its absence is not a finding on its own. It matters when sp is set to something weaker than p — for example p=reject with sp=none — because that leaves subdomains less protected than the main domain.

No, and any tool that claims to from DNS alone is guessing. Alignment is evaluated per message, using the From header, the Return-Path and the DKIM signing domain. A public checker sees none of those. What can be read from DNS is the alignment MODE you configured — relaxed or strict — which is what this page reports.

fo controls when failure (forensic) reports are generated: 0 sends a report when everything fails, 1 when any check fails, d on a DKIM failure and s on an SPF failure. It only has an effect when ruf is also configured.

pct asked receivers to apply the policy to a percentage of failing messages. RFC 9989 removed the tag, so modern receivers ignore it and apply p in full. This page shows the coverage the record asks for so you can see what was intended, and says plainly that it is a request rather than something receivers will honour. For a staged rollout, raise p from none to quarantine to reject instead of using pct.

It is the strength the published record actually asks receivers for, not just the p value. p=none is monitoring only. p=quarantine is partial enforcement. p=reject is full enforcement, unless t=y is set or pct is below 100, which both pull the record back to a weaker effective level.

No. t is the testing-mode tag introduced in RFC 9989, and it replaced pct. It does not disable the policy — it asks receivers to apply the level below the one you published, so p=reject with t=y is handled as quarantine and p=quarantine with t=y is handled as none. The default is t=n, which applies the policy exactly as written. This page reports the effective policy after that step down, and scores the effective policy rather than charging you twice for testing.

No. When rua or ruf points at another domain, DMARC requires that domain to publish an authorisation record of the form yourdomain.example._report._dmarc.theirdomain.example. This tool does not query that record, so it marks the destination as external and states that external authorization is not verified. It never labels a destination authorised or unauthorised.

adkim and aspf default to relaxed, pct defaults to 100, ri defaults to 86400 seconds, and sp is inherited from p when it is absent. Each of these is labelled on the result so you can tell an explicit choice from a default that simply applies.

p=none means messages are monitored, but failing messages are not instructed to be quarantined or rejected.

p=quarantine asks receiving servers to treat failing messages as suspicious. p=reject asks them to reject failing messages.

Without a DMARC record, receiving servers have no DMARC policy from the domain to apply. Create and validate a record before checking again.

p=none is useful for monitoring, but it is not full enforcement. Review legitimate mail sources before moving to quarantine or reject.

Yes. This is a limited, read-only public check using the protected CloudSpex Free Scan flow.

No. CloudSpex reads public DNS information only and does not change DNS, email settings or website configuration.

Yes — a DMARC lookup fetches the _dmarc TXT record, and this test goes on to interpret it the way a receiving server would: the effective enforcement level, the subdomain policy, the reporting destinations, and which values fall back to RFC defaults rather than being something you published.