DMARC Record Checker

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.