SPF allows a maximum of 10 DNS lookups. Exceed 10 and receiving servers return a PermerError, failing every email you send.
A domain using Google Workspace, Salesforce, and Mailchimp HubSpot can hit this without realizing it.
You can only have one SPF TXT record per domain. If you have two, receiving servers return a PermerError.
This typically happens after migrating email providers when the old record is left behind. Delete the duplicate and merge everything.
A misplaced space or typo can break your entire record.
Common examples include inlcude instead of include, or a record that doesn't start with v=spf1. The SPF Checker flags these in red and shows exactly where the issue sits.
?all (neutral) doesn't reject unauthorized senders — mail still gets delivered. Avoid using it. For active, email-sending domains, use ~all combined with DMARC at p=reject — this rejects unauthenticated mail without risking legitimate email delivery.
Reserve -all only for inactive domains that send no email at all.
FAQs
Red Sift's SPF Checker instantly looks up and validates your SPF record. This includes syntax errors, duplicate records, and “too many DNS lookups,” then Red Sift's tool shows you exactly how to fix issues. It’s fast and free.
SPF stands for Sender Policy Framework. It’s an email authentication protocol that acts as a whitelist, outlining the senders authorized to send emails on your behalf. Its aim is to prevent email forgery.
DNS TXT record that tells receiving mail servers which IPs/hosts are authorized to send email for a domain.
- Too many DNS lookups — SPF caps you at 10. Every include, a, mx, ptr, and redirect counts. Go over and every email fails, including legitimate ones.
- Multiple SPF records — One record per domain. Two or more triggers a PermError. This usually happens after a provider migration when the old record isn't removed.
- Syntax errors — Typos like "inlcude" instead of include, missing v=spf1 prefix, or stray characters. The checker highlights the exact location in red.
- Overly permissive qualifiers — ?all offers no protection. +all authorizes the entire internet. Both are flagged immediately.
- Void lookups — DNS queries that return nothing, often caused by stale or misconfigured include entries pointing to records that no longer exist.
- Compromised includes — Entries linked to the SubdoMailing campaign or other known-bad sources that attackers can exploit to spoof your domain.
- Nested errors in third-party records — Problems buried inside an included sender's SPF record that you wouldn't spot manually. The SPF tree visualization traces every branch so you can see exactly where the issue sits.
We compared seven free SPF checkers on diagnostic depth, visualization, and error detection. See the full breakdown in our guide to the best free SPF checker tools. Red Sift's SPF Checker is rated number 1.
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.5 -all
It starts with v=spf1, lists authorized senders in the middle, and ends with an all qualifier. One record per domain — no exceptions.
The SPF tree visualization provided by the SPF Checker illustrates each step of SPF record resolution, showing how each mechanism is evaluated and whether it results in a pass, fail, or neutral outcome. This visualization helps users understand the hierarchy of SPF mechanisms and identify potential issues or misconfigurations within the SPF record.
On Feb 27th, 2024, researchers at Guardio discovered a massive email ad fraud campaign based on thousands of hijacked domains and subdomains. You can read more about the SubdoMailing attack and how to protect yourself here.
The Red Sift SPF record check tool detects if your SPF record contains compromised includes that leave your domain open to spoofing attacks. The dynamic visualization of the SPF tree allows you to highlight where the poisoned includes exist. If compromised includes are discovered, we recommend you remove these entries from your SPF record immediately.
Running an SPF check on your domain's SPF configuration ensures that it is correctly set up to authenticate emails sent from your domain, reducing the likelihood of your emails being marked as spam or being rejected by recipient servers.
Depending on the SPF configuration of the specified domain, information messages are displayed with the option to "highlight in SPF tree".
- Green indicates information only (e.g., well-known provider).
- Yellow signifies warnings only (e.g., void lookup).
- Red denotes issues (e.g., permanent DNS error).
Yes, the SPF Checker can identify errors in nested includes from third-party records by analyzing each included SPF record within the hierarchy. This allows users to detect and address issues in third-party SPF configurations that may impact their own domain's email authentication.
You can access your domain's SPF record by querying the DNS records for your domain using tools like nslookup or dig. Alternatively, you can use online SPF lookup tools or access the DNS management interface provided by your domain registrar or hosting provider.
A void lookup occurs when a mechanism in the SPF record results in a DNS query that returns no result, indicating a misconfiguration or an invalid entry. Void lookups can lead to SPF authentication failures and should be addressed to ensure the integrity of the SPF configuration.
Syntax errors in an SPF record can be fixed by reviewing the SPF syntax guidelines and ensuring that the record is correctly formatted. Common syntax errors include missing or misplaced mechanisms, invalid characters, and incorrect spacing. Once identified, syntax errors can be corrected using the DNS management interface provided by your domain registrar or hosting provider.
SPF mechanisms are components of an SPF record that specify which mail servers are authorized to send emails on behalf of a domain. Mechanisms include IP addresses, domain names, and qualifiers that define how the mechanism should be interpreted. By configuring appropriate mechanisms in the SPF record, domain owners can control which mail servers are allowed to send emails using their domain name, thereby enhancing email authentication and security.
Run a lookup and ensure one record, valid syntax, ≤10 DNS lookups.
Typically multiple records, syntax issues, or too many “include” lookups.
RFC 7208 caps SPF at 10 DNS-querying mechanisms to protect receiving servers from overload. Each include, a, mx, ptr, and redirect counts toward that limit. Go over and SPF fails for every email, including legitimate ones. The SPF Checker shows your current lookup count and where it's coming from.
?all (neutral) doesn't reject unauthorized senders — mail still gets delivered. Avoid using it. For active, email-sending domains, use ~all combined with DMARC at p=reject — this rejects unauthenticated mail without risking legitimate email delivery.
Reserve -all only for inactive domains that send no email at all.
Yes, and you should. SPF on yourdomain.com doesn't cover mail.yourdomain.com or newsletter.yourdomain.com. Each sending subdomain needs its own record. Subdomains without SPF are open to spoofing.




