SPF a mechanism resolves to multiple IPs but only one permitted

Why does SPF allow only one permitted IP when multiple records resolve?

You send a transactional email. It bounces. The error says: “SPF fail.” You check your SPF record. It includes three domains, each resolving to a different IP. You’re confused. Why does one IP—any one—block all the rest?

SPF doesn’t route traffic or balance load. It’s not a delivery mechanism. It’s a sender authentication rule. The protocol allows only one IP per policy to be marked as "permitted," even when multiple IPs resolve through includes, A records, or MX lookups. That single permission is enforced by the receiving server during validation.

Here’s the core truth: SPF doesn’t work like a load balancer. It’s a gatekeeper, not a traffic cop. If your domain uses multiple IPs through mechanisms like include or expanded a and mx records, the policy checks all of them—but only one is allowed to pass as valid per SPF instance.

Key takeaways

• SPF allows only one permitted IP per policy, regardless of how many IPs resolve via includes or expanded mechanisms.
• SPF is not designed for routing or load balancing—only for sender verification.
• Any IP not explicitly permitted in the SPF record will fail validation, even if it’s used in a legitimate sending workflow.

How does SPF evaluate a domain with multiple resolved IPs?

When a domain’s SPF record resolves to multiple IPs, SPF evaluates all of them—no matter how many. Each IP listed in the policy (via ip4, ip6, a, mx, or include mechanisms) is added to the list of authorized senders. Only those IPs are permitted; any sender using a non-listed IP fails SPF, triggering a bounce or spam tag. The receiving server checks your sending IP against this full, dynamically resolved list.

How SPF processes multiple IPs step by step

1. Fetch the SPF record via DNS lookup as a TXT record from the domain’s zone. This is the starting point for verification.
2. Parse mechanisms in the record: ip4, ip6, a, mx, and include. Each defines a way to authorize IPs.
3. Resolve includes by making additional DNS lookups for domains in include directives. For example, include:mailchimp.com triggers a lookup to find that domain’s SPF policy and its allowed IPs.
4. Collect all authorized IPs from every mechanism. The final list includes direct IPs from ip4 and ip6, and dynamically resolved IPs from a, mx, or include.
5. Check the sending IP against this complete list. If it matches exactly, SPF passes. If not, it fails — regardless of how many IPs are authorized.

Why this matters for deliverability

SPF’s strict one-per-policy rule means even if the domain has dozens of valid IPs, only those explicitly listed in the policy count. An extra IP, even if legitimate, will fail SPF. This is why you must verify your SPF record is complete and up to date.

For example, if a include directive points to a third-party service like SendGrid, and that service changes its sending IPs, your SPF fails unless you update the policy. According to RFC 7208, the specification for SPF, the evaluation is deterministic: only IPs in the final resolved list are valid.

Let’s say your domain has a mx mechanism and two include directives. SPF looks up the MX records — which may resolve to multiple IPs — then fetches the SPF records of the included domains, pulls their IPs, and merges them all. It’s a chain of DNS lookups, but the final list is what matters.

When you send emails through multiple systems, this process ensures you don’t leak authorization. But it also means configuration errors—like outdated includes or incorrect ip4 entries—can cause delivery failures. A single misconfigured mechanism can break the entire SPF check.

Making sure your SPF policy is correct and up to date? That’s where tools like MailTester’s email checker help. Use it to test any address and see if its domain’s SPF setup will allow your message to pass.

What happens when an SPF record permits more than one IP via multiple 'include's?

Even if an SPF record uses multiple 'include' directives that resolve to different IP addresses, the receiving mail server evaluates them as part of a single, unified list. The SPF check passes only if the sending server’s IP appears in that combined list. You cannot bypass the one-IP-per-sender policy by listing multiple includes—each include’s resolved IPs are merged, and the policy still enforces a strict match. This means every included sender’s IP must be explicitly authorized, or delivery fails.

When multiple includes resolve to different IPs, how is the check performed?

Let's say you include both include:spf.protection.outlook.com and include:sendgrid.net. The receiving server resolves each and combines the resulting IPs into one list. It then checks whether the IP of the sending server appears anywhere in that list, regardless of which include it came from. SPF doesn’t count per-include; it counts per-IP in the final result.

Even if one 'include' resolves to an outdated or incorrect IP, it doesn’t break the whole record — but it can lead to a failed SPF check if the sending IP isn’t among the resolved ones. A misconfigured include may appear valid in isolation, but when combined, it can introduce a false negative. For example, if an old server’s IP is still in a legacy include, and you're sending from a new one not listed, the check fails.

The danger of assuming “it’s probably fine”

Many teams assume that because an SPF record contains multiple includes, it’s inherently flexible. But SPF policies are not about flexibility — they’re about precision. Each sending IP must be explicitly allowed. An outdated include with a removed IP doesn’t just reduce coverage; it can actively cause delivery failures for legitimate senders, especially when the sender’s IP isn’t in the list.

This is why testing SPF records against actual sending IPs is essential. You can’t rely on assumptions. Even if all includes appear valid on paper, the live result depends on current DNS records, which can change without notice. Use tools that validate SPF alignment and real IP verification. MailTester’s bulk email verification can check entire lists for valid SPF alignment, catch-all addresses, and other deliverability blockers before you send.

The SPF standard (RFC 7208) specifies that all mechanisms are processed in order and combined into a single allow list. You can’t treat includes as independent gates. The final check is binary: your IP is in the list or it isn’t. No exceptions. No partial credits. So if your sending IP is missing, delivery fails — no matter how many includes you have.

SPF record complexity leads to one permitted IP in practice: here’s why

SPF records can list multiple IPs, but only one is practically allowed at a time because ISPs and email services evaluate each sending IP against the full SPF policy. If an IP isn’t explicitly listed, it fails — regardless of how many IPs the record resolves to. This creates a de facto "one permitted IP" rule in delivery, even if the record technically allows more.

The limits shape the outcome

SPF records are constrained by two hard limits: a 255-character limit per TXT record and a maximum of 10 mechanisms per record. When you include third-party services like Google, SendGrid, or Mailchimp, you often need to use 'include' to extend the allowed list. But each include counts as a mechanism, and once you hit ten, you can’t add more — forcing a trade-off.

Even if you could list more IPs, the domain’s SPF policy is checked per sender, not per IP. That means every message from a new IP must be validated against the full rule set. If the IP isn’t in the allowed list, it fails — no exceptions. This is why it’s rare for more than one IP to effectively pass SPF in large-scale sending, even when many are technically listed.

Third-party services compound the risk

Many organizations use third-party email platforms that send from multiple IPs. Yet only those specific IPs that are explicitly included in the SPF record are permitted. If the record omits even one IP used by the service, that message will fail SPF and risk being rejected or marked as spam.

That’s why email deliverability teams often end up with a single, stable sending IP they can trust — not because it’s required, but because maintaining multiple valid IPs in SPF is brittle. Any change, omission, or policy misconfiguration breaks the chain. It’s easier to centralize sending through one IP that’s fully listed, than to manage a complex, fragile multi-IP setup.

For accurate pre-sending validation of these issues, use real-time verification that checks not only syntax but delivery readiness. MailTester’s email checker confirms whether an address can accept mail, including SPF and other deliverability risks, before you send.

The real-world outcome? Even with complex SPF records, delivery stability depends on one consistent, verified IP. That’s the practical limit, not the technical one. RFC 7208, the SPF specification, confirms this: “A sender is permitted only if it is authorized in the policy.”

For teams managing bulk sends, validating the full chain — including DNS, SPF, and inbox placement — is critical. MailTester’s inbox placement test simulates real delivery scenarios across major providers to ensure your messages land where they should.

How to validate that your SPF policy permits the correct IP

You must test each sending IP directly against your SPF record using real-time verification and inbox placement checks. DNS lookup tools only show the record, not whether delivery succeeds. Verify that every IP sending mail is explicitly listed in your SPF policy—no shortcuts via third-party domains—and audit these regularly, especially when services update their IPs.

Validate SPF policies with real-world tests

• Use a real-time verification tool like MailTester’s email checker to confirm that your SPF record permits the actual IP sending the message. This goes beyond checking DNS records—it tests delivery behavior in real inboxes.
• Run inbox-placement testing for each IP you use to send email. This confirms whether SPF passes in practice, not just in theory. Many domains pass SPF checks in DNS but fail in real delivery due to relaxed policies or incorrect alignment.
• Avoid relying solely on DNS lookup tools like MXToolbox or DNSChecker—they show your SPF record structure but do not tell you if a message actually gets delivered based on that policy.
• Ensure every IP used to send email is explicitly included in your SPF record. Do not assume that third-party services (like your email platform or marketing tool) are trusted just because they’re reputable. If they don’t list their IPs directly in your SPF, your emails may fail.

Keep your SPF policy up to date

• Third-party senders frequently change their IP addresses. Review your SPF record quarterly—or whenever you onboard a new service—and remove old IPs or add new ones.
• When you have multiple IPs in your SPF record, make sure they're all valid and active. Overly long SPF records can trigger alignment failures or be rejected by strict receivers. Keep the list lean and accurate.
• Use MailTester’s inbox placement tester to simulate sending from different IPs and verify SPF compliance in real inboxes, including major providers like Gmail, Outlook, and Apple.
• Consider using DMARC with a strict policy to monitor violations and identify IPs not in your SPF list—but only after you’ve verified every sending IP is correctly authorized.

SPF only works if the sending IP matches what your record explicitly allows. Verification isn't a one-time task—it’s ongoing. Let SPF be a gatekeeper, not a suggestion.

SPF vs DKIM vs DMARC: what each actually does

You’re sending emails, but they’re not landing in inboxes. The root cause? Authentication failure. SPF checks if the sending IP is authorized by the domain’s DNS record. DKIM verifies the email content hasn’t been tampered with using a cryptographic signature. DMARC sits on top, enforcing policy based on SPF and DKIM results — deciding what happens when either fails. If SPF lists only one IP but multiple resolve, only the listed one passes. The others fail, even if they’re legitimate. This strict permit list is by design — SPF doesn’t handle load balancing. You need a single, approved IP, or the email won’t be trusted.

How SPF, DKIM, and DMARC work together

Let’s break down what each protocol actually does — not how they're marketed, but how they function in real mail flows.

SPF’s strict permit list means if your email server uses dynamic IPs or load-balanced infrastructure, only the exact IPs listed in the TXT record are valid. Any IP not listed, even if it’s part of your network, fails. This is why many senders miss a key point: SPF doesn’t support scalability by default. If you have multiple IPs, you must list them all — or risk widespread delivery failures. For more complex setups, you need an SPF mechanism like RFC 7208’s "include" or "all" mechanisms — but misusing them can weaken security or cause unintended failures.

DMARC’s effectiveness depends entirely on proper SPF and DKIM configuration. Without both, DMARC has nothing to act on. It’s not a backup; it’s the enforcement layer. If SPF fails and DKIM passes, DMARC still applies policy — but only as set. To avoid delivery issues, you must test your email from real environments. MailTester’s inbox placement tool checks whether your emails land in inboxes, not spam — and it runs against actual inbox providers like Gmail and Outlook.

Common mistakes that make SPF fail even when multiple IPs resolve

SPF fails when your record includes mechanisms that resolve to multiple IPs, but only one is permitted—especially if third parties, outdated records, or unresolved mechanisms trigger a "hard failure." You don’t need multiple IPs to be valid; you need only one that’s explicitly allowed. If a mechanism like include resolves to more than one IP without proper allowance, or if an a or mx record points to obsolete servers, SPF breaks. Test your actual sending IPs before sending.

Watch for third-party domains with outdated or broad IP lists

• Don't assume a third-party service's SPF record is accurate or up to date—many still reference legacy IP ranges that no longer send email.
• Using include:thirdparty.com can cause failure if their SPF spans dozens of IPs, and your policy doesn’t allow them all.
• Always verify current IP ranges by checking the domain’s DNS records via tools like MxToolbox or RFC 7208 section 6.1.
• Consider replacing broad includes with explicit ip4: or ip6: entries for your own sending IPs.

Ensure mechanisms point to current IPs

• Using a or mx without verifying the resolved IP is still active today breaks SPF.
• Change your record if your mail server IP changes—using old a or mx entries results in hard failures.
• Don’t rely on DNS TTL as an excuse—many IPs shift without a change in the record.
• Check what your a or mx resolves to at runtime using dig a example.com or nslookup—not just what your DNS provider shows.

Validate SPF against real production sending IPs

• Testing SPF with a simulated IP doesn't catch real-world misconfigs.
• Always test SPF using tools that evaluate your record against your actual sending IP in production.
• Use inbox placement testing to see how your SPF performs in live inbox environments.
• Even a single unallowed IP in a chain—like a nested include—can trigger a hard failure and hurt deliverability.

Limit include chains and avoid implicit allowances

• Chains like include:parent.com → include:child.com can resolve to more than one IP, causing violation if not explicitly allowed.
• SPF limits the number of mechanisms to 10, and chains increase risk of hitting that limit, especially with unresolved or redundant includes.
• Use include sparingly—prefer explicit IP entries for your own infrastructure.
• Test your complete SPF chain using bulk verification or an SPF validator tool.

How MailTester helps ensure SPF policies are correctly enforced

You can’t rely on a DNS lookup alone to know if an SPF policy is actually enforced. MailTester goes beyond checking the record—it verifies the real sending IP against the domain’s SPF policy in real time, simulates delivery, and returns whether SPF passes or fails, so you catch issues before they hurt deliverability. This is critical because even if a domain’s SPF record resolves to multiple IPs, only one valid sending IP is permitted, and any deviation triggers a fail. Misconfigured SPF is a top reason for emails being marked as spam or rejected outright.

Real-time SPF validation that mimics real delivery

Let’s say you’re sending from a server with IP 198.51.100.10. A simple DNS check might show the SPF record is technically valid—but it won’t tell you if that IP is actually allowed. MailTester’s real-time verification API checks the actual sending IP against the domain’s SPF record, then returns a definitive result: Pass, Fail, or SoftFail. This isn’t just a static check—it simulates what happens when an email hits the receiving server, using actual SMTP behavior. The RFC 7208 standard defines SPF policy enforcement, and MailTester adheres to those rules precisely.

Ensuring your list and workflow stay compliant

If you're sending to a large list, you need to know which addresses are safe to contact. MailTester’s bulk list verification scans every email, identifies domains with invalid, outdated, or misconfigured SPF policies, and flags them as “risky” or “invalid.” This stops you from sending to domains that will reject your mail due to SPF failures, even if the email address looks valid. For teams using tools like Mailchimp, SendGrid, or HubSpot, MailTester integrates directly into the workflow, adding SPF validation before any send happens. You can test delivery in real inboxes with our inbox-placement tool, which confirms whether SPF policy issues are actually blocking your message from reaching the inbox.

For developers, the verification API is designed to be embedded into your sending process, ensuring every address is validated before it leaves your system. If you want to test a few addresses, our email checker gives you quick, accurate feedback on individual addresses. For teams running campaigns, the inbox-placement test shows how SPF and other factors impact real delivery. The whole system is built to give you confidence—not just a percentage, but actual results tied to what happens in production.

Why SPF’s one-permitted-IP model is a design constraint, not a bug

SPF’s rule that only one IP can be permitted per domain isn’t a flaw — it’s a deliberate design choice from the early 2000s. It reflects the protocol’s original intent: to prevent spoofing by tightly limiting which IPs can send on a domain’s behalf. That constraint still works today, but it forces senders to adapt rather than fix the protocol.

SPF was built for simplicity, not scale

When SPF was standardized in 2004, email volume was much lower, and most senders used just one server or small, dedicated infrastructure. The model assumed a domain sent from a handful of known IPs — not hundreds across third-party platforms. As email grew, so did reliance on vendors like SendGrid, HubSpot, and AWS SES. Now, a single company may need to list dozens of IPs across multiple providers, and SPF can’t scale that way.

But here’s the thing: this rigidity is intentional. By limiting the number of permitted IPs, SPF reduces the attack surface. An attacker can’t easily spoof a domain unless they control an IP already whitelisted — and that list is supposed to be small and auditable. That’s why you still see SPF checks in place, even if the IP list is outdated. It’s not broken; it’s serving its original purpose — reducing abuse.

Adapting, not upgrading, is the real solution

Instead of rewriting SPF, modern senders use DMARC to manage policy enforcement. DMARC relies on SPF and DKIM results but adds visibility and control. For example, you can set a policy to reject emails that fail SPF unless they also pass DKIM. Or, you can monitor reports to see if unauthorized IPs are sending.

Let’s say your domain sends through three vendors. You can’t legally list all their IPs in a single SPF record — or you’d hit the 10 lookup limit. But DMARC lets you align policies across all senders, even if SPF alone can’t track them all.

For developers and senders, this means verifying your email infrastructure isn’t just about SPF. Use a tool like our email checker to validate your domain setup, ensure deliverability, and catch invalid or risky addresses before they send. It’s not a fix for SPF’s limitations — but it’s a practical step toward better sender reputation and inbox placement.

SPF’s one-permitted-IP model remains a constraint, not a bug. The real work happens in policy, monitoring, and integration — not in re-inventing an email authentication protocol. For more, see how inbox placement testing reveals delivery outcomes across major inboxes, helping you confirm your setup works in the real world.

Final thoughts: SPF is not a load-balancer; use it as an IP permit list

SPF does not distribute sending load across multiple IPs. It only authorizes the specific IPs listed in the record. If a sender uses an IP not included, the email will fail authentication, regardless of correctness.

Even if DNS resolves multiple IPs through mechanisms like 'include', only those explicitly permitted in the SPF record will pass. Missing an IP—no matter how legitimate—can trigger delivery failures.

Tools like MailTester detect these misconfigurations before they impact campaigns. Real-time validation ensures your SPF record covers every sending IP, reducing bounces and protecting sender reputation.

Sources

• At regional mailbox providers, 15.5% of email goes missing without a trace versus only 2.8% filtered to spam — the inverse of the pattern at Gmail, Microsoft, Yahoo, and Apple. — Validity 2025 Email Deliverability Benchmark Report (2025)
• Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

Keep reading

• Anti-spam laws and compliance: CAN-SPAM, GDPR, CASL (complete guide)
• Why DMARC rua URI Using HTTP Violates Modern Email Security Standards
• How Complaint-Based Penalties From GDPR Impact Email Marketing
• How to Automatically Detect and Fix List-Unsubscribe Header Mistakes
• Fixing Authentication-Results Policy Mismatch in ESP Settings

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can SPF allow multiple IPs in one record?

Yes, a single SPF record can list multiple IPs using 'ip4' or 'ip6' mechanisms. However, the receiving server checks the sending IP against all listed IPs — not all resolved IPs automatically pass.

Why does SPF fail when multiple IPs resolve but only one is listed?

SPF only permits IPs explicitly listed in the record. Resolved IPs from 'include' or 'a' mechanisms are not automatically allowed — only those in the final policy.

Does SPF support load balancing or multiple sending servers?

No — SPF is not a load-balancing mechanism. It authenticates senders by IP. Multiple servers require each IP to be explicitly permitted.

How can I test if my SPF policy is working?

Use a real-time verification tool like MailTester to test SPF results against actual sending IPs and simulate inbox placement.

What happens if my third-party sender uses an IP not listed in SPF?

The email will fail SPF authentication, likely ending up in spam or being rejected. The sender must ensure all IPs are included.

Is it safe to use 'include' in SPF to add third-party IPs?

Yes, but only if the included domain’s SPF record lists your IP. If the third party changes their IPs, you may fail SPF unless you update the include.

Can I have more than one SPF record for a domain?

No — multiple SPF records cause a permanent failure. Only one SPF TXT record is allowed per domain.

Does DKIM replace SPF?

No — DKIM verifies email integrity and content. SPF verifies the sending IP. They work together, not in isolation.

What is DMARC’s role in SPF failures?

DMARC uses SPF and DKIM results to define actions. If SPF fails and DMARC is set to 'reject', the email is blocked.

How often should I audit my SPF policy?

At least monthly if you use third-party senders, or after any infrastructure change. Use real-time tools to catch issues automatically.