Common DMARC Mistakes to Avoid
Common DMARC Mistakes to Avoid
Overview
DMARC deployments fail for predictable reasons. Most issues come from rushing through setup, misunderstanding how the standards work, or skipping steps. This guide covers the most common mistakes and how to avoid them.
Mistake 1 — Jumping straight to p=reject
The most common and damaging mistake. Skipping p=none and jumping straight to p=reject blocks email from any source you haven't configured — including legitimate services you forgot about.
What happens: Marketing emails stop sending. Invoices from your accounting software don't arrive. Customer support tickets fail. Everyone gets confused about why email is broken.
The fix: Always start at p=none. Collect 1–2 weeks of data. Fix every legitimate sender. Then advance slowly.
Mistake 2 — Two SPF records
DNS allows only one SPF record per domain. If you have two TXT records starting with v=spf1, all SPF checks return PermError — which means SPF fails for everyone.
What happens: Legitimate email starts failing SPF. Depending on your DMARC policy, this can affect delivery.
The fix: Check with dig TXT yourdomain.com. If you see two SPF records, merge them into one.
Mistake 3 — Exceeding 10 SPF lookups
As you add services, the SPF lookup chain grows. Exceeding 10 lookups causes PermError — same result as having two records.
What happens: Gradual, hard-to-diagnose failures as you add services over time. Usually noticed when a specific service's emails start failing SPF with no obvious change.
The fix: Use the SPF Explorer in DMARC+ to count lookups. Remove unused services. Move high-volume senders to dedicated subdomains.
Mistake 4 — Forgetting _dmarc in the DNS record name
The DMARC record must be at _dmarc.yourdomain.com. Without the _dmarc prefix, it's just a random TXT record that mail servers won't look for.
What happens: DMARC records are never found. Your policy is never applied. Aggregate reports are never sent. You think DMARC is deployed, but it isn't.
The fix: Verify with dig TXT _dmarc.yourdomain.com — you should see your DMARC record.
Mistake 5 — Setting p=reject on parked domains without fixing SPF
If a parked domain has no SPF record and you set p=reject, email from that domain is blocked. But if you also set an SPF record with -all (nothing can send), it's consistent and correct.
The fix: Parked domains need both null SPF (v=spf1 -all) and p=reject DMARC to be properly secured.
Mistake 6 — Not monitoring after enforcement
Reaching p=reject isn't the finish line. New services get added, sending infrastructure changes, and new spoofing attempts emerge. Without monitoring, problems build up silently.
What happens: A new marketing tool gets deployed without SPF/DKIM setup. Weeks pass before anyone notices emails aren't being delivered.
The fix: Review DMARC+ monthly. Set up alerts for significant drops in pass rate.
Mistake 7 — Only configuring DKIM for one service
DKIM is needed for every service that sends email from your domain, not just your primary mail server. If Salesforce sends from your domain without DKIM, those emails fail alignment — and if your only authentication is SPF, forwarded email fails too.
The fix: Configure DKIM for every third-party sender, not just your primary mail server.
Mistake 8 — Treating p=none as "done"
p=none is monitoring mode — it provides data but doesn't protect anything. Many organisations deploy p=none and never advance. Attackers can still spoof your domain freely.
The fix: Set a target date to reach p=reject. Track your pass rate weekly. Treat it as a project with a deadline.
Mistake 9 — Not understanding SPF alignment
SPF passes when the sending IP is in your SPF record — but that alone doesn't satisfy DMARC. For DMARC to pass on SPF, the Return-Path domain must also match (align with) your From: header domain.
Many third-party services send with their own domain in the Return-Path, meaning SPF passes but DMARC fails alignment.
The fix: Configure services to use a custom MAIL FROM that's a subdomain of your domain, OR set up DKIM (which aligns via the d= tag, not the Return-Path).
Mistake 10 — Checking DMARC with a single test email
Running one test and declaring success doesn't account for the full range of sending sources, delivery paths, and receiver behaviours. Your DMARC pass rate in production will almost always look different from a controlled test.
The fix: Use DMARC+ aggregate report data from real traffic over 7+ days before making policy decisions. Let the data guide you, not individual tests.
Quick reference — common issues and their causes
| Symptom | Likely cause |
|---|---|
| All email failing SPF with PermError | Two SPF records, or > 10 lookups |
| One service always failing DMARC | SPF alignment issue — service using its own Return-Path |
| DMARC reports never arriving | Missing _dmarc prefix, or rua= address incorrect |
| Legitimate email blocked after p=reject | Undiscovered sending source — check DMARC+ for new sources |
| DKIM working for most but not for forwarded | Expected — SPF alignment breaks on forward; DKIM doesn't |
| High failure rate from one country | Active spoofing campaign using your domain — enforce to block it |