DMARC Validation Report

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, is the DNS policy that connects the visible From domain with SPF and DKIM results. SPF can pass for the sending path and DKIM can pass for a signature, but DMARC asks whether a passing result aligns with the domain recipients see.

A DMARC record is published as TXT at the domain's _dmarc name. The record starts with v=DMARC1, then uses tags such as p, pct, adkim, aspf, rua, and ruf to describe policy, rollout percentage, alignment mode, and report destinations. Those tags are short, but their operational meaning is large: p=none observes, p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks receivers not to accept failing mail.

DMARC rollout usually changes over time. A domain may begin with reports only, repair legitimate senders that fail alignment, then move to quarantine or reject at a partial or full percentage. A validator helps separate three different questions: is the DNS record visible, is the tag syntax coherent enough to interpret, and does the published policy match the rollout stage you intended?

A policy lookup is not a delivery test. It does not read message headers, prove that SPF or DKIM passes for real mail, or predict inbox placement. It explains the public DMARC TXT record and the report destinations visible through the selected resolver.

How to Use This Tool:

Use the organizational or sending domain whose DMARC policy you want to inspect.

1. Enter the domain in Domain. If you paste _dmarc.example.com, the input is normalized back to the checked domain.
2. Leave Resolver unchanged for the first pass. Switch resolvers only when investigating propagation or inconsistent public answers.
3. Run the lookup and read Policy Tags first. It shows each parsed tag, value, and meaning from the first usable DMARC record.
4. Open Validation Checks for record count, version order, policy value, subdomain policy, percentage rollout, alignment modes, reporting, external receiver authorization, and duplicate tags.
5. Use Report Destinations, Policy Posture, and Control Scores to decide whether the current record is only observing, partially enforcing, or ready for stricter handling.

If no DMARC record is found, confirm that the record is published at the domain's _dmarc owner name. If multiple records are found, remove duplicates before tuning policy details.

Interpreting Results:

The most important first signal is Record count. Exactly one DMARC record is healthy. No record or multiple matching records is Needs attention because receivers need one effective policy record to interpret.

Policy tag and Percentage rollout explain the enforcement request. p=none with pct=100 can still be useful for monitoring, but it is not an enforcement policy. p=quarantine or p=reject with pct below 100 is a partial rollout and should be read as a transition state.

Report Destinations deserves a separate look when reports go to a third party. External receivers need visible authorization from the receiver side. A review flag there does not change the DMARC policy itself, but it can explain why aggregate or failure reports do not arrive.

A strong control profile does not guarantee that all legitimate senders are aligned. Compare the DNS policy with real aggregate reports or message headers before moving a production domain from observation to enforcement.

Technical Details:

DMARC discovery queries TXT at the _dmarc owner for the checked domain. Only answers that begin with v=DMARC1 are treated as policy records. The selected public resolver's response time and answer count become part of the report, but the policy interpretation comes from the parsed tag list.

The parser splits the record on semicolons, lowercases tag names, preserves values, and flags duplicate tag names. Recognized tags are described directly: p and sp are policy values, pct is the percentage of failing mail requested for policy handling, adkim and aspf are alignment modes, and rua and ruf list aggregate and failure report destinations.

Rule Core:

Formula Core:

The Control Scores table converts policy features into six 0 to 100 scores, then the DMARC Control Profile chart plots those scores. Score labels are Strong for 80 or more, Review for 50 to 79, and Weak below 50.

A is the displayed average and C values are Record syntax, Policy enforcement, Alignment discipline, Reporting visibility, External receiver readiness, and Rollout completeness. The policy score uses none = 25, quarantine = 70, and reject = 100, with partial enforcement multiplied by the rollout percentage for quarantine and reject policies.

For example, p=quarantine; pct=50 gives a policy enforcement score of 70 * 0.5 = 35. The same domain can still score well on record syntax or reporting, so read the individual controls instead of treating the average as a pass/fail verdict.

Accuracy and Privacy Notes:

The checked domain, its DMARC owner name, and any external report-authorization names are sent to the selected public DNS resolver. The report does not inspect mailboxes, message content, aggregate reports, or private DNS credentials.

• Resolver cache state can make recent DNS changes appear inconsistent.
• External report authorization is checked from visible DNS only; it cannot confirm that the receiver accepts or processes reports.
• Control scores are operational heuristics based on the visible record, not a standards grade or deliverability guarantee.

Worked Examples:

A monitoring rollout for example.com might publish v=DMARC1; p=none; rua=mailto:dmarc@example.com. Policy Tags shows policy and reporting values, Validation Checks marks record count and version healthy, and Policy Posture keeps enforcement in Review because the domain is still observing.

A partial enforcement record such as p=quarantine; pct=25 is valid but intentionally incomplete. Percentage rollout becomes Review, and Control Scores shows lower Policy enforcement and Rollout completeness values. That is expected during a staged rollout, but it should match a real migration plan.

A troubleshooting case appears when rua points to a third-party mailbox. If Report Destinations lists an external receiver and External report authorization is Review, add or repair the receiver-side authorization record before assuming reports are being delivered.

FAQ:

Glossary:

DMARC alignment

The requirement that a passing SPF or DKIM result matches the visible From domain closely enough for DMARC.

p

The DMARC receiver policy for the checked domain: none, quarantine, or reject.

pct

The percentage of failing mail requested for policy handling.

rua

Aggregate report destinations where receivers can send summary DMARC reports.

External receiver

A report destination host outside the checked domain scope.

References:

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance, RFC Editor, March 2015.
• RFC 7208: Sender Policy Framework (SPF), RFC Editor, April 2014.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, RFC Editor, September 2011.