A DMARC record is a DNS TXT record that defines how receiving mail servers should handle emails that fail SPF and DKIM authentication. Defined in RFC 7489, DMARC is the final layer of email authentication that prevents domain spoofing and provides reporting visibility. Paste your DMARC TXT record value below to validate policy, URIs, and alignment settings.
Load Example
Policy Strength
Validation Checks
How to Use This DMARC Record Validator
DMARC is the enforcement layer that completes the email authentication trinity alongside SPF and DKIM. A DMARC record tells the world what to do with emails that fail your SPF and DKIM checks — and gives you visibility into how your domain's email is being used and potentially abused. This DMARC record validator checks every tag against RFC 7489 and provides security recommendations.
Step 1: Find Your DMARC Record
Your DMARC record is published as a TXT record at _dmarc.yourdomain.com. Unlike DKIM records, the DMARC record always lives at this fixed subdomain. Use the DNS Records Checker tool to look up the TXT record at _dmarc.yourdomain.com and paste the value here. If no record exists, your domain has no DMARC policy and is vulnerable to spoofing.
Step 2: Understand the Policy Strength Meter
The policy strength meter shows where your DMARC configuration falls on the spectrum from monitoring-only to full enforcement. p=none provides visibility only — emails that fail authentication are still delivered normally. p=quarantine sends failing emails to spam, protecting recipients while allowing legitimate edge cases through. p=reject blocks all failing emails outright — the gold standard for domains that send business email. The validator recommends upgrading from none to quarantine to reject over time.
Step 3: Set Up DMARC Reporting
The rua= tag is your aggregate report destination. Major mail providers (Gmail, Outlook, Yahoo) send daily XML reports to this address showing how many emails passed/failed DMARC and from which IP addresses. This is how you discover unauthorized senders using your domain and verify that all legitimate senders have proper SPF/DKIM configured before you increase policy strength. Always include a rua= address — monitoring without reporting is incomplete.
The Path to Full DMARC Protection
A well-known deployment path: Week 1 — set p=none; rua=mailto:dmarc@yourdomain.com and collect reports. Week 3 — review reports, ensure all legitimate senders have SPF or DKIM. Week 5 — upgrade to p=quarantine; pct=10 (quarantine 10% of failures). Week 7 — increase to pct=100. Week 10 — move to p=reject. This staged approach prevents accidentally blocking legitimate email while progressively increasing protection.
FAQ
What is a DMARC record and why is it important?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication policy defined in RFC 7489. It tells receiving mail servers what to do when an email fails SPF and DKIM checks — none (monitor only), quarantine (move to spam), or reject (block outright). DMARC also enables reporting, where receiving servers send aggregate reports back to domain owners showing how their domain's email is being handled. Without DMARC, even with valid SPF and DKIM, attackers can still spoof your domain.
What does this DMARC validator check?
This validator parses your DMARC record against RFC 7489 and verifies: that the record starts with v=DMARC1; that the required p= policy tag is present and set to none, quarantine, or reject; that rua= aggregate report URIs are valid mailto: addresses; that ruf= forensic URIs are valid if present; that pct= is a number from 0-100; that adkim= and aspf= alignment modes are r (relaxed) or s (strict); and that there are no unknown tags. It also shows a policy strength meter and security recommendations.
What is the difference between p=none, p=quarantine, and p=reject?
The p= tag controls what happens to emails that fail both SPF and DKIM: p=none means monitor only — take no action, just collect reports. This is the starting point for deployment. p=quarantine means suspicious emails should be moved to spam/junk folder. p=reject means failing emails should be rejected outright — the strongest protection. Best practice: start with p=none for 2-4 weeks to review reports, then move to p=quarantine, then p=reject once you're confident all legitimate email sources are covered.
What is the rua= tag and should I always set it?
The rua= tag specifies where aggregate DMARC reports should be sent. These reports (usually daily XML files from major receiving servers like Gmail and Outlook) show you how your domain's email is being handled globally — which servers are sending email for your domain, SPF/DKIM pass rates, and potential spoofing attempts. Yes, you should always set rua= — without it you're flying blind. Use a dedicated email address or a DMARC reporting service. Format: rua=mailto:dmarc@yourdomain.com.
Is my data safe when using this tool?
Yes. This DMARC record validator runs entirely in your browser using client-side JavaScript. Your DMARC record data is never sent to any server or stored anywhere. All parsing and validation runs locally on your device.
What does adkim= and aspf= control in DMARC?
These tags control DMARC alignment — how strictly the From: domain in the email must match the domains authenticated by DKIM and SPF. Relaxed alignment (r, the default) allows subdomain matches: if your email is from sub.example.com, DMARC alignment passes if DKIM/SPF authenticated example.com or any subdomain. Strict alignment (s) requires exact domain matching: the From: domain must exactly match the DKIM signing domain and the SPF envelope from domain. Most deployments use relaxed alignment.