DMARC Checker
Look up the DMARC policy published at _dmarc for any domain and validate it: policy mode, alignment, reporting addresses and the tag-level mistakes that quietly leave enforcement switched off.
About DMARC Checker
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receiving servers what to do with mail that fails authentication and where to send the reports that reveal who is sending as your domain. This checker queries the TXT record at the _dmarc subdomain of the name you enter, confirms it starts with v=DMARC1, and splits it into its individual tags so nothing is hidden in a single opaque string.
The policy tag (p) is the heart of the record. p=none is monitor-only: it gathers reports but takes no action, which is the right place to start but no protection on its own. The tool flags this explicitly and highlights the stronger modes, quarantine and reject, as well as a missing or invalid policy tag. It also detects the subdomain policy (sp), which can override the parent for hosts that never send mail, and catches the case of multiple DMARC records, which causes receivers to ignore the policy altogether.
Reporting and rollout tags decide how much you actually learn. Without an rua address you receive no aggregate reports and have no visibility into spoofing or misconfigured senders, so the checker calls this out. A pct value below 100 applies the policy to only a fraction of failing mail, useful during a phased rollout but easy to forget. The adkim and aspf tags control whether SPF and DKIM alignment is relaxed or strict, which the report displays alongside the rest.
The lookup is performed server-side from our European infrastructure, giving you the same view a real mailbox provider would see, with no sign-in and no third-party dependency.
How to use it
- 1Enter the organisational domain you want to inspect (for example example.eu).
- 2Run the lookup; the tool reads the TXT record at _dmarc.<domain>.
- 3Read the reported policy mode (p) and any subdomain policy (sp).
- 4Confirm an rua aggregate-report address is present so you actually receive DMARC data.
- 5Resolve any flagged errors or warnings and re-check to confirm the fix is live.
Common use cases
- -Confirming a domain has progressed from p=none to real enforcement
- -Checking a reporting address is set before relying on DMARC data
- -Verifying whether subdomains inherit or override the parent policy
- -Assessing whether a supplier or partner domain can be spoofed
- -Troubleshooting why expected DMARC reports are not arriving
Frequently asked questions
- What is a DMARC record?
- A DMARC record is a DNS TXT record published at _dmarc.<domain>, starting with v=DMARC1, that tells receiving servers how to handle mail failing SPF and DKIM and where to send authentication reports.
- What does p=none mean?
- p=none is monitor-only mode: it collects reports but takes no action on failing mail. It is the safe starting point, but real protection requires moving to p=quarantine or p=reject once your reports look clean.
- What is the rua tag for?
- The rua tag specifies the mailbox (as a mailto address) that receives aggregate DMARC reports. Without it you get no visibility into who is sending as your domain, so it should always be set.
- What is the difference between quarantine and reject?
- quarantine tells receivers to treat failing mail as suspicious, typically routing it to spam, while reject tells them to refuse it outright during the SMTP transaction. Reject is the strongest DMARC policy.
- Can a domain have more than one DMARC record?
- No. A domain must publish exactly one DMARC record. If multiple v=DMARC1 records exist, receivers ignore all of them and no policy is applied.
- Do I need SPF and DKIM for DMARC to work?
- Yes. DMARC evaluates the results of SPF and DKIM together with identifier alignment. At least one of them must pass and align with the header-from domain for a message to pass DMARC.