Why SPF Configuration Matters When You Have Both IPv4 and IPv6 A Records

You’ve set up both IPv4 and IPv6 A records for your mail server. Good. Modern infrastructure demands it. But if your SPF record only includes IPv4 addresses, your emails are vulnerable—even if everything else looks correct.

SPF checks sender authorization at the IP level, not the protocol level. That means both IPv4 and IPv6 addresses used to send mail must be explicitly listed. One missing, and your messages may fail authentication without warning—leading to bounces, poor inbox placement, or reputation damage.

This is why how to configure SPF for domains with separate IPv4 and IPv6 A records isn't a minor detail. It's a foundation of deliverability. Ignoring it risks what you’ve built with your email campaigns.

Key takeaways

  • SPF validates senders by IP address, not by protocol, so both IPv4 and IPv6 addresses used to send mail must be listed in the SPF record.
  • Excluding IPv6 addresses from SPF, even when properly routed, can cause authentication failures and lower deliverability.
  • SPF records must include both A records (if used) and any associated IPv4 and IPv6 addresses to avoid blocking legitimate email.

How SPF Handles IPv4 and IPv6 Records: The Technical Reality

You must include both ip4 and ip6 mechanisms in your SPF record if your domain resolves to both IPv4 and IPv6 addresses. SPF treats each protocol independently: ip4 only covers IPv4, ip6 only covers IPv6. Omitting one means valid sending IPs get blocked, even if they’re legitimate. This affects deliverability — especially for modern hosts that support both protocols.

SPF Mechanisms: IPv4 and IPv6 Are Not Interchangeable

SPF uses the ip4 and ip6 mechanisms to explicitly reference IP addresses. The ip4 mechanism applies only to IPv4 addresses; the ip6 mechanism applies only to IPv6 addresses. There’s no automatic fallback or cross-protocol matching. If you're sending from an IPv6-only server, then ip6 is required. If your mail server uses IPv4, ip4 is needed.

Let’s say your domain resolves to both 192.0.2.1 (IPv4) and 2001:db8::1 (IPv6). Your SPF record must include both ip4:192.0.2.1 and ip6:2001:db8::1. If you only add the IPv4 entry, IPv6-sending attempts will fail SPF validation — even if the IP is correct. This leads to hard bounces or delivery delays.

Building a Correct SPF Record with Dual Stack Support

When configuring SPF for dual-stack setups, list both mechanisms in a single record. Example: v=spf1 ip4:192.0.2.1 ip6:2001:db8::1 include:_spf.example.com -all. This ensures all valid sending IPs, regardless of protocol, pass validation.

Remember: SPF does not evaluate IP version at runtime — it checks against the exact mechanism used in the record. If a server uses IPv6 but your record only has ip4, the sender is rejected. This is a common misstep when transitioning to IPv6, especially in large organizations with mixed infrastructure.

As documented in RFC 7208, SPF validation is strict about mechanism matching. Misconfigurations here aren't subtle — they cause failed delivery or blacklisting. The protocol was designed to be precise, not forgiving.

For teams managing large email lists, verifying your SPF configuration across all sending IPs is critical. Use tools that test real delivery paths and catch issues before they impact campaigns. MailTester’s inbox placement tester checks how your messages land across major email providers — including IPv6-specific delivery behavior — providing insight you can’t get from SPF validators alone.

How to Configure SPF for Both IPv4 and IPv6 A Records

You can include both IPv4 and IPv6 addresses in your SPF record using ip4: and ip6: mechanisms. List all authorized sending IPs from your provider, combine them in a single v=spf1 record, and stay under 255 characters. Use tools like MXToolbox's SPF checker to validate syntax and avoid exceeding the 10-DNS-query limit.

Step-by-step SPF Configuration

  1. Identify all outgoing IPs from your email service provider (ESP) or SMTP relay. These are the IPs authorized to send mail for your domain. Check your ESP’s documentation or control panel — some providers publish this list. Without it, your SPF is incomplete.
  2. Determine IP version. IPv4 addresses are 32-bit (e.g. 192.0.2.1), IPv6 addresses are 128-bit (e.g. 2001:0db8::1). You can identify them by format — colons indicate IPv6. Mixtures are common in modern infrastructure.
  3. Build the SPF record with both ip4: and ip6: mechanisms. For example: v=spf1 ip4:192.0.2.1 ip6:2001:0db8::1 include:_spf.yourprovider.com -all. This defines all trusted sources.
  4. Respect DNS limits. SPF records must be under 255 characters and no more than 10 DNS lookups (including includes). If you exceed either, your record fails to validate. Avoid adding unnecessary includes or overly long lists.
  5. Test the record with a real validator. MXToolbox or RFC 7208 (the SPF standard) provide authoritative testing guidelines. A syntax error here can cause legitimate mail to get rejected.

Common Pitfalls to Avoid

  • Do not use ip4 for IPv6 addresses — they’re invalid in SPF. Similarly, never use ip6 with IPv4 addresses.
  • Do not rely solely on include: if you have public IPs. You must also include the actual ip4: and ip6: entries.
  • Check your record after any change. DNS propagation can take up to 48 hours; test again once it's live.

Once configured, verify your email deliverability. You can test inbox placement directly with MailTester’s Inbox Placement tool to see how your messages perform across major providers.

Common Mistakes to Avoid When Setting SPF for Dual-IP Domains

You must use the correct mechanism—ip4 for IPv4, ip6 for IPv6—never mix them. Including third-party providers without IPv6 support breaks SPF checks. Overlapping mechanisms and incorrect all placement can cause rejection. SPF evaluates only the first all mechanism found, so place ~all or -all last. Never assume your provider supports both IP versions.

Incorrect IP Mechanism Usage

  • Using ip4 for an IPv6 address or ip6 for IPv4 is invalid and will be rejected by receiving mail servers.
  • IPv6 addresses in SPF records must be enclosed in square brackets and use the ip6 mechanism—e.g., ip6=[2001:db8::1/128].
  • Check your DNS TXT records using tools like MXToolbox or RFC 7208 to verify correct syntax and mechanism usage.

Third-Party and Configuration Pitfalls

  • Do not use include directives from third-party providers (e.g., SendGrid, Mailchimp) unless you confirm they support IPv6 in their SPF record.
  • Many providers only list IPv4 ranges. Including them in an IPv6-ready SPF can lead to a permanent failure if the receiving server requires IPv6 validity.
  • Overlapping or duplicate mechanisms (like multiple ip4 or include entries) can trigger evaluation errors. Use only one of each mechanism type unless explicitly allowed.
  • SPF evaluation stops at the first all mechanism. If you place ~all or -all early in the record, everything after is ignored—leading to unintended failures.
  • Always place ~all or -all at the very end of the record, after all other mechanisms.

Let’s be clear: SPF is evaluated left to right, and only the first all mechanism counts. If you’re testing or debugging, validate your record using a real-time tool like the MailTester email checker to catch syntax issues before they impact deliverability.

How to Verify Your SPF Record Is Correctly Authorized

You can verify your SPF record is correctly authorized by checking your DNS with a real tool like MxToolbox or dig, ensuring both ip4 and ip6 mechanisms are present and properly formatted. Then, test whether your sending IPs—both IPv4 and IPv6—are included in the evaluation chain using a validator that supports both protocols. Never rely on tools that only check IPv4; IPv6 must be tested separately, as misconfiguration here breaks deliverability for modern sending infrastructure.

Check Your DNS Record with Real Tools

Use a public DNS lookup service such as MxToolbox or the command-line dig tool to retrieve your domain’s full SPF record. Paste your domain name into the tool and look for the TXT record with the v=spf1 header. This step confirms the record is published and visible. Misconfigured or missing records are a common cause of email rejection, even if your sending setup appears correct.

Validate IPv4 and IPv6 Together

Your SPF record must explicitly include both ip4 and ip6 mechanisms for every IP you use to send emails. For example, a correct record might include ip4:198.51.100.1 and ip6:2001:db8::1. If you're using a service that only validates IPv4, it will miss problems with your IPv6 configuration—something that can silently cause emails to be blocked, especially on large ISPs and modern mail systems.

Let’s say you send from a server with both IPv4 and IPv6 addresses. If your SPF record is missing the ip6 entry, even if the IPv4 is correct, your emails will fail authentication. This is why you need a validator that evaluates both protocols in the same chain. RFC 7208 (the SPF specification) doesn’t favor one IP version over the other; both are valid and must be covered.

To be safe, test your record against multiple tools—ideally one that shows detailed evaluation results. Some advanced tools, like those in the RFC 7208 compliance suite, validate the full chain of mechanisms, including IPv6. You can use MailTester’s email checker to verify the technical validity of a sending address before deployment, reducing the risk of misconfiguration slipping through.

Why SPF Errors Can Still Occur Even With Correct Syntax

Even with perfectly valid SPF syntax, delivery failures happen because SPF is evaluated in context—by receivers that check alignment, record reachability, and overall sender reputation. A single malformed include, oversized record, or misaligned domain can invalidate the entire check, regardless of formatting. You can have correct syntax and still fail if the underlying infrastructure or sender history doesn’t meet receiver expectations.

Include Failures Break SPF Validation

SPF evaluation is recursive. If any include in your record points to a domain with a missing, malformed, or unreachable SPF record, the SPF check fails entirely. That’s intentional—mail providers treat unverifiable includes as a sign of poor configuration or abuse. Let’s say you include a third-party provider’s domain, but their DNS returns a syntax error. The entire evaluation stops, and your email may be rejected or flagged.

Some providers, like Google and Microsoft, enforce strict enforcement policies for such failures. They don’t just skip invalid includes—they treat them as a red flag for infrastructure instability. You can have correct syntax across your own record, but a single broken include still breaks everything. This is why validating your entire SPF chain—especially third-party includes—is critical.

Alignment, Reputation, and Delivery

SPF syntax doesn’t guarantee inbox placement. Even if your record passes syntax checks and resolves correctly, SPF alignment fails if the sending domain in the email doesn’t match the domain used in the SPF record. For example, sending from [email protected] but checking SPF against yourcompany.com will result in failure if the sender domain isn’t explicitly authorized.

Even when syntax and alignment are correct, poor sender reputation or signs of domain misuse (like spam complaints or sudden high-volume sending) can still trigger delivery blocks. Mail providers track long-term behavior. A newly set up domain with perfect SPF but no sender history or inconsistent engagement may be treated as high risk.

Use tools like bulk email verification or inbox placement testing to catch these hidden issues early. These tools test not just SPF syntax, but real-world deliverability, helping you identify whether a bounce is due to DNS issues or sender reputation problems. Real delivery success depends on more than just DNS—timing, engagement, content, and reputation all matter.

Handling Large SPF Records

SPF records have a limit of 256 characters for a single DNS lookup, and a maximum of 10 DNS lookups per evaluation. If your record includes many third-party services, or has lengthy domain lists, you risk hitting this limit. When you exceed it, the evaluation stops early, producing a softfail or fail—even if the syntax is correct.

Some providers enforce this strictly. Others will still accept large records if they’re structured properly (e.g., using include instead of ip4: for individual IPs). But even then, overuse of includes leads to lookup exhaustion. A record with 15 includes may pass in theory, but fail in practice because of chain failures.

For guidance on limits and best practices, refer to the official SPF specification in RFC 7208. Use tools that validate the full evaluation path, including remote DNS lookups. You can't trust what your DNS parser shows—you need to test how receivers see it.

SPF Best Practices for Dual-IP Environments

You can configure SPF for domains with both IPv4 and IPv6 A records by listing all sending IPs in your SPF record using the ip4: and ip6: mechanisms, but only if your email providers officially support IPv6. Use include sparingly and only with services verified to handle both protocols. Keep DNS lookups under 10, enforce strict alignment with -all, and avoid cluttering your record. A clean, stable SPF reduces misdeliveries and reputation risks.

Keep It Simple and Secure

  • Use ip4: and ip6: mechanisms explicitly for your sending servers’ IPv4 and IPv6 addresses to avoid ambiguity.
  • Only use include: for providers you trust and verify support IPv6. For example, major email platforms like Amazon SES or SendGrid document IPv6 support in their official documentation — check their AWS SES FAQs or SendGrid docs before adding them.
  • Limit your total DNS lookups to fewer than 10. Each include, redirect, or mx counts as one lookup. Over 10 breaks SPF validation.
  • Always end your SPF record with -all (hard fail), not ~all. Soft fails allow forged mail to pass, increasing spam risk.
  • Never duplicate or overlap mechanisms. Avoid mixing ip4: and ip6: with redundant include statements for the same provider.

Optimize for Stability and Scalability

  • Test your SPF record using tools like MXToolbox or OpenSPF.org before deployment.
  • Consistency across infrastructure is critical. Ensure all email-sending systems — including marketing, transactional, and support platforms — use the same SPF policy to prevent misalignment.
  • Monitor for changes: updating your IP range or switching providers requires a corresponding SPF update. Avoid long, complex records that are hard to maintain.
  • When in doubt, start with a minimal record: v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/32 -all and add include mechanisms as needed, testing carefully.
  • Use an email verification service like MailTester’s single address checker to validate email addresses before adding them to mailing lists that may trigger SPF issues.

How to Test SPF Configuration with Real Email Deliverability Tools

You can verify your SPF setup in real-world inbox conditions using tools like MailTester’s inbox-placement testing, which checks how your SPF record performs across major email providers in actual inboxes—not just technical validation. This reveals whether your SPF passes in Gmail, Yahoo, Outlook, and others, helping you catch configuration issues before they affect deliverability.

Run Inbox-Placement Tests to Validate SPF in Practice

SPF records are only as good as their real-world validation. Run a test through MailTester’s inbox-placement tool to send a message from your setup and observe how major providers accept or reject it. This simulates actual sending from your infrastructure, including any dual-stack IPv4 and IPv6 A records, showing whether your SPF correctly authorizes your sending IPs in practice.

Use MailTester’s inbox placement tester to check deliverability across Gmail, Yahoo, iCloud, and Microsoft Outlook. The tool uses real SMTP sessions—not just checks—so you see whether your SPF passes at the receiving end, where it matters most. If your domain uses separate IPv4 and IPv6 A records, this test confirms SPF still permits delivery despite the dual configuration.

Combine SPF Checks with DKIM and DMARC for Full Authentication Coverage

SPF alone is not enough. Authentication failures often stem from missing or misconfigured DKIM or DMARC records. Use MailTester’s bulk verification to validate the authentication status of multiple sending addresses at once. This checks whether SPF, DKIM, and DMARC are properly set up across the board.

Many bounces and delivery errors point to authentication issues rather than invalid addresses. For example, a “550 5.7.1” error from Gmail often means SPF or DKIM failed. By testing across all three mechanisms, you catch gaps early. DMARC reports, which require proper alignment and policy setup, help monitor long-term compliance—especially useful when managing multiple sending IPs across IPv4 and IPv6.

SPF authentication can technically fail even if your record is syntactically correct—especially when a domain has both IPv4 and IPv6 A records and those IPs are not explicitly listed in SPF. The SPF specification (RFC 7208) allows for both, but improper handling can still lead to rejection. Always test with real delivery tools to ensure compatibility.

MailTester’s Role in Validating SPF and Deliverability Health

You can use MailTester to catch SPF, DKIM, and DMARC misconfigurations before they harm your sender reputation. It performs real-time checks across major email providers and flags issues that cause bounces or inbox placement failures. With 98.9% accuracy, it helps you identify weak or failing records before sending campaigns, reducing the risk of deliverability drops. The API integrates into your workflows for automated domain and IP validation.

Real-Time Checks Across Major Providers

SPF errors aren’t always caught by simple DNS tools. You might have a technically valid record, but still face delivery issues due to alignment, policy conflicts, or overly aggressive spam filtering. MailTester goes beyond syntax checks to simulate actual delivery conditions across Gmail, Outlook, and others. It tests how your domain’s authentication setup holds up during real-world verification attempts.

Let’s say your domain has separate IPv4 and IPv6 A records. That’s common, but it can trigger SPF validation failure if your SPF record doesn’t properly reference both IP ranges or includes a mechanism like include that doesn’t cover all delivery paths. MailTester detects those edge cases—like a missing ipv6 entry in a record expecting it—before you send. It's not just validating the syntax; it's testing whether the configuration works in practice.

For a deeper look, SPF is defined in RFC 7208, which outlines how mechanisms like ip4 and ip6 are evaluated. But real-world delivery systems don’t follow RFCs in isolation—they check alignment, policy enforcement, and historical sender behavior. That’s where MailTester adds value: it combines technical compliance with deliverability performance.

Integrations and Automation for Scaled Verification

When you're onboarding new senders or cleaning large email lists, manual checks take too long. With MailTester’s API, you can verify domains and IPs in bulk during onboarding, ensuring that SPF is correctly set before sending. The same tooling works for list cleanups: identify invalid or risky addresses before you hit the send button.

Integrations with Mailchimp, SendGrid, HubSpot, and Klaviyo let you embed verification directly into your workflow. For example, you can automate inbox placement tests with the inbox placement tester to check if your campaign will land in the inbox—or the spam folder—before delivery.

For one-off checks, the email checker confirms whether an address is valid, has a catch-all setup, or is disposable. It also evaluates the sender’s reputation and risk profile. Whether you're validating a single address or a full list, MailTester helps you avoid the common pitfalls: bounces, sender reputation penalties, and blocked campaigns.

SPF and the Future of Email Authentication

As IPv6 adoption grows, SPF records that ignore IPv6 will become increasingly invalid. Modern email providers require full alignment across SPF, DKIM, and DMARC, not just for compliance but for inbox placement. Proactively testing and updating your configuration ensures long-term deliverability, especially as Gmail and Outlook enforce stricter policies.

IPv6 Is No Longer Optional

More than half of internet traffic now uses IPv6, and that number keeps rising. If your SPF record only lists IPv4 addresses, you’re leaving valid sending sources out of the authentication process. That means legitimate emails may fail SPF checks, leading to hard bounces or delivery to spam folders.

SPF's mechanism checks the IP of the sending server against the DNS record. If IPv6 addresses aren’t included and your server uses them, the check fails—even if the email is genuine. This is not a future concern. It’s happening now.

Authentication Must Be Aligned Across the Board

SPF alone isn’t enough. Even if SPF passes, you’ll still fail if DKIM doesn’t align or if DMARC policies are misconfigured. Gmail, Outlook, and other major providers use all three to authenticate senders. Failure in any one layer can cause outright blocking.

For example, DKIM signs the email content, proving it wasn’t altered. DMARC tells receiving servers what to do if SPF or DKIM fail—such as quarantining the message. Without alignment between these protocols, even a single mismatch triggers filters.

As email providers move toward stricter enforcement, relying on partial or out-of-date configurations is a risk. You’re not just protecting deliverability—you’re maintaining sender reputation.

Test Before You Send

Don’t wait for bounces to appear. Use real-world testing to validate your setup before full rollout. Tools like MailTester’s inbox placement tester simulate how your messages land in major inboxes, showing where authentication may be failing.

Even with correct records, issues like catch-all domains, disposable email providers, or greylisting can still interfere. That’s why verifying your email list—both for validity and deliverability—is not optional. MailTester’s bulk verification can catch invalid or risky addresses before they hurt your reputation.

Standards evolve. IPv6 is no longer experimental. The SPF record you wrote yesterday may already be outdated. Keep your DNS current, validate your configurations, and monitor results. That’s how you future-proof your email operations.

Conclusion: Secure, Reliable Email Starts with Correct SPF Setup

Domains with both IPv4 and IPv6 A records must explicitly include both ip4 and ip6 mechanisms in their SPF records. Omitting either or using incorrect syntax breaks authentication, leading to hard bounces or inbox filtering.

A single misconfigured mechanism can block email from legitimate senders, even when all other authentication methods are correct. This makes precise SPF setup non-negotiable for reliable delivery.

Use real-world testing tools like MailTester to validate SPF configurations across actual email environments. Testing catches issues before they impact your sender reputation and inbox placement.

Sources

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 doesn’t include IPv6 addresses?

Emails sent from IPv6 addresses will fail SPF authentication, leading to delivery failures or being marked as spam. Both IPv4 and IPv6 IPs must be explicitly included.

Can I use the same SPF record for IPv4 and IPv6 sending IPs?

Yes, as long as the record includes both `ip4` and `ip6` mechanisms. SPF evaluates all authorized IPs regardless of protocol.

How many DNS lookups can an SPF record make?

SPF records can make up to 10 DNS lookups. Exceeding this limit causes a PermError, so keep the record simple and avoid nested includes.

Do I need separate SPF records for IPv4 and IPv6?

No. A single SPF record with both `ip4` and `ip6` mechanisms is sufficient and recommended for dual-stack domains.

How do I check if my SPF record includes IPv6 correctly?

Use DNS lookup tools like MxToolbox or dig to retrieve your domain’s full SPF record. Verify `ip6:` mechanisms appear with correct IPv6 addresses.

Can I use `include` with IPv6-capable providers?

Yes, but only if the included record also supports IPv6. Failure to do so results in SPF failures even with correct syntax.

What does `~all` mean in an SPF record?

`~all` is a soft fail—messages from unauthorized IPs are accepted but marked as suspicious. Use `-all` for strict enforcement.

Why does my email fail SPF even with correct syntax?

Issues may stem from misaligned domains, failed include lookups, or high sender reputation scores. Combine SPF testing with DKIM and DMARC checks.

How can MailTester help with SPF and deliverability?

MailTester validates real-world deliverability across major providers, checks SPF, DKIM, and DMARC alignment, and helps clean lists before sending.

Do SPF issues affect all email providers equally?

No. Providers vary in their SPF enforcement policies. Gmail and Outlook are stricter; testing across multiple inboxes is essential.

Can I use MailTester for bulk list verification before sending?

Yes. MailTester offers bulk verification to filter out invalid, catch-all, or risky addresses, reducing bounces and protecting sender reputation.

Do purchased credits expire in MailTester?

No. Once purchased, credits never expire, enabling long-term list hygiene and verification workflows.