Check your SPF record and see exactly how to fix it.

An SPF record breaks at 11 DNS lookups, even when every line in it is correct.

Each include, a, mx, ptr and exists term makes the receiving server do another DNS lookup, and so do the includes inside those includes. RFC 7208 caps the total at 10. One lookup over, and the whole record returns a permanent error, which Gmail treats as no SPF at all. The tree in the report above counts every lookup for you, nested ones included, and shows which include costs the most.

That is why an SPF record grows until it breaks. Each new tool someone in the company signs up for asks you to add its include: a help desk, a CRM, a newsletter tool, a billing system. Each one looks harmless on its own. The fifth or sixth one pushes the count past 10, and from that moment every message from the domain fails SPF, including the ones from Google Workspace that worked yesterday.

ip4 and ip6 terms cost nothing, because the address is already in the record. That is what "flattening" an SPF record means: replacing includes with the addresses they resolve to. It works until the provider changes its addresses, which is why we suggest removing includes you no longer use before you flatten anything.

Every part of an SPF record has one job.

A sign in front of a term changes what a match means: + pass (the default), - fail, ~ soft fail and ? neutral. In practice only the all term at the end carries one. A record that ends in +all or plain all passes every server on the internet, and our check fails it.

Some providers' includes cost one lookup, and some cost seven.

We ran each provider's documented include through the checker on its own. The number is the include plus every lookup nested inside it, which is what it costs you out of 10.

Measured on live DNS on 6 October 2026. Providers change their records without notice, so check your own record above rather than adding these up.

Google Workspace and Microsoft 365 cost one lookup each, so a domain that only sends through one of them has nine to spare. The expensive ones are the services that nest includes for several mail systems of their own.

Two SPF records on one domain is the most common way to break SPF.

It usually happens when a domain changes hands between services. The registrar publishes a default record for its own email service, then someone adds Google Workspace's record next to it instead of replacing it. Both look valid on their own, and together they fail: receivers read exactly one SPF record, and when they find two they return a permanent error for every message.

When our check finds more than one, it writes the merged record for you: one v=spf1, every include and address from the old records once, and one all term. If your mail runs on a provider we recognise and one of the old records is a registrar's default include (GoDaddy's secureserver.net, for example), the merged record leaves it out and says so. The report also counts the merged record's lookups before you publish it.

You publish an SPF record as one TXT record at the root of the domain.

1. Open the DNS settings wherever your domain's nameservers are: the registrar, Cloudflare or your host.
2. Find any TXT record whose value starts with v=spf1. If there is one, edit it. Do not add a second.
3. Use the host @ (some panels want the domain name itself, or leave the host empty). For a subdomain such as mail.yourdomain.com, the host is mail.
4. Paste the record from the report, save, and run the check again once the TTL has passed.

A domain that never sends email should still publish v=spf1 -all, which tells receivers to fail any message that claims to come from it. Gmail, Yahoo and Outlook all list SPF among their requirements for bulk senders: Google, Yahoo and Microsoft (read 6 October 2026).

Most broken SPF records fail for one of five reasons.

Every one of these returns a permanent error or lets the wrong servers through, and every one is easy to miss by reading the record by eye, because each term on its own looks fine.

A sixth problem is quieter: a record longer than 255 characters pasted as one string. DNS stores TXT values in chunks of up to 255 characters, and most DNS panels split a long record for you. If yours does not, it may cut the record off, and the check above will show the record exactly as receivers read it.

SPF passing is not the same as DMARC passing.

SPF checks the domain in the return-path address, the one bounces go to, not the one your recipient sees in From. When you send through a service that uses its own return-path, SPF can pass for that service's domain while doing nothing for yours. DMARC only counts SPF when the two domains match, which is called alignment.

That is why the other four checks run with this one. DKIM signs with your own domain and survives forwarding, so it is the record DMARC leans on most. See your DKIM key on the DKIM checker and your policy on the DMARC checker, or build a new SPF record from scratch with the SPF record generator.

Common questions about SPF records

More free tools for your sending setup