How to Add an IP Address to Your SPF Record Without Breaking It

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

Your website, a small VPS, or the office printer starts sending mail from an address your SPF record has never heard of. Gmail shows spf=fail or softfail in the headers, and the messages land in spam or bounce. The cure is one short edit to an existing DNS record, and it is easy to get slightly wrong in ways that only show up weeks later.

This guide covers exactly that edit: where the ip4 term goes, how to read the slash after an address, how to find the address that is really sending, and when an IP is the wrong tool. I looked up the live SPF records of 40 well-known domains on 10 October 2026 to see how large senders write theirs. If your record is already near the lookup ceiling, the guide to SPF subdomains and the ten-lookup limit covers that side of the problem.

The edit: one record, ip4 before the all

A domain gets one SPF record, a TXT record that starts with v=spf1. Publishing a second one does not add to the first. Receivers treat two SPF records as a permanent error, so every check fails. Always change the record you have rather than adding another.

Say your record is this:

v=spf1 include:_spf.google.com ~all

To authorise a server at 203.0.113.7, insert the address before the final all:

v=spf1 ip4:203.0.113.7 include:_spf.google.com ~all

The order matters for one reason. Receivers read terms left to right and stop at all, which always matches. RFC 7208 states that mechanisms after all are never tested, so an ip4 placed behind it does nothing. Putting IP terms first and includes second is a common habit, because it keeps the cheap checks at the front.

Single address or range: reading the slash

The syntax is ip4:address or ip4:address/prefix. With no prefix, the standard assumes /32, which means that one address and nothing else. The prefix says how many leading bits must match, so a smaller number covers more addresses.

You write	Addresses covered	Use it for
ip4:203.0.113.7	1	One server you control
ip4:203.0.113.0/28	16	A small block from a hosting plan
ip4:203.0.113.0/24	256	A whole subnet you own
ip4:203.0.0.0/16	65,536	Large organisations only

Two mistakes cause most of the damage here. The first is a partial address such as ip4:203.0.113., which the standard calls out as invalid; write 203.0.113.0/24 instead. The second is a range wider than you own. A /16 you copied from a forum post authorises sixty-five thousand addresses you have never met, and any of them can then send mail that passes SPF as your domain.

Find the address that is actually sending

Do not guess the address from your hosting dashboard. Send a test message from the system that is failing to a Gmail address, open it, choose Show original, and read the line that begins Received-SPF or the SPF part of Authentication-Results. A failing message names the connecting IP, and that is the value to authorise.

Three situations produce a different address from the one you expected:

• Shared hosting. Your site shares a mail server with hundreds of others, so its address is not yours to authorise. Use the include your host publishes instead.
• Home or office connections. A printer or scanner mailing directly shows your router’s public address, which your provider can change. If it moves, the record breaks silently.
• Several servers behind a load balancer. Test from each one; the outbound addresses can differ.

When an IP is the wrong answer

Use ip4 for infrastructure that you run and whose address does not move: your own VPS, a dedicated mail relay, a fixed office line. For a company that sends on your behalf, such as a newsletter tool or a payment platform, use its include: instead. Those companies add and retire sending addresses constantly, and an include follows the changes while a pasted IP goes stale the first time they do.

The large senders mix both. In my lookup, Dropbox lists 18 ip4 terms next to five includes, and WP Engine lists 21 ip4 terms. Their own data-centre ranges are IPs; the vendors they use for email are includes. That split is a good model for a small site too.

IPv6: the sender that connects the other way

If your server has an IPv6 address and your mail software prefers it, the check sees an IPv6 connection and your ip4 term cannot match. The syntax is the same idea: ip6:2001:db8::/32, where the prefix runs from 0 to 128 and an omitted prefix means /128. The Received-SPF line from your test message tells you which protocol was used, so you will know straight away if you need this term. Only 2 of the 40 domains I checked publish any ip6 term, so most senders still go out over IPv4.

Free for lookups, not free for length

The ten-lookup limit applies to include, a, mx, ptr, exists and redirect. The ip4, ip6 and all terms do not count, so adding addresses cannot push you over that limit. That is the reason to prefer a CIDR range or a few addresses over an a: or mx: term when you control the machine.

What a long list does cost you is record length. A single string inside a TXT record is capped at 255 characters, and RFC 7208 advises keeping the whole record within 512 bytes so it fits a classic UDP DNS answer. Records longer than 255 characters are stored as several strings that receivers join back together without spaces. Most DNS panels do this for you, though some reject a long paste or add a space at the join. If your panel complains, that is the thing to suspect. In my sample, 8 of 40 records were longer than 255 characters, and the longest, at 562 characters, was Dropbox’s.

What 40 real domains publish

I queried the SPF TXT record of each domain through Google’s public DNS service on 10 October 2026. The 40 included large web hosts, store platforms and email services.

What I counted	Result
Domains with exactly one SPF record	40 of 40
Domains using at least one ip4 term	16 of 40
Domains using an ip6 term	2 of 40
Total ip4 terms across all records	86
ip4 terms that are a single address (/32)	44
ip4 terms that are a /24 range	10
Records ending in -all (fail)	19
Records ending in ~all (softfail)	21
Records longer than 255 characters	8

Two readings are worth taking away. Half of the IP terms are single addresses, so the tidy one-line edit from the top of this guide is how the big senders do it as well. And no domain in the sample ended in +all or ?all, so neither is something to copy.

Check that the change worked

1. Query the record with nslookup -type=TXT yourdomain.com or dig TXT yourdomain.com +short and confirm there is one line starting v=spf1 containing your new term.
2. Wait for the old record’s TTL to expire. DNS caches may serve the previous version until then, so a change can look broken for up to the number of seconds in that TTL.
3. Send a fresh test message to Gmail and open Show original. You want spf=pass, with your new address named as the permitted sender.
4. If you have DMARC, remember it counts an SPF pass only. A softfail or neutral result does not satisfy it, so a message can still be rejected until SPF passes or DKIM aligns. Email Rejected by DMARC Policy: How to Read the Bounce and Fix the Sender walks through that case.

Where your site mail comes from matters

If you are on a plan that gives you no fixed sending address, you will spend your time chasing includes rather than IPs. A host that publishes a clean include for its mail servers removes the problem. Hostinger, for example, publishes an SPF record built entirely from includes with a hard -all ending, as my lookup showed. That describes its own mail, not yours, so your own domain still needs its own record.

Checked for accuracy on 10 October 2026 against RFC 7208 and live DNS lookups of 40 domains.