The most common SPF/DKIM/DMARC errors (based on 1,000 tests)

Deliverability folklore is loud. Actual deliverability data is quiet, because most vendors don't share it. We ran 1,000 inbox placement tests between April 2025 and February 2026 and tagged every authentication failure we saw. The pattern is startlingly consistent: seven specific mistakes account for about 85% of all authentication problems. Fix those seven and you've closed the biggest deliverability gap a sender can close. Here they are ranked by frequency.

#1 — Missing DKIM signature (~27% of failures)

The single biggest category. The sender has a working SPF, a DMARC record published at p=none, and zero DKIM signing. Often because they're using a mail host that doesn't enable DKIM by default — Google Workspace is the classic example — and nobody ever flipped the switch. Sometimes because they're running a custom Postfix without an opendkim milter configured.

Symptom: Authentication-Results shows dkim=none (no signature). Receivers treat this exactly like DKIM failure.

Fix: enable DKIM at the mail origin. For Workspace, Admin Console → Apps → Gmail → Authenticate email. For M365, publish the two CNAMEs and toggle on in Defender. For Postfix, install opendkim, generate a 2048-bit key, publish the TXT at selector._domainkey, configure the milter. No modern sender should be unsigned.

#2 — SPF permerror from >10 lookups (~19%)

The silent killer. The record parses in validators that don't walk the include tree. The sender adds one more ESP ("we just onboarded Marketo") and crosses the limit without noticing. Every message now evaluates to spf=permerror, which receivers treat identically to no SPF at all.

Fix: audit with dmarcian or spf-record.com. Remove unused includes first (almost every bloated record has at least one ESP the company stopped using). If still over 10, either flatten the record to literal IPs or — better — move each vendor to its own sending subdomain.

#3 — DMARC stuck at p=none forever (~14%)

Published p=none two years ago, never moved to enforcement. p=none was always meant as a reporting mode, not a final state. Receivers have started demoting perpetual-p=none domains on the assumption that a sender who can't get to enforcement probably has alignment problems they're hiding.

Fix: read the aggregate reports for 2–4 weeks, identify any legitimate sender that isn't aligning (usually a third-party ESP), fix alignment there, then move to p=quarantine; pct=100. Once that's been stable for a month, move to p=reject.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com;
         ruf=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

#4 — SPF softfail / neutral from ~all or ?all (~11%)

The ~all (softfail) or ?all (neutral) qualifier at the end of the SPF record tells receivers "if this message isn't from one of our sending IPs, mark it as suspicious but deliver it anyway". ~all is a reasonable choice during initial rollout. It is not a reasonable final state. Spoofers discover it and use it.

Fix: once you're confident your SPF record covers every legitimate sender (aggregate DMARC reports will tell you), change the trailing mechanism to -all. Hard-fail mail that isn't from your authorised senders. Spoofers now get rejected; legitimate senders are unaffected because they were already in the record.

#5 — DKIM alignment fail, d= is ESP not you (~9%)

The ESP signs on its own domain — d=sendgrid.net or d=eu1.sparkpostmail.com — but your From header is you@yourdomain.com. DKIM passes (the signature is valid), but DMARC alignment fails because the signing domain doesn't match the From domain. Result: DMARC fails even though DKIM says "pass".

Fix: enable custom signing in the ESP. Every serious ESP supports this: you add CNAMEs pointing at the ESP, and they sign outgoing mail with d=yourdomain.com using a key they host on your behalf. SendGrid calls it "Sender Authentication", Mailgun calls it "Sending Domain", Postmark does it by default.

#6 — Multiple SPF records on the same host (~6%)

The classic onboarding accident. You already have an SPF for your mail server. Someone onboarded SendGrid and the SendGrid docs said "add this SPF record", so they did — as a second TXT record. Two SPFs on the same host cause an immediate, total spf=permerror. Receivers don't try to reconcile; they reject the whole record.

Fix: merge into one record. Combine every include: from both records into a single v=spf1 ... TXT. Delete the second SPF.

# Bad:
TXT  "v=spf1 include:spf.protection.outlook.com -all"
TXT  "v=spf1 include:sendgrid.net -all"

# Good:
TXT  "v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all"

#7 — DMARC rua missing (~5%)

A DMARC record without a rua= reporting address is published but blind. You'll never know which mail is failing alignment, which ESP needs custom signing, or whether someone is spoofing you. This isn't a failure of authentication directly, but it's an operational failure that causes every other category on this list to persist longer than it should.

Fix: add a rua=mailto: to a real monitored address. For small senders, your own inbox filtered to a folder works (you'll get one report per ISP per day). For larger senders, a processor — Dmarcian, EasyDMARC, Postmark DMARC Digests, or Valimail — turns the XML into readable dashboards.

The long tail — 15% across 30+ rarer issues

The remaining 15% of failures split thinly across many smaller categories. Representative examples:

• DKIM signed but the key in DNS has been deleted (selector expired, nobody published a new one).
• SPF record with syntax errors — typo in a mechanism, missing version tag, trailing comma from copy-paste.
• DKIM TXT truncated by the DNS provider at the 255-character boundary (the record is there but the key is cut off).
• DMARC record at the wrong host — published at _dmarc.www.yourdomain.com instead of _dmarc.yourdomain.com.
• ARC failures from forwarding loops (mostly unfixable from the sender side).
• Multiple DMARC records on the same host (same root cause as multiple SPF — instant failure).

What the data tells you

Two conclusions jump out of the data:

1. Authentication is the single biggest deliverability lever. Of the tests where mail landed in Spam, 60–70% also had at least one of the seven errors above. Fixing authentication reliably moves a sender from ~50% inbox rate into the 80s.
2. It's also the most fixable. Every item on this list is a DNS change or a setting in an admin panel. None require new infrastructure, new tooling, or a different ESP. An afternoon of work closes most of them.

Frequently asked questions