SPF 10 Lookup Limit Explained

Why does SPF 10 lookup limit matter for email deliverability?

You send transactional emails through Microsoft 365 and Google Workspace. Your SPF record is working—most of the time. Then, suddenly, some messages fail without a clear reason. You’re not alone.

SPF’s 10 DNS lookup limit is a silent disruptor. When your SPF record chains too many mechanisms or includes too many third-party services, DNS resolution stops after 10 lookups. This breaks SPF validation. Both Microsoft 365 and Google Workspace enforce this limit strictly—and when it’s exceeded, messages get delayed, rejected, or land in spam.

Think of SPF like a security checkpoint with a fixed number of identity verifiers. If you’ve got more third-party vendors than verifiers, the gate closes. That’s what happens when lookup limits are hit. The result? Broken deliveries, wasted sends, and tarnished sender reputation.

Key takeaways

SPF records fail to validate if DNS lookups exceed 10, leading to delivery failures in Microsoft 365 and Google Workspace.
Both platforms enforce the 10-lookup limit strictly—exceeding it causes soft or hard bounces.
Overly complex SPF records with multiple third-party vendors can trigger rejection even if the sender is legitimate.

What exactly is the SPF 10 lookup limit with Microsoft 365 and Google Workspace?

Both Microsoft 365 and Google Workspace enforce the RFC 7208 standard, which limits SPF evaluations to 10 DNS lookups per email. Each time your SPF record includes external domains via mechanisms like include: or redirect:, it counts toward that total. If the chain exceeds 10 lookups, the SPF check fails, and your emails risk being rejected or marked as spam.

How DNS lookups count in SPF evaluation

Let’s say your SPF record uses include:spf.example.com. That’s one lookup. If that record includes include:mail.example.org, that’s two. Every time a new domain is referenced and queried, the counter increases. You can quickly hit the limit with multiple nested includes, especially if you use third-party email providers, marketing platforms, or legacy infrastructure.

The key point is that lookups aren’t just for your domain—they include every external DNS record required to validate the full SPF chain. A single misconfigured include can trigger a failure even if your main server is correct.

Why this matters for email delivery

If your SPF record exceeds 10 lookups, the receiving server (like Outlook or Gmail) can’t validate your domain. In practice, that means your emails may be bounced, quarantined, or delivered to spam. Neither Microsoft nor Google will accept a failing SPF evaluation — it’s a hard gate.

You can test for this using tools like MxToolbox or RFC 7208, which define the exact behavior. The limit is consistent across all compliant mail systems, so it’s not specific to Microsoft or Google but they enforce it rigorously.

If you’re checking your domain’s SPF chain, you can verify it directly with a service like MailTester’s bulk verification. It checks your domain’s DNS records, including SPF lookup chains, and flags if you’re approaching or crossing the 10-lookup threshold.

Failing SPF isn’t always obvious. An email might appear to send fine until it hits Google’s or Microsoft’s filter. Once blocked, recovery is harder — reputation takes weeks to rebuild. Proactively auditing your SPF chain is the only way to avoid surprises at scale.

How do _spf.google.com and spf.protection.outlook.com lookups factor into the limit?

You're limited to 10 DNS lookups in an SPF record, and queries to _spf.google.com and spf.protection.outlook.com count toward that total—even if the result is cached. Both domains are used by Google Workspace and Microsoft 365 for SPF validation, so any include: statement pointing to them uses one of your 10 allowed lookups. If you include multiple third-party senders with their own SPF records, especially through chained includes, you quickly hit the limit.

Why These Domains Matter in SPF Chains

When you use include:spf.protection.outlook.com or include:_spf.google.com, the receiving mail server resolves that domain and checks the SPF record it returns. This resolution counts as one DNS lookup, regardless of whether the result is cached or not. That’s why even a single include: to these domains uses up a portion of your 10-lookup allowance.

Think about it: if you’re a business sending via both HubSpot and SendGrid, and both require a separate include: in your SPF record, each one eats a lookup. Add in your own include: for your domain’s SPF, plus any additional services, and you’ll hit 10 fast—especially if one or more of those domains themselves chain to others. The result? SPF validation fails, and your email gets rejected or marked as spam.

Use Cases That Push the Limit

Common scenarios include agencies managing multiple clients, e-commerce platforms using various transactional email services, or organizations using multiple marketing automation tools. Each new include: increases the risk of hitting the limit, especially if third-party providers use complex chains in their own SPF records.

For example, if you include include:_spf.google.com and that record itself includes include:thirdparty1.google.com, the receiving server must resolve both—even if the first is cached. Each step in the chain uses a lookup. This is why SPF best practices recommend consolidating sender identities and using a single, well-maintained SPF record.

Even if you think your record is clean, third-party services often include their own SPF records via include: tags. Without visibility into those chains, you risk exceeding the limit unknowingly. One way to catch this early: verify your entire email ecosystem with tools that analyze SPF chains and detect lookup exhaustion. For a real-time check on your sender setup, try MailTester’s inbox placement testing or bulk email verification to catch issues before they affect deliverability.

For deeper analysis, refer to the SPF specification in RFC 7208, Section 5.1, which defines how DNS lookups work in the SPF validation process. The limit is strict, and every include: must be accounted for.

What happens when an SPF record exceeds the 10-lookup limit?

When your SPF record exceeds the 10 DNS lookup limit—common with complex setups using multiple third-party services—receiving servers like Gmail and Outlook stop processing it after 10 lookups. This can result in a permerror or softfail if the record isn’t fully validated, even if the domain itself is legitimate. The message may still be delivered, but often ends up in spam or is delayed, hurting deliverability.

How receiving servers handle oversized SPF records

Both Microsoft 365 and Google Workspace enforce the SPF limit of 10 lookups, as defined in RFC 7208. If your SPF record includes mechanisms like include: pointing to other domains, each one counts as a lookup. Once the limit is reached, the server stops checking and applies the policy from the last valid mechanism it processed.

For example, if your record includes include:spf.prosender.com and that domain triggers multiple further includes, you can easily hit the limit before the validation completes. If the final policy is set to all:~all (softfail), the server may classify your message as suspicious—even if the SPF is technically valid elsewhere.

According to industry data from Return Path (now Validity) and Microsoft’s own documentation on email authentication, failure to complete SPF validation is a common reason for email to be filtered or delayed. This is especially common in email marketing or sales automation flows where multiple ESPs and senders are involved.

Consequences: delivery issues, spam flags, and reputation damage

Results of hitting the limit aren’t always immediate rejection—many servers deliver the message with a softfail. But even a softfail reduces your sender reputation over time. In practice, this leads to lower inbox placement rates, especially across major platforms like Gmail and Outlook.

For instance, a message that passes SPF in theory may still be flagged as spam when the receiving server detects incomplete validation during the authentication process. This isn’t just a technical quirk—it's a real signal that your sending setup isn’t fully compliant.

Let’s say you’re managing a large email list with multiple verification tools, landing pages, and CRM integrations. Each of those may require an include: in your SPF. Without careful tracking, it’s easy to exceed the limit silently.

Use the MailTester bulk verification tool to audit your sending domains and check for SPF configuration weaknesses. It checks authentication headers, detects oversized records, and flags potential issues before they impact deliverability.

How to test if your SPF record is hitting the 10-lookup limit

Run a DNS query with a tool like MXToolbox or MailTester’s built-in SPF checker to simulate your SPF evaluation. If the result shows 'lookup limit exceeded' or 'exceeded 10 DNS lookups', your SPF record is over the limit. You can also check DNS query logs during email sends to see how many records were queried — if it hits 10 or more, your SPF is likely causing delivery issues with Microsoft 365 or Google Workspace.

Use a tool to simulate SPF evaluation

Go to MXToolbox or use the SPF check feature in MailTester's API to test your SPF record.
Enter your domain and run a full SPF validation. Look for explicit messages like "lookup limit exceeded" or "exceeded 10 DNS lookups" in the result.
Real-time tools like this reflect how receiving mail servers (including Microsoft 365 and Google Workspace) evaluate your SPF record — exactly as they do at scale.

Check actual DNS query behavior during sends

Use your email service provider’s logging or monitoring tools to capture DNS queries during actual outbound sends.
Look for multiple TXT or SPF record queries initiated during a single SPF check. Each external domain reference (like include:domain.com) counts as one lookup.
According to RFC 7208, Section 5.3, receivers must reject SPF checks that exceed 10 DNS lookups — so hitting this cap is not a bug, it's a protocol enforcement.
If your DNS logs show 10 lookups or more during a single SPF validation, your record is invalid for modern email gateways.

Let’s be clear: every include: directive in your SPF record increases the lookup count. If you’re using multiple third-party services (like SendGrid, HubSpot, or AWS SES), each one may require a separate include:, easily pushing you over the limit.

For teams managing large lists or multiple sending sources, bulk email verification with MailTester helps confirm deliverability risks before you send — including SPF-related delivery failures. You’re not just checking addresses; you’re checking the infrastructure behind them.

SPF is a layer of email authentication, but it breaks if it exceeds 10 DNS lookups — and that’s by design.

You can’t bypass this limit. But you can avoid it with well-structured records and tools that simulate real-world validation. Use MailTester’s real-time API to test SPF behavior across domains before sending.

Steps to fix SPF record lookup limit issues in Microsoft 365 or Google Workspace

SPF record lookups are capped at 10 per email validation. Exceeding this limit—common with nested includes or multiple third-party services—causes authentication failures and spammy behavior. To fix it, audit your current SPF record, trim redundant includes, consolidate overlapping providers, and isolate complex senders using a dedicated subdomain. This keeps you under the limit and ensures deliverability.

Review your current SPF record and count every include: or redirect: clause. Microsoft and Google both enforce the 10-lookup limit. Any extra clause beyond that will break SPF validation—even if the rest of your record is correct.
Identify non-essential third-party services and remove their include: entries. Not every tool needs direct SPF access. Audit your integrations and ask: is this still sending email? If not, delete the reference. This reduces lookup count without impacting delivery.
Use the all mechanism only once, typically at the end of the record. Multiple all mechanisms are invalid and can cause unexpected failures. The final mechanism must be all—but only one is allowed.
Consolidate multiple includes using a single, shared SPF record from a provider that supports it. Some vendors (e.g., SendGrid, Mailchimp) offer a single include: that covers multiple services. This can shrink dozens of entries into one.
Replace obsolete or redundant includes—especially for old CRM tools, defunct marketing platforms, or inactive senders. These aren’t just unnecessary; they risk being triggered in future delivery checks. Clean them out proactively.
Use a dedicated subdomain for outbound marketing—like mail.yourcompany.com. This isolates complex sender stacks (e.g., newsletter platforms, CRM triggers) behind their own SPF record. You can then maintain full control without affecting core corporate domains.

The 6 steps described in “Steps to fix SPF record lookup limit issues in Microsoft 36…”, in order.

When in doubt: test and validate

Even with a clean SPF record, misconfigurations happen. Use tools like RFC 7208 (SPF specification) to double-check syntax, and validate your record with an SPF lookup checker. For example, a test email from your system can show whether SPF fails silently or due to a lookup limit.

You can verify your sender setup with real-world deliverability feedback using MailTester's inbox placement test. This shows how your emails perform in actual inboxes—whether they’re caught by filters or end up in spam.

Real-world SPF record example: when the limit is exceeded

You exceed the SPF 10 lookup limit in Microsoft 365 and Google Workspace when your SPF record includes more than 10 include mechanisms, even if some are cached. Each include counts as a lookup during evaluation—so a record with 9 includes plus one more sender pushes it over the limit, causing validation failure and potential email rejection.

How common are over-limit SPF records?

Many businesses stack multiple third-party services directly into their SPF record, not realizing that every include counts toward the limit. For example: v=spf1 include:spf1.example.com include:spf2.example.com include:spf3.example.com include:sendgrid.net include:mailchimp.com include:hubspot.net include:klaviyo.com include:aws.com include:sendinblue.com ~all already uses 9 lookups. Adding just one more — say, a CRM or newsletter tool — hits 10, and the next one breaks it.

Even with DNS caching, each include query is counted separately. This means cached responses don’t reduce the lookup count. If the record is evaluated by Google or Microsoft, the total number of include mechanisms is tallied independently of caching or TTL settings.

SPF’s 10-lookup limit is defined in RFC 7208, section 5.1 — the standard your email infrastructure must follow. You can verify this behavior using public DNS tools like MxToolbox or Spamhaus’s lookup service.

When the limit is exceeded, receivers may reject your email or mark it as suspicious. This happens even if the sender is valid, because SPF validation fails before DKIM or DMARC are checked. The result: delivery failures, lower inbox placement, and damage to your sender reputation.

Why simple fixes don’t always work

Some teams try to solve this by replacing include with ip4 or ip6 addresses. But that’s impractical—many providers issue dynamic IPs, and hardcoding them leads to future failures. Others split SPF into multiple records. That doesn’t work either; receiving servers only read the first SPF record they find and ignore any others.

The correct approach is to use a single, shared SPF record that includes all necessary services through a reputable aggregator—or switch to DKIM-based authentication for outbound email. While SPF is still important, SPF’s limitations mean you need to rely on other mechanisms to maintain reliability.

With tools like MailTester’s bulk verification, you can check your list’s deliverability before sending, spot problematic domains early, and avoid reputation risks before they start.

How MailTester helps prevent SPF and deliverability issues

You don’t need to guess whether an email list is causing SPF lookup overloads with Microsoft 365 or Google Workspace. MailTester’s real-time verification and bulk checks detect problematic SPF configurations before they trigger bounces or spam filters. It flags high lookup counts, identifies catch-all domains, and confirms whether your sender reputation is holding up — all before you send a single mail.

SPF lookup limits: when they break delivery

Both Microsoft 365 and Google Workspace enforce strict SPF record lookup limits — typically capping at 10. Exceeding this means your mail gets rejected, even if the domain is valid. MailTester checks SPF records during every verification, alerting you when a domain’s setup risks crossing that threshold.

Real-time API checks for SPF — When you verify emails via the MailTester API, it probes SPF records dynamically and reports potential lookup overload risks as part of the verdict.
Bulk verification surfaces hidden issues — Use bulk list verification to scan entire lists for domains that use multiple include mechanisms or external services, which can trigger lookup overflows.
AI assistant explains and fixes deliverability problems — The in-app AI analyzes SPF and DKIM configurations, flags redundant includes, and suggests clean, compliant alternatives — all based on real-world delivery diagnostics.
Inbox placement testing confirms the effect — Run an inbox placement test to see if SPF issues are actually blocking delivery to Gmail or Outlook inboxes — not just theoretical.
No expired credits, no hidden limits — With MailTester, purchased verification credits never expire, so you can audit and fix lists at your pace, without urgency pressure.

What you can do today

Let’s say your list has 5,000 emails. You verify them via MailTester’s API, and it flags 12 domains with 11+ SPF lookups. You can now audit those domains, reduce includes, or switch to DKIM-only authentication where needed. You don’t need to wait for bounces or blacklisting to learn the impact.

SPF lookup limits are not just a technical detail — they’re a hard rejection point. One extra include can kill delivery.

For context, RFC 7208 (section 5.3) outlines SPF’s lookup mechanisms, and both Microsoft and Google enforce them strictly — you can’t rely on guesswork. Use actual verification data, not assumptions.

Best practices to avoid SPF lookup limit problems

You can avoid SPF lookup limit issues with Microsoft 365 and Google Workspace by keeping your SPF record lean, using dedicated sending domains, eliminating nested includes, auditing quarterly, and monitoring feedback loops and blocklists. These steps directly reduce lookup depth and help maintain deliverability.

Keep SPF records lean

Only include senders that are essential to your domain’s email flow — no more, no less.
Each additional include or mechanism increases lookup count. Stay under 10 lookups to stay compliant with Microsoft 365 and Google Workspace constraints.
Use RFC 7208 as a reference for SPF record structure and limitations.

Use dedicated domains and avoid nesting

Route campaign emails through a dedicated domain (e.g. [email protected]) or subdomain to isolate SPF complexity.
Avoid nesting includes — if you include another domain’s SPF, don’t let it internally include others (e.g., include:service1.com that itself pulls in service2.com).
Nested includes rapidly consume lookup slots, often pushing you over the limit before you realize it.

Audit and monitor consistently

Review your SPF record at least once every quarter — especially after adding a new email tool or sending service.
Check for stale or duplicate entries from outdated integrations.
Use tools like MxToolbox or SPF Record Check to validate your record’s lookup depth and structure.
Monitor feedback loops and blocklists regularly — early detection of delivery drops can reveal SPF issues before they cause widespread problems.
Integrate SPF checks into your email infrastructure audit using your verification tool: bulk list verification keeps sender domains clean, while inbox placement testing confirms deliverability in real consumer inboxes.

How to verify email addresses before sending to avoid deliverability harm

You can avoid deliverability issues by verifying every email address before sending. Use a tool like MailTester to catch invalid, catch-all, role-based, or disposable addresses that hurt sender reputation. Testing your list in real inbox environments ensures your messages reach inboxes, not spam folders, and reduces bounce rates with 98.9% accuracy.

Check for harmful address types early

Let's be clear: sending to role accounts like sales@, admin@, or info@ is risky. These often have high bounce rates, even if the email exists, because they're shared and rarely monitored. Catch-all domains accept all incoming mail, which means you’ll send to hundreds of fake or unused addresses—this looks like spam behavior to ISPs. Disposable domains (like temp-mail.org) are used for one-time sign-ups and quickly discarded, causing hard bounces.

Tools like MailTester flag these address types before you send. You get real-time results showing whether an address is valid, risky, or invalid. Filtering out these addresses improves list hygiene, reduces your bounce rate, and protects your sender reputation. This is an industry-standard practice backed by organizations like the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG).

Test your list in real inbox environments

Even a clean list can fail if inbox placement fails. That’s why you need to test your message in actual recipient environments. MailTester’s inbox placement feature simulates how your email lands in Outlook, Gmail, Apple Mail, and other inboxes across major providers.

This isn’t theoretical. Many senders assume their message is safe until they see it in a spam folder. A real inbox test reveals issues like poor authentication, low sender reputation, or content triggers before you send to thousands. This is how you avoid being flagged by providers like Microsoft or Google, which have strict enforcement policies.

With a 98.9% accuracy rate, MailTester helps ensure you're only sending to addresses that actually receive mail. Use our bulk verification tool to clean large lists, integrate via our real-time API, or test your campaigns before launch with our inbox placement tester. All credits never expire—so you can verify at your pace without waste.

For teams using marketing platforms, our integrations with Mailchimp, HubSpot, Klaviyo, and SendGrid fit into existing workflows. No matter your setup, consistent verification is the most effective way to maintain inbox placement and sender trust.

Final takeaway: don’t wait for delivery failures

SPF lookup limits in Microsoft 365 and Google Workspace can silently degrade deliverability. Issues often go undetected for weeks — long after configuration changes are made — until bounce rates rise or emails land in spam folders.

Prevention is not a feature. It’s a requirement. Every email sent must be validated against real-time standards, not assumptions. Misconfigured SPF records or excessive DNS lookups can break delivery without warning.

Use tools that test your setup with precision: MailTester checks SPF, DKIM, DMARC, and address validity at scale. With no expiry on purchased credits, you can run audits anytime, before problems emerge.

Sources

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)
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)

Keep reading

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

Frequently asked questions

Does Microsoft 365 enforce the SPF 10 lookup limit?

Yes. Microsoft 365 enforces the 10 DNS lookup limit defined in RFC 7208. Exceeding it results in SPF failure, which can lead to email rejection or spam filtering.

Does Google Workspace have a 10 lookup limit for SPF records?

Yes. Google Workspace follows the same RFC standard and stops processing SPF records after 10 DNS lookups. Overloaded records may fail validation.

What does 'spf.protection.outlook.com' do in SPF DNS lookups?

It serves as an SPF include target for Microsoft 365. Including it in your SPF record counts as one lookup and is used to validate sender legitimacy.

Can I bypass the SPF 10 lookup limit?

No. The limit is enforced at the protocol level. You cannot bypass it, but you can reduce the number of lookups through record consolidation or subdomain separation.

How do I check if my SPF record is within the 10-lookup limit?

Use a DNS tool like MXToolbox or MailTester’s API to simulate SPF evaluation. These tools report how many DNS lookups are required during validation.

Can I use multiple SPF records for the same domain?

No. Multiple SPF records cause a DNS error. Only one SPF TXT record per domain is allowed, and it must be merged properly.

Why does my email sometimes get delivered even with an SPF lookup limit violation?

SPF failures may result in softfail or neutral outcomes. Some receivers still accept messages despite failure, but spam filters treat them as risky, reducing inbox placement.

How often should I audit my SPF record?

Review it quarterly or when adding new email services. Changes in third-party tools can quickly push your record over the 10-lookup limit.

Can a catch-all email address affect SPF validation?

Catch-all addresses don't directly affect SPF, but they signal poor list hygiene. Their presence increases the risk of spam complaints and harms sender reputation over time.

What is the impact of SPF on sender reputation?

SPF failure increases the risk of spam filtering and delivery delays. Consistent SPF alignment improves trust with receivers and supports better inbox placement.

How does MailTester verify email addresses and detect SPF issues?

MailTester checks domains via real-time API, identifies SPF lookup counts, and flags records that exceed the 10-lookup limit before sending.

Do mail verification tools like MailTester expire credit?

No. Purchased verification credits never expire, meaning you can use them at any time without time pressure.