Back to Tools

DMARC Record Checker

Check your domain's DMARC policy to protect against email spoofing and phishing. Verify your DMARC record configuration and get recommendations for improvement.

About this tool

You've set up SPF and DKIM — great. But without DMARC, inbox providers still don't know what to do when those checks fail. Should they deliver the email anyway? Send it to spam? Reject it entirely? DMARC (Domain-based Message Authentication, Reporting, and Conformance) answers that question by publishing a policy in your DNS that tells receivers exactly how to handle unauthenticated mail from your domain.

How DMARC works

DMARC sits on top of SPF and DKIM. When a receiver gets an email claiming to be from your domain, it checks SPF and DKIM first. Then it checks your DMARC record (published at _dmarc.yourdomain.com) to see if either result "aligns" with the From domain. Alignment means the domain in the From header matches the domain that passed SPF or DKIM. If alignment passes, DMARC passes. If it fails, DMARC tells the receiver what to do: nothing (p=none), quarantine it (p=quarantine), or reject it outright (p=reject).

A typical DMARC record looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100. This quarantines 100% of failing messages and sends aggregate reports to your email. Generate yours with our DMARC generator.

The right way to roll out DMARC

Never jump straight to p=reject. Start with p=none to collect reports without affecting delivery. After 2-4 weeks, review the reports to identify every legitimate service sending as your domain — your ESP, transactional email provider, CRM, support tool, etc. Fix any that fail authentication. Then move to p=quarantine with pct=25 (only affects 25% of failing messages), gradually increasing to pct=100. Once you're confident, switch to p=reject. This phased approach prevents you from accidentally blocking your own legitimate emails.

Understanding DMARC reports

DMARC aggregate reports (rua) are XML files sent daily by receiving servers. They show every IP that sent email using your domain, whether SPF and DKIM passed, and how many messages were sent. Most people find raw XML unreadable — use a DMARC report analyzer service to visualize the data. Forensic reports (ruf) contain details about individual failures, but many providers don't send them due to privacy concerns.

Common DMARC pitfalls

The biggest mistake is forgetting about third-party senders. That HR tool sending onboarding emails, the billing system sending invoices, the support platform sending ticket updates — they all need SPF and DKIM alignment with your domain. Use DMARC reports in "none" mode to find these before enforcing a policy. Another pitfall: not setting up a dedicated mailbox for DMARC reports. If you use your personal inbox, you'll be buried in XML attachments within a day. Finally, verify your record has propagated globally with the DNS propagation checker, and use the email header analyzer to debug specific failures.

Frequently Asked Questions

What is DMARC and do I really need it?

DMARC tells inbox providers what to do when emails from your domain fail SPF and DKIM checks. Without it, providers make their own judgment call — which often means letting spoofed emails through. As of 2024, Google and Yahoo require DMARC for bulk senders. Even if you're not a bulk sender, DMARC protects your domain from being used in phishing attacks targeting your customers or partners.

What's the difference between p=none, p=quarantine, and p=reject?

p=none means 'do nothing, just send me reports' — use this for monitoring. p=quarantine means 'send failing emails to spam' — use this as a middle step. p=reject means 'block failing emails entirely' — this is the strongest protection. Always start with none, review reports for 2-4 weeks, then gradually move to quarantine and finally reject. Jumping straight to reject will almost certainly block some of your own legitimate emails.

What are DMARC aggregate reports and how do I read them?

Aggregate reports (rua) are XML files that receivers send you daily. They list every IP address that sent email using your domain, the volume, and whether SPF/DKIM/DMARC passed or failed. Raw XML is painful to read — use a free DMARC report analyzer to visualize the data. The key thing to look for is any legitimate sender that's failing alignment, so you can fix their authentication before enforcing a strict policy.

What does DMARC alignment mean?

Alignment means the domain in your From header matches the domain that passed SPF or DKIM. There are two modes: strict (exact match required) and relaxed (subdomains count). For example, if your From is user@yourdomain.com and SPF passes for mail.yourdomain.com, relaxed alignment passes but strict fails. Most people use relaxed alignment (the default) because it's more forgiving with subdomains.

How does DMARC interact with email forwarding?

Forwarding is DMARC's biggest challenge. When someone forwards your email, SPF breaks because the forwarding server's IP isn't in your SPF record. If DKIM also breaks (because the forwarder modified the message), DMARC fails. This is a known problem and the reason ARC (Authenticated Received Chain) was created. Major providers like Gmail support ARC, but it's not universal. If you get DMARC failures from forwarded messages, that's expected behavior.

What's the pct tag in DMARC and should I use it?

The pct tag controls what percentage of failing messages your policy applies to. Setting pct=25 with p=quarantine means only 25% of failing emails go to spam — the rest get delivered normally. It's a safety valve during rollout. Start at pct=25, check reports for a week, bump to 50, then 75, then 100. Once you're at pct=100 with quarantine and everything looks good, switch to p=reject.

My DMARC reports show failures from services I use. What do I do?

This is exactly what the monitoring phase is for. Identify each failing IP address — match it to a service using reverse DNS or your ESP's documentation. Then fix the alignment: add the service to your SPF record, set up DKIM signing with your domain, or both. Common culprits are CRM systems, support tools, and transactional email services that were set up without custom domain authentication.

Can I have different DMARC policies for subdomains?

Yes, use the sp= tag to set a separate policy for subdomains. For example, you might have p=reject for your main domain but sp=none for subdomains if different teams manage them. You can also publish separate DMARC records on individual subdomains to override the parent domain's policy. This is useful when your marketing team uses marketing.yourdomain.com and needs a more relaxed policy during their own rollout.

Compare email marketing software

Hands-on roundups to help you pick the right platform.

More Free Tools

View all tools

SPF Record Checker

Ensure your domain is properly authenticated with our SPF record checker. Avoid spoofing and improve inbox placement.

DKIM Record Checker

Verify your domain's DKIM configuration for email authentication. Check the public key, selector, and key strength to ensure your emails are properly signed.

Email Header Analyzer

Analyze email headers to trace routing, check authentication (SPF, DKIM, DMARC), identify delivery delays, and debug email issues. Paste headers from any email client.

MX Record Lookup

Look up MX (Mail Exchange) records for any domain to see which mail servers handle its email. Essential for troubleshooting email delivery and verifying domain configuration.