Common DMARC Mistakes

DMARC is simple to deploy but easy to get wrong. Here are the most common mistakes we see — and how to avoid them.

❌ Mistake #1: Jumping straight to p=reject

The biggest mistake. If you haven’t audited your email sources, going straight to p=reject will block legitimate emails from services you forgot about — marketing platforms, CRMs, billing systems, third-party tools.

✅ Fix: Always start with p=none, review your reports for 2-4 weeks, then gradually move through p=quarantine to p=reject. See our policy guide.

❌ Mistake #2: No rua= address (no reporting)

Publishing a DMARC record without an rua= address means you’re flying blind. You won’t know who’s sending email as your domain, whether legitimate senders are passing, or if you’re being spoofed.

✅ Fix: Always include rua=mailto:address@example.com. Use our DMARC Record Generator to get a free reporting address.

❌ Mistake #3: SPF exceeds 10 DNS lookups

Every include:, a, and mx in your SPF record costs a DNS lookup. Exceed 10 and SPF returns a PermError — which means SPF fails for all your email, and DMARC fails too (unless DKIM saves you).

✅ Fix: Audit your SPF record with our Domain Checker. Remove unused includes, use ip4: where possible, or split senders across subdomains.

❌ Mistake #4: Forgetting DKIM

Many people set up SPF and DMARC but forget DKIM. This is risky because SPF breaks when email is forwarded — DKIM is your safety net. Without DKIM, forwarded emails will fail DMARC.

✅ Fix: Enable DKIM for every service that sends email as your domain. See our DKIM setup guide.

❌ Mistake #5: Ignoring subdomains

Your DMARC record at _dmarc.example.com might have p=reject, but if you don’t set sp= or publish separate records for subdomains, attackers can spoof anything.example.com using the inherited policy (or lack thereof).

✅ Fix: Add sp=reject to your DMARC record to protect all subdomains. Or publish individual DMARC records for subdomains that send email.

❌ Mistake #6: Multiple SPF records

A domain must have exactly one SPF record. If you have two (e.g., one from your host and one you added), SPF returns a PermError and fails.

✅ Fix: Merge all include: directives into a single SPF record. Delete duplicates.

❌ Mistake #7: Using +all in SPF

+all means “allow anyone to send as my domain” — it completely defeats the purpose of SPF. Sometimes added by mistake or copied from a bad example.

✅ Fix: Use -all (hard fail) for production or ~all (soft fail) during setup. Never +all.

❌ Mistake #8: Setting and forgetting

Email infrastructure changes over time. New services get added, old ones get removed, IPs change. A DMARC record that worked 6 months ago might not cover a new tool someone added to the marketing stack.

✅ Fix: Keep monitoring your DMARC reports even after reaching p=reject. Review them at least monthly for new senders or failures.

❌ Mistake #9: Wrong DMARC record location

The DMARC record must be at _dmarc.yourdomain.com, not at the root domain. Some DNS providers auto-append the domain, so entering _dmarc.example.com actually creates _dmarc.example.com.example.com.

✅ Fix: In most DNS providers, enter just _dmarc as the hostname (they append the domain automatically). Use our Domain Checker to verify it’s in the right place.

❌ Mistake #10: Not using DMARC at all

The most dangerous mistake. Without DMARC, anyone can send email pretending to be your domain. Your customers, partners, and employees are all potential targets. Google and Yahoo now require DMARC for bulk senders.

✅ Fix: Generate a DMARC record right now. Even p=none with reporting gives you visibility you didn’t have before.

Check your setup for mistakes

Our Domain Checker validates your DMARC and SPF records and flags common issues.

Check Your Domain →