You have an SPF record. The question is whether it actually works. Publishing a TXT record that starts with `v=spf1` is the easy part. The hard part is confirming that the record survives evaluation: that the syntax is valid, the DNS lookup count stays within bounds, the mechanisms resolve to live infrastructure, and the whole thing aligns with the DMARC policy sitting next to it. An SPF record check is the diagnostic step that answers those questions before a receiver answers them for you by rejecting mail.
Most SPF failures are not syntax errors. They are structural problems that accumulate quietly as teams add vendors, migrate platforms, and inherit records from previous administrators. A record can look perfectly reasonable in a text editor and still produce a permerror when a receiver tries to evaluate it, because the real constraint is not what the record says but how many DNS queries it takes to resolve. That gap between appearance and evaluation is exactly what an SPF record check is designed to close.
Quick check: Run your domain through the SPF Builder to see your current lookup count, or use the Email Security Check for a full SPF, DKIM, and DMARC audit in one pass.
What an SPF Record Check Validates
A thorough SPF record check is not a single test. It is a sequence of validations that mirrors the evaluation path a receiving mail server follows when it processes an inbound message. Each layer catches a different class of problem, and passing one layer does not guarantee the next.
Syntax Correctness
The record must begin with `v=spf1` exactly. Not `v=spf 1`, not `spf1`, not a versioned variant. Every mechanism after the version tag must be a recognized type (include, a, mx, ip4, ip6, redirect, exists, all) with a valid qualifier (+, -, ~, ?) if one is present. Unrecognized mechanisms cause the entire record to fail evaluation, which means a single typo can silently disable authorization for every legitimate sender on the domain.
DNS Lookup Count
RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms per check. The mechanisms that cost one lookup each are `include`, `a`, `mx`, `redirect`, and `exists`. The mechanisms that cost zero lookups are `ip4`, `ip6`, and `all`. This distinction is the single most important thing an SPF record check reveals, because the limit applies recursively: if your record includes a vendor, and that vendor's SPF includes two more domains, all three lookups count against your budget of ten.
Void Lookup Limit
Separately from the 10-lookup cap, RFC 7208 limits void lookups to two. A void lookup is any DNS-querying mechanism that returns either an empty answer (NOERROR with zero records) or a name error (NXDOMAIN). This catches stale includes that point to domains a vendor no longer maintains. Two void lookups produce a permerror just as reliably as exceeding the 10-lookup limit, but they are harder to spot because the mechanism looks valid in the record text.
Record Length and String Limits
DNS TXT records have a 255-byte limit per string within the record, but multiple strings can be concatenated into a single logical record. Most modern resolvers handle concatenation correctly, but some older systems truncate at the first string boundary. An SPF check validates both that the total record length is within practical UDP response limits and that string boundaries do not split a mechanism in a way that breaks parsing.
Multiple SPF Records
A domain must publish exactly one SPF record. If two TXT records both start with `v=spf1`, the result is an immediate permerror regardless of what either record contains. This happens more often than teams expect, typically when a new record is added without removing the old one, or when a migration leaves behind a record on a subdomain that was supposed to be cleaned up. An SPF record check flags this as a fatal condition because no amount of syntax correctness in either record can compensate for the ambiguity.
The 10-Lookup Limit: Why Most SPF Records Fail
The 10-lookup limit is not an edge case that affects only large organizations. It is the most common structural failure mode for any domain that uses more than a few cloud services for email. The arithmetic is straightforward, but the numbers add up faster than most teams realize because they cannot see the nested lookups inside each vendor's SPF record.
Consider a domain that sends through five common services. Here is what the lookup budget actually looks like when you resolve each include chain:
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:servers.mcsv.net ~all
Lookup breakdown:
include:_spf.google.com → 1 (resolves to 1 nested include) = 2
include:sendgrid.net → 1 (no nested includes) = 1
include:spf.protection.outlook.com → 1 (resolves to 1 nested) = 2
include:mail.zendesk.com → 1 (resolves to 1 nested) = 2
include:servers.mcsv.net → 1 (resolves to 1 nested) = 2
Total: 9
Budget remaining: 1 lookup
Add one more vendor → permerror → all SPF checks failNine lookups out of ten, with five vendors. The domain is one include away from total SPF failure, and the owner of the record cannot control when a vendor decides to add a nested include to their own SPF chain. Google's SPF record, for example, has changed its nesting depth multiple times over the years. A record that passed yesterday can fail today without any change on your side.
This is why an SPF record check that only validates syntax is almost useless. The record above is syntactically perfect. It would only fail under evaluation, and only when a receiver actually counts the recursive lookups. A proper check must resolve every include chain and return the true lookup cost, not just the number of mechanisms visible in the top-level record.
Google and Yahoo Bulk Sender Requirements
Since February 2024, Google and Yahoo enforce stricter authentication requirements for domains sending more than 5,000 messages per day to their users. The requirements are not optional guidelines. Mail that fails them is throttled, deferred, or rejected, and the enforcement has tightened steadily since the initial rollout.
For SPF specifically, the requirements mean the following:
- The sending domain must have a valid SPF record that does not evaluate to permerror or temperror.
- SPF or DKIM must pass for the sending domain. Both passing is stronger, but at minimum one must succeed.
- A DMARC policy must be published at the organizational domain, even if set to p=none.
- SPF alignment with the DMARC policy must be present if SPF is the passing mechanism.
- The domain's spam complaint rate must stay below 0.3%, with a target under 0.1%.
The critical detail for SPF record checks is that permerror counts as a failure, not as an absence. A domain with an SPF record that exceeds the 10-lookup limit is in a worse position than a domain with no SPF record at all, because the permerror is an active signal of misconfiguration rather than a passive gap. Receivers treat these differently in their filtering decisions.
Use the DMARC Builder to verify that your DMARC policy exists and that its alignment mode matches your SPF and DKIM configuration.
Common SPF Problems and How to Fix Them
The problems below are ordered by how frequently they appear in real-world SPF record checks. Each one can independently cause mail delivery failures, and several of them can coexist in the same record without being obvious from a visual inspection.
1. Too Many DNS Lookups
The fix depends on the situation. Flattening replaces include mechanisms with the resolved IP ranges (ip4 and ip6 mechanisms), which eliminates the DNS lookup cost. The tradeoff is that flattened records become stale when the vendor changes their sending infrastructure, so flattening requires automated monitoring and re-resolution on a schedule. The cleaner long-term fix is to move different mail classes onto subdomains: marketing mail from `mail.example.com`, transactional mail from `notify.example.com`, each with its own SPF record and its own lookup budget.
2. Missing Include for an Active Sender
A sender that is not covered by the SPF record will fail SPF checks even if the mail is legitimate. The symptom is usually visible in DMARC aggregate reports as a source IP that fails SPF but sends real mail. The fix is to add the correct include mechanism, but the prerequisite is knowing which vendors are actually sending on behalf of the domain, which is why DMARC reporting and SPF checking work best as a pair.
3. Softfail vs. Hardfail: ~all vs. -all
The `~all` qualifier (softfail) tells receivers that mail from unlisted sources should be accepted but marked. The `-all` qualifier (hardfail) says it should be rejected. In practice, most receivers treat both similarly when DMARC is in place because DMARC policy overrides the SPF qualifier. The real risk is using `+all` or `?all`, which effectively disable SPF enforcement entirely. A record check should flag any all-mechanism that is not `~all` or `-all` as a configuration weakness.
4. Subdomain SPF Does Not Inherit from Parent
SPF records are evaluated per domain. A subdomain does not inherit the SPF record of its parent domain. If `example.com` has a comprehensive SPF record but `mail.example.com` has none, then mail sent with a Return-Path at the subdomain will have no SPF policy to evaluate. This is a common gap when teams create subdomains for specific mail streams but forget to publish SPF records for each one.
5. Broken Include Chains
An include mechanism points to another domain's SPF record. If that domain changes its record, removes it, or lets the domain expire, the include becomes a void lookup or a resolution failure. This happens regularly when vendors rebrand, merge, or deprecate legacy sending infrastructure. The only way to catch it is to periodically resolve the full include chain and verify that every link still returns a valid SPF record with reachable IP ranges.
SPF Check Workflow
A complete SPF record check follows a defined sequence. Each step depends on the output of the previous one, which is why partial checks miss structural problems that only emerge during recursive resolution.
- Query TXT records for the domain using the DNS Lookup Tool and isolate the record starting with v=spf1.
- Confirm exactly one SPF record exists. Two or more records are a fatal permerror.
- Parse the SPF string into individual mechanisms and qualifiers. Flag unrecognized tokens.
- Recursively resolve every include, redirect, a, mx, and exists mechanism, counting each as one lookup.
- Track void lookups separately: any mechanism that resolves to NXDOMAIN or empty counts toward the 2-void limit.
- Sum the total lookup count across all recursion levels. Anything above 10 is a permerror.
- Verify that each resolved IP range corresponds to infrastructure the domain owner recognizes as a sender.
- Check the all-mechanism qualifier. Flag +all or ?all as enforcement gaps.
- Cross-reference the SPF alignment mode with the published DMARC policy to confirm they are consistent.
This workflow is what the Email Security Check automates end to end. Running it manually is instructive for understanding the evaluation model, but for ongoing monitoring, automated resolution and alerting on lookup count changes is the practical approach.
Beyond SPF: The Full Authentication Stack
SPF checks the envelope sender, which is the Return-Path address used during the SMTP transaction. It does not check the From header that the recipient sees in their mail client. This is the fundamental limitation of SPF as a standalone mechanism: a message can pass SPF and still display a forged From address, because the two addresses are independent.
DKIM closes part of that gap by signing the message body and selected headers with a cryptographic key published in DNS. The signature survives forwarding in most cases, unlike SPF which breaks whenever the message is relayed through an intermediary server that is not listed in the original SPF record. DMARC ties the two together by requiring that at least one of SPF or DKIM passes and aligns with the From domain, then applying a policy (none, quarantine, or reject) based on the result.
An SPF record check is necessary but not sufficient. It confirms that one layer of the authentication stack is correctly configured, but it does not tell you whether DKIM selectors are published, whether DMARC alignment is in place, or whether your policy is actually enforcing anything. The Email Security Check evaluates all three layers together, which is the only way to get a complete picture of whether a domain's email authentication is working as intended.
For a deeper treatment of how SPF, DKIM, and DMARC interact, see SPF, DKIM and DMARC Explained. For guidance on reading the reports that DMARC generates, see DMARC Report Analysis Guide.
Independent references: Review RFC 7208 for the SPF specification and lookup limits, and Google Sender Guidelines for current bulk sender authentication requirements.
SPF record checking is not a one-time task. It is a recurring diagnostic that reflects the current state of your sending infrastructure against a fixed evaluation budget. The domains that maintain reliable delivery are the ones that treat SPF as an operational surface with ownership, change tracking, and periodic validation, not as a DNS record that was set once and forgotten.