SPF record syntax explained: a practical guide for developers

An SPF (Sender Policy Framework) record is a DNS TXT record that specifies which servers are authorized to send email on behalf of a domain, using mechanisms like `ip4`, `include`, and `a` to list approved senders. The record must end with an `all` directive (e.g., `~all` for softfail or `-all` for hardfail) and is limited to 10 DNS lookups per evaluation to avoid errors. Common mistakes include having multiple SPF records, forgetting subdomains, or omitting the `all` directive, which can break email authentication.

SPF Sender Policy Framework is a DNS record that tells receiving mail servers which servers are allowed to send email on behalf of your domain. If a server not on that list sends email claiming to be from your domain, the receiving server can reject or flag it. Understanding the syntax makes it easier to set it up correctly and avoid common mistakes like accidentally hitting the 10-lookup limit. An SPF record is a TXT record on your domain's DNS. It always starts with: v=spf1 After that, you list your authorized senders as mechanisms, then end with an all directive. A typical SPF record looks like this: v=spf1 include: spf.google.com include:spf.sendinblue.com ip4:203.0.113.50 ~all ip4: and ip6: Authorizes a specific IP address or CIDR range. ip4:203.0.113.50 ip4:203.0.113.0/24 ip6:2001:db8::1 Use this when you know the exact IP of a mail server you control. include: Delegates to another domain's SPF record. Each include: causes one DNS lookup. include: spf.google.com include:sendgrid.net include:spf.mailchimp.com Most third-party email services give you an include: value to add. Each one authorizes all IPs in that service's SPF record. a: Authorizes the A record of a domain. If the domain's A record matches the IP the email came from, it passes. mx: Authorizes the MX records of a domain. Less common, typically used when your mail server and MX records are the same host. ptr: Avoid this one. It is slow, unreliable, and deprecated in practice. all directive The all at the end controls what happens to mail from servers not on your list: ~all softfail — fail but usually deliver anyway, marking as suspicious-all hardfail — reject the email+all pass all — authorizes everything, which defeats the purpose of SPF entirely?all neutral — no policy, same as having no SPFFor most senders, ~all is the safe starting point. Once you are confident your record is complete, switch to -all for stronger protection. SPF has a hard limit of 10 DNS lookups per evaluation. Each include: , a: , mx: , and ptr: costs one lookup. Exceed 10 and the SPF check returns permerror , which effectively means the record fails. This is a common problem when a domain uses multiple services: Google Workspace plus Mailchimp plus SendGrid plus a CRM can easily push you over the limit. To fix it: include: values with the raw IPs they resolve to but you will need to update this when the provider changes their IPs InboxGreen's SPF lookup tool shows your current record and flags lookup count issues. Multiple SPF records: You can only have one TXT SPF record per domain. A second record breaks SPF validation entirely. Merge them into one. Wrong domain: SPF needs to match the domain in the From: header for DMARC alignment. If you send from noreply@mail.yourdomain.com , the SPF record needs to be on mail.yourdomain.com . Forgetting subdomains: SPF on yourdomain.com does not cover mail.yourdomain.com or info.yourdomain.com . Each sending subdomain needs its own record. Missing all : Every SPF record must end with some form of all . Without it, the result is undefined. InboxGreen's free checker pulls your SPF record, parses the mechanisms, and runs an authentication check against your domain. No login required.