Inspect the exact domain’s policy, alignment settings and reporting destinations.
Your DNS query is sent to Sky’s server and its fixed public resolver to complete the lookup. It is not added to tool history. Ordinary hosting access logs may still exist.
DMARC tells receivers how your domain asks them to handle messages that fail authentication and can request aggregate reports. This checker reads DNS at the exact name you enter; it does not test a message or confirm sender alignment.
Entering example.com queries the TXT name _dmarc.example.com. Invalid input shows Invalid domain. For a subdomain, enter its full name to check that exact DNS record.
No DMARC record found at the queried name means the checker found no DMARC-like record there; it may display NXDOMAIN or No TXT data. A parent policy may apply, but this checker does not look for it. DMARC lookup unavailable means no conclusion can be drawn; retry instead of treating it as a missing record.
DMARC policy record is valid means the single record passed syntax checks. DMARC record parsed with compatibility notes means a warning was found, such as historic pct or ri. DMARC record needs correction means a structural or value problem was found. None of these results tests real mail.
The fields include Requested policy (p), Subdomain policy (sp), DKIM alignment (adkim), SPF alignment (aspf), and Aggregate report destinations (rua). Relaxed alignment is the default for adkim and aspf. A displayed rua destination is not tested for authorization or report delivery.
Usual cause: There is no TXT policy at the exact name queried. A receiver may discover a policy elsewhere in the DNS tree, but this tool does not.
Fix: Check the domain spelling and query the relevant organizational domain. Confirm the policy for each From domain before editing DNS.
Usual cause: More than one DMARC-like TXT record makes the policy ambiguous, so the checker will not choose one.
Fix: Have the DNS administrator combine intended tags into one record and remove the extra policy. Check again after the change is visible.
Usual cause: The parser found a missing or misplaced version tag, missing or invalid p value, duplicate tag, or malformed tag list.
Fix: Use v=DMARC1 first and one p value: none, quarantine, or reject. Remove duplicate or malformed fields before publishing.
Usual cause: A DNS record does not authenticate mail. DMARC needs an SPF or DKIM pass aligned with the visible From domain.
Fix: Check a representative message and aggregate reports. Ask the sender to configure an SPF or DKIM identity aligned with your From domain, then verify again.
Usual cause: rua requests aggregate feedback. The checker does not test whether receivers send reports or whether an external destination is authorized.
Fix: Confirm the mailbox or service can process reports and check authorization for an external destination. A displayed address does not prove reports arrive.
Usual cause: p=none asks receivers not to change handling because of DMARC. A DNS check cannot show whether every legitimate sender authenticates and aligns.
Fix: Review aggregate reports and fix legitimate sources before choosing quarantine or reject. Coordinate the change with owners of your sending systems.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"The result can show policy none and the aggregate destination. This syntax check does not prove that mail aligns or that a receiver will send a report.
Yahoo sets p=none as the minimum policy for bulk senders but still requires DMARC to pass. Gmail requires DMARC for bulk senders and says SPF or DKIM must authenticate with an aligned domain. p=none alone does not show that mail passes.
An SPF- or DKIM-authenticated domain must match the message From domain. Relaxed alignment allows the same organizational domain; strict alignment requires identical domains. Authentication can pass while DMARC fails if alignment is missing.
rua lists destinations for aggregate reports about mail using your domain. Reports can show sending sources and alignment gaps. It requests reports; this checker cannot confirm a destination or report delivery.
sp sets the requested policy for subdomains when present. Read it with p, the requested policy for the domain. This checker shows only the exact record queried and does not discover inherited policy.