Why does the SPF IP4 not in range error happen in Mailgun or SendGrid?

You sent an email. It bounced. The error says: "SPF IP4 not in range." Not a typo. Not a hiccup. It’s a technical wall between your message and the inbox.

If your domain’s SPF record lists an IP address that Mailgun or SendGrid isn’t using—because their IPs shift dynamically—it breaks the rule. Your mail isn’t allowed in. It’s like showing up to a concert with a ticket for the wrong venue.

The root cause? SPF records are static, but Mailgun and SendGrid use rotating IP pools. If your SPF isn’t updated or misaligned with their current IP ranges, the sender is unauthorized—bounced, even if the address is valid.

Key takeaways

  • SPF records must include current IP ranges used by Mailgun or SendGrid—static IPs in your SPF won't work over time.
  • These services use dynamic IP pools; their IP ranges change regularly, so hardcoded IP4 entries fail.
  • Correct SPF alignment requires either using the designated include mechanisms or regularly syncing your SPF with service updates.

How does the SPF error affect email deliverability?

If your SPF record lists an IP4 address that’s not within the permitted range, receiving mail servers treat your message as unauthorized. This triggers hard bounces, reduces inbox placement, damages sender reputation, and can lead to blocks by major providers like Gmail or Outlook. Even a single misconfiguration can lower deliverability by up to 40% in high-volume campaigns.

Hard bounces and immediate delivery failure

When a receiving server checks your SPF record and finds an IP4 address outside the allowed range, it rejects the message immediately. The sender sees a hard bounce, and the email never reaches the recipient’s inbox. This isn’t just a hiccup—it’s a direct rejection based on authentication failure.

SPF is a foundational email authentication method. If validation fails at this stage, the message is considered potentially fraudulent. Many providers, including Google and Microsoft, enforce strict SPF checks. You can verify your SPF setup using tools like MxToolbox or the SPF specification (RFC 7208), which defines the protocol’s behavior.

Long-term damage to sender reputation

Even if one message is caught early, repeated SPF failures from the same sending domain signal poor configuration hygiene. ISPs track this behavior over time and use it to assess sender trustworthiness. A single misconfigured SPF record may not cause an immediate block, but multiple instances—especially with high-volume sends—can lower your sender reputation score.

Once reputation drops, even valid emails may land in spam folders or be throttled. High-volume senders, like those using Mailgun or SendGrid, are especially vulnerable. The more emails you send, the more each failure compounds the risk. A 2023 study by Return Path found that sender reputation is one of the top three factors affecting inbox placement.

To catch SPF issues before they hurt delivery, use real-time verification. Check your list with MailTester’s bulk verification tool—it flags invalid, risky, or catch-all addresses, including those tied to misconfigured authentication. You can also test individual addresses before sending with the email checker, or use the API for automated validation in your workflow.

What does 'IP4 not in range' actually mean?

If you see an "IP4 not in range" error when sending via Mailgun or SendGrid, it means the IP address used to send the email isn’t listed in the SPF record of your sending domain. Receiving servers check SPF records for alignment, and if your domain’s policy doesn’t list the sending IP (even if it’s a valid Mailgun or SendGrid IP), the message fails validation. This happens even if your sending service is trusted—your domain’s SPF policy must include the IP range the message comes from.

How SPF validation works during email delivery

When an email arrives, the receiving server checks your domain’s SPF record—specifically, whether the sending server's IP is authorized. SPF records use mechanisms like ip4 to define allowed IPs. If the sending IP is not in the allowed range, the server flags it as a misalignment. Even if your IP is part of Mailgun or SendGrid’s public IP pool, your domain’s SPF record must explicitly allow it. Without that, the message is rejected or marked as suspicious.

Let’s say your domain uses include:mailgun.org in its SPF record. That works only if Mailgun’s policy allows it—and even then, only if your domain’s full SPF record includes their current IP ranges. If the record isn’t updated or is too restrictive (e.g., listing only a few IPs), newer or different sending IPs won’t pass.

Real-world causes and fixes

The error typically appears when sending from a third-party service but the domain’s SPF record is misconfigured or overly strict. You might have added Mailgun or SendGrid to your domain’s SPF, but omitted the correct IP ranges, or used outdated or incomplete mechanisms like ip4 with an incorrect subnet.

Fixing it means updating your domain’s SPF record to include the exact IP ranges used by your sending service. For Mailgun, this includes specific ip4 entries for their delivery servers. For SendGrid, you’ll need to use include:sendgrid.net and verify it’s not blocked by overly narrow policies. Always test your SPF record using tools like MxToolbox or RFC 7208.

Before sending bulk messages, verify your list with a reliable email checker. Use MailTester’s bulk verification to catch invalid or malformed addresses early. This helps prevent deliverability issues caused by poor list hygiene, which can compound SPF errors.

How to verify if your SPF record is correctly configured for Mailgun or SendGrid?

You can verify your SPF record by using a DNS lookup tool like MXToolbox or RFC 4033 to check your domain’s TXT record. Ensure it includes include:spf.sendgrid.net or include:mailgun.org and doesn’t exceed 10 DNS lookups. Conflicting mechanisms like multiple ~all or fail values will also break SPF validation.

Step-by-step SPF verification process

  1. Run a DNS lookup on your domain using a tool like MXToolbox or the dig command. This shows the raw SPF record currently published. You’ll see something like txt "v=spf1 include:spf.sendgrid.net ~all".
  2. Confirm the correct include directive is present. For SendGrid, it must be include:spf.sendgrid.net. For Mailgun, use include:mailgun.org. Missing or incorrect includes will cause SPF failures during email delivery.
  3. Count your DNS lookups to ensure you're under the 10-lookup limit. Each include:, ip4:, ip6:, or redirect: triggers a DNS lookup. Over 10 breaks SPF validation and can cause sends to be rejected.
  4. Check for conflicting mechanisms. Your record should have only one qualifier (~all for soft fail, -all for hard fail). Multiple ~all or mixed mechanisms like ~all -all violate SPF standards and degrade sender reputation.
  5. Test the full chain by verifying the included domains (e.g., sendgrid.net) also have valid SPF records. Even if your record is correct, a malformed include can still break delivery.

Common mistakes to avoid

One frequent mistake is copying incomplete examples. A valid SPF record must start with v=spf1 and end with ~all or -all. Another is merging multiple third-party includes without tracking lookup counts. Always test with tools that show lookup depth.

If you’re managing large sends, use bulk email verification to clean your list before sending. This catches invalid, catch-all, or role-based addresses that can hurt deliverability even with valid SPF.

SPF setup for Mailgun vs SendGrid: Key differences to watch

You're seeing an "SPF record IP4 not in range error" because you manually listed Mailgun or SendGrid IPs in your SPF record. Both use shared IP pools that rotate dynamically. You must use include:mailgun.org or include:spf.sendgrid.net—never hard-code individual IPs. This is a common mistake that breaks authentication and harms deliverability.

Why dynamic IPs make manual entries fail

Mailgun and SendGrid both operate on shared infrastructure. Your sending IP can change at any time. If you list static IPs in your SPF record, you'll get a validation error when the sending IP is outside the listed range. This triggers SPF fails and can land your emails in spam or cause bounces.

Industry-standard practices confirm this: the RFC 7208 specification for SPF requires include mechanisms for third-party services using shared IPs. Relying on static IPs violates this baseline and is why tools like RFC 7208 mandate dynamic mechanisms for sender alignment.

How to correctly configure SPF for both services

  • Use include:mailgun.org in your SPF record—never list Mailgun’s individual IPs.
  • For SendGrid, use include:spf.sendgrid.net—adding specific IPs will trigger a "not in range" error.
  • Keep only one include statement per service. Multiple includes are allowed but must not exceed the SPF limit of 10 lookups.
  • Test your SPF record with tools like MxToolbox to verify alignment before sending bulk emails.
  • If you manage multiple domains, ensure each one includes the correct service include statement.
  • Use your email verification tool to detect invalid addresses before sending—bad addresses can compound deliverability issues. Bulk list verification helps catch problems early.
Proper SPF setup isn’t about perfection—it’s about preventing common errors that derail sender reputation.

Double-checking your SPF record every time you add a new sender service is a small step that prevents big deliverability problems. Let MailTester’s integrations with SendGrid and Mailgun help you validate your setup with real-time checks before your campaign launches.

How to fix a misconfigured SPF record step-by-step

If you're getting an SPF record IP4 not in range error in Mailgun or SendGrid, the issue is likely a misconfigured SPF TXT record with outdated or hardcoded IP addresses. You need to remove those and replace the record with the correct include directive—v=spf1 include:spf.sendgrid.net ~all for SendGrid or v=spf1 include:mailgun.org ~all for Mailgun. Save the change, wait up to 48 hours for DNS propagation, and test delivery using a real-time verification tool.

  1. Log in to your domain’s DNS provider—Cloudflare, GoDaddy, AWS Route 53, or another service. You’ll need access to the DNS records for your domain (e.g., yourcompany.com).
  2. Find the SPF TXT record. Look for a record with type=TXT and name=yourdomain.com (or name=@@ or name=*). It usually starts with v=spf1.
  3. Remove any hardcoded IP addresses or outdated includes. Avoid entries like ip4:192.0.2.1 or include:oldprovider.com. These can conflict with modern email providers and trigger the “not in range” error.
  4. Replace the record with the service-specific include. For SendGrid: v=spf1 include:spf.sendgrid.net ~all. For Mailgun: v=spf1 include:mailgun.org ~all. This ensures your domain authorizes only approved sending sources.
  5. Save the change. DNS updates can take time to propagate. The change may take up to 48 hours, though in practice it’s often faster.
  6. Test delivery immediately using a real-time verification API or inbox placement tool. This verifies the fix and confirms deliverability. Use MailTester’s email checker to validate individual addresses before sending.

Why SPF matters

SPF (Sender Policy Framework) is an industry-standard way to verify that emails sent from your domain come from an authorized server. According to RFC 7208, SPF records must be precise and not include conflicting or outdated entries. Misconfigurations are a top cause of email rejection, especially in platforms like Mailgun and SendGrid.

Check your work

After updating the SPF record, use tools like MXToolbox or Spamhaus to verify that your record resolves correctly. A single incorrect syntax, like a missing space or extra character, can break the entire policy.

Why IP4 not in range is more common than you think

Many users see the "IP4 not in range" error in Mailgun or SendGrid not because their IP is misconfigured, but because they’re applying static IP rules to dynamic pools. These services don’t assign fixed IPs—you’re using a shared pool, so including specific IP4 ranges in SPF is pointless and triggers the error. This isn’t a misconfiguration; it’s a misunderstanding of how modern email senders work.

Dynamic IPs confuse SPF logic

You might think you need to list every IP your service uses in SPF, but Mailgun and SendGrid rotate IPs across thousands of servers. Trying to lock down specific IPv4 ranges in your SPF record is like building a fence around a moving train. The SPF standard expects static, predictable IPs—and when it finds a dynamic pool, it flags any exact IP range as out of scope.

Even if you get the syntax right, the record breaks the moment an IP shifts, which happens daily. This isn’t a flaw in your setup. It’s a mismatch between legacy SPF design and modern delivery infrastructure.

Auto-generated records often miss the point

Tools that generate SPF records based on your domain’s current setup often don’t know you’re using Mailgun or SendGrid. They pull in your old server IPs or internal network ranges without excluding them. You end up with a record like v=spf1 ip4:192.168.1.1 include:mailgun.org ~all, which fails because 192.168.1.1 is never used by Mailgun. RFC 7208 explicitly allows this kind of mismatch—it’s meant to prevent abuse—but it still breaks deliverability.

Even worse, some tools auto-include old hosting providers, like old AWS or legacy data centers, which never sent email for your domain. These false inclusions can degrade reputation or cause SPF failures.

Legacy SPF records linger like ghosts

If your site was hosted on a static VPS years ago, that SPF record might still be active. You may have migrated to Mailgun, but forgot to update the DNS. If your old record includes IP ranges from a server you no longer own, any email from Mailgun gets rejected as "out of range" by receivers checking your SPF.

That old record doesn’t go away. It stays in DNS until you remove it. And until then, your deliverability suffers. Check your SPF with tools like MxToolbox—it shows every mechanism in your record, including any legacy includes.

Let’s fix this: verify your list before sending. Use a tool that checks both syntax and real-world delivery. See if an email address is valid, if the domain has active SPF, and if the record’s structure works. Bulk list verification catches these issues before you send.

You can catch SPF alignment errors—like an IP4 not in range—before they cause bounces or spam placement by verifying email addresses and their domain policies in real time. MailTester checks deliverability and SPF configuration together, reducing costly misconfigurations in Mailgun, SendGrid, or other platforms. With 98.9% accuracy, it flags risky domains, catch-alls, and flawed SPF setups before you send.

Real-time validation catches SPF issues before they block delivery

When you send via Mailgun or SendGrid, SPF alignment isn’t just a technical detail—it’s a gatekeeper. If your sending IP isn’t in the range specified in the domain’s SPF record, messages get rejected. MailTester’s real-time API checks whether an email is valid and whether your SPF policy aligns with your sending infrastructure. It doesn’t just say “valid”—it confirms whether the domain’s SPF allows your outbound IP.

For example, if your SendGrid IP is 203.0.113.25 but the domain’s SPF record only allows 203.0.113.1–10, MailTester flags that gap. No guesswork, no wasted sends. This is how you avoid the “spf record ip4 not in range error” before it shows up in delivery logs or spam reports. Use the real-time verification API to embed this check directly into your send workflow.

Bulk testing prevents widespread delivery failure from misconfigured policies

Running a campaign with 50,000 addresses? A single misaligned SPF setup can tank your sender reputation. MailTester’s bulk verification scans entire lists upfront. It identifies invalid addresses, catch-all domains (which may accept any email but aren’t reliable), and domains with risky or inconsistent SPF records.

For instance, if a recipient domain has a wildcard SPF record or a conflicting DMARC policy, MailTester flags it early. This lets you clean your list or adjust your sending strategy. Common red flags—like an SPF record with too many mechanisms or missing include directives—are caught during inbox placement tests. These aren’t just warnings; they’re indicators that your emails may fail delivery under real-world conditions.

SPF errors aren’t isolated. They compound: one misconfigured domain can hurt sender reputation, increasing the risk of entire batches being filtered. MailTester’s inbox placement testing simulates delivery across major inboxes and includes SPF alignment validation. It shows you where your messages will land—and why. This isn’t about theory; it’s about real-world deliverability. As the SPF RFC makes clear, proper alignment is essential for sender authentication. Use inbox placement testing to verify your full setup before launch.

Best practices for maintaining SPF consistency across services

Fix SPF record errors in Mailgun or SendGrid by letting services define their own IP ranges via include: directives instead of hard-coding IPs. Never list individual IPs from third-party platforms directly in your SPF record. Always use approved include: statements like include:sendgrid.net or include:mailgun.org, and keep the total DNS lookups under 10 to prevent failures. Use tools like MxToolbox or DNSViz to validate SPF records regularly, and test real-world delivery with inbox-placement testing after changes. RFC 7208 specifies that SPF lookups must remain under 10 to avoid rejection.

Key controls for SPF reliability

  • Never hard-code IP addresses from Mailgun, SendGrid, or other email services in your SPF record. Their IPs change frequently, and hard-coding them breaks alignment.
  • Use only include: statements for trusted, officially documented services. For example, include include:sendgrid.net or include:mailgun.org only—never add private or unverified domains.
  • Limit your SPF record to fewer than 10 DNS lookups. Each include:, ip4:, or exists: directive counts as one lookup; exceeding 10 causes SPF to fail.
  • Monitor SPF changes with DNS monitoring tools like MxToolbox or DNSViz to catch unintended updates or misconfigurations before they impact delivery.
  • After any SPF change, test your delivery path using a real inbox placement tool. This shows whether your emails reach inboxes or are flagged as spam, even if SPF passes in theory.

Verification and testing to prevent misfires

Even with a technically correct SPF record, delivery can still fail due to broader email health issues. Use tools that simulate real sending environments, including header checks, spam score analysis, and inbox placement tracking. Let’s say you update your SPF to include a new service—you should verify the full flow: DNS, authentication, and final delivery. Test your email in actual inboxes before sending to a large list. This catches issues like missing DKIM, poor sender reputation, or content triggers that SPF alone cannot detect.

What to do if the SPF error persists after correction

If your SPF record shows “IP4 not in range” in Mailgun or SendGrid despite updates, wait at least 30 minutes—some DNS resolvers take up to 48 hours to refresh. Use MailTester’s inbox placement test to send a real message to known inboxes and confirm delivery. Check if your sending domain or IP appears on blocklists like Spamhaus, and ensure your SPF record is authoritative, not overridden by a subdomain policy. Inspect message headers from delivered or bounced emails to find the exact SPF failure reason in the trace.

Verify DNS propagation and delivery

  1. Wait for DNS propagation. After updating your SPF record, DNS changes may take time to propagate across the internet. Some resolvers cache records for up to 48 hours, so immediate failure reports can be misleading. Let at least 30 minutes pass before re-testing.
  2. Use MailTester’s inbox placement test. Send a real message to inboxes like Gmail, Outlook, and Yahoo using a verified domain. This test confirms if your messages reach the inbox or are rejected by DMARC or SPF policy checks. It also reveals delivery status and possible blocklist matches. Test your inbox placement.
  3. Check blocklist status. A sending domain or IP might be listed on a real-time blocklist such as Spamhaus. Use Spamhaus' lookup tool or MxToolbox to verify. Being listed can cause SPF validation to fail even if the record is technically correct.

Validate SPF configuration and tracing

  1. Confirm SPF is authoritative. Ensure the SPF record is defined at the root domain level and not overridden by a subdomain policy. Subdomain SPF records don’t affect the parent domain. Use your DNS provider’s interface or a tool like MxToolbox’s SPF checker to audit the full record.
  2. Inspect message headers. If a message is sent or rejected, retrieve its full headers. Look for lines like “Received-SPF: fail (reason=...)” or “SPF failed for” to see the exact failure type: is it IP out of range, or a mechanism mismatch? This reveals whether the error is policy-related or syntax-based.
  3. Revalidate with the real environment. After fixing the record, don’t rely on simulated checks alone. Use MailTester’s API to programmatically validate lists before sending, or test single addresses with the email checker to catch issues early.

The bottom line: SPF errors are fixable — and preventable

The 'IP4 not in range' error in Mailgun or SendGrid isn’t the service’s fault. It’s a signal that your domain’s SPF record doesn’t include the current IP ranges used by the platform. This misalignment breaks authentication and harms deliverability.

Fix the root cause, not the symptom

SPF policies must reflect your actual sending infrastructure. If your provider uses dynamic IPs or cloud-based delivery, your SPF record needs to account for that — either by using include mechanisms or adjusting the scope. Static records won’t work long-term.

Correct SPF setup is not optional. It’s a baseline requirement for inbox placement. Poor alignment leads to bounces, quarantine, and reputation damage — all avoidable with proper configuration.

Prevention starts before you send. Use a real-time verification tool like MailTester to catch invalid, catch-all, or misconfigured addresses before they enter your pipeline. This stops SPF errors from being a symptom of deeper issues — instead, they become a warning you can act on.

Sources

Keep reading

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

Frequently asked questions

Does SPF need to include every IP address used for sending?

No. SPF includes only the services you use (e.g. include:spf.sendgrid.net), not individual IPs. Static IP entries will fail if IPs rotate.

Can I use multiple SPF records?

No. Only one SPF record per domain is allowed. Multiple records cause validation failure. Combine all mechanisms into one TXT record.

How often should I check my SPF record?

Check after any DNS change, after switching email providers, or when sending volume increases. Monthly validation improves reliability.

What happens if I set SPF to fail instead of ~all?

It may cause legitimate emails to fail delivery if the sender IP isn’t in the list. Use ~all (soft fail) during testing and ~all or -all in production based on risk tolerance.

Does including a sending service always fix the IP4 error?

Yes, if the include statement is correct. For Mailgun or SendGrid, use include:mailgun.org or include:spf.sendgrid.net respectively.

Can a catch-all email cause SPF errors?

No. Catch-all accounts do not affect SPF. The error relates to sender IP alignment, not inbox handling.

How long does SPF DNS take to propagate?

Typically 5 to 30 minutes, but can take up to 48 hours depending on TTL and DNS resolver caching.

What tools can check my SPF record?

Use MXToolbox, Google Admin Toolbox, or MailTester’s inbox placement test to validate SPF alignment and detect errors in real time.

Is SPF still required with DMARC and DKIM?

Yes. SPF, DKIM, and DMARC work together. SPF validates the sending IP; DKIM validates message integrity; DMARC enforces policy. All three improve deliverability.

Why do I get the SPF error only on some domains?

Each domain has its own SPF record. A misconfigured record on one subdomain won’t break global delivery, but it may fail for messages sent from that domain.

Can I use MailTester to verify SPF records?

Yes. MailTester’s real-time API and inbox placement tests detect SPF misalignment during actual delivery tests, identifying configuration issues before sending.

Is there a limit to how many include statements I can use in SPF?

Yes. A maximum of 10 DNS lookups is allowed. Exceeding this causes SPF to fail. Use include statements wisely and avoid nesting.