DMARC
The SPF and DKIM Mistakes We Keep Finding in Client DNS Records
August 25, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Every MSP that has pulled a new client's DNS zone knows the feeling. The SPF record is a wall of includes nobody remembers adding, the DKIM selector points at a marketing tool that was decommissioned two years ago, and DMARC, if it exists at all, sits at p=none collecting reports nobody reads. These are not exotic failures. They are the same handful of misconfigurations, repeated across thousands of domains, because SPF and DKIM were built as text-based, DNS-hosted protocols that punish drift and reward almost nobody for maintaining them.
The most common SPF and DKIM mistakes in client DNS are avoidable with regular auditing: too many DNS lookups in SPF, duplicate SPF records left behind after migrations, orphaned includes for retired vendors, DKIM keys still at 1024 bits or never rotated, and selectors that stopped resolving after a platform switch. Each one silently breaks authentication without ever throwing an obvious error to the sender.
Why does SPF keep failing even when it "looks right"?
SPF fails on domains that appear correctly formatted because the record violates a hard limit the sender never sees enforced until a message bounces. RFC 7208 caps SPF evaluation at 10 DNS-querying mechanisms per check, including every lookup triggered by an include or redirect. Cross that ceiling and the entire record returns a PermError, which most receivers treat as an outright fail rather than a partial pass.
This limit is easy to blow past without noticing. A typical business stacks includes for its email marketing platform, its CRM, its helpdesk tool, and its cloud provider, and each of those includes can nest further includes of its own. As one technical breakdown of the problem puts it, most domains exceed this limit without realizing it, often due to nested includes and outdated services. Nobody adds an eleventh service intending to break authentication. They add it because a previous MSP or admin never removed the ninth and tenth that stopped being relevant.
The second SPF failure mode is simpler and more embarrassing: duplicate records. RFC 7208 states plainly that multiple SPF records are not permitted for the same owner name, and when a domain accumulates two separate v=spf1 TXT entries, often from a migration where the old record was never deleted, receivers cannot determine which one governs. The result is the same PermError as the lookup-limit problem, but it is entirely self-inflicted and trivial to spot once someone actually queries the zone.
A third, quieter issue is the qualifier at the end of the record. Domains that use ~all (soft fail) instead of -all (hard fail) are explicitly telling receivers that unauthorized senders might be legitimate, which weakens the entire point of publishing SPF in the first place. Fixing lookup count, removing duplicates, and tightening the qualifier are the three things worth checking before anything else on a new client's SPF record.
The DKIM problems that hide until a key needs rotating
DKIM issues are less visible day to day because a broken DKIM signature does not usually block mail outright, it just quietly degrades DMARC alignment. RFC 6376 defines the DKIM signature mechanism, under which assertion of responsibility is validated through a cryptographic signature and by querying the signer's domain directly to retrieve the appropriate public key. That query only works if the selector still resolves and the key is still strong enough to trust.
Key length is the most common technical gap. A large share of client domains ActiScan-style audits turn up still publish 1024-bit RSA keys, which comparative analyses now describe plainly: a 1024-bit RSA key is weaker than current cryptographic recommendations, which is why standards bodies and mailbox providers have moved toward 2048-bit deployments. Migrating is not disruptive, it just requires someone to actually do it, which is where most MSPs find the gap.
Rotation is the second recurring failure, and it is almost always a process gap rather than a technical one. The Messaging, Malware and Mobile Anti-Abuse Working Group's best practices document lays out the safe method: begin by generating another key pair and publish the public key in your DNS, then wait for the new key to propagate through DNS before continuing. Skipping the propagation wait, or rotating without keeping the old selector live during transition, causes exactly the kind of intermittent authentication failure that is hardest to diagnose after the fact.
Selector sprawl compounds both problems. Every platform a client has ever used to send mail, an old marketing tool, a former helpdesk, a one-time bulk sender, potentially left a DKIM selector behind. If that selector's key was never rotated and the platform is compromised or resold, mail signed with that stale key can still pass DKIM under the client's domain.
What this looks like in an actual DNS audit
The table below reflects the pattern seen repeatedly across client domains during onboarding, not a hypothetical checklist.
| Issue | Root cause | Typical fix |
|---|---|---|
| SPF PermError | More than 10 DNS lookups from nested includes | Consolidate or flatten includes, drop unused vendors |
| SPF PermError | Two separate v=spf1 TXT records | Merge into a single record, delete the duplicate |
| SPF too permissive | ~all left in place indefinitely | Move to -all once monitoring confirms legitimate senders |
| DKIM alignment failure | 1024-bit key or unrotated key | Regenerate at 2048 bits, rotate on a schedule |
| DKIM selector orphaned | Retired vendor never removed from DNS | Audit selectors against active sending platforms, remove stale ones |
None of these require exotic tooling to find. They require someone to actually query the zone, count the lookups, and cross-reference selectors against what is currently sending mail, which is exactly the kind of recurring task that gets skipped when a technician is managing DNS for forty clients by memory.
Why this matters more in 2025 than it did two years ago
Mailbox providers have stopped treating these as cosmetic gaps. Since February 2024, Google has required that senders of 5,000 or more daily messages set up SPF or DKIM email authentication for your sending domains, paired with a DMARC record, or face delivery friction. Yahoo adopted parallel requirements the same year. A domain that fails silently on SPF lookups or DKIM alignment is no longer just a theoretical exposure, it is a direct deliverability problem for any client running even modest email volume.
The adoption data suggests most organizations are still behind. EasyDMARC's tracking of the top 1.8 million domains found that DMARC adoption rose from 27.3% in 2023 to 47.6% in 2025, but the same report notes that more than 70% of DMARC-enabled domains lack reporting tags, meaning many of those domains have no visibility into whether their SPF and DKIM records are actually functioning correctly underneath the DMARC layer. A policy without reporting is a smoke detector with the battery removed.
For an MSP, this is the argument for treating SPF and DKIM hygiene as a recurring line item rather than a one-time setup task during onboarding. A client's DNS does not stay still. Vendors change, marketing platforms get swapped, and keys age past their useful life without anyone noticing until a delivery problem forces the question. Teams that are still doing this manually across dozens of domains can walk through the process in ActiScan's getting-started guide, which covers how automated scanning surfaces lookup counts, duplicate records, and stale selectors before they cause a bounce.
Building this into a standard client engagement
Catching these errors once is not the same as preventing them from recurring. The domains that stay clean are the ones on a recurring scan schedule, not the ones that got a thorough review during a single onboarding pass.
A few habits separate the MSPs who catch this early from the ones fielding angry calls after a delivery failure:
- Recheck SPF lookup counts after any vendor change, not just annually, since a single new include can be the one that crosses the limit.
- Track DKIM key age and selector inventory per domain, retiring selectors tied to platforms the client no longer uses.
- Move SPF from soft fail to hard fail only after DMARC reporting confirms which sources are legitimate, to avoid blocking real mail.
Multi-tenant scanning tools exist specifically to make this cheap to do across a full client book rather than one domain at a time, and the pricing page lays out how that scales as an MSP's client count grows. For MSPs evaluating whether to formalize this into a service offering, starting with a full inventory scan through ActiScan's signup is a faster path to the answer than manually walking each client's zone file by hand, especially once the client count moves past a handful of domains where nobody has time to check every include chain by memory.
None of this guarantees a client will never see a spoofed email or a delivery bounce. What it does is remove the DNS-level errors that make authentication fail before an attacker even has to try, which is the part of the problem entirely within an MSP's control.