Multiple SPF Records Found: How to Fix It

Why this error breaks mail

Two SPF records can make SPF fail for every message from that Mail From domain.

SPF is strict. A domain can publish many TXT records, but only one TXT record at the same DNS name can start with v=spf1. If a receiver finds two SPF records for the envelope sender domain, the SPF check returns a permanent error. For bounce messages with an empty return path, SPF can fall back to the HELO name. Gmail, Outlook, Yahoo, and other mailbox providers may then treat the message as unauthenticated or risky.

The fix is to merge the allowed senders into one SPF TXT record at each sending name. Do not delete a vendor blindly. Your newsletter tool, help desk, CRM, billing app, and Google Workspace or Microsoft 365 may all send real mail for you. The goal is one valid record that keeps the real senders and removes the duplicate SPF record.

How to fix multiple SPF records

Build one record from the senders you still use, then remove the extra SPF records.

• Find every TXT record at your sending domain that starts with v=spf1. Check the root domain and any subdomain that sends mail, such as mail.example.com. Each DNS name can have its own SPF record, but it gets only one.
• List the services that send as that exact domain. Common examples are Google Workspace, Microsoft 365, Mailchimp, HubSpot, Zendesk, Shopify, Stripe, and your own mail server.
• Keep one record and merge the mechanisms from the others. Example: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all.
• Remove old vendors you no longer use. This lowers risk and helps keep the record under the SPF 10 DNS lookup limit.
• End with ~all while you are checking traffic. Move to -all only when you are sure every real sender is covered.
• Delete the extra v=spf1 TXT records. Leave unrelated TXT records alone, including site verification records.
• Wait for DNS to update, then test the domain again with a live checker such as InboxRadar.

SPF has two traps after the duplicate is gone. First, include, a, mx, exists, and redirect can trigger DNS lookups. SPF evaluation has a hard limit of 10 DNS lookups. Go over it and receivers can return permerror again. Second, SPF checks the envelope sender domain. DMARC only counts SPF when that domain aligns with the visible From domain.

Avoid copying a vendor's whole IP list into your SPF record unless that vendor tells you to. Vendor includes change over time. A stale manual list can pass a DNS lookup test today and still break future sending.

Do not break DKIM or DMARC

SPF is only one part of the trust chain.

DKIM signs the message with a selector-specific key, such as selector1._domainkey.example.com. Each sender that supports DKIM should sign with your domain or a DMARC-aligned domain. Keep DKIM enabled while you repair SPF because DKIM can keep DMARC passing when forwarding or SPF alignment fails.

DMARC tells receivers what policy to apply when mail fails DMARC. A message passes DMARC when SPF or DKIM passes and aligns with the visible From domain. Start with p=none and a rua address so you can read aggregate reports. Tighten to p=quarantine or p=reject after your real senders pass. If the XML reports are hard to read, use the free DMARC report reader before you enforce.

MX records matter too. They tell the world where to deliver mail for your domain. Bad or missing MX does not cause the multiple SPF record error, but it can hurt replies, bounces, and trust checks. Blocklist listings can also hurt placement, especially after abuse or a compromised account. Authentication is the first fix, not the whole inboxing story. Gmail and Outlook weigh SPF, DKIM, DMARC, sender history, user complaints, and message behavior together when routing mail to inbox or spam.

If your DNS also affects AI search

Email DNS and web crawl rules are separate, but domain owners often fix them in the same pass.

For AI search visibility, make sure the public site can be reached and read. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine. Google AI Overviews use the normal Search index, so there is no separate Google AI crawler to block.

Training and opt-out controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a stated policy, not proof of what a bot did. Perplexity-User and Bytespider have been reported to ignore it, so use logs before making claims. Googlebot documents JavaScript rendering. For other AI crawlers, client-side-only content is an undocumented risk, so put important content in crawlable HTML. You can test this with the free AI visibility checker.