DMARC

The SPF and DKIM Mistakes That Actually Break Client Mail Flow

September 10, 2026

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

A client calls because invoices stopped arriving in a customer's inbox. The domain has SPF, it has DKIM, everything looked fine in the DNS panel six months ago. Nothing changed on purpose, yet mail is failing. This pattern repeats across MSP ticket queues constantly, and it almost always traces back to a small set of well-documented, entirely avoidable configuration errors.

The two most common failures are exceeding SPF's 10 DNS-lookup ceiling and letting DKIM keys or selectors drift out of sync with what the sending platform actually uses. Both are silent until a receiving mail server enforces the rule strictly, at which point authentication fails and messages bounce, land in spam, or get rejected outright with little warning to the sender.

Why does SPF break even when the record looks correct?

SPF fails most often not because the syntax is wrong, but because the record triggers too many DNS lookups during evaluation. The specification is unambiguous on this point: implementations must cap the total at 10 lookups, and anything beyond that is a hard failure, not a warning.

Per RFC 7208, the SPF standard, implementations "MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS," and if that limit is exceeded the result must be treated as a permanent error. Mechanisms like include, a, mx, redirect, and exists all count toward that total, and nested includes count too, which is exactly why the problem tends to sneak up on MSPs managing multi-vendor stacks.

A typical client domain accumulates SPF includes over years: the email provider, a CRM, a marketing platform, a helpdesk tool, a fax-to-email service nobody remembers approving. Each vendor's own SPF include often nests further includes of its own. The record still looks like one tidy line in the DNS panel, but the resolved chain of lookups can quietly climb past 10, and once it does, the entire SPF check returns permerror regardless of whether the actual sending IP was authorized.

The fix is not simply raising a limit, since the limit is fixed by the protocol. It means flattening or trimming the include chain, removing vendors no longer in use, and replacing broad mechanisms with more specific ones where possible. This is exactly the kind of drift that a scheduled scan catches before a client's marketing platform mysteriously starts bouncing, which is why building SPF validation into onboarding, as outlined in ActiScan's getting-started guide, matters more than a one-time audit ever will.

The one-record rule nobody remembers until it breaks something

A domain can only have one SPF record. Publishing a second TXT record starting with v=spf1 because a new vendor's setup wizard told you to "add this SPF record" does not merge the two. It creates ambiguity that most validators treat as a failure, and the fix is manual consolidation into a single record, not creation of a second one.

This is one of the most common self-inflicted wounds in MSP-managed DNS. A client's marketing team follows a vendor's setup instructions literally, pastes a new v=spf1 TXT record into the zone, and now two competing SPF records exist side by side. Some validators pick one arbitrarily, others fail the check entirely, and the client sees intermittent bounces that seem to have no pattern because different receiving servers behave differently. The only durable fix is combining every authorized sender into a single record with one v=spf1 prefix and one set of mechanisms, then deleting the duplicate.

DKIM: the key length and rotation problems that hide until enforcement changes

DKIM failures tend to be quieter than SPF failures because a broken DKIM signature does not always fail delivery on its own, it just weakens DMARC alignment. That changes the moment a receiving provider tightens enforcement, which is exactly what happened when Google and Yahoo rolled out bulk sender requirements in 2024.

Key length is the first place this shows up. Google's own sender guidelines state plainly that sending to personal Gmail accounts requires a DKIM key of at least 1024 bits, and that Google recommends using a 2048-bit key where the domain's DNS provider supports it, calling longer keys more secure than shorter ones in its setup documentation. The IETF went further in 2018, publishing RFC 8301, which states that verifiers "MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures" and recommends 2048-bit keys as the practical floor for new deployments. Domains still running keys generated years ago on 1024-bit defaults are sitting closer to that floor than most admins realize.

The second quiet failure is selector mismatch after a platform migration. When a client moves from one email security gateway to another, or swaps marketing platforms, the old DKIM selector often stays published in DNS while the new platform starts signing with a selector nobody added. Mail still goes out, DKIM still technically exists on the domain, but the signature the receiving server checks against does not match any published key, so it fails validation silently. Nothing in the client's day-to-day mail experience flags this until a receiving provider starts enforcing alignment more strictly and delivery rates quietly drop.

Because DNS TXT records cap each individual string at 255 characters, a 2048-bit DKIM public key has to be split across multiple quoted strings inside the same record rather than pasted as one long string, a formatting detail Google's sender guidelines call out explicitly because it trips up manual DNS edits. Get the quoting wrong and the key parses as invalid even though every character is correct.

Why forwarding makes both problems worse

Forwarded mail is where SPF and DKIM misconfigurations collide with a protocol limitation that no amount of record-tuning fixes. When a message is forwarded, the forwarding server's IP is not in the original domain's SPF record, so SPF fails almost by design, not by misconfiguration.

DKIM tends to survive forwarding better than SPF because the signature travels with the message body and headers rather than depending on the connecting IP, which is exactly why DMARC allows either check to satisfy alignment. As one deliverability provider's technical writeup on the issue puts it, DKIM "verifies that the message hasn't been altered in transit" and typically withstands forwarding as long as the signed headers and body remain intact, per Postmark's analysis of the mechanism. That is precisely why a DKIM misconfiguration is more dangerous than an SPF one for domains with heavy forwarding traffic. If DKIM is also broken, there is no fallback path left for DMARC alignment, and the message fails both checks at once.

How DMARC alignment turns small errors into hard failures

DMARC does not check SPF and DKIM in isolation, it checks whether either one aligns with the domain in the visible From header. RFC 7489 defines two alignment modes, and in strict mode, "only an exact match between both of the Fully Qualified Domain Names is considered to produce Identifier Alignment," meaning a subdomain mismatch that would pass under relaxed mode fails completely under strict.

This is why a policy change that looks purely administrative, moving a domain's DMARC policy from p=none to p=quarantine or p=reject, can suddenly expose SPF and DKIM problems that had been sitting dormant for months. The underlying records were never actually correct, they just hadn't been tested against enforcement yet.

Making this repeatable across a client book

None of these failures require sophisticated attacks to trigger. They require time passing, vendors changing, and nobody re-checking a record that worked fine at initial setup. For an MSP managing dozens of client domains, that means the actual defense is a scanning cadence, not a one-time deployment checklist.

Catching an SPF record at 8 lookups before a client adds a ninth vendor, or flagging a DKIM selector that stopped resolving after a platform swap, is the difference between a routine DNS update and an emergency call about missing invoices. This is the specific gap ActiScan's scanning workflow is built to close, and it's one of the reasons the platform's signup flow is built around continuous domain monitoring rather than a single audit report. Teams evaluating the cost of adding that coverage across a full client book can compare tiers on the pricing page before deciding how deep to roll it out.

Getting SPF and DKIM right once is achievable with a checklist. Keeping them right for a year, across every client domain and every vendor change nobody thinks to mention, is the part that actually determines whether the client's mail keeps flowing.