Most email authentication failures I see in support tickets trace back to seven recurring mistakes. You've configured SPF, DKIM, and DMARC records, but mail still lands in spam or bounces outright. The problem usually isn't the concept—it's a typo, a missing step, or a subtle DNS quirk that breaks the chain.
This guide walks through each error with its symptoms, the underlying cause, and the exact fix. Check your own setup against these patterns before filing a ticket with your host or email provider.
Error 1: SPF record exceeds 10 DNS lookups
Symptom
Your SPF record validates locally, but recipients report SPF PermError or SPF fail (too many lookups) in mail headers. Delivery to Gmail and Outlook degrades.
Root cause
The SPF specification caps DNS queries at ten per lookup to prevent abuse. Each include: directive counts as one lookup, and any nested includes count too. A typical mistake is chaining multiple third-party services—Mailchimp, SendGrid, Office 365, and Google Workspace—without flattening the record.
Fix
Audit your SPF record for all include: and a: mechanisms:
dig TXT yourdomain.com +short | grep "v=spf1"
Count the lookups manually or use an SPF checker tool. If you hit ten, consolidate vendors by moving to a single ESP where possible, or replace include: with explicit ip4: and ip6: blocks:
v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 include:_spf.google.com ~all
For large infrastructures, SPF flattening services can help, but they introduce a new dependency. Weigh that against the risk of your IPs changing.
Error 2: Missing or mismatched DKIM selector
Symptom
Outbound mail shows DKIM=none or DKIM=neutral (no key for selector) in headers. The receiving server never validates your signature.
Root cause
DKIM relies on a DNS TXT record at a specific subdomain: selector._domainkey.yourdomain.com. If you configured the signing daemon (OpenDKIM, cPanel's DKIM manager, or your ESP) with selector default, but the DNS record lives at mail._domainkey.yourdomain.com, the lookup fails silently.
Another variant is copying the public key incorrectly—extra line breaks, missing quotes, or truncated strings all break validation.
Fix
First, identify the selector your mail server is using. In cPanel, check Email Deliverability or look at the DKIM-Signature header in a raw sent message:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=default;
The s= tag is the selector. Then verify the DNS record:
dig TXT default._domainkey.yourdomain.com +short
You should see a TXT record with v=DKIM1; k=rsa; p=MIGfMA0.... If it's missing, publish it. If it's malformed, regenerate the key pair and copy the public key exactly as provided—no extra spaces, no line breaks unless your DNS panel requires semicolon-joined segments.
Test with dkimvalidator.com or send a message to a Gmail account and inspect the headers.
Error 3: DMARC policy set to p=reject too soon
Symptom
Legitimate mail from your domain bounces or vanishes. Users complain they never received password resets or invoices. You check logs and see DMARC fail with p=reject.
Root cause
You published a DMARC record with p=reject before fixing SPF and DKIM alignment across all sending sources. A single misconfigured relay, an old marketing tool, or a forgotten subdomain can trigger hard failures.
Fix
Roll back to p=none immediately:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100
Monitor the aggregate reports (rua) for at least two weeks. Look for sources that fail SPF or DKIM. Fix each one by adding it to your SPF record or configuring DKIM signing, then step up to p=quarantine at a low percentage:
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
Gradually increase pct and only move to p=reject when failure rates drop below one percent.
Error 4: SPF record contains multiple v=spf1 statements
Symptom
SPF validation fails with PermError or Multiple SPF records found. Some recipients accept mail, others reject it outright.
Root cause
DNS allows multiple TXT records at the same name, but SPF requires exactly one record starting with v=spf1. A common scenario is adding a second SPF record when migrating mail providers instead of merging the mechanisms into one.
Another trigger is leftover records from a previous admin or a DNS zone template that injected a default SPF.
Fix
Query your domain's TXT records:
dig TXT yourdomain.com +short
If you see two or more lines starting with "v=spf1", consolidate them. Merge all include:, ip4:, ip6:, and a: mechanisms into a single record:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all
Delete the duplicate records in your DNS panel. Wait for TTL to expire—usually five to fifteen minutes—and test again.
Error 5: DKIM key rotation breaks old signatures
Symptom
Mail sent weeks ago suddenly shows DKIM=fail when users forward or reply. New outbound messages validate correctly, but threads break.
Root cause
When you rotate DKIM keys and immediately delete the old public key from DNS, any message still in flight or stored in a recipient's inbox fails validation on subsequent checks. Some ESP's anti-spam filters re-evaluate old messages when they're forwarded, triggering a failure.
Fix
When rotating keys, keep the old selector published for at least 30 days:
old-selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=OldPublicKey..."
new-selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=NewPublicKey..."
Configure your mail server to sign with the new selector going forward, but leave the old record live. After the grace period, delete the old record. Most major platforms handle this automatically, but self-hosted OpenDKIM or Postfix setups require manual DNS updates.
If you've already deleted the old key and users are affected, republish it temporarily to restore validation.
Error 6: DMARC subdomain policy not aligned
Symptom
Mail from newsletter.yourdomain.com fails DMARC even though SPF and DKIM pass for the subdomain. The parent domain's DMARC record exists, but the subdomain doesn't inherit the policy as expected.
Root cause
DMARC policies apply to the organizational domain by default, but subdomains can override them with their own DMARC records. If you rely on the parent policy, you must ensure aspf=r (relaxed) and adkim=r alignment, or the subdomain must publish its own policy.
Another gotcha is the sp= tag in the parent record, which sets the policy for subdomains. If sp=reject but the subdomain doesn't pass alignment, mail fails.
Fix
Check the parent domain's DMARC record:
dig TXT _dmarc.yourdomain.com +short
If it includes sp=quarantine or sp=reject, and your subdomain fails alignment, either:
- Publish a subdomain DMARC record at
_dmarc.newsletter.yourdomain.comwith its own policy:
v=DMARC1; p=none; rua=mailto:[email protected]
-
Fix alignment by ensuring the subdomain's SPF record authorizes the sending IP and the DKIM signature's
d=tag matchesnewsletter.yourdomain.com. -
Relax the parent policy temporarily (
sp=none) while you debug.
Subdomain DMARC is often overlooked in bulk mail setups and marketing automation. Check your DMARC reports for subdomain failures.
Error 7: SPF ~all vs -all misunderstanding
Symptom
You set SPF to -all (hard fail) expecting to block spoofing, but legitimate mail from an unlisted source bounces. Or you use ~all (soft fail) and spammers exploit it to send forged mail.
Root cause
The SPF qualifier determines what receiving servers should do with mail that doesn't match your record:
+all– pass everything (never use this)~all– soft fail; most servers accept but flag-all– hard fail; servers should reject?all– neutral; no policy (rarely useful)
A common mistake is jumping straight to -all without accounting for every sending source. The result is false positives. Conversely, sticking with ~all indefinitely gives phishers room to bypass filters.
Fix
Start with ~all and collect data. Check your mail server logs and DMARC reports to identify every legitimate source. Add them to your SPF record. Once you're confident the record is complete, switch to -all:
v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
If you later discover a missed source, you'll need to add it quickly. Keep a list of authorized IPs and third-party includes in your documentation. -all is the right long-term posture, but it requires discipline.
What happens when DMARC reports pile up?
Aggregate reports arrive as XML attachments, often dozens per day for active domains. If you point rua= at a regular inbox, you'll drown in noise. Use a dedicated mailbox and either parse reports manually with a Python script or subscribe to a DMARC report analyzer service. The key data points are sending IP, SPF result, DKIM result, and message count. Focus on sources that show up frequently with failures.
Forensic reports (ruf=) are rarer and privacy-sensitive—many receivers don't send them. When they do arrive, they contain full headers and sometimes message bodies. Treat them carefully and store them securely.
How do you test all three records at once?
Send a test message to a Gmail address you control. View the original message source (three-dot menu > Show original). Look for the Authentication-Results header:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates 203.0.113.10 as permitted sender);
dkim=pass [email protected] header.s=default;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE)
All three should say pass. If any say fail, softfail, neutral, or none, trace back through the specific error patterns above.
Alternatively, use mail-tester.com or mxtoolbox.com/deliverability for automated checks. They catch most configuration issues but can miss edge cases like subdomain alignment.
Quick reference: what to check first
When email authentication breaks, follow this checklist before diving into advanced troubleshooting:
- Count SPF lookups – strip out unnecessary
include:directives or flatten the record. - Verify the DKIM selector matches DNS – check the
s=tag in outbound headers and queryselector._domainkey.yourdomain.com. - Confirm DMARC is in monitoring mode – use
p=noneuntil SPF and DKIM pass consistently. - Check for duplicate SPF records – only one
v=spf1per domain. - Review subdomain policies – ensure
sp=aligns with your sending setup. - Test from every sending source – don't assume your ESP handles alignment automatically.
- Read the actual error headers – symptoms differ, but the root cause is almost always in the DNS records or mail server config.
Fix these seven errors and you'll solve most authentication failures. The rest is tuning policies and keeping your records up to date as infrastructure changes.
Common questions
Can I use both SPF and DKIM, or do I need all three?
You need SPF and DKIM for DMARC to work. DMARC requires at least one of them to pass and align with the From domain. Running all three together is standard practice.
How long does DNS propagation take for email records?
TTL determines cache duration. Most email DNS records default to 300 seconds (five minutes) to one hour. Changes propagate quickly, but some recursive resolvers ignore TTL. Wait at least an hour before trusting tests.
What if my host auto-generates SPF and I need to customize it?
In cPanel's Zone Editor, you can edit the TXT record directly. Some hosts lock the record and require you to request changes through support. Check your panel's Email Deliverability or DNS management section first.
Do forwarded emails break DMARC?
Yes, when a mailbox forwards a message without re-signing it. SPF fails because the forwarding server's IP isn't in the original domain's SPF record, and DKIM may break if the forwarder modifies the message. Senders can't fully fix this—it's a known weakness in email authentication.
Should I delete old DKIM selectors immediately after rotating keys?
No. Keep the old selector live for at least 30 days so messages already delivered can still validate if forwarded or re-checked.
Fixing authentication before enforcement
SPF, DKIM, and DMARC errors are fixable if you approach them methodically. Diagnose symptoms in mail headers, identify the root cause in your DNS records or mail server config, and apply the exact fix for that error. Don't jump straight to enforcement with p=reject until you've monitored reports and confirmed all legitimate sources pass alignment. Most authentication failures I see in tickets trace back to one of these seven patterns—check your setup against them and you'll close the gaps before they break delivery.