What is the best practice for using IP addresses in SPF records?
Published 4 May 2025
Updated 23 Oct 2026
14 min read
Summarize with
Updated on 23 Oct 2026: We clarified how to add SPF IP addresses safely, publish longer TXT records, and choose between softfail and hard fail.
The best practice is to use ip4 and ip6 mechanisms only for stable public outbound IP addresses that your organization operates or a provider documents for your sending service. SPF compares the connecting IP with the policy for the SMTP MAIL FROM (envelope sender) domain, or the HELO identity when MAIL FROM is empty. 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.
When to use direct IPs or includes
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, with a qualifier chosen for your mail flows. Never use +all; it authorizes every connecting IP.
For unlisted senders, -all returns fail and ~all returns softfail. Neither is an SPF pass for DMARC. An SPF pass supports DMARC only when the MAIL FROM domain meets the domain-matching requirement for the visible From domain; a matching DKIM pass can also satisfy DMARC. RFC 9989 cautions that receivers using SPF hard fail can reject mail before checking DKIM or DMARC, including forwarded messages. Choose ~all or -all after testing legitimate mail flows, rather than treating hard fail as mandatory for production.
- 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 unrelated mail streams on separate return-path subdomains when the sender mix is different, then publish SPF at each MAIL FROM domain.
- 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 straightforward to evaluate and avoids DNS lookup-limit pressure. The tradeoff is maintenance: when one of those senders changes IP, the record must change too. All IP addresses and .example domains shown here are documentation placeholders; replace them with your actual sending IPs and provider domains.
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 which MAIL FROM or return-path domain each sender uses. Publish SPF at those domains; the visible From domain alone does not determine which SPF record is checked. SPF is not inherited from the parent domain.
- 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 and to verify domain matching for DMARC.
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 at least one term of the SPF lookup budget when evaluated, plus any nested DNS-querying terms.
- Main risk: Too many providers on one domain can create an over-limit path and SPF permerror.
Before changing a live record, run it through an SPF checker and check for multiple SPF records, syntax errors, excessive lookups, and void lookups. A record without all is not automatically invalid; verify whether it intentionally uses redirect instead.
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 (prefix length) when you mean a range. A bare address such as 192.0.2.10 is not a valid SPF mechanism. IPv4 prefix lengths are 0-32; IPv6 prefix lengths are 0-128. Wildcards such as 192.0.2.x and address ranges written with hyphens are not valid IP mechanisms.
Only publish public egress IP addresses that open outbound SMTP connections for the domain. If the server sits behind NAT, authorize the public NAT address seen by the receiving server, not the private address assigned to the MTA. Do not publish private or loopback addresses. A website or gateway IP belongs in SPF only if it opens the outbound SMTP connection. Check IPv4 and IPv6 egress separately; an IPv4 entry does not authorize IPv6 connections.
- 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. Do not combine unrelated IPs into a broad CIDR block just to shorten the record. When ranges overlap and qualifiers differ, order them to express the intended policy because SPF evaluates left to right and stops on the first match.
How to add IP addresses to an existing SPF record
Add new IP mechanisms to the existing policy instead of creating another SPF record. SPF stops at the first matching mechanism, so entries after all are never evaluated.
- Edit the TXT record at the exact MAIL FROM domain. Use the root-domain host field only when that is the envelope sender domain.
- Insert each ip4: or ip6: entry before the final ~all or -all, with spaces between mechanisms. Retain other authorized senders.
- Save one SPF TXT record, using the TXT record type rather than the obsolete SPF record type.
- Allow caches holding the old policy to expire according to its previous TTL. Then send a test and inspect the receiving server's Authentication-Results for spf=pass and the expected smtp.mailfrom domain.
Before adding another outbound IPdns
v=spf1 ip4:192.0.2.10 ~all
After adding another outbound IPdns
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ~all
There is no 10-IP limit. Each TXT character-string is limited to 255 bytes, but a longer SPF policy can use multiple strings within one TXT record. Preserve spaces where mechanisms cross string boundaries, since DNS concatenates strings without inserting spaces. Separate SPF records cannot extend the policy. M3AAWG SPF guidance covers these publication checks. Keep the complete record compact even when it contains only IP mechanisms.
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 | Separate return path | Separate policy |
Parked domain | No sending | Use -all |
Common SPF authorization patterns and when they fit.
Mixed provider and fixed serverdns
v=spf1 ip4:192.0.2.10 include:spf.sender.example ~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. Put stable IP mechanisms before includes to avoid unnecessary lookups for those senders, provided this preserves the intended qualifiers. This follows RFC 7208 guidance on placing lower-cost mechanisms earlier.
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?" Confirm the MAIL FROM or return-path domain the provider uses and follow its published SPF instructions. Shared pools and cloud platforms change IPs, so copying a current relay IP into SPF creates stale authorization and misses future senders.
- Microsoft 365 commercial and GCC mail uses include:spf.protection.outlook.com, not the website A record. Other Microsoft clouds have different include values; follow Microsoft's SPF configuration for your tenant.
- 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 fails because the MAIL FROM domain lacks the provider's required authorization. DKIM selectors and tracking-domain settings do not determine the SPF result.
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 DNS-querying terms are include, a, mx, exists, and ptr mechanisms, plus the redirect modifier. RFC 7208 says ptr should not be used. If one evaluation path exceeds the 10 DNS lookup limit, SPF returns permerror. The receiving system decides how to handle the message. Fetching the initial SPF TXT record does not consume one of these 10 terms.
Count the worst-case evaluated path 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 include, a, mx, exists, or redirect paths. SPF evaluates mechanisms left to right and stops on the first match, so one sender can pass while a later sender reaches an over-limit path and returns permerror.
Void lookups also matter. Empty DNS answers and missing names inside include, a, mx, or exists paths count as void lookups. RFC 7208 recommends a limit of two; exceeding an implementation's limit produces permerror. A TTL such as 3600 seconds is a common operational choice, but TTL does not change either SPF lookup limit.
Evaluated SPF lookup path
Operational headroom before RFC 7208's limit of 10 DNS-querying terms on one evaluation path.
Low pressure
0-5
More operational headroom for nested provider changes.
Review
6-8
Inspect nested paths before adding senders.
No headroom
9-10
One provider change can push a path over the limit.
Permerror
11+
SPF returns permerror if evaluation reaches this point.
This is where SPF flattening enters the conversation. Flattening replaces provider lookups with IP ranges. It reduces lookup count, but a one-time flatten creates stale authorization when a provider changes infrastructure. Do not manually flatten a dynamic cloud include. Use flattening only for stable, documented ranges or through an automated process that tracks provider changes and refreshes the record.
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 can centralize change control and automate refreshes.
Suped's hosted SPF product manages authorized senders and refreshes flattened IP ranges. Suped's DMARC monitoring helps teams compare an SPF change with observed authentication results and investigate new failures.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
The workflow is to add the domain, review current SPF, move verified senders into hosted SPF, and publish the supplied DNS record. Use DMARC reports and alerts to investigate remaining legitimate failures. Agencies and MSPs can manage later sender changes without requesting client DNS access each time.
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 entry is the current public egress IP seen after NAT and maps to an 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 and no space after it. Omit a trailing period for compatibility with older SPF implementations.
- Lookup count: Count every DNS-querying term on the worst-case evaluated path, including nested terms 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.
Choose ~all or -all after checking forwarding and receiver behavior, even with DMARC enabled.
Review SPF after mail migrations because old static IPs often remain authorized.
Marketer view
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 view
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
Frequently asked questions
No. It is good practice when the IP addresses are stable outbound senders and someone owns the maintenance. Direct IP mechanisms also do not use SPF DNS lookups. Do not add a website A record, CDN address, or random relay IP unless it is the documented outbound sender.
Use mx only when the domain's MX hosts send outbound mail for that domain. If they only receive inbound mail, remove mx after checking production data.
No. ip4 and ip6 mechanisms are direct matches. They do not perform DNS lookups during SPF evaluation.
Use a separate return-path subdomain when the marketing platform or ESP supports it. This keeps provider includes away from business email SPF and gives that mail stream its own lookup budget. Changing only the visible From domain does not select a different SPF record; SPF checks the MAIL FROM domain.
Yes, for MTAs you operate. HELO SPF helps with null sender and bounce cases, but it does not replace SPF on the envelope sender domain used for DMARC domain matching.
Check DMARC aggregate data, mail logs, current vendor ownership, and recent sending history. During an ESP migration, keep old and new SPF sources authorized until the old sender has stopped legitimate mail.
