| Tag | Value | Copy |
|---|---|---|
| {{ key }} | {{ uri.text }} {{ uri.text }} , {{ val }} |
| Check | Status | Copy |
|---|---|---|
| {{ c.label }} | Pass Fail |
Email authentication policy records describe how a domain asks receivers to treat messages that pass or fail identity checks. They help reduce spoofing and build trust with recipients.
Enter a domain and run a quick lookup so you can read the policy tags and see a simple score. The result highlights reporting addresses and enforcement stance in one place.
For a practical example, a configuration that rejects failures and uses strict alignment on both identifiers will rate highly and signals a preference for strong protection.
Treat the score as a snapshot of configuration rather than deliverability, and recheck after edits propagate. Use consistent input and repeat checks so cache windows do not mislead.
Domain‑based Message Authentication, Reporting, and Conformance (DMARC) policies are published as DNS TXT records under _dmarc.<domain>. The policy defines an enforcement action for authentication failures, alignment modes for identifiers, reporting endpoints for aggregated and failure data, and related options.
This tool queries the policy record, parses tag–value pairs, and evaluates a set of compliance checks. The score expresses the fraction of checks that pass, converted to a percentage, so higher values indicate closer adherence to a strict protection posture.
Results focus on policy presence and intent. A policy passes the enforcement check only when p=quarantine or p=reject. Partial rollout via pct passes only when the tag is absent or set to 100. Strict alignment requires adkim=s and aspf=s. Subdomain coverage is recognized when sp is present. Failure options (fo) and aggregate reporting (rua) are expected; failure reporting (ruf) is treated as optional and does not block the score.
Comparisons are most meaningful for the same domain over time. Scores can vary during DNS propagation; use the displayed time to resolve and time‑to‑live to judge freshness.
| Symbol | Meaning | Unit/Datatype | Source |
|---|---|---|---|
| S | Compliance score | % | Derived |
| P | Number of passing checks | integer | Derived |
| N | Total checks evaluated | integer | Derived |
| T | Record time‑to‑live | s | DNS answer |
| Δt | Lookup time | ms | Measured |
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; adkim=s; aspf=s; sp=reject; fo=1.
Interpretation: all checks pass, indicating a fully strict, reject‑based policy with reporting configured.
| Field | Type | Min | Max | Step/Pattern | Error Text | Placeholder |
|---|---|---|---|---|---|---|
| Domain | string | 2 labels | 253 chars | ^[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?$ per label; letters, digits, hyphens |
Please enter a valid domain (e.g., example.com). | example.com |
| Input | Accepted Families | Output | Encoding/Precision | Rounding |
|---|---|---|---|---|
| Domain name | ASCII labels; punycode form allowed | Tags, checks, score, TTL, lookup time | Percent integers; times in ms; TTL in s | Score rounded to nearest integer |
Networking & storage. A single DNS‑over‑HTTPS request is issued from the browser to a public resolver endpoint with header Accept: application/dns-json. No cookies or local storage are used.
Security considerations. Domain input is constrained to common label syntax. Report URIs are linkified only for mailto:, http:, and https:; other schemes are shown as plain text. JSON rendering is read‑only.
sp is explicitly set.pct below 100 is treated as non‑compliant.ruf is optional and does not reduce the score.mailto, http, and https.v tag or wrong version token.rua/ruf.Privacy & compliance. Requests are performed by your browser against a public DNS resolver; the site does not store input or results.
Policy assessment reads a domain’s record and summarizes enforcement and reporting.
Example. Checking example.com returns a policy with p=reject, adkim=s, aspf=s, and a score near 100%.
You now have a concise readout of protection settings for quick remediation.
No. The check happens in your browser and the DNS request goes to a public resolver. Nothing is kept by the site.
Network access is required to fetch DNS answers.It mirrors the defined checks. Scores can shift while DNS changes propagate; use TTL as a freshness cue.
Higher values indicate stricter enforcement per these checks.Score is a percent, lookup time is in milliseconds, and TTL is in seconds.
Numbers are rounded to whole units for readability.No. A live DNS response is required to read the policy record.
Recheck after edits to confirm propagation.Publish and query the TXT record at the _dmarc subdomain of your domain.
It usually means some expectations failed, such as partial rollout or relaxed alignment. Tighten settings to raise the score.
Focus on enforcement, alignment, and reporting.No pricing or license terms are surfaced here. Use the results as a configuration aid.
Policies remain under your domain’s control._dmarc name and wait for propagation.p is quarantine or reject and pct is 100.sp tag for consistent behavior.rua contains valid mailto addresses.adkim=s and aspf=s for strict alignment.Tip Use the score to track policy hardening over time after each change window.
Tip Keep rua mailboxes monitored so alignment drift is noticed early.
Tip Prefer a single policy record to avoid ambiguous DNS answers.
Tip Raise enforcement gradually only if your reports confirm readiness, then return to full coverage.
Tip Treat pct below 100 as temporary; aim for full application once sources are aligned.
Tip Document intended values for p, sp, adkim, aspf, and fo to keep teams aligned.
s means strict.mailto:.