DMARC Checker - Check Your Record, Policy and Reporting
Look up your domain's DMARC TXT record and review its published policy, reporting address and alignment settings. Find configuration issues and understand what those settings request from receiving mail servers. A DNS record lookup cannot prove that a particular email passes DMARC.
Takes ~10 seconds
This example performs a real DNS lookup for google.com. Results may change. It does not verify message-level DMARC authentication.
What This Tool Checks
DMARC Record Presence
Verifies _dmarc.domain.com TXT record exists
Policy Level (p=)
Shows none, quarantine, or reject setting
RUA Reporting
Checks if aggregate reports are configured
Alignment Mode
Shows SPF/DKIM alignment (relaxed/strict)
How to Fix Common Issues
Example monitoring record
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
This is an example only. Replace the reporting address with a mailbox or service you control and verify. Do not copy an example address into production unchanged.
Policy is p=none
p=none requests monitoring without a DMARC-specific disposition. It does not guarantee inbox delivery. Consider a stronger policy only after legitimate messages pass aligned SPF or DKIM.
No RUA reporting configured
The optional rua tag designates where receivers that support DMARC aggregate reporting can send reports. Adding rua does not guarantee that every receiver will send a report. Use an address or reporting service that can actually accept and process the reports.
How It Works
Enter Your Domain
Type your domain name without http:// or www
We Query DNS
Our tool fetches your _dmarc TXT record in real-time
Get Instant Results
See your policy, reporting status, and recommendations
Frequently Asked Questions
What is a DMARC record?
A DMARC record is a DNS TXT record published at _dmarc.example.com. It requests a policy (none, quarantine, or reject) and can include reporting addresses. Receivers retain discretion over final handling. A DNS record lookup cannot prove that a particular email passes DMARC.
What DMARC policy should I use?
p=none requests monitoring without a DMARC-specific disposition. It does not guarantee inbox delivery. p=quarantine requests that messages failing DMARC receive suspicious handling, which might include placing them in spam. p=reject requests rejection of failing messages. Receivers retain discretion over final handling.
Start with a valid policy and ensure you can review relevant authentication results. Inventory every service sending mail using your domain, including support tools, marketing platforms and forwarded flows. Confirm that legitimate messages pass aligned SPF or DKIM. After validation, consider moving deliberately from p=none to p=quarantine and then p=reject where appropriate. Test each change and monitor the effects before strengthening the policy further.
What is DMARC alignment?
DMARC compares the domain in an email's visible From: header with the domain authenticated by SPF and/or DKIM. A message can pass DMARC when at least one of SPF or DKIM passes and aligns with the From: domain. A published DMARC record alone does not prove that real outgoing messages authenticate correctly. Relaxed alignment (the usual default) allows a subdomain to align with its organizational domain, while strict alignment requires an exact domain match.
How do I set up DMARC reporting?
The optional rua tag designates where receivers that support DMARC aggregate reporting can send reports. Report frequency and completeness depend on participating receivers; adding rua does not guarantee that every receiver will send a report. Use an address or reporting service that can actually accept and process the reports. Some third-party reporting destinations require additional DNS authorization.
Example monitoring record: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. This is an example only. Replace the reporting address with a mailbox or service you control and verify. Do not copy an example address into production unchanged.
Why is my DMARC failing?
Typical causes include an SPF pass for a non-aligned envelope domain, a DKIM signature using a non-aligned d= domain, authentication failures, or message changes during forwarding. To diagnose a specific message, inspect its Authentication-Results, Return-Path, From: header and DKIM signature information-not just the domain's DNS record.
Understanding DMARC: The Complete Guide
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on SPF and DKIM. Published as a DNS TXT record at _dmarc.example.com, it requests how receiving mail servers handle emails that fail aligned authentication. Receivers retain discretion over final handling.
Why DMARC Matters for Your Domain
Attackers can forge visible sender identities; DMARC helps domain owners request handling of messages that fail aligned authentication.
DMARC solves this by letting you:
- Monitor who is sending email using your domain
- Protect your domain from unauthorized senders
- Report authentication results back to you
What does DMARC check?
DMARC compares the domain in an email's visible From: header with the domain authenticated by SPF and/or DKIM. A message can pass DMARC when at least one of SPF or DKIM passes and aligns with the From: domain. A published DMARC record alone does not prove that real outgoing messages authenticate correctly.
DMARC policy: p=none, p=quarantine or p=reject
p=nonerequests monitoring without a DMARC-specific disposition. It does not guarantee inbox delivery.p=quarantinerequests that messages failing DMARC receive suspicious handling, which might include placing them in spam.p=rejectrequests rejection of failing messages.
Receivers retain discretion over final handling. DMARC is an authentication and domain-abuse control, not a guarantee of placement or immunity from phishing.
How to move from monitoring to enforcement
Start with a valid policy and ensure you can review relevant authentication results. Inventory every service sending mail using your domain, including support tools, marketing platforms and forwarded flows. Confirm that legitimate messages pass aligned SPF or DKIM. After validation, consider moving deliberately from p=none to p=quarantine and then p=reject where appropriate. Test each change and monitor the effects before strengthening the policy further.
Understanding DMARC reporting
The optional rua tag designates where receivers that support DMARC aggregate reporting can send reports. Report frequency and completeness depend on participating receivers; adding rua does not guarantee that every receiver will send a report. Use an address or reporting service that can actually accept and process the reports. Some third-party reporting destinations require additional DNS authorization.
Example monitoring record
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
This is an example only. Replace the reporting address with a mailbox or service you control and verify. Do not copy an example address into production unchanged.
Why a message can fail DMARC
Typical causes include an SPF pass for a non-aligned envelope domain, a DKIM signature using a non-aligned d= domain, authentication failures, or message changes during forwarding. To diagnose a specific message, inspect its Authentication-Results, Return-Path, From: header and DKIM signature information-not just the domain's DNS record.
DMARC specification: RFC 7489.
Common DMARC Mistakes to Avoid
- Jumping straight to p=reject - Consider
p=rejectonly after confirming that legitimate messages pass aligned SPF or DKIM, and test the change. - Assuming reports will arrive - Adding
ruadoes not guarantee that every receiver will send a report. - Ignoring subdomains - The optional
sp=tag requests a policy for subdomains. - Forgetting third-party senders - Marketing platforms, CRMs, and support tools all need proper configuration.
Related Email Security Tools
Monitor Your DMARC Daily
Get alerts when your DMARC record changes or issues are detected.
Start Free Monitoring