Blog · Spf-dkim
The SPF and DKIM Configuration Mistakes That Break Email Delivery
You have SPF configured. You have DKIM set up. Your emails are being signed. And then something breaks: a major provider starts rejecting your mail, or a domain that should accept your messages silently drops them into spam folders.
The problem is rarely that SPF or DKIM is absent. It is that they are configured wrong in ways that are not obvious during testing but cause real failures in production.
This guide covers the specific misconfigurations that cause the most email delivery problems. Each one includes what the broken record looks like, why it fails, and how to fix it.
The seven most common SPF mistakes
1. Exceeding the 10 DNS lookup limit
RFC 7208 hard-limits SPF processing to 10 DNS lookups. Every include:, a:, mx:, ptr:, and exists: mechanism counts as one lookup. Exceeding the limit returns permerror, which most receiving servers treat as a hard failure.
A record with four third-party providers quickly approaches the limit:
v=spf1 include:_spf.google.com include:_spf.salesforce.com include:_spf.marketo.com include:_spf.mailchimp.com a mx ~all
That is six lookups before you even finish counting. Add two more providers or an a mechanism and you are over the edge. When SPF returns permerror, receivers cannot safely pass the message, so they reject it.
To check your current count, use an SPF analyzer tool or walk through your record manually counting each mechanism. If you are close to 10, consolidate. Replace include: directives with direct IP ranges where the provider gives you a static range. Audit whether old vendors you no longer use are still in the record.
2. Multiple TXT records at the/apex
SPF requires exactly one TXT record at the/apex domain. If a second TXT record exists (from a botched migration, a manual addition, or a system that added records automatically), receivers may read the wrong one or return permerror.
Check:
dig TXT example.com +short
If you see two TXT records and one starts with v=spf1, you have a split SPF situation. Find out which record is current, remove the stale one, and verify that only one remains.
3. No terminator (bare record)
SPF records need an explicit end directive. Without -all (hardfail) or ~all (softfail) at the end, the record has no policy statement. Receivers see no guidance on what to do with mail from sources not listed in the record.
This record looks valid during testing:
v=spf1 a mx include:_spf.google.com
No error. No warning. But it tells receivers nothing about what to do with mail from unlisted sources. Add -all or ~all at the end before going to production.
4. Include pointing to the wrong domain
Every include: mechanism must resolve to an SPF record that covers the IP addresses actually sending your mail. If the included domain has changed its sending infrastructure, the include may still pass even though the actual sending IPs have moved.
More concretely: if your vendor tells you to add include:_spf.vendor.com and vendor.com has recently migrated their sending infrastructure to new IP ranges without updating their SPF record, your SPF check may pass but the mail may not actually come from an authorized source.
Always verify that the included domain resolves to an SPF record that lists IPs you expect to send mail from.
5. Using softfail when hardfail is the right policy
~all (softfail) tells receivers to deprioritize mail from unlisted sources. It does not block anything. Spoofed mail from servers you do not control will typically land in the recipient's spam folder rather than being rejected.
If you have fully enumerated every IP and service that sends from your domain, softfail leaves a gap that spoofers can exploit. The right policy for a known, stable sending infrastructure is -all (hardfail).
Use ~all as a staging policy while auditing your sending sources. Once you are confident the record lists everything and nothing else should be sending from your domain, switch to -all.
6. Publishing SPF at the wrong domain
SPF must be published at the MAIL-FROM envelope domain, not the From header domain. These are frequently different.
The MAIL-FROM domain is set during SMTP and is often a subdomain like bounce.example.com or mail.example.com. The From header domain is what the recipient sees in their email client.
If your SPF record lives at example.com but your MAIL-FROM is bounce.example.com, receivers checking SPF will look up bounce.example.com and find no record. Your SPF check fails even though example.com has a perfectly valid record.
Check the MAIL-FROM domain with your mail server logs or by examining the envelope sender in headers. Verify that domain has an SPF record.
7. Forgetting to remove old provider includes when switching
When you move from one email platform to another, the old platform's include: often stays in the record. The new include gets added on top. Over time, SPF records accumulate includes for vendors that are no longer sending your mail but are still authorized to do so.
Before switching providers, audit what is currently in your SPF record. Remove includes for systems you are leaving. When you add a new provider, add only their include. Do not just append to the existing record without checking what is already there.
The seven most common DKIM mistakes
1. 2048-bit RSA keys failing to resolve
DKIM keys longer than 1024 bits can fail to resolve through DNS resolvers that do not properly handle large UDP responses or do not fully support EDNS buffer sizes. When the key cannot be retrieved, the DKIM check returns none, which fails DMARC alignment.
Test from multiple vantage points:
dig TXT selector1._domainkey.example.com
dig TXT selector1._domainkey.example.com @8.8.8.8
If resolution succeeds from some locations and fails from others, the key length is likely the problem. Switch to 1024-bit RSA keys, or verify your DNS infrastructure fully supports large responses before using 2048-bit.
2. Selector name mismatch
DKIM selectors must match exactly between the DNS TXT record and the signing configuration in your mail server. The selector in DNS is the prefix before _domainkey.example.com. The selector in your MTA config is what you tell the signer to use.
If DNS has selector1._domainkey.example.com but your MTA is configured to sign with selector2, receivers look up selector1, find a key, and the signature validation fails because it was not signed with that key.
Always verify the selector string in your MTA config matches a TXT record that actually exists in DNS.
3. DKIM domain does not align with From header
DKIM signatures carry a d= tag that specifies the signing domain. DMARC alignment requires this domain to match or be a parent of the From header domain. A signature with d=thirdparty.com on a message with From: sender@example.com passes DKIM but fails DMARC alignment.
This happens routinely with third-party email platforms that sign with their own domain by default. The DKIM check passes. The receiver is satisfied. But DMARC enforcement at the recipient side still fails because the signing domain does not match the From header domain.
Enable custom DKIM signing with your own domain whenever the platform supports it. This ensures the d= tag in the DKIM signature matches your From header domain.
4. Publishing DKIM at a subdomain while From header uses the root
Even if you own both domains, publishing DKIM at marketing.example.com while the From header shows example.com creates a domain mismatch. The DKIM d= tag is marketing.example.com but the From header domain is example.com. DMARC alignment fails.
If you send from subdomains, publish DKIM records that cover them. Either add DKIM records at each sending subdomain, or use a wildcard record that covers all subdomains.
5. DNS record created with a typo
DKIM selector records must be published exactly as configured in the MTA. A single character difference in the selector name, a missing underscore, or a transposition in the domain means the DNS lookup returns nothing and the DKIM check fails.
Before enabling DKIM signing in production, verify the exact selector string in DNS matches exactly what your MTA is configured to use.
6. No DKIM record at all for the signing selector
Some platforms generate DKIM keys and display the DNS record to create, but the record never actually gets published. The MTA signs with a selector that has no DNS record behind it. Every DKIM check returns none.
Always confirm the DNS TXT record exists and resolves before marking DKIM as operational.
7. Unused selectors from old vendors
Multiple DKIM selectors accumulate when you switch platforms and the old selector records stay in DNS. They do not cause active failures, but they create confusion about which key is current and make it harder to audit your signing infrastructure.
If you have DKIM selectors for platforms you no longer use, remove them. Keep only the selectors actively signing your outbound mail.
Why SPF and DKIM passing is not enough: the alignment problem
SPF and DKIM are independent authentication checks. DMARC adds a layer on top: alignment.
DMARC requires at least one of SPF or DKIM to pass, and the domain that passed must align with the From header domain. A DKIM signature from the wrong domain passes DKIM but fails DMARC. An SPF pass from the MAIL-FROM domain that does not match the From header domain passes SPF but fails DMARC alignment.
The result is a DMARC failure even though both SPF and DKIM are individually configured correctly.
Example: your From header shows support@example.com. Your DKIM is signed with d=emailplatform.com. The DKIM check passes. But emailplatform.com does not match example.com, so DMARC alignment fails. Your email is not rejected outright but is more likely to land in spam or get soft-rejected.
The fix for third-party senders is custom DKIM signing, covered above. For SPF, ensure your MAIL-FROM domain is either the same as your From header domain or a subdomain of it.
How to audit your own SPF and DKIM setup
include:, a:, mx:, ptr:, and exists: is one lookup. If the total is 10 or more, reduce it before going to production.dig TXT example.com +short. You should see exactly one v=spf1 record and nothing else starting with v=spf1.-all or ~all. No bare include: or mechanism at the end.d= domain matches your From header domain.How ongoing monitoring catches misconfigs before they cause failures
Most SPF and DKIM misconfigs are discovered after something breaks. A provider updates their sending infrastructure. A new administrator adds a vendor include without checking the lookup count. A DKIM key expires. Any of these can happen between your quarterly audits and cause an immediate delivery failure.
Continuous SPF and DKIM monitoring detects these changes as they happen. DMARCFlow monitors your SPF and DKIM records continuously, alerting you when your SPF record exceeds lookup limits, when DKIM keys fail to resolve, when records change unexpectedly, or when new sending sources appear that are not in your record. This means you find out about a misconfiguration from an alert rather than from a support ticket.
The specific alerts that catch the problems in this article: an alert when SPF lookup count exceeds 8 (giving you buffer before the 10-limit), an alert when DKIM resolution fails from monitored vantage points, and an alert when your record changes without a corresponding change request.
Summary checklist
SPF:
- Lookup count is under 10
- Exactly one TXT record at the/apex
- Record ends with
-allor~all - Every
include:points to a current, verified SPF record - Old vendor includes have been removed after switching providers
- MAIL-FROM domain has an SPF record that covers it
DKIM:
- Selector in DNS exactly matches MTA config
- DKIM
d=domain matches or is a parent of the From header domain - DKIM record resolves consistently from multiple locations
- No typos in the selector DNS name
- Only active selectors remain in DNS
- Keys are 1024-bit or verified-2048-bit with full EDNS support
Ongoing:
- Run SPF and DKIM diagnostics after any infrastructure change
- Monitor for record drift and unexpected changes
- Remove selectors and includes for decommissioned vendors immediately