Why does your SPF record scanner report 'include domain not in DNS'?

You just ran your SPF record through a scanner, and it flagged: “include domain not in DNS.” You’re not sure what that means — but you know it could be breaking your email deliverability.

Here’s the thing: SPF doesn’t just check your own DNS. It recursively checks every domain listed in an include mechanism. If any one of them can’t be resolved, the whole verification fails. Even if the rest are valid, your SPF record is treated as invalid. And that means your emails are at risk of being blocked by Gmail, Outlook, or other major providers.

This isn’t a minor technicality. It’s a chain reaction — one broken include can ruin your sender reputation, just like a faulty link in a relay race.

Key takeaways

  • An SPF record fails if any domain listed in an include directive cannot be resolved via DNS lookup.
  • SPF validation is recursive: each included domain must be queryable in DNS, regardless of your own record’s content.
  • A single unresolved include breaks the entire SPF chain — even one invalid reference can cause email rejection.

What happens when an SPF include domain is not in DNS?

If an SPF record references a domain via include: that doesn’t exist in DNS, the record is treated as invalid or incomplete. Mail servers can’t verify the legitimacy of the included domain, so they reject or flag the email as suspicious. This often leads to delivery failures, poor inbox placement, and damage to sender reputation over time.

Why mail servers treat it as invalid

SPF relies on a chain of DNS lookups. When a receiving server checks your SPF record, it must resolve every include: domain to a valid record. If one fails, the entire validation process breaks. According to RFC 7208, the standard for SPF, this causes the policy to be undefined or malformed.

Major providers like Gmail, Yahoo, and Outlook enforce these rules strictly. They don’t accept SPF records with unresolved includes. The result? Your message gets marked as unverified or risky—exactly the kind of signal that triggers inbox filtering or outright rejection.

What this means for deliverability and reputation

When receivers see an SPF include domain that can’t be found, they assume you’re either misconfiguring your setup or trying to impersonate a domain. This isn’t just a technical glitch—it’s a red flag for spam detection systems.

Over time, repeated messages with invalid SPF records lead to higher bounce rates and lower inbox placement. Even if a single email gets through, the receiver may still tag it as low trust. This accumulates into a poor sender reputation, which affects future deliveries across all providers.

Let’s be clear: a single broken include won’t destroy your reputation overnight. But left unchecked, it’s a persistent flaw that compounds. The same way a cracked foundation weakens a building, unresolved SPF includes undermine your email program’s reliability.

Use a real-time validator to catch these issues before sending. With MailTester’s email checker, you can test individual addresses for valid SPF alignment, catch-all status, or deliverability risks—before your message even leaves your system.

How SPF includes work: the technical foundation

You’re using SPF includes to extend your email authentication to third-party services like Google or Amazon, but if the included domain isn’t in DNS or lacks a valid TXT record, the SPF check fails silently. That means your email gets rejected even if everything else is correct, because the chain of trust breaks. Let’s unpack why.

The chain reaction of SPF includes

When you add include:_spf.google.com to your SPF record, you’re telling receiving servers: “Trust the rules defined at Google’s SPF record.” But here’s the catch: each include must resolve via DNS. If the domain doesn’t exist, or has no TXT record, the include stops processing. That failure doesn’t show up as an error—it just makes the entire SPF check fail, often without clear debugging clues.

The receiving server doesn’t just read your SPF record—it recursively queries DNS for every include directive. It’s like following a map where one landmark is missing. If the path breaks, you don’t know whether the destination is unreachable or if the map was wrong. That’s why it’s critical to ensure every included domain is valid and has a correctly published SPF TXT record.

Why silent failures are dangerous

SPF doesn’t require the receiver to report why an include failed. It just marks the entire check as “fail” if any part of the chain can’t be verified. This can happen even if you've configured everything else perfectly—just one broken include ruins the whole result.

For example, if you include include:mail-tester.com but that domain has no SPF record, or if the record is misconfigured, your SPF validation breaks. This is especially common when using temporary domains, old service integrations, or third-party tools that don’t maintain their DNS settings.

That’s where DNS validation comes in. Before sending email, you should check that every include domain resolves to a valid SPF TXT record. Tools like RFC 7208 — the official SPF specification — confirm that includes must be resolvable at check time. If they aren’t, the check fails.

With MailTester’s email checker, you can validate individual addresses and verify that all SPF includes are active and resolvable. It’s a direct way to catch problems before they hit deliverability.

Detecting 'include domain not in DNS' with a real SPF scanner

When an SPF record references a domain via include that doesn’t resolve in DNS, your emails risk being rejected or marked as spam. A real SPF scanner doesn’t just check syntax—it validates every included domain by performing live DNS lookups. This catches issues like typos, missing records, or misconfigured domains before they harm deliverability.

Why syntax checks alone aren’t enough

Many tools scan SPF records only for correct formatting—like missing tags or invalid mechanisms. But a syntax error-free line can still fail if one of the include domains doesn’t exist or has a misconfigured DNS. You might see your email bounce silently because a third-party service’s SPF setup is broken, even though your own record looks perfect.

How MailTester’s SPF scanner works

MailTester’s real-time verification API goes beyond static checks. It performs a full DNS resolution on every domain listed in your SPF record, including those in include directives. If a domain like include:_spf.example.com doesn’t resolve, or returns an invalid record, MailTester flags it immediately.

It’s not just about syntax—it’s about actual reachability. A domain that appears in your SPF record but has no DNS entry, a misconfigured TXT record, or a timeout during lookup will fail. MailTester detects that and tells you why: “include domain not in DNS” isn’t just a warning—it’s a deliverability red flag.

For teams relying on third-party services (like sending platforms or marketing tools), this means you can identify weak links before scaling campaigns. One misconfigured include can affect all emails sent from your domain. You can test individual domains instantly using our email checker, or verify entire lists with our bulk verification.

SPF is one layer of email authentication. According to RFC 7208, valid SPF records must be resolvable at the time of delivery. But many systems ignore that. A scanner that doesn’t do DNS lookups is essentially blind to the real-world state of your sending infrastructure.

Let’s say you’re using a service that uses include:someprovider.com. If that domain’s DNS is unreachable, mail systems will reject or demote your message—even if your SPF record is syntactically correct. MailTester surfaces these risks before you send, so you know the full picture.

Common causes of include domain not in DNS errors

If your SPF record contains an include: directive pointing to a domain that doesn’t have a valid DNS record, email rejection or soft failures are likely. This often happens due to spelling mistakes, outdated third-party inclusions, or uncoordinated DNS changes. The SPF validation process checks the full DNS chain, so any missing or misconfigured record breaks the chain. Let’s break down the most frequent culprits.

Typo in the included domain name

  • One common mistake is a simple typo in a third-party domain included in your SPF record, like include:spf.goolge.com instead of include:spf.google.com. Even a single letter change breaks DNS resolution.
  • Use tools like MXToolbox's SPF Record Validator to test your record in real time. It shows exactly where the chain fails and highlights incorrect domain names.
  • Always double-check the spelling of every include: domain, especially those from providers like Amazon SES, SendGrid, or Mailchimp.

Outdated or unverified third-party includes

  • Third-party email providers often update their SPF records. If you include their domain without verifying it still exists, your own record becomes invalid.
  • For example, if your SPF includes include:spf.mandrillapp.com, but Mandrill (now part of Mailchimp) changed their DNS setup and no longer hosts that record, your SPF fails.
  • Regularly audit your SPF record. If you use a service that changes its SPF policy, update your record accordingly or test it with a real-world tool like MailTester’s email checker to verify delivery readiness.
  • Deleting or modifying a third-party DNS record without updating your SPF is just as damaging. If the provider removes their SPF record but your domain still tries to include it, the SPF chain breaks completely.

These errors are a leading cause of email deliverability issues. They can trigger SPF failures even when the email is legitimate. Proactively scanning your SPF record, especially before sending to high-value lists, prevents this. You can test your full SPF configuration for issues like include domains not in DNS with a real-time scanner like MailTester’s inbox placement tester, which checks SPF alongside other deliverability factors.

Step-by-step: Fixing 'include domain not in DNS' in your SPF record

When your SPF record references a domain not resolveable via DNS, it breaks authentication and risks your emails being rejected. Run your SPF through a DNS-aware scanner like MailTester’s SPF inspection tool to catch these issues early. Each include must point to a valid, publicly accessible TXT record—otherwise, your SPF fails validation. Let’s walk through how to diagnose and fix it correctly.

Diagnose the issue with a DNS-aware scanner

  1. Start with MailTester’s SPF inspection tool to scan your current SPF record. It checks not just syntax but actual DNS resolution, flagging any include that doesn’t return a valid TXT record.
  2. Review each include directive in your SPF record. For example, if you see include:mail.example.com, verify that mail.example.com has a public, resolvable TXT record.

Verify each included domain’s DNS record

  1. For each domain listed in include, use a tool like MxToolbox or run dig TXT mail.example.com to confirm it returns a valid TXT record. If no record appears, the domain is unreachable or misconfigured—common with outdated third-party providers.
  2. Check the SPF record of the included domain itself. Some providers don’t allow third-party SPF inclusion unless explicitly white-labeled. Use RFC 7208, the SPF standard, to verify the include mechanism is used correctly.
  3. Correct or remove broken includes. If the included domain no longer exists or doesn’t support inclusion, replace it with a working one or remove it entirely. Too many includes can exceed the 10 DNS lookup limit, so keep your list lean.
  4. Update your SPF record and wait for DNS propagation (usually under 30 minutes). Then revalidate it using the same scanner.
  5. Test the final record by sending a single message via a real-time verification API like MailTester’s Email Verification API to ensure your domain passes authentication checks across major email providers.
Clean SPF records are the foundation of email deliverability. One broken include can break authentication for all your outbound traffic.

Spam filters often reject messages from domains with malformed or failed SPF checks. Regularly auditing your SPF record helps preserve sender reputation and ensures inbox placement. Use these steps to fix any include domain not in DNS errors before they hurt your deliverability.

Why you should use real-time SPF validation, not just syntax checks

You’re not safe just because your SPF record passes a syntax check. A valid SPF syntax can still fail if included domains are unreachable in DNS, leading to rejected emails and damaged sender reputation. Real-time validation ensures each domain listed in your SPF record actually resolves — no guesswork, no false positives.

Syntax checks can’t catch DNS resolution failures

Many tools only validate SPF syntax, like whether the format follows RFC 7208. But a record can be syntactically correct and still break during delivery if one of the included domains has been deleted, misspelled, or has no DNS records. For example, if your SPF includes include:example.com and that domain doesn’t exist or lacks a TXT record, the entire SPF check fails at delivery time.

It’s like building a bridge with correct blueprints but missing a foundation. The design is valid, but it won't hold. Same goes for SPF. Tools that don’t actively resolve included domains may give you a "pass" when the reality is far worse — your emails could be silently rejected by recipients.

MailTester goes beyond syntax to check actual DNS reachability

MailTester doesn’t just parse your SPF record — it queries DNS for every domain listed in your include, redirect, or exp mechanisms. No assumptions. No shortcuts. Each lookup is done in real time, mimicking how email servers actually verify SPF during delivery.

This real-time approach finds missing records, misconfigured subdomains, or domains that no longer exist — the kind of issues syntax-only tools miss entirely. It’s an industry-standard practice to test SPF against actual DNS state, not just a static rule set. For more on how SPF works in practice, see the official RFC 7208.

You’re not just checking format; you’re testing deliverability. If you’re sending emails at scale, this difference is what separates a working email program from one plagued by bounces and reputation issues. Use an SPF record scanner that validates DNS reachability — not just syntax — to ensure your messages actually get through.

SPF record best practices to avoid include domain errors

You reduce SPF record errors by minimizing 'include' mechanisms, validating each included domain’s DNS record in real time, tracking changes from third-party services, and using a tool that checks DNS as it validates. Over-reliance on 'include' chains creates fragility—each linked domain must exist and return a valid SPF record, or the entire SPF fails. Let’s go through the exact steps to avoid this.

Limit include mechanisms and validate each one

  • Only use include when you absolutely must. If a provider gives you a specific domain to include, confirm it resolves in DNS before adding it.
  • Always verify the included domain returns a valid SPF record using a real-time DNS lookup—don’t assume it works just because it’s a known service.
  • Some providers may change their SPF records without warning. Treat them as dynamic and monitor them periodically, especially after a major update.

Use tools with real-time DNS validation

  • Choose an SPF scanner or verification tool that checks DNS resolution during evaluation—not just syntax. A record can be valid syntactically but fail in practice if the include target is unreachable.
  • Tools like MailTester’s email checker verify SPF in real time, flagging include domains that don’t resolve or return non-compliant records.
  • Use automated monitoring for critical third-party providers—like your email service or CRM—to detect when their SPF changes and trigger a review.
  • Don’t rely on static SPF tools that skip DNS checks. This increases the risk of sending mail from misconfigured domains due to expired or missing include records.
SPF records can only fail when a domain included in the chain does not exist or returns a malformed or unauthorized record—this is why validation must happen at query time.

Think of each include as a dependency. If one fails, SPF fails. Treat them like external libraries: you need to know they’re online, healthy, and correctly configured. This is why real-time DNS checking during SPF validation isn’t optional—it’s essential.

Many common email delivery issues trace back to misconfigured or invalid SPF records. A single unresolved include can result in your emails being rejected by receiving servers. Use a tool that checks both the syntax and the live DNS state of every domain involved. That’s how you prevent bounces and protect sender reputation.

How MailTester’s SPF scanner helps prevent delivery failures

You can’t fix SPF errors you don’t know about. MailTester’s SPF scanner checks every include domain in real time by resolving DNS records as they’re configured, flagging issues like 'include domain not in DNS' with clear context—so you catch problems before they trigger bounces or spam filters. It’s not just a checklist; it’s a live diagnostics tool built to stop delivery failures before they happen.

Real-time DNS resolution finds hidden SPF flaws

SPF records can break silently if an included domain drops off the DNS map. Let’s say you use include:thirdparty.com—if that domain is removed or misconfigured, your email starts failing. MailTester doesn’t just parse the record; it resolves every include domain live, checking for valid DNS records, reverse DNS, and proper TXT entries. If a domain isn’t in DNS, it flags the issue instantly with the exact domain and record type, so your team knows what to fix.

Connects SPF checks to inbox placement testing

Fixing SPF isn’t just about technical correctness. A properly configured SPF record is a baseline—but inbox placement depends on sender reputation. MailTester ties SPF verification into real inbox-testing workflows, letting you simulate delivery through actual recipient servers using known sender reputations. This means you don’t just see if the SPF is valid; you see if the email actually lands in the inbox—or gets quarantined. It’s a practical check that combines technical compliance with real-world behavior.

For teams managing thousands of domains or sending at scale, the API version of this scanner detects SPF flaws across massive lists in seconds. You can validate SPF records as part of your onboarding pipeline, integration testing, or routine audit. It’s a preventative shield, catching misconfigurations that would otherwise slip through.

SPF failures are among the top reasons for email rejection. According to [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208), SPF is designed to prevent forgery—so when it’s broken, it affects deliverability. The same document states that receivers use SPF results to make acceptance decisions. That’s why catching errors early matters. Tools like MailTester, which combine real-time DNS checks with deliverability testing, provide a more complete picture than static scanners or basic syntax validators.

Use the bulk verification tool to scrub large lists for SPF-related risks, or integrate the API directly into your systems to validate domains on the fly. The goal isn’t just compliance—it’s reliable delivery.

What to do if an include domain is intentionally removed or deprecated

If an include domain in your SPF record is no longer in use—whether intentionally removed or deprecated—you should either replace it with a working include or remove it entirely. Leaving behind outdated domains in your SPF chain can trigger validation failures, especially if the domain no longer resolves in DNS, causing your emails to be rejected by receivers that enforce strict SPF policies. This is a common issue when third-party tools or email providers are retired but their SPF entries remain in the configuration.

Keep your SPF chain clean and active

Each include directive in SPF must resolve to a valid DNS record. If a domain is deprecated, its record may no longer exist, or it may point to a different service. When that happens, the entire SPF check fails for any sender relying on it. You can check this by running a DNS lookup on the domain in question, or using an SPF validator tool like RFC 7208’s guidelines on SPF evaluation. It's a best practice to audit every domain listed in your SPF chain regularly, especially when onboarding or offboarding vendors.

Use bulk verification to catch hidden issues

Even if you think you've cleaned up your SPF setup, old or dead providers might linger in your email list—especially if you use multiple senders or past campaigns. You can’t rely on guesswork. Let’s run a full audit: use the MailTester bulk verification tool to check the entire sender and recipient list for SPF, DNS, and validity issues in one go. It flags not only malformed records but also catch-all domains, disposable addresses, and role accounts—any of which can harm deliverability if you’re unaware. The tool checks each domain in your list against real-time DNS records, so you don’t have to test one-by-one.

When you’re done, review the results. Any SPF warnings tied to "include domain not in DNS" are likely tied to deprecated services or inactive providers. Replace them with valid ones—or remove the entry if it's no longer needed. This is not just about compliance—it’s about ensuring every email you send has a clear, working path through DNS validation. The fix is simple: clean your chain, validate the whole list, and stay ahead of bounce spikes and inbox placement drops.

Conclusion: Proactive SPF validation prevents delivery issues

An SPF record with unresolved includes can silently degrade inbox placement, even if the syntax appears correct to basic validators.

Standard SPF parsers often miss real-world DNS failures, failing to detect when an included domain does not resolve — a common cause of authentication failures and deliverability drops.

Use a real-time SPF scanner like MailTester to validate both syntax and DNS resolution, ensuring your SPF records work as intended before they impact sender reputation.

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 does 'include domain not in DNS' mean in an SPF record?

It means one of the domains listed in your SPF record’s 'include' directive does not exist in DNS or lacks a valid TXT record.

Can an SPF record with a missing include still pass validation?

Some tools may accept the syntax, but receiving servers will reject the email if any include fails DNS lookup.

How do I test if an SPF include domain exists?

Use DNS tools like dig or MxToolbox to query the TXT record for the included domain directly.

Does every include in an SPF record need to be publicly accessible?

Yes — receiving servers perform DNS lookups on every include, so all must resolve to valid records.

Can I use MailTester to check SPF records for bulk domains?

Yes — MailTester’s bulk list verification and API support SPF validation across multiple domains at scale.

Is SPF syntax validation enough to prevent delivery issues?

No — syntax validity doesn’t guarantee DNS resolution. Real-time checks are required.

Why does MailTester’s SPF scanner flag an include domain not in DNS?

It actively resolves each domain during validation, detecting unreachable or misconfigured records.

Can a typo in an include domain break SPF?

Yes — even a small typo (e.g., spf.googel.com) makes the include fail DNS lookup, breaking the SPF chain.

How often should I audit my SPF record?

Review it whenever you add a new service, change providers, or after a major change in email infrastructure.

What happens if I ignore a 'include domain not in DNS' error?

Your emails may be rejected, delivered to spam, or fail authentication, all hurting deliverability over time.

Does MailTester support SPF validation for domains from all top-level providers?

Yes — it checks DNS resolution across all public domains, regardless of provider.

How do I prevent third-party SPF changes from breaking my record?

Monitor the status of included domains and use tools with real-time DNS validation to catch updates or outages early.