DMARC

The SPF and DKIM Mistakes That Actually Break Client Mail Flow

September 18, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Most SPF and DKIM failures an MSP deals with are not exotic. They are the same handful of configuration mistakes, repeated across hundreds of client domains, that quietly break outbound mail until someone notices bounced invoices or a marketing campaign stuck in spam. The frustrating part is that these mistakes rarely show up in a routine glance at DNS. They surface only when a receiving mail server actually evaluates the record and returns an error that looks nothing like the misconfiguration that caused it.

The short answer to what actually breaks client mail flow: exceeding SPF's 10-DNS-lookup ceiling, publishing more than one SPF record on the same hostname, and mistiming DKIM key rotation so a signature can no longer be verified. Each produces a hard authentication failure, not a warning, and each is preventable with routine monitoring rather than one-time setup.

Why Does the SPF 10-Lookup Limit Break Mail That Used to Work?

It breaks because SPF was never designed to scale indefinitely with the number of vendors a client adds over time. RFC 7208 caps SPF evaluation at 10 DNS lookups, and every include, a, mx, ptr, and exists mechanism, along with the redirect modifier, counts against that ceiling, while ip4, ip6, and all do not because they require no additional query. When a domain crosses that limit, the receiving server does not keep counting or fail gracefully. It stops evaluation entirely and returns a PermError, a result the SPF specification treats as distinct from a simple fail but which most inbox providers handle identically at the DMARC layer.

This is what makes the limit so dangerous for MSPs managing many tenants. A client's SPF record can pass every check for months, then break the day someone in marketing adds a new outreach tool's include: statement without checking what it costs. Google's own guidance for Workspace admins warns that nested lookups inside an included domain's own SPF record count toward the same limit, so a single include:_spf.thirdparty.com can secretly consume three or four lookups instead of one, and recommends removing include mechanisms for any third party that no longer sends mail for the domain, since unused entries compound the risk with every added service. A record that looked fine at five vendors can silently tip over at seven.

The Second SPF Record Nobody Remembers Creating

The other common failure is simpler and, in practice, more common: two SPF records on the same domain name. RFC 7208 is explicit that a domain must not have multiple records that would cause an authorization check to resolve more than one, and when a receiver finds two TXT records both starting with v=spf1, the specification requires a PermError result rather than an attempt to reconcile them.

This usually happens when a new platform's onboarding instructions say "add this TXT record to your DNS" and whoever is doing the DNS work takes that literally instead of merging the new mechanism into the domain's existing SPF string. The fix is mechanical: pull every v=spf1 TXT record for the domain, merge the mechanisms into one line, and delete the duplicates. The risk for an MSP is that this kind of drift happens client by client, tool by tool, and it is invisible until a batch of outbound mail from that one domain starts failing while everything else looks normal.

What Happens When DKIM Key Rotation Goes Wrong?

DKIM key rotation breaks mail flow when the old key is deregistered from DNS before every system still signing with it has caught up, or when a new key is published with a formatting error the sending platform never validates against. M3AAWG's operational guidance recommends rotating DKIM keys at minimum every six months to limit exposure if a private key is compromised, but the mechanics of the rotation matter as much as the schedule.

Microsoft's implementation in Exchange Online illustrates why. Custom domains get two DKIM selectors, and Microsoft documents that only one selector is active for signing at a time while the other stays inactive until the next rotation, specifically so mail signed under the previous key can still be verified during the handover. If an MSP or a client's IT staff only publishes one of the two required CNAME records because the second one looked redundant, everything signs correctly until Microsoft's automatic rotation flips to the missing selector, and DKIM fails across the domain with no warning and no change on the sending side. The same logic applies to self-managed DKIM: removing a private key from a mail server the same day the public key is deleted from DNS leaves any message still in a queue, or any forwarded copy processed late, without a matching key to verify against.

Why Bulk Sender Rules Make These Mistakes More Costly Now

Because these are no longer stylistic best practices, they are prerequisites for inbox delivery at scale. Google's guidelines for accounts sending more than 5,000 messages a day to Gmail addresses require that senders set up both SPF and DKIM for their domain, in addition to a DMARC record, and state plainly that senders who don't meet these requirements may see their email rejected. Google's alignment FAQ adds a detail worth building monitoring around: for bulk senders, only one of SPF or DKIM needs to be aligned with the From domain to satisfy DMARC, but both authentication methods are still required to be configured even though only one has to align. A client that assumes a passing SPF record is enough, while DKIM silently broke months ago, is one key rotation away from losing DMARC alignment entirely.

For an MSP, the operational lesson is that SPF and DKIM are not "set and forget" the way a firewall rule can sometimes be. A vendor changing their sending infrastructure, a client outgrowing the 10-lookup budget, or a scheduled key rotation landing on a Friday afternoon can each independently break mail flow. Manual quarterly reviews catch some of this, but they miss the interval between checks, which is exactly where PermErrors and expired selectors do their damage.

A practical baseline for keeping this under control across a client book:

• Count SPF lookups after every vendor addition, not just at initial setup, since nested includes change silently when a vendor updates their own record
• Treat a second v=spf1 TXT record as a hard stop to fix immediately, not a warning to schedule for later
• Confirm both DKIM selectors are published before enabling signing on platforms like Exchange Online, and never delete an old selector the same day a new one goes live
• Verify DKIM and SPF independently after any DNS migration, registrar change, or CNAME cleanup

Building this into onboarding rather than treating it as a one-time task is the difference between catching a broken record in a scheduled scan and getting a call from a client whose invoices stopped arriving. ActiScan's own getting-started guide walks through setting up that kind of recurring check across a client's full domain portfolio rather than one domain at a time.

None of this requires exotic tooling, but it does require checking the right things on a schedule instead of trusting that a record which passed once will keep passing. Teams evaluating how this fits into existing workflows can compare monitoring tiers on the pricing page, and MSPs ready to put continuous SPF and DKIM checks in front of every client domain can get started from the signup page. The mistakes covered here are common precisely because they are boring and easy to overlook. Catching them before a mail server does is the entire job.