DMARC Validation Report

Most recipients judge a message by the visible From address, but email authentication happens through several different domain identities. SPF checks the sending path, DKIM checks a cryptographic signature, and DMARC connects those results back to the author domain that appears in the message header. That connection is what lets a domain owner publish a policy for mail that claims to be from the domain but does not authenticate in an aligned way.

The central DMARC idea is alignment. SPF helps DMARC only when the SPF-authenticated domain lines up with the author domain. DKIM helps DMARC only when the DKIM signing domain lines up with the author domain. Relaxed alignment accepts domains under the same organizational domain, while strict alignment requires an exact match. This is why a message can pass SPF or DKIM and still fail DMARC when the passing identity belongs to a different domain than the one shown to the reader.

p policy

The requested receiver action for mail that fails DMARC: monitor, quarantine, or reject.

rua reporting

Aggregate feedback that helps domain owners find unauthenticated or misaligned sending sources.

Alignment mode

The relaxed or strict match rule for SPF and DKIM domains against the visible From domain.

Policy strength is not just the choice between none, quarantine, and reject. A monitoring policy can be the right first step when a domain has many senders because aggregate reports reveal legitimate services, forgotten systems, and spoofed traffic. Stronger policies should follow evidence that real mail is aligned, otherwise an enforcement change can disrupt newsletters, help desk systems, billing mail, or regional sending platforms that were never fully configured.

Reporting is the feedback loop that makes DMARC practical. Aggregate reports summarize authentication outcomes across mail streams, while failure reports can carry much more detailed message-level information and need careful privacy handling. Report destinations outside the checked domain also need authorization from the receiving domain, because a domain owner should not be able to force another domain to receive unwanted report traffic.

A DNS record review cannot prove that live messages pass DMARC, and it cannot predict inbox placement. It shows what policy is publicly visible, how that policy is shaped, and whether obvious syntax, reporting, alignment, or rollout problems are present before the record is compared with real message headers and aggregate reports.

How to Use This Tool:

Start with the domain whose visible From address you want to review, such as example.com. A pasted URL or _dmarc.example.com owner name is reduced to the checked domain before validation runs.

1. Enter the domain in Domain and run Validate DMARC.
2. Use the default resolver for a normal check. Switch Resolver only when comparing propagation, cache differences, or conflicting public DNS answers.
3. Read Policy Tags first to confirm which v=DMARC1 record was parsed and how its tags are interpreted.
4. Open Validation Checks for record count, version order, policy value, subdomain policy, rollout percentage, alignment modes, reporting, external receiver authorization, and duplicate tags.
5. Use Report Destinations when rua or ruf is present. Pay special attention to external receiver rows, because a missing authorization record can stop reports from being sent there.
6. Use Policy Posture, Control Scores, and DMARC Control Profile for an operating summary after the individual validation rows are understood.

The result is ready for handoff when the summary either says the policy is coherent or names the exact condition needing attention, such as multiple records, a missing policy tag, an invalid alignment value, no aggregate reporting, or an external receiver review.

Interpreting Results:

Record count is the first health signal. Exactly one visible DMARC policy record is the expected state. No record means receivers have no published DMARC instruction at that owner name, and multiple records make the policy ambiguous enough to require cleanup.

Policy tag and Percentage rollout describe enforcement posture. p=none is monitoring mode, not enforcement. p=quarantine and p=reject ask receivers to handle failing mail more strongly, while a legacy pct value below 100 means the visible record still expresses partial rollout behavior.

Alignment modes tells you whether the domain asks for relaxed or strict SPF and DKIM alignment. Relaxed alignment is common because it lets related subdomains authenticate mail for the same organizational domain. Strict alignment is narrower and can be useful for tightly controlled sending, but it can expose third-party senders that were never aligned.

Report Destinations matters because a domain cannot tune DMARC well without feedback. Aggregate reporting through rua is the usual visibility channel. Failure reporting through ruf can expose message-level details and is handled inconsistently by receivers, so it should be treated as sensitive diagnostic signaling rather than a routine dashboard feed.

Control scores are review aids, not standards grades. A high average can still hide a single serious gap, and a low enforcement score may be intentional during a monitoring rollout. Use the scores to prioritize review, then confirm decisions against aggregate reports and real authentication headers.

Technical Details:

Current DMARC is defined by RFC 9989, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. A DMARC policy record is a DNS TXT record whose tag list starts with v=DMARC1. For the checked domain, the public owner name is formed by prepending _dmarc to the domain and evaluating TXT records that begin with that version marker.

The DNS record check is narrower than full receiver-side DMARC processing. Receiver processing evaluates the message's author domain, SPF result, DKIM result, identifier alignment, policy discovery behavior, and local overrides. This report reviews the visible policy record, parses common tags, checks selected syntax and reporting conditions, and summarizes those findings as validation rows and control scores.

Rule Core:

External reporting checks follow the DMARC reporting authorization pattern. A report destination inside the checked domain scope is treated as in scope. A destination at another receiver host is checked for a visible authorization record under that receiver host. The row remains in review when no v=DMARC1 authorization answer is visible through the selected resolver.

Score Core:

The control profile is a heuristic summary and is not part of the DMARC standard. Six category scores are bounded from 0 to 100, averaged, and rounded. Labels are Strong for 80 to 100, Review for 50 to 79, and Weak below 50.

For example, p=quarantine; pct=25 gives an enforcement score of 70 * 0.25 = 17.5, rounded into the displayed category score. That does not mean the record is malformed; it means the published policy still reads like a staged enforcement rollout.

Accuracy and Privacy Notes:

The checked domain, its _dmarc owner name, and any external report-authorization owner names are sent to the selected public DNS resolver. The report does not inspect mailboxes, message bodies, private DNS zones, SPF mechanisms, DKIM public keys, or live message headers.

• Resolver caches can make recent DNS changes appear differently across Cloudflare DNS, Google Public DNS, and Quad9 DNS.
• The lookup checks the exact entered domain's DMARC owner name; it does not perform a full receiver-style DNS tree walk for every possible author domain.
• Newer RFC 9989 tags such as np, psd, and t may be parsed as custom or less common tags rather than fully evaluated controls.
• Failure report destinations can involve sensitive message details when receivers honor them, but this report only checks the published DNS destination values.

Worked Examples:

A domain beginning DMARC deployment might publish v=DMARC1; p=none; rua=mailto:dmarc@example.com. The record is useful because aggregate reports can reveal authorized services, forgotten systems, and spoofing attempts, but the policy remains monitoring mode until the domain owner moves to quarantine or reject.

A staged record such as v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com shows stronger intent but partial rollout. The validation rows should treat the policy value as valid and the rollout percentage as a review note. That is acceptable only if the domain owner still has a clear migration reason for using legacy percentage rollout behavior.

A third-party reporting setup might use rua=mailto:dmarc@reports.example.net for example.com. If the receiver host is outside the checked domain scope, look for external authorization at the receiver side before assuming aggregate reports will be delivered.

FAQ:

Glossary:

Author domain

The domain in the visible From header that DMARC protects.

DMARC alignment

The match between the author domain and a passing SPF or DKIM domain, using relaxed or strict rules.

p

The requested receiver policy for mail that fails DMARC: none, quarantine, or reject.

sp

The optional subdomain policy. When omitted, subdomains inherit the main policy behavior.

rua

Aggregate report destinations used for periodic DMARC feedback.

ruf

Failure report destinations for more detailed per-message failure feedback, when supported and safe to send.

pct

A legacy rollout percentage tag still seen in deployed records, though current DMARC standards removed it.

References:

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, 2026.
• RFC 9990: DMARC Aggregate Reporting, RFC Editor, 2026.
• RFC 9991: DMARC Failure Reporting, RFC Editor, 2026.
• RFC 7489: DMARC, RFC Editor, 2015, obsolete but useful for legacy tag context.