Why Your SPF Record Isn't Working (Even Though You Already Set One Up)
You checked a box, added a TXT record, and figured SPF was handled. Then invoices start landing in spam, a client says your emails "look suspicious," or your free deliverability check comes back with an SPF failure anyway. It's one of the most common surprises for churches and small nonprofits running their own domain: SPF isn't a one-time setup, it's a record that has to stay accurate every time you add a sending tool, and it breaks in ways that are invisible until mail starts bouncing. The good news is that SPF failures are almost always caused by one of a small number of specific, fixable problems. Below is what actually goes wrong, how to check which one is happening to you, and how to fix each one without needing to be a network administrator.
First, confirm SPF is actually broken (not something else)
Before troubleshooting SPF specifically, verify that's really the failing check. Deliverability problems get blamed on SPF constantly when the real issue is DKIM, DMARC, or just sender reputation. Run a free lookup (MXToolbox's SPF checker or a domain health tool like the one on this site) and look at the actual result: does it say "no SPF record found," "SPF permerror," "SPF softfail," or "too many DNS lookups"? Each of those is a different problem with a different fix, and knowing which one you have saves a lot of guessing.
It's also worth checking the raw email headers of a message that failed. Gmail, Outlook, and most providers show an "Authentication-Results" line when you view the original message — search for "spf=" and read the result next to it. That single line tells you more than any dashboard summary.
You have more than one SPF record (this is the #1 cause)
SPF only allows exactly one TXT record per domain that starts with "v=spf1". If you've ever set up Google Workspace, then later added Mailchimp, a form plugin, or a VoIP phone system, and each one told you to "add this SPF record," you may now have two or three separate v=spf1 records sitting in your DNS. When a receiving server finds more than one, the SPF check doesn't merge them — it fails outright, with a "permerror."
The fix is to combine every service into a single line. Instead of two records like `v=spf1 include:_spf.google.com ~all` and `v=spf1 include:mailgun.org ~all`, you need one: `v=spf1 include:_spf.google.com include:mailgun.org ~all`. Log into your DNS host (GoDaddy, Namecheap, Cloudflare, wherever your domain is registered), find every TXT record starting with v=spf1, and merge them into one. Delete the duplicates only after the merged one is saved and verified.
You've gone over the 10 DNS lookup limit
SPF has a hard technical ceiling: no more than 10 DNS lookups per check, set by the SPF specification (RFC 7208). Each `include:` mechanism in your record costs at least one lookup, and some services (especially ones that themselves include other providers) cost more than one. Add Google Workspace, a CRM, an email marketing tool, a fundraising platform, and a couple of legacy `include:` lines nobody remembers adding, and it's easy to quietly cross 10 without anyone noticing until mail starts failing.
When you exceed the limit, the result is a "permerror," and most receiving mail servers treat a permerror as if you had no SPF record at all — which can be worse than not having one, since it looks like a misconfigured or abandoned domain. To fix it, flatten your record: remove any `include:` for a service you no longer use, and for services you do use, check whether they offer a lower-lookup or "flattened" SPF snippet. If you're already lean and still over the limit, an SPF flattening tool (or your email provider's support team) can pre-resolve the includes into static IP ranges.
The record has a typo or the wrong syntax
SPF records are unforgiving about exact syntax. A few mistakes we see constantly on real church and small-business domains:
Missing the "all" mechanism at the end — every valid record needs to end in `~all` (soft fail, recommended for most) or `-all` (hard fail). Leaving it off, or using `+all` (which allows literally anyone to send as your domain), both cause problems — one is a syntax gap, the other defeats the purpose of SPF entirely.
A stray space, an extra quotation mark, or a copy-pasted record that got mangled when it was pasted into your DNS provider's text box. Some DNS panels wrap long TXT values automatically and introduce line breaks that shouldn't be there.
Using `redirect=` and `include:` in the same record, which is invalid — redirect replaces the entire record's evaluation and shouldn't be combined with other mechanisms.
The safest way to check is to copy your live record exactly as it appears in DNS (not from memory) and run it through a validator. One character out of place turns a working record into a silent failure.
SPF is correct, but DKIM or DMARC alignment is what's actually failing
This is the one that trips people up most: SPF can pass and your mail can still get rejected or spam-foldered, because SPF alone isn't enough anymore. Gmail and Yahoo's 2024+ bulk sender requirements check SPF, DKIM, and DMARC together, and they specifically care about alignment — whether the domain in your "From:" address matches the domain SPF and DKIM actually authenticated.
A common setup mistake: your SPF record authorizes Google Workspace to send for yourchurch.org, but a form tool or bulk sender you use sends mail with a "From:" address of yourchurch.org while its own authentication is tied to a totally different domain underneath. SPF alignment fails even though the include: itself is technically valid. If you send through more than one platform, each one needs to either send from a subdomain it controls (like mail.yourchurch.org) with its own SPF/DKIM, or be properly included in your main record with matching alignment.
If your SPF check passes in isolation but mail is still failing, check your DMARC report (or run a full audit) to see whether it's an alignment problem specifically, not a raw SPF problem.
DNS hasn't propagated yet, or you're checking the wrong record
If you just fixed your SPF record and it's still showing as broken, propagation delay is a real possibility — DNS changes can take anywhere from a few minutes to 24-48 hours to fully propagate, depending on your DNS host and cached TTL values. Before assuming your fix didn't work, wait at least an hour and re-check using a tool that queries multiple DNS servers (not just your local cache).
The other common mix-up: checking the wrong domain or subdomain. If your church sends mail from mail.yourchurch.org or a subdomain used by your donation platform, the SPF record needs to exist on that exact subdomain — a record on the root domain doesn't automatically apply. Double-check you're looking up (and editing) the precise hostname your mail actually sends from.
You changed email providers and never updated the old record
This one is common during a migration: a church moves from an old host or a previous IT volunteer's setup to Google Workspace, but the SPF record still lists the old mail server's `include:` or IP range instead of (or alongside) Google's. Mail sent through the new system doesn't match what SPF says is authorized, so it fails — even though, from your end, everything looks switched over.
Any time you change who sends your email (a new provider, a new marketing tool, a new phone/fax-to-email service), SPF has to be updated in the same move. It's not automatic, and it's the single most common reason a domain that "used to work fine" suddenly starts failing after a provider switch.
Check my church's email — free →Frequently asked questions
How do I know if my SPF record is actually working?
Send a test email to a Gmail address you control, open the message, and view the original/raw headers. Look for the "Authentication-Results" line — it will show spf=pass, spf=fail, spf=softfail, or spf=permerror. Free tools like MXToolbox's SPF record checker will also validate your record's syntax and flag lookup-count or duplicate-record problems without needing to send a test email.
Can I have SPF and still get flagged as spam?
Yes. SPF is only one of three authentication checks major providers use — DKIM and DMARC matter just as much, and Gmail/Yahoo now expect all three to be aligned for bulk senders. A passing SPF record with no DKIM signature or no DMARC policy still leaves you exposed to spam filtering.
What's the difference between ~all and -all in an SPF record?
~all (soft fail) tells receiving servers to accept but flag mail from unauthorized sources; -all (hard fail) tells them to reject it outright. Most small organizations start with ~all while confirming every legitimate sending source is included, then move to -all once they're confident nothing legitimate will be blocked.
How many SPF records can a domain have?
Exactly one. If a receiving server finds two or more TXT records starting with v=spf1 on the same domain, it treats the SPF check as a permanent error (permerror) — the same outcome as having no valid SPF record at all. Every sending service needs to be merged into a single record using multiple include: statements.
I fixed my SPF record — why does it still show as failing?
Most likely DNS propagation delay (give it up to 24-48 hours, though it's often much faster), a cached lookup from the tool you're using to check it, or the fix was applied to the wrong hostname (root domain vs. a subdomain your mail actually sends from). Re-check with a fresh tool after an hour, and confirm you edited the exact domain your outgoing mail uses.