Common SPF/DKIM/DMARC Misconfigurations and How to Fix Them
Email authentication is not complicated in theory. Add some DNS records, enable some settings, and you are done. In practice, it is one of the most common sources of deliverability problems because the setup involves multiple DNS records, multiple sending services, and multiple points where things can go wrong silently.
Most authentication issues do not announce themselves with error messages. Your emails just quietly start going to spam, and you may not connect the cause to a DNS record you modified three weeks ago. Here are the most common misconfigurations and how to diagnose and fix each one.
SPF: Too Many DNS Lookups
This is the number one SPF problem, and it is invisible unless you specifically check for it.
The SPF specification limits evaluation to 10 DNS lookups. Every "include" statement in your SPF record triggers one or more lookups. Some includes reference other includes, creating nested lookups. When your total exceeds 10, the entire SPF record fails with a PermError, meaning every email you send fails SPF authentication.
How to diagnose: Use MXToolbox's SPF Record Check tool. Enter your domain and it will show the total number of DNS lookups. If it says "Too many lookups" or shows more than 10, you have this problem.
How to fix: Remove services you no longer use from your SPF record. If you stopped using Mailchimp six months ago but its include is still in your SPF, remove it. Replace include statements with direct IP addresses where possible (ip4: entries do not count as lookups). Consider an SPF flattening service like Auto SPF or SPF Guru that resolves includes into IP addresses and maintains the flattened record automatically.
SPF: Multiple SPF Records
You can only have one SPF record (one TXT record starting with v=spf1) per domain. If you have two, both are invalid. This happens when someone adds a new SPF record for a new service without realizing one already exists.
How to diagnose: Look up all TXT records for your domain. If you see two entries starting with v=spf1, that is the problem.
How to fix: Merge both records into a single SPF record that includes all authorized sources. Delete the duplicate. Test after merging to confirm the combined record works and does not exceed the 10-lookup limit.
DKIM: Key Not Published or Mismatched
DKIM fails when the public key in DNS does not match the private key being used to sign emails, or when the DNS record simply does not exist.
This commonly happens when you set up DKIM through your email service's admin console (which generates the keys and starts signing) but forget to add the corresponding DNS record (which publishes the public key). Emails get signed, but the receiving server cannot find the public key to verify the signature.
How to diagnose: Send a test email and check the authentication results in the headers. If you see dkim=fail or dkim=neutral, the verification is not working. Use MXToolbox's DKIM Lookup tool with your domain and selector to check if the public key is published.
How to fix: Go to your email service's admin console and find the DKIM setup section. It will show you the DNS record (either a TXT or CNAME record) that needs to be added. Add this record to your DNS provider. Wait for propagation (up to 48 hours, though usually much faster) and test again.
DKIM: Selector Mismatch
Each DKIM configuration uses a selector to identify which key to look up. If the selector in the DKIM-Signature header does not match the selector used in the DNS record, DKIM fails.
This happens when you configure DKIM with one selector name in DNS but the email service signs with a different selector. It also happens when you copy DNS records from documentation without adjusting the selector to match your specific setup.
How to diagnose: Inspect the DKIM-Signature header in a sent email. Note the s= value (the selector). Then check DNS for that specific selector: selector._domainkey.yourdomain.com. If no record exists at that exact subdomain, you have a mismatch.
How to fix: Either update the DNS record to use the correct selector from the DKIM-Signature header, or reconfigure the email service to use the selector you published in DNS. The selector names must match exactly.
DMARC: No Record
As of 2025-2026, Gmail, Yahoo, and Microsoft all require DMARC records for bulk senders. Not having a DMARC record does not cause immediate rejection, but it means you are missing a foundational authentication layer that mailbox providers increasingly expect.
How to diagnose: Look up the TXT record at _dmarc.yourdomain.com. If no record exists, you do not have DMARC configured.
How to fix: Add a TXT record at _dmarc.yourdomain.com with the value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. This is the most basic DMARC record. It starts in monitoring mode and sends aggregate reports to the specified email address.
DMARC: Alignment Failures
DMARC passes only when at least one of SPF or DKIM passes AND aligns with the From domain. Alignment means the domain in the SPF check or DKIM signature matches the domain in the email's From header.
The most common alignment failure: your cold email platform sends through its own servers (passing SPF for its domain) and signs with its own DKIM key (passing DKIM for its domain), but neither matches your From domain. Both SPF and DKIM pass, but neither aligns with your domain, so DMARC fails.
How to diagnose: Check DMARC aggregate reports or send a test email and inspect the authentication results. If you see spf=pass but dmarc=fail, it is likely an alignment issue.
How to fix: Configure custom DKIM for each sending service so that the d= tag in the DKIM signature matches your From domain. For SPF alignment, ensure the envelope sender (MAIL FROM) matches your From domain, which may require configuring a custom return-path with your sending service.
DMARC: Subdomain Policy Gaps
DMARC policies can apply differently to subdomains depending on the sp= tag. If you have p=reject for your main domain but no sp= tag, subdomains inherit the main domain's policy by default. But if you have sp=none, subdomains have no protection even though the main domain is protected.
Attackers sometimes exploit this gap by spoofing email from subdomains (marketing.yourdomain.com, info.yourdomain.com) that are not covered by your DMARC policy.
How to diagnose: Check your DMARC record for the sp= tag. If sp=none while p=reject, you have a gap.
How to fix: Either remove the sp= tag (so subdomains inherit the main domain's policy) or set sp=reject to explicitly protect subdomains.
General: DNS Propagation Timing
After making any DNS change (SPF, DKIM, DMARC), the change needs to propagate across the DNS system. This typically takes 15 minutes to 4 hours, but can take up to 48 hours in some cases.
A common mistake is making a DNS change, immediately testing, seeing it fail, and making additional changes to "fix" it before the original change has propagated. This leads to compounding errors.
After any DNS change, wait at least 1-2 hours before testing. If the test still fails after 4 hours, then investigate. Use DNS checking tools that query multiple DNS servers worldwide to see whether your records have propagated or are still in transit.
Testing Your Complete Authentication Setup
After fixing any misconfiguration, run a comprehensive test of your entire authentication stack.
Send a test email from each sending service to a Gmail account. Inspect the original message headers. Verify spf=pass, dkim=pass, and dmarc=pass for each service.
Use mail-tester.com to get a comprehensive authentication score. Submit an email and review the detailed results for SPF, DKIM, and DMARC.
Check your DMARC aggregate reports 48 hours after the fix to verify the authentication pass rate has improved.
Authentication misconfigurations are one of the most common and most fixable causes of poor email deliverability. Most issues are simple DNS record problems that take minutes to fix once identified. The hard part is identifying them in the first place, which is why regular testing and DMARC report monitoring should be part of every email sender's operational routine.
