SPF include vs ip4: Which Record Should You Use?

The short answer

One extra SPF sender can break a record that looked fine in a DNS editor.

Use include: when a mail provider manages the sending IPs for you. Use ip4: or ip6: when you own the exact mail server addresses and they rarely change.

Most SaaS email setups need includes. Google Workspace, Microsoft 365, Mailchimp, HubSpot, SendGrid, Postmark, and many CRMs publish SPF records because their sending pools can change. If you copy their current IPs into your own record, you now own every future update. That can break quietly.

Direct IP mechanisms fit stable infrastructure, such as your own outbound gateway or a fixed relay your team controls. They do not spend SPF DNS lookups, but they are only safe when the address list is complete and maintained.

How include and ip4 differ

SPF is a DNS TXT record that tells receivers which servers are allowed to send mail for your domain.

• include:_spf.example.com means: match only if that other domain's SPF record returns pass for the sending server.
• ip4:203.0.113.10 means: match if the sender's IPv4 address is that exact address.
• ip4:203.0.113.0/24 means: match if the sender is in that IPv4 range.
• ip6:2001:db8::/32 does the same for IPv6.

The tradeoff is control. An include lets the vendor keep its sender list current. That is usually the right call for cloud email and marketing tools. A direct IP gives control to you. That is better only when you know the list will stay true.

Do not flatten a vendor SPF record unless you also have a process to refresh it. Flattening turns includes into a long list of IPs. It can lower lookups today, but it can leave tomorrow's real vendor IPs out of your record.

The 10-lookup trap

RFC 7208 caps SPF evaluation at 10 DNS-querying terms. The receiver's first lookup of your SPF TXT record is separate from that term count.

include, a, mx, exists, ptr, and redirect can spend lookups. Nested includes count too. ip4, ip6, and all do not.

This is why a record can fail after you add one more vendor. Your top-level record may show only four includes, but each include can point to more records. When the receiver follows the chain and the total goes over 10, SPF returns permerror. Receivers may treat that as a failed authentication result.

Avoid ptr in SPF. It is slow, fragile, and discouraged by the SPF standard. If a service tells you to use it, ask for a better record.

A safe SPF pattern

Start with the senders you actually use. Remove old vendors before adding new ones.

• Keep exactly one SPF TXT record at the domain that sends mail.
• Prefer vendor includes for cloud email and marketing tools.
• Use ip4 or ip6 for your own fixed mail hosts and relays.
• Count all nested DNS lookups before publishing.
• End with ~all while you are still finding senders. Move to -all when SPF, DKIM, and DMARC reports show the list is clean.
• Never use +all. It says every server is allowed to send as you.

A simple Google Workspace record might be v=spf1 include:_spf.google.com ~all. A mixed record might be v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.vendor.example ~all. The example IPs here are documentation addresses, not values to copy.

If you want a quick read on your live domain, the free InboxRadar domain scorecard checks SPF, DKIM, DMARC, MX, and common blocklist signals without a login.

SPF is only one signal

Gmail, Outlook, and other mailbox providers do not decide inbox placement from SPF alone.

SPF checks the envelope sender path. DKIM signs the message with a selector and a domain, then the receiver checks the public key in DNS. DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. If neither aligned check passes, the receiver applies the DMARC policy.

p=none asks receivers to send reports without enforcing a block. p=quarantine asks them to put failing mail in spam or a similar place. p=reject asks them to reject failing mail. A careful rollout starts at p=none, reads aggregate RUA reports, fixes real senders, then tightens policy. If the XML reports are hard to read, use the free DMARC report reader.

MX records do not authorize outbound mail, but they still matter for a real mail domain because replies, bounces, and abuse paths need to work. Reputation, spam complaints, bounces, bad lists, sudden volume jumps, missing reverse DNS, and blocklists can still push mail to spam. Authentication gives receivers a domain they can trust or punish.

If the page also needs AI search visibility

A clean email setup will not help if your help docs or signup pages are blocked from the systems that cite live web pages.

For live AI answers, allow OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews ride the normal Google Search index, so there is no separate opt-out crawler. Disallowing these crawlers in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect 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 behavior. Perplexity-User and Bytespider have been reported to ignore it, so logs need careful reading. Only Googlebot documents JavaScript rendering. If key content exists only after client-side JavaScript runs, treat that as an undocumented risk for other AI crawlers. The AI visibility checker can show whether the important crawlers can reach a page.