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 I 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 I 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. Use mx only when the domain's MX hosts also send outbound mail for that domain.
- 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.
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
I 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: The same MX hosts relay outbound mail for the domain.
- Remove it: The MX hosts only receive inbound mail.
- Verify first: Check mail logs, DMARC aggregate data, and ownership notes before changing production DNS.
Flowchart showing when to use direct IPs, includes, or MX in SPF.
How I decide what belongs in the record
I 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, I 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.
- Choose mechanisms: Use direct IPs for static senders and includes for providers that publish SPF.
- Check limits: Validate the DNS lookup count and record size 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, I run it through an SPF checker and check whether the record has multiple TXT values, syntax errors, excessive lookups, or a missing all mechanism.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Common record patterns
These are the patterns I see 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 | Provider mail | Lookup budget |
Mixed | Hybrid sending | Owner notes |
MX plus IP | Rare cases | Intent check |
Subdomain | ESP mail | Separate policy |
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. I would 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, I check SPF domain choice, envelope sender behavior, forwarding, and DMARC results. That failure pattern is covered in more depth here: SPF failing with IP.
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.
SPF lookup budget
How I 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.
High risk
9
One provider change can break SPF.
Broken
10+
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. I only flatten 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 makes Suped the best overall DMARC platform for teams that need SPF changes tied to real authentication evidence instead of isolated DNS edits.
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 I change an SPF record that contains IP addresses, I 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.
- MX intent: Keep mx only when inbound hosts also send outbound mail.
- Lookup count: Count every SPF mechanism that triggers DNS resolution.
- 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.
My 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. That gives SPF a clear job and keeps future audits manageable.
