SPF Record Example with Include and IP4

Why Your SPF Record Matters for Gmail Inbox Placement

You send a perfectly crafted email. The copy is on point. The timing is right. But it never reaches the inbox. It vanishes—silent, unexplained. Your deliverability is being blocked not by content, but by a single line of DNS configuration: your SPF record.

For Gmail, SPF isn’t optional. It’s a gatekeeper. If your SPF record is malformed—especially with incorrect use of mechanisms like ip4 or include—Gmail may reject your email entirely, flag it as spam, or ignore it. Even one misplaced directive can break deliverability, no matter how clean your message.

This guide walks you through building a correct SPF record using include and ip4 mechanisms specifically for Gmail. We’ll show the exact syntax, why it works, and how it’s validated in real-world testing—not theory, not guesswork.

Key takeaways

SPF records with improperly configured ip4 or include mechanisms can cause Gmail to reject emails, even with perfect content.
Gmail requires strict SPF alignment, and a single syntax error in the record (like duplicate mechanisms) may result in a hard fail.
The correct SPF record example using include and ip4 ensures Gmail checks pass, directly improving inbox placement for bulk senders.

What Does 'SPF Record Example with Include and IP4' Mean?

You use an SPF record with ip4 and include mechanisms to specify which IP addresses and third-party services (like SendGrid or Mailchimp) are authorized to send email from your domain. The ip4 mechanism lists individual IPv4 addresses, while include allows you to reference another domain’s SPF policy—useful when outsourcing email sending. This setup helps prevent spoofing and improves deliverability, especially with Gmail.

How SPF Works: The Basics

SPF is a DNS record that tells receiving mail servers which senders are allowed to use your domain. Without it, spammers could forge your domain in emails, harming your reputation. When a recipient server receives an email, it checks the SPF record to confirm the sending server is listed as authorized.

You can think of SPF as a digital permission slip. If the sending IP isn’t in the list, the email may be marked as suspicious or rejected, even if it’s legitimate. Proper setup doesn’t just block fraud—it increases the chance your emails land in the inbox.

Breaking Down ip4 and include

The ip4 mechanism is used to add specific IPv4 addresses. For example, ip4:192.0.2.1 authorizes that single IP to send mail. If you manage your own mail server, you’ll likely need this. But it can become hard to manage if you use multiple services or have dynamic IPs.

That’s where include comes in. It lets you reference another domain’s SPF record—e.g., include:sendgrid.net—so you don’t have to manually track SendGrid’s IP pool. This is a common practice when using email marketing platforms, and it keeps your SPF record clean.

Because SPF has a limit of 10 DNS lookups (including includes), overusing include can cause problems. You must balance convenience with technical constraints. Always test your record using tools like MxToolbox or RFC 7208 to ensure it’s valid and doesn’t exceed the limit.

Once your SPF record is correctly formatted, you can use it alongside DKIM and DMARC for stronger authentication. This trio is what modern email providers like Gmail and Outlook rely on to determine whether to trust your messages. For a real-world check, see if your domain passes SPF checks before sending large mail campaigns with inbound placement testing.

SPF Record Example with Include and IP4 for Gmail Deliverability

Here’s a valid SPF record for Gmail deliverability: v=spf1 ip4:192.0.2.10 include:_spf.google.com include:mailchimp.com ~all. This authorizes a specific IP (192.0.2.10), Google’s outbound mail servers, and Mailchimp’s sending infrastructure. The ~all mechanism means a soft fail — Gmail accepts the message but flags it for scrutiny, helping avoid outright rejection while still applying strict checks.

The Mechanics Behind the Record

Start with the SPF version identifier: v=spf1 declares this is an SPF record version 1. This is required and must be present or the record is invalid.
Add your authorized IP address: ip4:192.0.2.10 explicitly allows outbound mail from that IPv4 address. Use your actual sending IP — missing or incorrect IPs are a common cause of delivery failures.
Include Google’s mail servers: include:_spf.google.com lets Gmail know you’re using Google’s infrastructure. This is essential when sending via Gmail or Google Workspace.
Include third-party senders: include:mailchimp.com grants permission for Mailchimp to send emails on your behalf. This is needed if you use Mailchimp for campaigns or transactional emails.
Set the default mechanism: ~all means "soft fail." Gmail receives the message but may apply additional spam filtering. Avoid -all (hard fail) unless you’re certain no other sender will use your domain.

Why This Matters for Gmail

Gmail uses SPF, DKIM, and DMARC to assess sender legitimacy. If your SPF record is missing, malformed, or overly strict, Gmail may mark your email as spam or skip the inbox entirely. Using ~all instead of -all offers a safety net during configuration. It allows messages through while still enabling Gmail to apply reputation-based filtering.

According to industry standards, SPF failures are a leading cause of email rejection. The SPF specification (RFC 7208) defines how mechanisms are evaluated in sequence and how failures should be handled. Misconfigured SPF records — especially those with -all and missing includes — are frequently flagged by major providers.

Before sending bulk campaigns, verify every address in your list. Use tools like MailTester’s bulk verification to check for invalid, disposable, or risky addresses—ensuring your sending infrastructure stays clean and trusted.

How SPF Mechanisms Work Together: ip4 and include in Practice

You can use ip4 to authorize specific sending IPs and include to delegate trust to trusted third parties like Google or Mailchimp. For Gmail deliverability, combining include:_spf.google.com with your own ip4 entries ensures both your internal servers and Google’s outbound gateways are recognized. This layered approach prevents your mail from being flagged as suspicious due to unauthorized sources.

What Each Mechanism Does in Real-World SPF

ip4:192.0.2.10 grants permission to a single IP address to send on your domain’s behalf. If you manage your own mail server or use a dedicated outbound relay, this is the most precise way to allow it. It’s a straightforward, low-risk method when you control the sending infrastructure.

include:_spf.google.com is essential if you use Google Workspace. It tells receiving servers: “These messages are sent via Google’s infrastructure—trust them.” Without it, Gmail’s outbound systems won’t be recognized, leading to delivery failures even when you’re sending to Gmail addresses.

For services like Mailchimp, include:mailchimp.com gives their sending servers permission to send mail that appears to come from your domain. You must verify that your provider includes this, and if you use multiple ESPs, each needs its own include directive.

Order and Limitations: Avoiding Common Conflicts

SPF mechanisms are evaluated in the order they appear in your DNS record. Only the first 10 include directives are processed — any beyond that are ignored. This means if you have five ESPs, stacking them properly is critical.

Also, SPF doesn't allow multiple spf records. You must combine all mechanisms into one record using the include and ip4 syntax. Misconfigurations here — like duplicate records or using redirect when you need include — cause SPF failures. According to the IETF’s official specification, SPF validation is strict, and errors in ordering or structure result in a soft or hard fail.

Use MailTester’s email checker to validate individual addresses before sending, ensuring your SPF setup is working as intended and reducing bounce rates, especially when you’re testing delivery to Gmail accounts.

When auditing your domain’s setup, tools like MxToolbox can help verify DNS records in real time, highlighting syntax issues or missing components before they impact deliverability.

Common SPF Mistakes That Break Gmail Deliverability

You've likely heard that SPF helps Gmail trust your emails, but even a small misconfiguration—like stacking too many include statements or using all without a soft fail—can silently kill deliverability. Gmail relies on strict SPF evaluation, and errors at the DNS level often go unnoticed until your messages land in spam or vanish. Let’s fix the most common pitfalls that break Gmail’s trust.

SPF Record Overload: The 10-Include Limit

Using more than 10 include mechanisms in a single SPF record triggers a DNS lookup limit, causing the record to fail silently. Gmail will reject the message without a clear bounce reason.
Each include adds a DNS query. Exceeding the limit (10 is the RFC-recommended maximum) results in a permerror—a silent failure that harms sender reputation over time.
Instead of piling includes, use ip4 or ip6 for your own IP ranges. If you rely on third-party senders, verify their SPF includes are properly delegated and avoid chaining multiple includes.

Mistakes with All Mechanisms and Third-Party Senders

Using all (hard fail) in your SPF record blocks all unlisted sources. If you’re using HubSpot, Klaviyo, or SendGrid, this blocks their sending IPs unless explicitly included—leading to hard delivery failures.
Use ~all (soft fail) instead. It tells receivers like Gmail: "this is likely not your sender, but I’ll let it through anyway." This is Gmail’s preferred approach for flexible, scalable email sending.
Mixing third-party tools without proper delegation—like adding an include for a marketing tool without verifying its SPF scope—breaks the chain. Every sender must be explicitly authorized per your SPF, or you risk alignment failures.
If you’re unsure whether a sender is properly included, test your SPF with a real-time verifier. You can validate how Gmail treats your record before sending.

SPF isn’t just a checkbox. A broken record hurts deliverability at scale. Use tools like MailTester’s email checker to validate individual addresses and confirm your SPF alignment before sending to real users.

For teams managing bulk lists or complex setups, bulk verification helps detect invalid, catch-all, or suspicious addresses—many of which would trigger SPF checks when sent to. It’s not just about syntax; it’s about ensuring every address you send to can be trusted and delivered.

How to Test Your SPF Record Before Sending to Gmail

You can test your SPF record for Gmail deliverability by validating its syntax and mechanism count using tools like MxToolbox, then checking that it resolves correctly and stays under the 10-mechanism limit. After confirming syntax, send a test email via Gmail’s SMTP and inspect the message headers for authentication results to verify alignment and avoid bounces.

Validate SPF Syntax and Mechanism Count

Use a tool like MxToolbox to check your SPF record syntax. It will show if your record is valid and resolve all include directives. Invalid syntax or unresolved includes can cause email rejection.
Count every mechanism in your SPF record: ip4, ip6, include, all, exists, and ptr. Gmail and other receivers enforce the 10-mechanism limit set by RFC 7208 — exceeding it results in a soft fail or rejection.
Check that includes resolve to valid, compliant SPF records. Some third-party services (like SendGrid or AWS SES) use include directives that may themselves exceed the limit. If so, you may need to replace or consolidate them.

Test Real Email Delivery and Authentication

Send a test email from your verified domain directly through Gmail’s SMTP gateway (smtp.gmail.com), using your domain's authenticated credentials. This mirrors real-world delivery conditions.
After sending, open the email in Gmail and view the full message headers (click the three-dot menu → “Show original”). Look for the Authentication-Results section.
Check for spf=pass. If you see fail, softfail, or neutral, it means the receiving server did not verify your SPF record — likely due to an incorrect or overly complex setup.
If you're verifying a list of addresses, use MailTester’s bulk verification tool to detect invalid, catch-all, or risky addresses before sending. This reduces the impact of poor SPF alignment on your sender reputation.

How MailTester Validates SPF and Other Authentication Checks

You can’t rely on DNS syntax alone to guarantee Gmail deliverability. MailTester goes beyond checking if your SPF record uses include and ip4 mechanisms correctly—it simulates real email delivery to Gmail, Outlook, and other major inboxes. It tests whether your SPF, DKIM, and DMARC configurations actually pass during live delivery, not just in theory.

Real-World Validation, Not Just Syntax

Many tools check if your SPF record is formatted right. MailTester checks what happens when your message arrives in a real inbox. It sends test emails through your domain’s actual infrastructure and observes whether receivers like Gmail accept or reject them based on authentication. This means you'll see if your SPF record with include and ip4 mechanisms actually passes, fails, or results in a soft fail in practice.

For example, an SPF record with an include directive pointing to a third-party provider (like include:_spf.google.com) might pass DNS validation but still fail delivery if that include isn't properly configured or if the sender’s IP isn't authorized in the third-party’s policy. MailTester detects these issues in flight, not just in static checks.

Live Feedback from Actual Inboxes

Each test sends a real message to Gmail, Outlook, Yahoo, and others. You get to see how your authentication setup affects inbox placement—whether the message lands in the primary inbox, gets filtered to spam, or is blocked entirely. This isn’t just a mock-up. It’s a live validation that includes the full email path, from DNS to final inbox outcome.

MailTester’s inbox placement reports show exactly how your domains and IPs perform in practice, based on how real receivers react. This is critical because even a perfect SPF record can fail if DKIM alignment is off or DMARC policies are overly strict. The tool checks all three protocols together, because deliverability depends on their coordinated behavior, not isolated syntax.

For example, a DMARC policy set to reject will block messages that pass SPF but fail DKIM alignment. If the DKIM signature doesn’t match, even a technically correct SPF record won’t help. MailTester catches these mismatches before they cost you in engagement or sender reputation.

Learn how your domain performs today with a real-world test: run an inbox placement test and see how your email stack holds up. The feedback isn’t theoretical—it’s what real inboxes do with your messages.

While industry standards like RFC 7208 (SPF) and RFC 7672 (DMARC) define the rules, only real delivery tests like MailTester’s reveal whether your implementation works in practice. You can verify the technical correctness of your SPF record example with include and ip4 mechanisms, but only a live test tells you if Gmail actually accepts the message.

Real-World SPF Failures: What Happens When You Don’t Get It Right

If your SPF record doesn’t list every IP address or service you use to send email—like your ESP, marketing platform, or even your CRM—Gmail may reject messages with a 550 hard bounce or silently quarantine them, especially if you’re not using a properly configured include or ip4 mechanism. This breaks deliverability, hurts sender reputation, and can persist even with high-quality content.

When SPF Fails, Deliverability Breaks Down

Let’s say you send newsletters via SendGrid but forgot to add include:_spf.sendgrid.net in your SPF record. Even if your domain is otherwise clean, Gmail will see the sending IP as unapproved. The result? A 550 error in the SMTP response, meaning the message never reaches the inbox—no bounce notification, no feedback loop, just silence.

More insidiously, some providers like Gmail don’t always return a hard error. Instead, they place your message in the spam folder or delay delivery. Over time, repeated failures—even if not flagged as hard bounces—trigger algorithmic penalties, especially on long-term sending behavior.

Spam filters now evaluate entire email ecosystems, not just content. A missing or malformed SPF record is a signal of poor sender hygiene. According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), inconsistent authentication is one of the top red flags for email filtering systems.

Reputation Damage is Persistent and Hard to Recover

Each failed authentication attempt harms your sender reputation, a score that influences where your email lands. Even a few months of unauthenticated sending can reduce your inbox placement by 20–30%—a significant drop that affects open and click rates.

Beyond delivery, reputation impacts future relationships. ISPs like Gmail and Yahoo use long-term sender behavior to assess trust. If your domain has a history of SPF issues, you’ll face stricter filtering, higher verification thresholds, and longer delays on new IP registrations.

Don’t wait for bounces to appear. Use tools like MailTester’s real-time email checker to validate SPF configurations and test deliverability before sending to large lists. Even with clean content, a weak SPF record can sink your entire campaign.

Best Practices for Maintaining SPF as Your Email Infrastructure Grows

You should limit include to only trusted third-party email services, avoid stacking multiple include directives for minor tools, and regularly audit your SPF record as new senders join your stack. This keeps your SPF record under the 10 mechanism limit and reduces the risk of authentication failures that hurt deliverability with Gmail and other major inboxes.

Use include only for vetted, high-volume services

Use include only when integrating with well-managed, widely used email providers like SendGrid, Amazon SES, or Mailchimp — services that maintain strict infrastructure hygiene.
Never include random or niche tools. Each include adds a new lookup and increases the risk of exceeding SPF’s 10 mechanism limit.
When in doubt, verify the service’s reputation using tools like MXToolbox or Spamhaus to check for past abuse or blacklisting.

Prefer ip4 for low-traffic or internal senders

For internal tools, test environments, or low-volume senders, use ip4 to explicitly list IP addresses instead of include.
Using ip4 keeps your record more predictable and avoids unintended exposure from third-party infrastructure changes.
Let’s say you have a custom CRM that sends occasional transactional emails. Instead of adding include for a vague provider, specify its outbound IP directly with ip4.
For large-scale workflows, test SPF validity before deployment with an inbox placement tester to catch issues early.
Run a quarterly audit of your SPF record — especially after onboarding new tools, or when your email volume shifts.
Use RFC 7208 as a reference for syntax correctness and mechanism limitations.
Remember: the order of mechanisms matters. Put the most critical ones first.
When you’re unsure, simplify. A clean, minimal SPF with known, verified components performs better than a complex, poorly documented record.

You can prevent SPF-related delivery failures by verifying email addresses in bulk and checking SPF records in real time. MailTester identifies domains with missing, weak, or misconfigured SPF records before you send, reducing bounces and protecting your sender reputation. With 98.9% accuracy and no expiring credits, it gives you confidence in every send.

Bulk List Verification Flags SPF Weaknesses

When you run a bulk list through MailTester, it doesn’t just check if an address is valid—it checks the underlying domain’s SPF record. A domain without an SPF record, or one with a broken or overly permissive configuration, is flagged as high-risk. This is critical because senders without proper SPF are frequently blocked by major email providers like Gmail, even if the message itself is legitimate.

For example, an SPF record that includes include:_spf.google.com but omits your sending domain’s IP address creates a gap. MailTester spots these missing or ambiguous configurations, so you can clean your list before sending. You’re not guessing—there’s a clear signal that something’s off.

Real-Time API Checks SPF Before Every Send

With the MailTester real-time verification API, every email address is checked against current DNS records—including SPF—at the moment you send. This prevents one-off delivery failures caused by outdated or broken SPF policies.

For instance, a user might have changed their email provider recently, but the SPF record hasn’t updated. Sending to that address could fail if your system isn’t aware. The API checks all DMARC, SPF, and DKIM alignments in real time, so you know whether the domain is set up to receive mail from your origin.

SPF is not just a technical requirement—it’s a trust signal. According to RFC 7208, SPF is one of the core mechanisms for validating sender identity. Email providers use it heavily in filtering decisions. Using tools like MailTester ensures you're not just compliant, but proactive. For a deeper look at how email authentication works, see the official SPF specification or explore authentication best practices from Spamhaus.

Whether you’re sending newsletters via Mailchimp or transactional emails through SendGrid, integrating MailTester’s API or using their bulk verification service helps you maintain inbox placement and sender reputation. You can verify your list ahead of time or validate individual addresses on the fly. No credit expiration means you’re never locked into a short-term plan—all checks matter.

You don’t need to be an email security expert to use it. Just upload your list, get results, and fix issues before they cost you deliverability. See how it works: verify your list with MailTester.

Conclusion: SPF is Not Optional for Gmail Deliverability

Without a correctly structured SPF record using include and ip4 mechanisms, Gmail will reject your messages—even if your domain is otherwise trusted.

Even a syntactically valid SPF record can fail in practice due to misalignment, overloading, or configuration errors. Real-world testing is required to confirm delivery success.

MailTester gives you the tools to verify SPF alignment and test inbox placement before sending. Use real verification and deliverability checks to act on what your SPF record actually does.

Sources

Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)
After Gmail began requiring authentication for large senders, the number of unauthenticated messages Gmail users received plummeted by 75%. — Google (The Keyword blog) (2023)

Keep reading

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

Frequently asked questions

What happens if my SPF record exceeds 10 mechanisms?

Gmail and other receivers will treat it as invalid, which can result in delivery failures or spam marking, even if the record looks correct.

Can I use both include and ip4 in the same SPF record?

Yes — combining include and ip4 is standard practice when using third-party services and private servers.

Does Gmail check SPF records in real time?

Yes — Gmail evaluates SPF during the SMTP transaction, based on the sender’s DNS record at the time of delivery.

What does ~all mean in an SPF record?

It means 'soft fail' — the email is accepted but marked as suspicious, allowing further review by the receiving server.

How do I know if my SPF is working with Gmail?

Check message headers for 'Authentication-Results' — look for spf=pass, spf=softfail, or spf=fail.

Should I use a hard fail (all) or soft fail (~all) in SPF?

Use ~all for new domains or when using many third-party services. Hard fail (all) can block legitimate emails during misconfigurations.

Can I test SPF without sending actual emails?

DNS-level checks confirm syntax, but only real email delivery tests reveal how Gmail treats your record in practice.

How often should I audit my SPF record?

Review it quarterly or after onboarding new senders, especially when adding services like Klaviyo or HubSpot.

What is the role of DKIM if SPF fails?

DKIM provides cryptographic proof of authenticity, but SPF failures still lead to reduced inbox placement even if DKIM passes.

Can MailTester help me fix SPF issues?

Yes — it identifies domains with weak SPF, tests inbox placement, and integrates with tools like SendGrid and Mailchimp to validate delivery.

Do all major email providers check SPF the same way?

Most do, but interpretation of softfail vs fail can vary. Gmail generally allows softfail messages into inbox, others may not.

What is the maximum length of an SPF record?

SPF records should not exceed 255 characters per DNS TXT record, and multiple records should be combined into one.