SPF Record Checker

An SPF checker answers one question fast: will receiving mail servers accept your domain's SPF record, or does it fail before it is even evaluated? Run an SPF record check here and we fetch the live v=spf1 record, show it in full, explain every mechanism in plain English, follow each include to count DNS lookups against the limit of 10 set by RFC 7208, and flag void lookups, duplicate records, the deprecated ptr mechanism and a dangerous +all. When something is wrong, you get a corrected record to publish.

How to use the SPF checker

1. 1 Enter your domainType the domain you send email from, such as example.com. You can also paste a website address or a full email address and we will pick out the domain.
2. 2 Run the SPF checkPress the button to look up the domain's live DNS. You need a free account to run tools, and results are cached for about ten minutes per domain.
3. 3 Read the verdict and the lookup countThe first line tells you whether the record passes, needs attention or fails outright. Below it you see DNS lookups out of 10, void lookups out of 2 and the qualifier on all.
4. 4 Work through the mechanism table and include treeEvery term in the record is listed with what it does and what it costs. The include tree shows which provider record is using up your lookups.
5. 5 Publish the suggested record and test againCopy the corrected record into the TXT record at your DNS host, replacing the old one. Once it has propagated and our cache has expired, run the SPF test again.

SPF record check: the short answer

A valid SPF record is a single TXT record on your domain that starts with v=spf1, lists every service allowed to send mail for you, needs no more than 10 DNS lookups to evaluate, and ends with ~all or -all. If any one of those is not true, receivers either ignore the record or return a PermError, and SPF fails for every message you send, including the legitimate ones.

To check an SPF record by hand you would run a TXT lookup on the domain, then a further lookup for every include, a, mx and redirect, and keep a running total. This SPF lookup tool does that for you in one step. It reads the same public DNS that Gmail, Outlook and Yahoo read, so the result reflects what they see. It is read-only: nothing is sent from your domain and nothing in your DNS is changed, so you can safely check a client's or supplier's domain too.

What this SPF test checks, line by line

Each finding is shown as a pass, a warning or a critical issue, with the record value we found and advice on what to do. Only the overall SPF verdict and the MX line affect the score; the other lines explain why the verdict is what it is.

• Full record: the exact v=spf1 text, its length and how many strings it is published as.
• Mechanism table: every ip4, ip6, a, mx, include, exists, ptr, redirect and all term, the result it gives when it matches (pass, fail, softfail or neutral), whether it costs a DNS lookup and what it means in plain English.
• DNS lookups: the total across the whole include tree, measured against the limit of 10. Nine or ten is flagged as close to the limit; eleven or more is a PermError.
• Include tree: each include and redirect, nested as deep as it goes, with the provider name where we recognize it and how many lookups sit underneath.
• Void lookups: lookups that return no records at all, such as an include for a service whose domain has gone. RFC 7208 recommends receivers allow only two.
• Multiple records: two or more v=spf1 records on one domain, which is always a PermError.
• Deprecated ptr, +all and missing all: the three qualifier and mechanism choices that weaken or break SPF.
• Record length: records over 255 characters must be split into several strings, and we warn when a split has glued two terms together.
• Suggested record: your record with the problems fixed, keeping the order of your mechanisms so the result for each sender stays the same.

How SPF evaluation works, and why the order matters

When a message arrives, the receiving server takes the domain from the envelope sender, also called the Return-Path or MAIL FROM, rather than the From address you see in your inbox. It fetches that domain's v=spf1 record and works through the mechanisms from left to right. An ip4 or ip6 mechanism matches an address directly. An include fetches another domain's SPF record, such as Google's or Microsoft's, and checks that. The a and mx mechanisms match the addresses behind your own A, AAAA and MX records.

Evaluation stops at the first match, and the qualifier in front of that mechanism decides the result: + (the default) is pass, - is fail, ~ is softfail and ? is neutral. If nothing matches, the all mechanism at the end applies. Anything written after all is never read, which is why our checker flags terms placed after it. A redirect= modifier hands evaluation to another domain's record, but only when the record has no all mechanism of its own.

Common provider includes for Google Workspace, Microsoft 365 and others

Every service that sends mail with your domain in the envelope sender needs to be covered, usually by an include that the provider documents. Copy the value exactly from the provider's current help pages, because a typo creates a void lookup or a PermError. The values below are the ones each provider documents for standard accounts at the time of writing.

Some platforms send with their own envelope domain and authenticate your From domain with DKIM instead, so they need no SPF include at all. Mailchimp's marketing platform works this way, and many newsletter and CRM tools offer a custom return-path or domain authentication setting that uses CNAME records. Check each platform's domain authentication guide before adding an include you may not need, since every unnecessary include costs at least one lookup.

• Google Workspace: include:_spf.google.com
• Microsoft 365 (most commercial tenants): include:spf.protection.outlook.com
• Zoho Mail: include:zohomail.com
• Amazon SES with a custom MAIL FROM domain: include:amazonses.com
• SendGrid: include:sendgrid.net
• Mailgun: include:mailgun.org
• Mailchimp Transactional (Mandrill): include:spf.mandrillapp.com
• Your own web or mail server: ip4: or ip6: with its address, rather than a or mx, so it costs no lookup.

How to fix "too many DNS lookups" (SPF PermError)

RFC 7208 caps the number of DNS-querying terms a receiver will process at ten. Every include, a, mx, ptr, exists and redirect counts, and so does every one of those nested inside a provider's record. Provider records can contain nested includes of their own, and providers change them over time, so a handful of services can reach the limit sooner than the record text suggests. Go over it and the receiver stops with a PermError, which DMARC treats as an SPF fail even if the sending server is listed.

Use the include tree to see where the lookups go, then work through these fixes in order. Each one is safe and keeps the record maintainable.

• Remove includes for services you no longer use. Old newsletter tools, a previous email host and trial accounts are the usual culprits.
• Replace a and mx with ip4 and ip6 for your own servers. Our suggested record does this automatically when you are over the limit, using the addresses those names resolve to today.
• Delete ptr completely. It costs a lookup, RFC 7208 says not to use it, and ip4 or ip6 does the same job.
• Move bulk and marketing mail to a subdomain such as news.example.com with its own SPF record. Each subdomain gets its own budget of 10 lookups.
• Check whether a platform still needs an include, or whether it has moved to a custom return-path with DKIM, which needs none.

SPF flattening: when it helps and what to watch

Flattening means replacing an include with the ip4 and ip6 ranges it currently resolves to, so receivers no longer need to look it up. It can bring a large record under the limit in one step, and for your own servers, where you control the addresses, it is the right fix.

For third-party providers it comes with real risks. Providers change their sending ranges without notice, and a flattened record does not change with them, so mail from new addresses starts failing SPF. Flattened records are also long, often needing several 255-character strings, and can push the DNS answer past the size that fits in one UDP packet. If you flatten a provider, use a service or script that re-checks and republishes the ranges automatically, and keep the provider's include in your notes so you can switch back. In most cases, removing unused includes or splitting mail across subdomains is the safer fix.

SPF vs DKIM vs DMARC

The three standards work together, and modern mailbox providers expect all three. SPF authorizes sending servers by IP address and is checked against the envelope sender. DKIM, defined in RFC 6376, signs each message with a private key, and receivers verify it with a public key published at selector._domainkey on your domain; it survives forwarding, where SPF usually breaks. DMARC, defined in RFC 7489, ties them to the visible From address: a message passes DMARC only if SPF or DKIM passes for a domain that aligns with the From domain, and your DMARC policy tells receivers what to do when neither does.

So an SPF pass on its own does not prove the From address is genuine, and an SPF record with no DMARC policy leaves receivers to guess. After this SPF check, run the DKIM checker with your selector and the DMARC checker on the same domain, or use the email deliverability checker to see all three at once.

Gmail and Yahoo bulk sender requirements (2024)

Since February 2024, Gmail requires everyone sending to personal Gmail accounts to set up SPF or DKIM for their domain. Senders of close to 5,000 or more messages a day to Gmail accounts must have SPF, DKIM and a DMARC record (p=none is accepted), with the From domain aligned with either the SPF or the DKIM domain. They must also offer one-click unsubscribe in marketing mail and keep reported spam rates low. Yahoo introduced matching requirements at the same time.

Microsoft announced comparable rules for high-volume senders to Outlook.com, Hotmail and Live addresses, which took effect in 2025. In the United States, federal civilian agencies have been required to deploy SPF and DMARC since CISA's Binding Operational Directive 18-01. Most small businesses do not reach the bulk thresholds with everyday email, but newsletters and automated notifications can, and a broken SPF record hurts delivery at any volume.

SPF record best practice

Treat your SPF record as living documentation of who sends for you, and review it whenever you add or drop a service.

• Publish exactly one v=spf1 record per domain or subdomain that sends mail.
• Keep the total under ten lookups, counting nested includes, and leave room for the next service you add.
• Start with ~all while you confirm every sender, then move to -all. Never publish +all or ?all.
• Protect domains that never send email with v=spf1 -all, plus a DMARC policy of p=reject.
• Use ip4 and ip6 for servers you control, and update them when those servers change.
• Pair SPF with DKIM and DMARC, because SPF alone breaks when mail is forwarded.

Examples you can copy

v=spf1 include:_spf.google.com -all

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

v=spf1 -all

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 include:_spf.google.com " "include:sendgrid.net -all"

Common mistakes to avoid

Frequently asked questions