SPF checker

It's a TXT record on the domain that lists the servers authorised to send email with it. When a message arrives, the receiving server looks at which IP it comes from and checks whether it's on that list. If it isn't, SPF fails and the message loses credibility: it may go to spam or be rejected, depending on what your DMARC says.

The standard (RFC 7208) limits the DNS lookups an SPF evaluation can cost to ten, so nobody can use email as an attack amplifier. include, a, mx, ptr, exists and redirect count, including those inside each include. To reduce them: remove providers you no longer use, replace a and mx with the IP using ip4 when it's fixed, and send newsletters from a subdomain with its own SPF. Flattening the record (replacing the includes with their IPs) works until the provider changes IPs without warning.

If you already have DMARC, ~all is enough: DMARC decides what to do with a failure, and that way you don't lose legitimate email if one day you send from a service you forgot to add. -all makes sense when you know for certain who sends on your behalf. What you should never use is +all, which authorises anyone, or ?all, which protects nothing.

No. If the domain publishes two TXT records starting with v=spf1, the result is a permanent error and neither is valid. It's a very common mistake when adding a new service: instead of creating another record, add its include to the one you already have.

It helps, but it isn't enough. Since February 2024 Gmail and Yahoo require SPF or DKIM from anyone sending to them, and SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day. They also look at the IP's reputation, the content and how recipients react. To see it all together, send a message to our email test.