DMARC Explained in 5 Minutes

What is DMARC in Plain English

DMARC is like a bouncer for your email domain. It tells email providers (Gmail, Outlook, Yahoo) what to do when someone sends an email claiming to be from your domain but fails authentication.

Without DMARC, anyone can send emails pretending to be you. With DMARC, you decide whether those fake emails get delivered, quarantined, or rejected.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on two existing standards -- SPF and DKIM -- and adds a policy layer that tells receiving servers how to handle failures.

Check your domain's current DMARC status with our free DMARC Checker.

The Three DMARC Policies

How to Create Your First DMARC Record

Setting up DMARC takes about five minutes. Here's the step-by-step process:

Step 1: Start with Monitoring

Create a TXT DNS record with the monitoring policy. This won't affect email delivery but will start sending you reports:

Step 2: Publish the Record

Add this as a TXT record at _dmarc.yourdomain.com in your DNS provider (Cloudflare, Route 53, GoDaddy, etc).

Step 3: Review Reports

Wait 2-4 weeks and review the aggregate reports that arrive at your rua email address. These reports show every IP that sent email using your domain and whether authentication passed or failed.

Step 4: Tighten the Policy

Once you've confirmed all legitimate senders are passing authentication, upgrade your policy:

Understanding DMARC Reports

• Aggregate reports (rua) are XML files sent daily by receiving servers like Gmail and Outlook.
• They show which IPs sent email for your domain and the volume from each IP.
• Each entry shows SPF and DKIM pass/fail results plus DMARC alignment status.
• Use them to find unauthorized senders before tightening your policy.

Our Email Health Score tool gives you a quick overview of your domain's authentication status without parsing XML reports manually.

Common DMARC Mistakes and How to Fix Them

1. Setting p=reject immediately

Jumping straight to p=reject without monitoring first will block legitimate emails from third-party services you forgot about. Always start with p=none and review reports before tightening.

2. Forgetting about third-party senders

Marketing tools (Mailchimp, SendGrid), CRMs (HubSpot, Salesforce), and transactional email services all send email on your behalf. Each one needs to be authorized in your SPF record or set up with DKIM signing for your domain.

3. Not adding rua for reporting

Without rua=mailto:..., you're flying blind. You won't know who is sending email as your domain or whether your authentication is working correctly.

4. Using multiple DMARC records

RFC 7489 requires exactly one DMARC record per domain. Publishing multiple v=DMARC1 records causes receiving servers to treat it as a configuration error and ignore DMARC entirely.

5. Ignoring subdomain policy

The sp= tag controls DMARC policy for subdomains. Without it, subdomains inherit the parent domain's policy. Attackers often spoof subdomains (like billing.yourdomain.com) to bypass DMARC.

DMARC and Email Forwarding: The Catch

DMARC works great for direct email delivery. But when email is forwarded, SPF fails because the forwarding server isn't authorized by the original sender's domain. If DKIM is also broken during forwarding, DMARC fails entirely.

This is the single biggest problem with DMARC enforcement: it punishes legitimate email forwarding. The solution is ARC (Authenticated Received Chain), which preserves authentication results through forwarding hops.

Read more in our detailed guide: Why Your Forwarded Emails Go to Spam.