SPF Check

SPF check: reading the analyzer report

To check an SPF record for a domain, the tool queries the domain's TXT records, picks the one that starts with v=spf1 and parses it. The report shows a score from 0 to 100, the raw record, the number of mechanisms, the number of DNS lookups and the final policy. The score is driven mainly by the all qualifier:

If the record has more than ten lookup mechanisms, another 30 points are deducted. Keep in mind that the SPF lookup counter covers the mechanisms in the record itself. Each include is one lookup, but the included record can contain its own includes, and those count too. To walk the chain, run:

dig +short TXT example.com
dig +short TXT _spf.google.com

Also read the raw record in the report. If there is no all at all, the spec gives unlisted senders a neutral result, the same as ?all. A bare all with no sign means +all.

SPF syntax in one screen

Mechanisms are evaluated left to right; the first match wins. Each can carry a qualifier: + pass (default), - fail, ~ softfail, ? neutral.

• ip4:198.51.100.7, ip4:198.51.100.0/24, ip6:2001:db8::/32 — explicit addresses. No DNS lookup.
• a and mx — the domain's A/AAAA hosts and its mail exchangers. One lookup each (mx adds lookups for the hostnames).
• include:vendor.example — "also accept what this domain authorizes". How you authorize Google, Microsoft or an ESP.
• exists, ptr — rare; RFC 7208 says not to use ptr.
• redirect=other.example — modifier that hands the whole policy to another domain; ignored if the record contains all.

The 10 DNS lookup limit

RFC 7208 caps SPF evaluation at ten DNS-querying terms: include, a, mx, ptr, exists and redirect, nested ones included. ip4, ip6 and all are free. Go over the limit and receivers return permerror, which means SPF fails for every message from the domain while the record still looks fine in the DNS panel. There is also a separate limit of two "void" lookups (queries that return nothing), which stale includes often trip.

Ways to get back under ten:

1. Remove includes for services you no longer use.
2. Drop a and mx if your web server and inbound mail hosts never send as the domain.
3. List your own servers with ip4/ip6.
4. Move marketing mail to a subdomain such as news.example.com with its own record and its own budget.

"Flattening" includes into IP lists also works, but vendors change their ranges, so a flattened record needs maintenance.

Common SPF mistakes

• Two v=spf1 records. Only one is allowed; two cause permerror. Merge the mechanisms into a single record. The report shows the first record it finds, so confirm the count with dig TXT example.com.
• +all — authorizes anyone to send as you.
• Typos — v=spf without the 1, a space after the colon, an IPv6 address inside ip4:.
• Assuming subdomains inherit SPF. They don't. A subdomain that never sends mail should publish v=spf1 -all.
• Publishing the old SPF record type (99). It is deprecated; use TXT only.

Example records: Google Workspace, Microsoft 365, SendGrid

A domain on Microsoft 365 that sends receipts through SendGrid and alerts from its own VPS:

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

Many ESPs check SPF on a dedicated bounce (Return-Path) subdomain that you point to them with a CNAME, not on your root domain. Follow the vendor's setup guide instead of adding includes by habit.

SPF header check: what the receiver actually saw

A DNS lookup tells you what is published; the message headers tell you how a receiver evaluated it. In Gmail, open the message and choose "Show original" — the summary shows SPF as PASS, SOFTFAIL, FAIL, NEUTRAL or PERMERROR with the sending IP. In the raw headers, look for Authentication-Results (or the older Received-SPF):

Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected]
       does not designate 198.51.100.25 as permitted sender) [email protected]

Two facts matter here: SPF was evaluated for the smtp.mailfrom domain, and 198.51.100.25 is not authorized. Add that server with ip4 or with the include of the service that owns it. permerror almost always means duplicate records or too many lookups; temperror points to a temporary DNS failure at your nameservers.

Where to edit the record

Edit SPF wherever your domain's nameservers are hosted — registrar, hosting panel or Cloudflare. Look for an existing TXT record with v=spf1 on the root name (@) and change it instead of adding a second one. Use type TXT, name @ (or just the label, such as news, for a subdomain), and a TTL around 3600. Strings longer than 255 characters must be split into several quoted strings inside one TXT record; most DNS panels do that for you. Cloudflare never proxies TXT records, so nothing else needs to be switched on.

~all vs -all

-all is stricter, but some receivers reject on SPF fail before they evaluate DKIM, and forwarded mail, where SPF breaks by design, gets lost. With DMARC in place, many operators keep ~all and let DMARC make the final call based on SPF and DKIM together. For domains that send no email at all, publish v=spf1 -all.

How SPF fits with DKIM and DMARC

SPF validates the envelope sender (Return-Path), not the From address the reader sees. DKIM signs the message with a domain key; DMARC requires SPF or DKIM to pass for a domain aligned with From and tells receivers what to do with failures. Since 2024 Gmail and Yahoo require all three from bulk senders. After the SPF check, look up your signing key with the DKIM checker, verify your policy with the DMARC checker, confirm your MX records, and inspect other record types with DNS lookup. After editing a record, wait for the old TTL to expire and run the SPF check again.