How to Configure SPF with Include and IP4 for Better Email Authentication

Why SPF Configuration Matters for Deliverability in 2024

You send emails every day. Some get delivered, some don’t. You check your inbox, then your spam folder, then your bounce logs—only to find a pattern of rejections with no clear reason. Chances are, your SPF record isn’t set up to handle modern email infrastructure, and that’s costing you reach.

SPF is your email's digital fingerprint. It tells receiving servers whether a message came from an authorized source. Misconfigure it—even slightly—and you risk rejection, higher bounce rates, and a damaged sender reputation. In 2024, with more companies using third-party tools and shared IP pools, getting SPF right is not optional.

Setting up SPF with include and ip4 mechanisms isn’t just technical—it’s a direct lever for inbox placement. It ensures only your authorized servers, including partners and cloud senders, can send on your behalf, without triggering fraud alarms.

Key takeaways

• SPF errors in 2024 still cause up to 15% of delivery failures for organizations using multiple email services.
• Using include safely expands SPF coverage to trusted third parties without over-relying on hard-coded IPs.
• Combining ip4 with include allows precise, scalable control across multi-tenant infrastructure without violating SPF’s 10-lookup limit.

What Does SPF with Include and IP4 Actually Mean?

SPF with include and ip4 means you're using DNS records to explicitly authorize specific IPv4 addresses and other domains to send emails on your behalf. The ip4 mechanism lists exact IPv4 addresses allowed to send, while include lets you trust the SPF policies of third-party services like marketing platforms or hosting providers—keeping your domain’s authentication both strict and scalable.

How IP4 Defines Authorized Sending IPs

The ip4 mechanism is straightforward: it lists the IPv4 addresses that are permitted to send mail from your domain. For example, if your company uses a specific mail server with the IP 192.0.2.1, adding ip4:192.0.2.1 to your SPF record tells receivers this address is trustworthy.

Using ip4 ensures that only known, approved servers can send on your behalf. This prevents spoofing and improves inbox placement. If your mail server’s IP changes, you must update the SPF record—failure to do so may result in bounces or deliverability drops.

Why Include Lets You Trust Third-Party Services

When you use services like SendGrid, Mailchimp, or HubSpot, you're not sending directly from your own infrastructure. The include mechanism allows you to reference their SPF policies without copying them manually.

For instance, include:_spf.sendgrid.net means "treat any IP authorized by SendGrid as valid for my domain." This is essential because most email providers manage large pools of IPs across multiple data centers. Manually listing every IP would be impractical and error-prone.

While SPF checks are not foolproof—some malicious actors still bypass them—combining include with ip4 creates a layered defense. The combination ensures you’re not overly restrictive yet not too permissive. The IETF’s RFC 7208 outlines these mechanisms in detail, giving them broad industry support.

If you're verifying your domain’s authentication setup before sending to a large list, you can use MailTester’s email checker to validate how your SPF policy affects deliverability in real time.

How to Configure SPF with Include and ip4: A Step-by-Step Process

Set up SPF with include and ip4 by editing your domain’s DNS TXT record: start with v=spf1 include:_spf.google.com ip4:216.239.32.0/19 -all, then add include: for each third-party service (like your marketing platform) and ip4 for direct IP ranges using CIDR notation. Keep DNS lookups under 10 to avoid soft failures. Test with a lookup tool or MailTester’s real-time API.

Step-by-Step Configuration

1. Access your domain’s DNS management interface — log into your provider (Cloudflare, AWS Route 53, GoDaddy, etc.). SPF is managed via DNS TXT records, so ensure you have access to your domain’s DNS zone.
2. Locate the existing SPF TXT record — look for a TXT record with v=spf1 at the start. If it doesn’t exist, create a new one. If it does, you’ll modify it — never duplicate SPF records.
3. Start with a base policy — use v=spf1 include:_spf.google.com ip4:216.239.32.0/19 -all as a baseline if you're using Gmail/Google Workspace. Replace the domain in include:_spf.google.com with your own if you’re not on Google.
4. Add include directives for each service — if you use SendGrid, add include:sendgrid.net. For HubSpot, include:spf.hubspot.com. Each include adds a DNS lookup.
5. Use ip4 for direct IPs and ranges — for servers or IP blocks you control, use ip4:192.0.2.0/24. The /24 notation defines a block of 256 IPs. Use CIDR notation consistently — never specify individual IPs unless absolutely necessary.
6. Stay under 10 DNS lookups — SPF limits you to 10 DNS queries per policy. Too many include statements can trigger a soft fail. Check lookup count with tools like MXToolbox’s SPF Lookup, or RFC 7208 §5.6.
7. Test your configuration — use a DNS lookup tool or MailTester’s real-time email verification API to validate your SPF record and verify delivery readiness.

Common Mistakes and Fixes

Don’t use multiple SPF records—only one TXT record per domain, combined with include and ip4 directives. Avoid ~all unless you’re testing; use -all to enforce strict alignment. If you have complex setups, consider using a tool like SPF Analyzer (no affiliation, but widely used for debugging).

For ongoing validation, test individual addresses before sending with MailTester’s email checker, especially if you're managing a high-volume list. This lets you catch syntax errors or delivery risks before they harm your sender reputation.

SPF Mechanisms: What Each One Does (And When to Use It)

SPF is a DNS record that defines which servers are authorized to send email for your domain. The core mechanisms—v=spf1, ip4, include, a, mx, and all—each control a specific part of that authorization. You start with v=spf1, then add rules like ip4 for your mail server’s IP or include to trust another domain’s policy. Use -all to block unauthorized senders; ~all soft-fails them. Understanding each builds a stronger authentication foundation.

SPF Rule Breakdown: How They Work Together

Let’s walk through what each mechanism does and when you should use it—based on real-world email authentication standards set by RFC 7208 and adopted across major email providers.

The RFC 7208 documents the official SPF specification. It’s the definitive guide for how these mechanisms are defined and intended to be used. Following it ensures compatibility with major providers like Gmail and Outlook, which check SPF during delivery.

Let’s say you use a service like SendGrid but also have a small team sending from a known IP. Your SPF might look like: v=spf1 ip4:192.0.2.1 include:_spf.sendgrid.net -all. That’s clean, explicit, and safe.

Keep in mind: there’s a limit of 10 DNS lookups across all SPF mechanisms. Every include or a counts. Over-reliance on includes can break SPF if the chain gets too long. Use MailTester’s email checker to test your domains and catch issues before they hit send.

Common SPF Misconfigurations That Break Deliverability

You’re likely failing email authentication because your SPF record has too many nested include statements, exceeds 10 DNS lookups, or contains outdated domains. The result? Legitimate emails get rejected. You don’t need to overcomplicate it: keep your SPF record simple, test it before deployment, and avoid mixing multiple records or overusing -all.

1. Exceeding 10 DNS Lookups with Nested Includes

• Each include directive triggers a DNS query. Too many nested includes (e.g., include:example.com which itself includes include:provider.com which includes include:subprovider.com) quickly reach the 10-lookup limit defined in RFC 7208.
• Once exceeded, SPF evaluates to fail. Even if your mail server is correct, receivers will reject your messages.
• Check your record using tools like MXToolbox or dmarcanalyzer.com to verify lookup count before deploying.

2. Using -all Without Testing

• Setting -all means “reject anything not explicitly listed.” If you misconfigure or forget a service (like a CRM or transactional email provider), all mail from that source will fail SPF.
• Start with ~all (soft fail) during testing. It marks suspicious messages as potentially fraudulent but doesn’t block delivery, allowing you to observe real-world behavior.
• Only switch to -all after confirming every sending source is accounted for. Use MailTester’s email checker to test individual addresses in advance.

3. Including Outdated or Invalid Domains

• Old include directives to domains that no longer send email or have gone inactive create failures.
• Example: If you once used a third-party tool that changed ownership, but your SPF still includes their domain, that lookup fails — and may push you over the limit.
• Review and remove any includes from services no longer in use. Regular audits prevent silent failure chains.

4. Having Multiple SPF Records in DNS

• Only the first SPF record is processed by DNS resolvers. Any additional SPF records are ignored.
• Multiple records are not merged — they just conflict or cause confusion. This is a top reason for SPF failures during migration or in complex infrastructures.
• Combine all policies into a single DNS TXT record. For example, use v=spf1 include:provider.com ip4:192.0.2.0/24 -all instead of splitting across multiple records.

Why You Should Verify Your SPF Configuration With Real Email Tests

Even if your SPF record is correctly formatted in DNS, it doesn’t guarantee your emails will land in inboxes. Real-world filters evaluate your full authentication stack — SPF, DKIM, and DMARC — and even small misalignments can trigger rejection. You need live tests that simulate how actual mail servers validate your setup.

Spf Isn’t Enough — Alignment Matters

Spf checks are just one step. The receiving server also verifies DKIM signatures and DMARC policies. If your DMARC policy is set to "reject" but your DKIM fails, or your SPF aligns but your DKIM doesn’t, your email gets flagged — even with a technically correct SPF record.

For example, if you use DMARC's alignment requirements, both the SPF and DKIM domains must match the "From" address. A mismatch here, even with valid SPF, can result in your email being quarantined or rejected.

Real-World Testing Confirms What DNS Doesn’t

DNS records can be valid but still misconfigured in practice. A record that passes a syntax check might still reference outdated IP ranges or fail during a handshake with real mail servers.

This is why MailTester’s inbox-placement testing is essential. It doesn’t just validate your SPF setup — it simulates how major providers like Gmail, Outlook, and Yahoo actually assess your full authentication chain. With 98.9% accuracy, it identifies hidden flaws that syntax-checking tools miss.

Use it to test your entire email flow before sending to real users. See how your messages land — in inbox, spam, or rejected — using actual recipient infrastructure, not just theoretical checks.

Let’s say you’ve set up SPF with include:_spf.google.com and ip4:192.0.2.1. Your record passes a public DNS check, but MailTester’s inbox tester shows your email gets blocked by Gmail due to a DKIM alignment issue. That’s the kind of insight that prevents delivery failures you’d never catch otherwise.

Run inbox tests before launch or bulk campaigns — it’s how you verify your full sender stack works in production conditions. You can test individual addresses or run bulk checks using our inbox placement tool or integrate verification into your workflow with our API.

Using MailTester to Validate SPF and Test Deliverability

You can validate your SPF policy in real time using MailTester’s API and test how your messages land across Gmail, Outlook, and Yahoo inboxes. Combine SPF checks with DMARC and DKIM alignment to catch issues before sending. Integrate directly with SendGrid, Mailchimp, or Klaviyo to clean lists automatically.

Validate SPF and catch alignment issues before sending

• Use MailTester’s real-time API to check your SPF record with include and ip4 entries — no need to guess if they’re parsed correctly.
• Run inbox-placement tests to see exactly how your email appears in real user inboxes across Gmail, Outlook, and Yahoo, not just in spam traps.
• Check SPF alignment with DKIM and DMARC in a single test to ensure your domain’s authentication chain holds — a misaligned DKIM or missing DMARC record can break deliverability.
• Test the complete chain: a valid SPF policy is not enough. If DKIM signs with a different domain, or DMARC alignment fails, your email may still be flagged as suspicious.

Automate verification and avoid delivery failures

• Connect MailTester to SendGrid, Mailchimp, or Klaviyo to automatically check each email address against spam traps, invalid formats, and catch-all domains before sends.
• Use the bulk verification tool to scan entire lists for invalid or risky addresses — especially important when using third-party data or older contact lists.
• See why messages fail: MailTester reports not just “bounced,” but whether it’s due to non-existent mailboxes, greylisting, or policy rejections.
• Monitor sender reputation health with real-world testing — unlike synthetic tools, MailTester sends to actual inboxes, giving you a true picture of deliverability.

Authentication is only as strong as its weakest link. Even a single misconfigured SPF include or missing ip4 can hurt your reputation. The industry standard is to use SPF’s include and ip4 mechanisms for accurate, scalable domain trust. Let your verification tool do the work — not just check syntax, but simulate real delivery. You already have the technical pieces. Use MailTester to validate them.

SPF, DKIM, and DMARC: How They Work Together to Secure Email

You can’t trust email authentication without all three: SPF checks the sending IP, DKIM verifies message content hasn’t changed, and DMARC combines both results to enforce policy and report failures. When they align, inbox filters trust your messages. If any one fails, delivery drops. Let’s break how each one works—and why they must work together.

SPF: The Sender’s IP Address Check

SPF (Sender Policy Framework) validates if a message came from an IP address authorized by the domain’s owner. You list approved IPs in a DNS TXT record. For example, if you send emails through your server and also use a service like Mailchimp, you need both your IP and Mailchimp’s included in the record.

That’s where include and ip4 come in. include:_spf.google.com lets Gmail’s servers send for you. ip4:192.0.2.1 adds a specific IPv4 address. Too many includes or oversized records can trip SPF’s 10-include limit, which breaks validation. Use only what’s necessary.

DKIM and DMARC: Content Integrity and Policy Enforcement

DKIM signs emails with a cryptographic key. The receiving server checks that signature against your public key in DNS. If the content changes—any whitespace, a broken link, a header edit—the signature fails. This stops attackers from spoofing your email with altered text.

DMARC is the policy engine. It tells receivers what to do if SPF or DKIM fails: quarantine, reject, or allow with reporting. DMARC uses the results from SPF and DKIM to decide. Without both, DMARC can’t evaluate properly. It also collects reports so you can see why emails fail.

For example, if your SPF passes but DKIM fails, DMARC may still fail. That’s why you need both. You can’t skip one and expect success. Industry standards, like those from the IETF, define these protocols in RFC 7208 (DMARC), RFC 5446 (DKIM), and RFC 7208 (SPF).

Even with correct setup, misconfiguration or outdated records can harm deliverability. Tools like MailTester’s email checker help verify addresses and test authentication in real inboxes before sending. They spot issues like missing DKIM or malformed SPF records without waiting for bounces.

Proper configuration reduces inbox placement failure. It’s not a guarantee, but it’s required. If you’re sending to many addresses, use bulk list verification to clean your list and avoid sending to bad or non-existent addresses.

How to Maintain SPF as Your Email Infrastructure Evolves

SPF doesn't set and forget. As you add or switch email services — like marketing platforms, helpdesk tools, or payment gateways — you must update your SPF record to include new senders using include and ip4 tags. Omission leads to authentication failures, even if your email is legitimate. Keep checks ongoing: validate sender lists, review DMARC reports, and scrub invalid addresses.

Track and document every third-party sender

• Make a full inventory of all services that send emails on your behalf — from CRM tools to transactional systems.
• Check each provider’s SPF policy: some require include (e.g. include:_spf.sendgrid.net), others provide specific ip4 ranges or require a ~all softfail.
• Never assume a tool’s SPF policy is fixed. Updates or service changes can break inclusion silently.

Update SPF directives when services change

• When switching from one email service to another, remove the old include or ip4 directive before adding the new one.
• Test new configurations by sending a single message to a real inbox and checking its headers with tools like MxToolbox or RFC 7208, Section 5.4.
• Use MailTester’s bulk verification to scan your mailing list before sending and catch invalid or risky addresses that could harm your sender reputation.
• Review DMARC reports (typically sent as a weekly .zip file) to detect unauthorized senders. This helps catch misconfigurations before they cause inbox placement issues.
• Monitor the alignment between SPF, DKIM, and DMARC in your DMARC reports — misalignment is a common reason for delivery failure.

Even one outdated include directive can block legitimate email. Keep your SPF record lean, correct, and aligned with actual sender activity.

SPF is not a one-time setup. It evolves with your tools and workflows. Regular review, proactive monitoring, and list hygiene are the real guardrails. Use MailTester’s real-time verification API to validate addresses as you add them, and keep your deliverability on track.

Final Checklist: Is Your SPF Set Up Correctly?

You're using one SPF TXT record per domain, starting with v=spf1, including all sending sources via include and ip4, limiting DNS lookups to ten or fewer, ending with -all or ~all, and verifying alignment through inbox testing and domain monitoring. This setup prevents spoofing and improves deliverability. Let’s walk through the details.

SPF Record Structure & Syntax

• Only one SPF TXT record should exist for your domain. Multiple records cause validation failures.
• The record must begin with v=spf1 — a required identifier for SPF parsing.
• Use include for third-party services (e.g., include:_spf.mailchimp.com) and ip4 or ip6 for specific IPs, such as ip4:192.0.2.0/24.
• Each include or ip4 counts toward the DNS lookup limit. Exceeding 10 lookups breaks SPF validation.

Policy & Verification

• End your record with -all (hard fail) for strict enforcement, or ~all (soft fail) to allow some flexibility.
• Test the full chain by sending a message from your domain using MailTester’s inbox-placement test to confirm SPF alignment in real inboxes.
• Use domain monitoring tools to detect misconfigurations or policy drift over time.
• Validate the record using public tools like RFC 7208 or MXToolbox’s SPF checker to catch syntax issues before deployment.

Even with correct syntax, SPF can fail if the sender’s IP isn’t listed or the include chains are too deep. Use the MailTester email checker to spot issues in individual addresses before sending, especially when building mailing lists.

Conclusion: Secure Email Starts With Correct SPF Configuration

Proper SPF configuration using include and ip4 ensures your emails are authenticated and trusted by receiving servers. Skipping or misconfiguring these elements opens the door to delivery failures and reputation damage.

A single syntax error or outdated entry can trigger rejection, even if all other authentication methods are correct. This makes ongoing validation essential—proof of correctness is not the same as proof of working.

Tools like MailTester do not just check syntax; they test your SPF record in real-world conditions, confirming it works with actual mail servers. Regular verification is required as infrastructure evolves—new IPs, third-party services, or migrated domains can break your existing setup without warning.

Sources

• DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• SPF Include Chain Depth Over 10 Levels Causes Email Rejection
• Best Practices for Email Verification Systems to Handle DNS Load Spikes During SPF Checks
• SPF Include Failure Due to Cached DNS Responses in 2026
• Fix DMARC Alignment Failure with Multiple From Headers in 2026

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

Frequently asked questions

What does ip4 mean in an SPF record?

ip4 specifies a single IPv4 address or range authorized to send email on behalf of the domain. It is used when you have a known IP address that sends mail.

Can I use include more than once in an SPF record?

Yes, but each include triggers a DNS lookup. Using more than 10 can cause SPF validation to fail due to lookup limits.

What happens if SPF fails during email delivery?

The receiving server may reject the message, mark it as spam, or accept it with a soft fail, depending on the policy set by the domain.

Does SPF work for all email services?

SPF applies to any sender that uses the domain in the From or Return-Path header. It’s effective across email platforms like Gmail, Outlook, and others.

How do I check my SPF record using DNS?

Use tools like mxtoolbox.com or dig spf.domain.com to query your DNS TXT record and validate the configuration.

Why is DMARC important if SPF is already configured?

DMARC uses SPF and DKIM results to enforce policies and provide fraud reporting. It provides visibility into authentication failures and blocks unauthorized senders.

Can I have multiple SPF records in DNS?

No. Multiple SPF records cause DNS parsing errors. Only one SPF TXT record should exist per domain.

How often should I audit my SPF configuration?

Audit SPF every time you add a new email sender or switch providers. Monthly checks help maintain consistency and security.

What’s the difference between -all and ~all in SPF?

-all means reject all emails not covered by the policy. ~all means treat unverified sources as a soft fail, which is less strict but more forgiving.

How can MailTester help with SPF setup?

MailTester’s real-time API and inbox-placement test verify your SPF configuration along with DKIM and DMARC, ensuring full authentication compliance before sending.