What this analysis does
Mailybox starts at the entered author domain, follows the bounded RFC 9989 DNS Tree Walk when needed, and reports the exact policy source, effective policy tags and validation issues. It does not mistake a malformed record or duplicate policy RRset for a clean DMARC deployment.
A useful DMARC check must answer two different questions: what record is published, and which policy actually applies to the author domain. Mailybox keeps those answers separate so a syntactically present TXT value is not mistaken for an effective policy.
Start with the domain visible in From
Enter the domain from the visible RFC 5322 From address. Do not substitute the Return-Path domain, a DKIM signing domain or the company homepage. Those identities become relevant when alignment is evaluated, but DMARC policy discovery begins with the author domain.
The checker queries the DMARC owner name for that domain and follows the bounded DNS Tree Walk defined by the current DMARC specification. The result reports the exact policy domain, the published record and the discovery path so inherited policy is visible rather than silently treated as a direct record.
- Use only a domain name, without an email address or URL.
- Test the production From domain used by the affected message.
- Keep the discovery path when documenting a DNS change.
Read the effective policy, not just p=
The p tag is only one part of the outcome. Subdomain policy can come from sp, a non-existent subdomain can be affected by np, and alignment modes determine whether a passing SPF or DKIM identity can satisfy DMARC for the visible From domain. Reporting destinations describe telemetry; they do not turn monitoring into enforcement.
A p=none result still represents a valid policy when the record is well formed. It asks receivers to collect evidence without requesting quarantine or rejection. Treat it as an observation stage, not as proof that spoofed mail will be blocked.
Test SPF and DKIM alignment against the discovered policyRead the DMARC alignment guide
Multiple or malformed records are operational findings
Publishing more than one DMARC policy record at the same owner name does not create a stronger combined policy. It creates an ambiguous record set that receivers cannot safely interpret as a clean configuration. Invalid version or policy tags can also make a record inapplicable even though a DNS lookup returns text.
Correct the authoritative DNS source rather than adding another TXT record beside the old one. After the change propagates, run the checker again and compare the returned policy source, record count and effective tags.
Example: policy inherited by a subdomain
Evidence supplied
Author domain: alerts.example.com — no valid policy exists at _dmarc.alerts.example.com.
How to read the result
The discovery path continues upward. If a valid organizational policy is found, the result names that policy domain and shows whether its subdomain instructions apply. The tool does not claim that a missing direct record means DMARC is absent.
Known limits
- DNS results describe the state visible to the resolver at analysis time; cached or split-horizon DNS can differ elsewhere.
- A valid policy does not prove that a particular message passed SPF, DKIM or DMARC.
- Receiver enforcement, reputation and local filtering decisions remain outside a DNS-only check.
Common questions
Does every subdomain need its own DMARC record?
No. A subdomain can inherit an applicable organizational policy. Publish a direct record when that subdomain needs an intentionally different policy or reporting configuration.
Is p=none a DMARC failure?
No. It is a valid monitoring policy when the record is otherwise valid. It does not request quarantine or rejection.
Why does the checker query more than one name?
Current DMARC policy discovery can require a bounded DNS Tree Walk. Each query is shown so the selected policy is auditable.