DMARC record checker

That a record exists at the DMARC hostname of the domain, which is a dedicated name rather than the domain apex.

That exactly one record is published. Several DMARC records is a permanent error under the specification, and receivers treat the domain as having no policy at all — a failure mode that looks identical to publishing nothing.

That the syntax is valid. An unparseable record is discarded by receivers, which is again equivalent to no policy, and the usual cause is a tag separator or a quoting problem introduced by the DNS editor rather than by the author.

That the required version tag opens the record, since a record missing it is not a DMARC record regardless of what follows.

The policy tag is the whole point of the record. Nothing asks the receiver to act on a failure; quarantine asks for the spam folder; reject asks for refusal at the SMTP transaction. A domain sitting on nothing is publishing a request for reports, not a protection.

The subdomain tag decides what happens to mail claiming to come from a subdomain. Without it, subdomains inherit the main policy — and an explicit rejection on subdomains blocks forgery of names that send no mail at all, which is most of them.

The percentage tag applies the policy to a share of the traffic. Anything below full coverage leaves the remainder unprotected, and it is only a sensible value during a deliberate rollout.

The alignment tags decide how strictly the authenticated domain must match the visible sender. Strict rejects mail sent through subdomains of legitimate providers; relaxed is the default and the more tolerant choice. Either is fine as a decision and neither is fine as an accident.

The aggregate address receives daily summaries: which sources sent mail as the domain, how much of it authenticated, and how much did not. This is the data a rollout is steered by, and without it a policy is being tightened blind.

The forensic address receives per-message failure reports. Those carry message content, which makes them useful during an active spoofing campaign and a data-protection consideration the rest of the time.

A record with a policy and no aggregate address is the common half-finished state: the protection is on, and nobody can see what it is catching or what legitimate sender it is about to break.

Both addresses are optional under the specification. Only the first is close to essential in practice.

A policy of none that has been in place for a long time. The record is valid, the reports are arriving, and the domain is exactly as spoofable as it was before it was published.

A policy of reject with a partial percentage, which is frequently a rollout somebody stopped halfway and never finished.

Two records at the same name, usually left after a migration where the old one was never removed. This produces no policy, and it produces it silently.

An aggregate address on a domain that does not accept the reports, which is a failure nobody notices because the reports simply stop arriving.

`email.dmarc.present` retrieves the record and `email.dmarc.syntax` verifies it is unique and free of syntax errors. `email.dmarc.policy` reports the enforcement level.

`email.dmarc.subdomain` reads the subdomain tag, `email.dmarc.pct` the coverage, and `email.dmarc.alignment` the alignment modes.

`email.dmarc.rua` and `email.dmarc.ruf` report the aggregate and forensic destinations. `email.spoofing_exposure` combines these with SPF and DKIM into the overall exposure statement.

DNS is read, not mail flow. The record says what receivers are asked to do; whether a given receiver honours it is outside anything a DNS query can establish.

Whether the reporting addresses actually accept and process reports is not tested.

A valid record is not evidence that legitimate mail passes. That requires the aggregate reports, which arrive over days rather than during a scan.

Nothing here inspects a message. No mail is sent and no mailbox is read.