DMARC Validation Report

Introduction:

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the DNS policy that connects a visible From domain with SPF and DKIM authentication. SPF checks the sending path, DKIM checks a cryptographic signature, and DMARC asks whether at least one passing result aligns with the domain that recipients see. That alignment step is what turns separate authentication records into a domain-level anti-spoofing control.

A DMARC record matters most when a domain sends mail from several places. A company might use a primary mail platform, a newsletter service, a billing system, a helpdesk, and a few internal systems. Each sender can pass or fail SPF and DKIM in different ways, so the published DMARC policy should show the current rollout stage rather than simply copy an ideal final state.

The policy values are intentionally simple. p=none asks receivers to report without changing message handling because of DMARC. p=quarantine asks receivers to treat failing mail as suspicious. p=reject asks receivers not to accept failing mail. A domain owner can also publish a sampling percentage with pct, alignment modes with adkim and aspf, and report destinations with rua or ruf.

Validation is useful after a DNS change, before a stricter rollout, or when a mailbox provider says authentication is incomplete. A single lookup can show whether the expected record is visible at _dmarc, whether more than one DMARC record was published, and whether the record has the tags that explain policy, reporting, and alignment.

A DMARC validation report is not a live delivery test. It does not read message headers, confirm that SPF or DKIM passes for real mail, or predict inbox placement. It checks the policy record that receivers can discover in DNS, then turns that record into practical review notes.

Technical Details:

DMARC policy discovery starts with a DNS TXT query at _dmarc.<domain>. For example.com, the queried owner is _dmarc.example.com. The record itself is a semicolon-separated tag list that begins with v=DMARC1 and normally includes a p tag with one of three policy values: none, quarantine, or reject.

The validation report uses a live TXT lookup through the selected public DNS-over-HTTPS resolver. Cloudflare DNS is the default resolver, and Google Public DNS is available from Advanced. The entered value is normalized to a hostname, lowercased, stripped of a trailing dot, and then checked as a DNS-style domain before the _dmarc query is made.

Only TXT answers that start with v=DMARC1 are treated as DMARC records. If exactly one matching record is found, the record count check is healthy. Multiple matching records are flagged as needing attention because receivers are expected to find one effective DMARC policy record. If no matching record is found, the lookup stops with a clear error message instead of fabricating default tags.

The tag parser keeps the visible record easy to inspect. It joins quoted TXT fragments from the DNS answer, splits the policy on semicolons, lowercases tag names, and keeps each value as text. Recognized tags receive short meanings for version, policy, subdomain policy, percentage rollout, reporting, DKIM alignment, SPF alignment, report interval, failure options, and report format. Less common tags are still shown, but they are described as custom or less common instead of being silently removed.

The summary badges compress the parsed record into four quick signals. The headline status becomes DMARC needs attention if any validation note needs attention, DMARC has rollout notes if there are review notes but no blocking findings, and DMARC policy is coherent when every check is healthy. Separate badges show the policy and percentage, DKIM and SPF alignment modes, and counts for aggregate and failure report destinations.

The Policy Posture section turns the same facts into three short findings. Enforcement reports reject, quarantine, none, or a missing policy together with the rollout percentage. Alignment reports DKIM and SPF as relaxed or strict, defaulting to relaxed when the tags are absent. Reporting shows the number of aggregate and failure destinations and reminds the reader that third-party report destinations may still need authorization outside this lookup.

The validator is deliberately narrower than a complete mail authentication audit. It does not query SPF records, DKIM selectors, parent-domain DMARC records, DNSSEC state, external report authorization records, or actual message headers. It reports the current DMARC TXT answer for the exact hostname entered and explains what that answer says.

Everyday Use & Decision Guide:

Start with the domain whose policy you want to see, not with the raw record text. A normal domain such as example.com is enough. Pasted web URLs are reduced to their host before the lookup, so a copied website address can still lead to the matching _dmarc owner when the host is valid.

Use the Advanced resolver choice when a recent DNS change seems inconsistent. Cloudflare DNS and Google Public DNS can see different cached answers during propagation, so changing the resolver is a useful second pass before deciding that a DNS edit failed. The summary line names the resolver and lookup time for the current run.

• Read Policy Tags first when you need the exact published tag names, values, and short meanings.
• Read Validation Notes when the summary says Needs attention or Review; the note row names the condition that changed the status.
• Read Policy Posture when you need a plain summary of enforcement, alignment, and reporting for a ticket or rollout note.
• Use JSON when another system or reviewer needs the same parsed tags, validation notes, and posture rows in a structured shape.

The best first pass after publishing DMARC is to confirm record count, version tag order, and policy tag before judging enforcement strength. A domain with p=none can be in a planned monitoring phase. A domain with two DMARC records at the same owner has a more urgent problem because receivers can treat that policy discovery as invalid or ambiguous.

Do not treat a reporting count as proof that reports will arrive. The report counts comma-separated rua and ruf destinations in the record, but it does not verify mailbox ownership, provider support, or external destination authorization. If aggregate reports stay quiet after publication, check the destination address and any receiver-domain authorization record separately.

The lookup makes a DNS request through the selected public resolver. That means the queried domain is visible to Cloudflare DNS or Google Public DNS, depending on the resolver setting. The result is kept in the page state for the current session and can be copied or exported by the user, but the page does not add a separate storage step for the parsed result.

A useful follow-up is to compare the Policy Tags table with the sender rollout plan. If the plan says monitoring, a coherent p=none record with reporting can be acceptable. If the plan says enforcement, check that Policy Posture shows quarantine or reject, the expected pct, and the alignment mode your senders can actually satisfy.

Step-by-Step Guide:

1. Enter the domain in Domain. If the field returns Enter a valid domain such as example.com, remove spaces, paths, unsupported characters, or incomplete hostnames and try again.
2. Open Advanced only if you want to switch Resolver from Cloudflare DNS to Google Public DNS for a propagation comparison.
3. Select Validate DMARC. A successful lookup opens the result tabs and the summary box names the domain, selected resolver, lookup time, policy badge, alignment badge, and report counts.
4. If the page reports No DMARC TXT record was found, confirm that the record is published at _dmarc for the same host you entered. Parent-domain fallback is not checked here.
5. Use Policy Tags to inspect each parsed tag and value. Copy a row when you need to paste one finding into a DNS ticket.
6. Use Validation Notes to locate record-count, version, policy, percentage, reporting, or alignment problems. Clear Needs attention rows before treating the record as coherent.
7. Use Policy Posture to summarize enforcement, alignment, and reporting in ordinary language for a review note.
8. Use JSON when you need a structured snapshot of the parsed policy tags, validation notes, and posture rows from the current lookup.

Interpreting Results:

The most important result is the summary status. DMARC policy is coherent means the record passed the validator's checks for count, version order, policy value, rollout percentage, reporting presence, and alignment values. It is a configuration signal, not proof that real messages are passing DMARC.

DMARC has rollout notes usually means the record is syntactically usable but deserves a human decision. A pct value below 100 may be an intentional rollout stage, and missing report destinations may be acceptable for some domains, but both reduce visibility or coverage. The follow-up is to read the specific Validation Notes row rather than changing the policy blindly.

DMARC needs attention points to a condition likely to break or confuse policy discovery: multiple records, a version tag that is missing or not first, an invalid policy value, a percentage outside 0 to 100, or unsupported alignment values. Fix those before using Policy Posture as evidence in a rollout decision.

A common false-confidence signal is a green-looking policy with no message evidence. A coherent p=reject record can still block legitimate mail if a sender fails both aligned SPF and aligned DKIM. Use this report to confirm the DNS policy, then verify real mail with message headers or aggregate reports before tightening a production domain.

Lookup time is only an elapsed request measurement for the selected resolver. It can help when comparing repeated checks, but it does not grade DMARC quality, reporting reliability, or sender reputation.

Worked Examples:

One coherent monitoring record

For example.com, the record v=DMARC1; p=none; rua=mailto:dmarc@example.com produces one policy row, one aggregate report destination, relaxed default alignment, and full percentage coverage. Policy Posture reads as monitor mode at 100%, and Validation Notes should be healthy unless the resolver returns extra DMARC records at the same owner.

A staged quarantine rollout

A record such as v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=r; aspf=r has a valid policy and reporting destination, but Percentage rollout is marked Review because pct=25 applies the requested policy to only part of failing mail. The summary should read DMARC has rollout notes, which is the expected cue for a planned partial rollout.

Two records at the same owner

If DNS returns both v=DMARC1; p=none; rua=mailto:dmarc@example.com and v=DMARC1; p=reject, the report parses the first matching record for tag display but marks Record count as Needs attention. Remove the duplicate so receivers see one effective DMARC policy.

A policy spelling error

A record with v=DMARC1; p=blocked; rua=mailto:dmarc@example.com still appears in Policy Tags, but Policy tag is marked Needs attention because blocked is not one of the accepted DMARC policy values. Replace it with none, quarantine, or reject.

Checking the wrong host

If mail.example.com is entered but the only DMARC record lives at _dmarc.example.com, the lookup for _dmarc.mail.example.com can report no record. Run the check again against example.com when you want the parent domain's published policy.

FAQ:

Glossary:

DMARC

Domain-based Message Authentication, Reporting, and Conformance, the DNS policy system that uses aligned SPF or DKIM results.

Alignment

The relationship between the visible From domain and the authenticated SPF or DKIM domain.

_dmarc

The DNS owner label where a domain publishes its DMARC TXT policy record.

p

The main requested receiver policy for mail that fails DMARC.

pct

The percentage tag that limits how much failing mail is asked to follow the requested policy.

rua

The aggregate report destination tag used for summary reports from receivers.

ruf

The failure report destination tag used when receivers support and choose to send failure reports.

DNS-over-HTTPS

A DNS query method that sends the lookup to a resolver over HTTPS.

References:

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance, IETF, March 2015.
• DMARC Specifications, DMARC.org.
• DMARC Overview, DMARC.org.
• Email Sender Guidelines, Google Workspace Admin Help.
• What is a DNS DMARC record?, Cloudflare.