{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}: {{ badge.value }}
Enter one public domain or URL, such as example.com.
Changing resolver can expose cache or propagation differences; it does not rerun the report automatically.
CheckStatusEvidenceNext actionCopy
{{ row.label }}{{ statusLabel(row.status) }}{{ row.evidence }}{{ row.action }}
TypeURIReceiverScopeStatusEvidenceCopy
{{ row.type }}{{ row.uri }}{{ row.host }}{{ row.scope }}{{ statusLabel(row.status) }}{{ row.note }}
{{ remediationHeadline }}

{{ remediationSummary }}

{{ statusLabel(computation.values.verdict_code) }}
Observed policy

{{ observedRecord }}

Priority actions
  1. {{ action }}
Decision boundary

This is a point-in-time public-DNS review. Confirm aggregate reports and aligned SPF/DKIM results from real messages before changing enforcement.

The chart renderer is unavailable. The same control values remain available in the findings and exported CSV.

DKIM Validation Report Check a DKIM selector in public DNS and review its record count, key strength and policy tags with clear testing and resolver evidence.
SPF Validation Report Check a domain's SPF record, trace include and redirect dependencies, and flag duplicate policies or lookup-budget risks from public DNS.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
SPF Record Generator Build an SPF TXT record from real sender paths with ordered mechanisms and lookup-budget planning plus DNS packaging and rollout checks.

DMARC connects the domain visible to a mail recipient with the authentication results produced by SPF and DKIM. A message passes DMARC when at least one of those methods passes and its authenticated domain aligns with the domain in the visible From address. The published policy then tells receivers how the domain owner wants failing mail assessed and where reports should go.

The policy lives in a TXT record below _dmarc, so example.com is checked at _dmarc.example.com. Exactly one effective record should be present. Multiple candidates make policy selection ambiguous, while a missing or malformed record leaves receivers without a usable published instruction.

Element Practical purpose Important limit
p Sets the assessment policy to none, quarantine, or reject A stronger value does not repair broken sender alignment
adkim and aspf Choose relaxed or strict domain alignment Strict alignment can expose legitimate subdomain or provider flows
rua Names aggregate-report destinations External receivers need authorization in their own DNS
ruf Requests message-specific failure reports Availability varies and report content can raise privacy concerns
t=y Marks a testing posture under the current DMARC specification Testing weakens the meaning of an otherwise enforcing policy

DMARC deployment is an evidence problem, not just a syntax problem. A valid p=reject record can still disrupt wanted mail when a sender uses an unaligned return path or an unexpected signing domain. Aggregate reports reveal those sender streams before enforcement is tightened. They should be reviewed over a representative period that includes scheduled jobs, vendors, marketing services, support systems, and low-frequency mail.

Report destinations introduce a separate trust boundary. A receiver inside the checked domain needs no cross-domain authorization. A receiver hosted elsewhere must publish an authorization record for the sending policy domain. The presence of a mailbox URI alone does not prove that the external domain accepts those reports.

A public-DNS check is only a snapshot from one recursive resolver. It does not inspect real message headers, prove that SPF or DKIM aligns for production traffic, or guarantee that every receiver applies policy identically. Use it to review publication and control gaps, then confirm changes against aggregate reports and representative messages.

How to Use This Tool:

Start with the organizational domain whose visible From address you are protecting. A URL is accepted, but only its hostname is used.

  1. Enter one public hostname in Domain. A leading _dmarc. is removed so the policy owner is constructed once.
  2. Select the DNS resolver. Cloudflare, Google Public DNS, and Quad9 provide separate recursive views; changing the selection does not rerun an existing report.
  3. Run validation. The policy owner is queried first, followed by authorization owners for report destinations outside the checked domain.
  4. Resolve every Attention finding before enforcement work. Use Review findings to confirm rollout, reporting, privacy, or standards-currentness decisions.
  5. Recheck through another resolver after a DNS change, then verify real SPF and DKIM alignment in aggregate data before making the policy stricter.

Interpreting Results:

Healthy means the specific control passed the report's rule. Review identifies a usable or intentional configuration that still needs judgment, such as monitoring policy, testing mode, external authorization, historic tags, or failure reporting. Attention means the record count, version syntax, policy, or alignment value prevents a coherent result.

The effective policy can be none, quarantine, reject, or not available. When p is omitted but a usable rua exists, this report applies the current-specification fallback to none. That fallback is a monitoring posture, not evidence that enforcement is ready.

The control profile score is a diagnostic comparison aid, not part of the DMARC standard. It rewards stricter policy and alignment, but a higher score does not mean better deliverability or safer rollout. A domain with unknown legitimate senders can score well and still reject wanted mail. Confirm aggregate reports and representative message authentication before changing policy.

Technical Details:

The record parser keeps duplicate and unknown tags visible rather than silently discarding them. The version tag must appear first as the case-sensitive value v=DMARC1. Policy accepts only none, quarantine, or reject; omitted alignment modes default to relaxed r.

Transformation Core

The DNS observation is reduced to a policy report in four stages: normalize the domain, collect candidate policy records, parse the selected tag list without hiding duplicates, then query cross-domain report authorization owners. Eight findings and six numeric control scores are derived from that normalized evidence.

Rule Core

Control Healthy rule Review or attention rule
Record count Exactly one candidate record Zero or more than one is Attention
Syntax v=DMARC1 first, with no duplicate tags Any failure is Attention
Policy Quarantine or reject without t=y None, testing, or a rua-based fallback is Review; invalid policy is Attention
Alignment Both modes are r or s Missing record or any other value is Attention
Aggregate reporting At least one rua destination No aggregate destination is Review
External authorization Every external destination has a visible authorization record Any unconfirmed external receiver is Review
Current tags No pct, ri, or rf Any historic tag is Review
Failure reporting No ruf destination Requested failure reports are Review for privacy handling

Formula Core

The overall profile is the rounded arithmetic mean of six bounded scores: syntax, policy, alignment, reporting, external authorization, and current tags.

Soverall = round( Ssyntax+ Spolicy+ Salignment+ Sreporting+ Sexternal+ Scurrent 6 )
Component Exact score rule
SyntaxStart at 100 for one record or 35 otherwise; subtract 45 for an invalid version-first tag and 20 for duplicates; clamp to 0–100.
PolicyNone 35, quarantine 75, reject 100; testing caps the value at 35.
Alignment70 when both modes are valid, plus 15 for each strict mode; otherwise 0.
Reporting100 with at least one aggregate destination; otherwise 30.
External authorizationAuthorized external destinations divided by all external destinations, rounded as a percentage; 100 when none are external.
Current tags100 minus 33 for each historic tag, with a floor of 0.

The headline verdict is independent of the numeric average. Any Attention finding produces Attention; otherwise any Review finding produces Review; only eight Healthy findings produce Healthy.

Accuracy and Privacy Notes:

The checked domain and any external report-authorization names are sent to the selected public DNS resolver. No message content or mailbox is inspected. Public resolvers may log queries under their own policies, and cached answers can differ during propagation.

Failure-report destinations can receive message-specific data depending on sender and receiver behavior. Keep ruf disabled unless the diagnostic benefit, access controls, retention, and privacy obligations have been reviewed. Aggregate reports also contain operational sender information and should be handled as security telemetry.

Worked Examples:

Monitoring before enforcement

A single record with v=DMARC1; p=none; rua=mailto:dmarc@example.com can have healthy syntax, alignment defaults, reporting, and authorization. Policy remains Review and scores 35 because it only requests monitoring. Use the aggregate stream to identify legitimate senders before moving to quarantine or reject.

External report receiver without authorization

A rua mailbox at another domain creates an external receiver check. If the required authorization owner is not visible, the destination is Review even though the DMARC record itself parses. Confirm the receiver domain's authorization publication before depending on those reports.

References: