DMARC Record Checker

A DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is a DNS TXT entry that tells receiving mail servers what to do when a message claims to come from your domain but fails SPF or DKIM authentication. Without DMARC, even a correctly configured SPF record only affects how the receiving server scores the message — the outcome depends entirely on that server's own policies. DMARC gives domain owners explicit control: quarantine suspicious messages to the spam folder, reject them outright, or run in monitoring mode while you observe authentication results before committing to enforcement. The AT USE DMARC Checker queries _dmarc.{domain} via a live DNS-over-HTTPS resolver, parses every tag in the record, and returns a structured breakdown of your current policy alongside plain-English warnings for common misconfigurations.

How DMARC authentication works

DMARC adds a policy layer on top of SPF and DKIM. For a message to pass DMARC, at least one of SPF or DKIM must pass — and the passing mechanism must be aligned with the From header domain. SPF alignment means the domain in the SMTP envelope-from address matches (or is a subdomain of, in relaxed mode) the From header domain. DKIM alignment means the d= domain in the DKIM signature matches the From header domain. Alignment is the key distinction between DMARC and standalone SPF or DKIM: a spammer can send a message that passes SPF using their own domain in the envelope-from while using your domain in the visible From header. DMARC catches this because SPF passes but is not aligned with the From domain.

The three policy levels

The p= tag sets what receivers should do with messages that fail DMARC evaluation. p=none is monitoring mode: failures are reported (if rua= is set) but no action is taken on delivery. This is the starting point for new DMARC deployments — it lets you see what is sending on behalf of your domain before enforcing anything. p=quarantine instructs receivers to route failing messages to the spam or junk folder. p=reject instructs receivers to block failing messages entirely. The standard progression is none first, then quarantine at 100% or a lower pct= value, then reject once you are confident no legitimate mail is failing. Moving too fast to p=reject before auditing all senders causes legitimate mail to be blocked.

Aggregate reports and forensic reports

The rua= tag specifies where aggregate DMARC reports should be sent. These reports, delivered daily as XML by participating receivers, show authentication pass and fail counts per sending source — broken down by IP, with SPF and DKIM alignment results. They give you visibility into whether any legitimate mail is failing authentication before you raise policy to quarantine or reject. The ruf= tag specifies a forensic report address for individual failure samples. Aggregate reports are widely supported by major providers; forensic reports have reduced coverage due to privacy concerns from receivers. If rua= is missing from your DMARC record, you are running blind — failures are silently dropped or quarantined without you seeing them.

Subdomain policy and percentage

The sp= tag sets a separate policy for subdomains (mail.example.com, send.example.com, etc.). If sp= is absent, subdomains inherit the p= policy. The pct= tag (default 100) applies the p= enforcement to a percentage of failing messages, letting you ramp up enforcement gradually. For example, p=quarantine pct=20 quarantines 20% of failing messages and passes the other 80%, reducing the blast radius of an incomplete SPF/DKIM setup during a transition period. The DMARC Checker shows your current pct= value and flags when it is below 100 on a p=quarantine or p=reject policy, so you know enforcement is partial.