SPF is the record I check first in almost every audit, and it's also the one people are most confident is already correct, because a basic checker shows a green checkmark next to it. That checkmark just confirms a syntactically valid TXT record exists. It says nothing about whether the record is structured to actually protect you, and three specific mistakes let a domain look fully authenticated while quietly undermining it.
A domain can only have one SPF record. This one sounds obvious until you see how it actually happens. A company sets up SPF for their email platform, then months later adds a new marketing tool or CRM integration, and instead of editing the existing TXT record to add the new sender, someone creates a second TXT record with its own v=spf1 line. Both records are individually valid syntax. Together, they're a permanent error.
Most receiving servers respond to two SPF records by treating the domain as if SPF isn't published at all, or by failing it outright. Either way, you lose the benefit of authentication you believe you have, and a basic checker that only confirms "an SPF record exists" won't catch that there are two.
v=spf1. If there are two, the fix is merging every include: statement into a single record, not choosing one to delete.
SPF records end in a mechanism that tells receiving servers what to do with mail from sources not listed in the record. ~all is a soft fail, it tells the receiver unlisted sources are probably unauthorized but the mail should likely still be accepted, sometimes with extra scrutiny. -all is a hard fail, it tells the receiver unlisted sources are not authorized.
Plenty of guides recommend starting with ~all while you're confirming every legitimate sending source is captured, which is reasonable advice during initial setup. Where it goes wrong is that senders stay on ~all indefinitely, because it never visibly breaks anything. The problem is that ~all never gives mailbox providers a firm signal either. It caps how much trust SPF alone can contribute to your reputation, because you've told the receiving server your own policy is uncertain about who's allowed to send as you.
~all to -all. Moving too early breaks legitimate mail. Never moving at all leaves a permanent gap in your authentication posture.
This is the one that catches senders using multiple platforms without realizing it. SPF allows a maximum of 10 DNS lookups when a receiving server evaluates the record, and that includes lookups nested inside every include: mechanism you've added, not just the top-level ones. Each connected platform, your ESP, your CRM, a helpdesk tool, a marketing automation platform, often adds its own include:, and each of those can itself trigger further nested lookups.
v=spf1 include:_spf.esp1.com include:_spf.crm2.com include:mail.helpdesk3.com include:spf.marketing4.com ~all
A record that looks reasonable, four or five includes, can silently exceed 10 total lookups once nested lookups are counted. When that happens, the result is a permerror, and most mailbox providers respond to a permerror by treating the domain as if it has no valid SPF record, the exact same outcome as having none published at all. The record looks complete. It fails silently, and nothing in a basic checker's green checkmark tells you it's over the limit.
A domain with no SPF record at all is at least an honest signal, mailbox providers know to weigh other factors more heavily. A domain with two conflicting records, a permanently soft policy, or a silently broken lookup count looks configured on the surface while actually contributing nothing, or worse, actively degrading trust. That gap between what a sender believes is protecting them and what's actually happening is the single most common thing I find in the authentication track of a diagnosis.
Part of the deliverability diagnosis guideNo. A domain can only have one SPF record. If two exist, most mailbox providers treat that as a permanent error and either ignore SPF for that domain entirely or fail it outright.
~all tells receiving servers unlisted sources are probably not authorized but should likely still be accepted. -all tells them unlisted sources are not authorized and mail should be rejected. Staying on ~all indefinitely never breaks mail outright, but it also never gives mailbox providers a firm trust signal.
SPF allows a maximum of 10 DNS lookups, including nested ones from every include: mechanism. Exceeding that limit causes a permerror, and most mailbox providers then treat the domain as if it has no SPF at all. This is easy to hit once a few ESPs, CRMs, and marketing tools each add their own include: over time.