What is the best practice for using IP addresses in SPF records?
Published 4 May 2025
Updated 19 Jun 2026
12 min read
Summarize with
Updated on 23 Jun 2026: We updated this guide with clearer guidance for hosted mail platforms, shared-IP ESP migrations, parked domains, and SPF lookup limits.
The best practice is to use ip4 and ip6 mechanisms only for stable outbound mail servers that you control, operate, or have been explicitly assigned. It is normal to list several IP addresses in an SPF record. Direct IP mechanisms also do not consume the SPF DNS lookup budget, which makes them useful when the sender list is known and stable.
The part to check carefully is intent. An SPF record such as v=spf1 mx ip4:192.0.2.10 ~all does two separate things: mx authorizes the domain's MX hosts, while ip4 authorizes a specific IPv4 sender. MX hosts often receive inbound mail and do not send outbound mail, so never keep mx just because it was copied from an old template.
The short answer
Use direct IP mechanisms when the sending IPs are static, documented, and owned by a known sender. Use include when a mail provider publishes its own SPF record and changes its sending IPs over time. For a hosted mailbox platform such as Microsoft 365, do not guess at the domain's A record or the last visible relay IP. Use the provider-published include unless you also operate a static outbound server. Use mx only when the domain's MX hosts also send outbound mail for that domain. End the record with an explicit all mechanism, usually ~all during testing or -all once the sender inventory is known.
- Direct IPs: Use ip4 and ip6 for fixed servers, outbound gateways, and dedicated sending IPs.
- Provider includes: Use include for hosted mailbox platforms, ESPs, CRMs, billing systems, and tools whose IPs change.
- MX mechanism: Use mx only when the MX hosts are part of the outbound sending path.
- Subdomains: Put marketing, application, and transactional mail on separate subdomains when the sender mix is different.
- Parked domains: Publish v=spf1 -all for domains that should not send mail.
Direct IP SPF exampledns
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip6:2001:db8::10 ~all
That record says only those two IPv4 addresses and that one IPv6 address are authorized. It is simple, fast to evaluate, and resistant to DNS lookup limit issues. The tradeoff is maintenance: when one of those senders changes IP, the record must change too.
What mx means in SPF
There is no separate "MX section" inside an SPF record. SPF has a sequence of mechanisms. The mx mechanism means: look up the domain's MX records, resolve those hostnames to addresses, then allow mail from those addresses.
That is different from writing IP addresses directly. A record with mx and seven ip4 mechanisms authorizes the MX hosts and the seven IPv4 addresses. The IP mechanisms are not "inside" MX. They are separate authorization rules.
Ask what should send
Treat mx as an explicit choice, not a default. If the MX hosts only receive inbound mail, keeping mx authorizes servers that do not need SPF authorization.
- Keep it when the same MX hosts relay outbound mail for the domain.
- Remove it when the MX hosts only receive inbound mail.
- Verify first by checking mail logs, DMARC aggregate data, and ownership notes before changing production DNS.
SPF decision flowchart for choosing direct IPs, includes, or MX mechanisms.
How to decide what belongs in the record
Start with actual sending behavior, not with the current DNS record. A clean SPF record is an inventory of allowed outbound senders. If the organization uses separate mail streams, split the work by domain or subdomain first.
- List senders: Identify mailbox, marketing, application, billing, CRM, and support systems that send mail.
- Map domains: Record whether each sender uses the parent domain or a dedicated subdomain. Each sending subdomain needs its own SPF record.
- Choose mechanisms: Use direct IPs for static senders and includes for providers that publish SPF.
- Check limits: Validate the DNS lookup count, void lookup count, record size, and syntax before publishing.
- Monitor results: Use DMARC aggregate data to find senders that still fail SPF or DKIM.
Direct IP mechanisms
- Best use: Static outbound mail servers and dedicated sending IPs.
- DNS effect: No SPF DNS lookup is used by ip4 or ip6.
- Main risk: Stale records after server moves or provider changes.
Include mechanisms
- Best use: Hosted senders that publish and maintain their own SPF record.
- DNS effect: Each include consumes SPF lookup budget.
- Main risk: Too many providers on one domain leads to SPF permerror.
Before changing a live record, run it through an SPF checker and check whether the record has multiple TXT values, syntax errors, excessive lookups, void lookups, or a missing all mechanism.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
CIDR and IP syntax rules
Direct IP mechanisms must use exact SPF syntax. Use ip4: for IPv4, ip6: for IPv6, and an optional CIDR suffix when you mean a range. A bare address such as 192.0.2.10 is not a valid SPF mechanism.
Only publish public IP addresses that open outbound SMTP connections for the domain. Private ranges, web-hosting IPs, CDN addresses, and inbound-only gateway IPs do not authorize the sender that actually transmits the message.
- Single IPv4: Use ip4:192.0.2.10. It is treated like ip4:192.0.2.10/32.
- IPv4 range: Use ip4:192.0.2.0/24, not a shortened address such as ip4:192.0.2.
- Single IPv6: Use ip6:2001:db8::10. It is treated like ip6:2001:db8::10/128.
- IPv6 range: Use a CIDR range such as ip6:2001:db8::/32 only when the whole range belongs to the outbound mail path.
CIDR examplesdns
v=spf1 ip4:192.0.2.10 -all v=spf1 ip4:192.0.2.0/24 -all v=spf1 ip6:2001:db8::10 -all v=spf1 ip6:2001:db8::/32 -all
Use the narrowest range that accurately covers the sender. A /24 authorizes 256 IPv4 addresses, so it is usually too broad for one server but reasonable for a documented outbound pool. When ranges overlap and qualifiers differ, put the narrowest mechanism first because SPF evaluates left to right and stops on the first match.
Common record patterns
These are the patterns that appear most often during audits. The correct one depends on who sends mail, how often the sender IPs change, and whether the domain is shared across business email, marketing, and application mail.
|
|
|
|---|---|---|
IP only | Fixed servers | Needs upkeep |
Include only | Cloud or provider mail | Lookup budget |
Mixed | Hybrid sending | Owner notes |
MX plus IP | Rare cases | Intent check |
Subdomain | ESP mail | Separate policy |
Parked domain | No sending | Use -all |
Common SPF authorization patterns and when they fit.
Mixed provider and fixed serverdns
v=spf1 include:spf.sender.example ip4:192.0.2.10 ~all
That mixed pattern is reasonable when one hosted sender publishes SPF and one internal system sends from a fixed IP. Document both entries in the change ticket or DNS notes. Six months later, that context is what stops an audit from turning into guesswork.
Record that needs an intent checkdns
v=spf1 mx ip4:192.0.2.10 ip4:192.0.2.11 ~all
This record is not automatically wrong. It just needs a question answered: do the MX hosts send outbound mail? If the answer is no, the clean record is usually the same record without mx. If mail is failing even with an IP listed, check SPF domain choice, envelope sender behavior, forwarding, and DMARC results. That failure pattern is covered in more depth here: SPF failing with IP.
For a server hostname used in HELO or EHLO, SPF can also authorize the host identity. That matters for bounce and null-sender traffic, where receivers check the HELO identity. Keep that host SPF separate from the customer return-path record, and make sure the hostname and reverse DNS still identify the sending server clearly.
Hosted platforms and shared-IP ESPs
When the sender is a hosted mailbox platform, CRM, billing system, or ESP on shared IPs, the question is usually not "which IP should I add?" The better question is which SPF domain the provider has told you to include. Shared pools and cloud platforms change IPs, so copying a current relay IP into SPF creates stale authorization and misses future senders.
- Microsoft 365-only mail usually uses include:spf.protection.outlook.com, not the website A record.
- Shared-IP ESP mail should use the provider's documented SPF include, return-path domain, or DNS delegation path.
- Hybrid mail can combine a provider include with direct ip4 or ip6 entries for static on-premises relays.
- ESP migrations should keep old and new SPF sources authorized during the overlap, then remove old entries once DMARC data shows the old source has stopped.
IP warming and SPF authorization are separate tasks. A shared IP pool can already have sending history while SPF still fails because the envelope sender domain, return-path domain, DKIM selector, or tracking domain was not configured for the new platform.
Hosted and hybrid SPF examplesdns
v=spf1 include:spf.protection.outlook.com -all v=spf1 include:spf.sender.example -all v=spf1 ip4:192.0.2.10 include:spf.protection.outlook.com -all
IP addresses and lookup limits
Direct IP mechanisms are useful because they do not trigger DNS lookups during SPF evaluation. The mechanisms that create lookup pressure are things like include, a, mx, exists, and redirect. If the record exceeds the 10 DNS lookup limit, receivers treat SPF as a permanent error.
Count the lookups inside provider includes, not just the visible mechanisms in your own TXT record. A record with six includes can exceed the limit if those includes contain nested includes, a, mx, exists, or redirect paths.
Void lookups also matter. Empty DNS answers and missing names inside include, a, mx, or exists paths can trigger permerror before the main lookup budget is the only problem. A practical DNS TTL, such as 3600 seconds, also reduces the chance that slow or inconsistent DNS creates false troubleshooting signals during a change.
SPF lookup budget
How to treat SPF DNS lookup count during a record audit.
Clean
0-5
Plenty of space for future senders.
Tight
6-8
Review includes before adding vendors.
At limit
9-10
One provider change can break SPF.
Broken
11+
Receivers return permerror.
This is where SPF flattening enters the conversation. Flattening replaces provider lookups with IP ranges. It reduces lookup count, but unmanaged flattening creates stale authorization when providers change infrastructure. Use flattening when the record is close to breaking and there is a process to refresh changes.
Where hosted SPF helps
If the SPF record has a handful of stable IPs, plain DNS is enough. When the record has many senders, frequent vendor changes, DNS access bottlenecks, or repeated lookup pressure, hosted SPF is usually easier to operate.
Suped's product connects hosted SPF with DMARC monitoring, DKIM visibility, SPF flattening, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, and issue alerts. That gives teams a way to tie SPF changes to real authentication evidence instead of treating each DNS edit as a separate task.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
The practical workflow is straightforward: add the domain, review current SPF, identify senders, move authorized senders into hosted SPF, then use DMARC reports and alerts to see whether any legitimate source still fails. For agencies and MSPs, the same workflow scales across client domains without asking every client for DNS access for every sender change.
Audit checklist before publishing
Before changing an SPF record that contains IP addresses, check both the syntax and the sending reality. A syntactically valid record still fails the business goal if it authorizes the wrong host or misses the domain actually used in the envelope sender.
- One record: Publish one SPF TXT record at the domain, not multiple competing SPF records.
- Known IPs: Confirm each direct IP maps to a current outbound sender with a named owner.
- Hosted senders: Use the provider's documented include or return-path setup instead of copying shared-pool IPs.
- Parked domains: Publish v=spf1 -all on domains and subdomains that should not send mail.
- MX intent: Keep mx only when inbound hosts also send outbound mail.
- HELO hostname: If you operate the MTA, publish SPF for the HELO or EHLO name and keep its rDNS consistent with the sending IP.
- Provider syntax: Use include:domain with a colon, no trailing period, and no space after the colon.
- Lookup count: Count every SPF mechanism that triggers DNS resolution, including nested lookups inside provider records.
- Migration cleanup: Keep old and new senders authorized during overlap, then remove old IPs or includes after traffic stops.
- Whole domain: Run a domain health check to catch related DMARC, SPF, and DKIM issues.
A clean end state
A good SPF record is short enough to evaluate, specific enough to avoid over-authorization, and documented enough that the next change does not depend on memory.
Views from the trenches
Best practices
Use direct ip4 and ip6 mechanisms only for stable outbound servers you can inventory.
Keep ESP and marketing streams on subdomains so each SPF record stays easier to audit.
Document every authorized sender with an owner, purpose, and expected mail stream.
Common pitfalls
Leaving mx in SPF after copying a template can authorize inbound-only hosts by accident.
Manual flattening of provider includes into IPs makes stale authorization easy to miss.
Adding every sender to the parent domain creates lookup pressure and noisy audits.
Expert tips
Check DMARC aggregate data before deleting IPs that still send legitimate domain mail.
Stage SPF changes with soft fail first when ownership of old senders is unclear.
Review SPF after mail migrations because old static IPs often remain authorized.
Marketer from Email Geeks says direct IP mechanisms are normal when the sending IPs are fixed, known, and intentionally authorized.
2022-04-27 - Email Geeks
Marketer from Email Geeks says the mx mechanism authorizes the domain's MX hosts, not a separate section of the SPF record.
2022-04-27 - Email Geeks
The practical rule
Using IP addresses in SPF is good practice when the IPs are stable, owned, and documented. Seven direct IPs in a record is not unusual by itself. The better question is whether each IP still sends mail for the domain and whether any non-IP mechanism, especially mx, was added on purpose.
The default rule is simple: authorize the smallest accurate set of outbound senders, split unrelated streams onto subdomains, avoid unnecessary DNS lookups, and monitor DMARC results after every change. Cloud platforms and shared-IP ESPs belong in SPF through their documented include or return-path path, not copied IPs. That gives SPF a clear job and keeps future audits manageable.
