← Back to Guides

Understanding SPF Records

Learn how SPF works, how to configure it, and how to avoid common pitfalls like exceeding the DNS lookup limit.

What Is SPF?

Sender Policy Framework (SPF) is a DNS-based email authentication protocol defined in RFC 7208. It allows a domain owner to specify which IP addresses and mail servers are authorised to send email on behalf of their domain. Receiving mail servers check the SPF record during the SMTP transaction, before the message body is even transferred, making it one of the earliest checks in the delivery pipeline.

SPF validates the envelope sender (also known as the Return-Path or MAIL FROM address), not the From: header that users see. This is an important distinction — it is DMARC's alignment check that connects SPF results back to the visible sender.

SPF Record Syntax

An SPF record is a TXT record published at the root of your domain. Every SPF record begins with a version tag and ends with a default mechanism:

v=spf1 [mechanisms] [default]

Here is a real-world example:

v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 include:_spf.google.com include:sendgrid.net mx -all

Mechanisms

Mechanisms are the rules that define authorised senders. They are evaluated from left to right, and the first match determines the result.

ip4 and ip6

Authorise a specific IPv4 or IPv6 address or range. This is the most explicit way to authorise a sender.

v=spf1 ip4:198.51.100.10 ip4:203.0.113.0/24 ip6:2001:db8::1 -all

include

Delegates authorisation to another domain's SPF record. This is how you authorise third-party services like Google Workspace, Microsoft 365, Mailchimp, or SendGrid. When the receiving server encounters an include, it looks up the referenced domain's SPF record and evaluates it.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

a

Authorises the IP addresses that your domain's A (or AAAA) records resolve to. Useful if your web server also sends email.

v=spf1 a -all

mx

Authorises the IP addresses of your domain's MX (mail exchange) servers. If your inbound mail servers also handle outbound delivery, this is a convenient shorthand.

v=spf1 mx -all

all

The catch-all mechanism that matches everything. It should always appear at the end of your record and defines the default action for senders that did not match any previous mechanism.

Qualifiers

Each mechanism can be prefixed with a qualifier that determines the result when it matches:

  • + (Pass) — The sender is authorised. This is the default if no qualifier is specified.
  • - (Fail) — The sender is explicitly not authorised. Use -all at the end of your record to hard-fail everything that does not match.
  • ~ (SoftFail) — The sender is probably not authorised. Messages are accepted but may be flagged. ~all is commonly used during initial deployment, but -all is recommended once you are confident in your record.
  • ? (Neutral) — No assertion is made about the sender. Rarely used in practice.

The 10 DNS Lookup Limit

This is the most common source of SPF failures. RFC 7208 specifies that an SPF evaluation must not require more than 10 DNS lookups. The following mechanisms each consume one lookup: include, a, mx, redirect, and exists. Notably, ip4 and ip6 do not require a DNS lookup.

Each include can itself contain further include statements, and these nested lookups count toward the same limit. For example, include:_spf.google.com alone can consume 3-4 lookups because Google's SPF record chains to other records.

If your SPF evaluation exceeds 10 lookups, the result is a permerror and SPF fails entirely — even for legitimate senders.

How to Stay Under the Limit

  • Replace include with ip4/ip6 where possible. If a service sends from a known, stable set of IP addresses, list them directly.
  • Remove unused services. Audit your SPF record regularly and remove includes for services you no longer use.
  • Use SPF flattening. Tools can resolve all includes to their underlying IP addresses and produce a flattened record. Be aware that flattened records must be updated when the service provider changes their IP ranges.
  • Avoid the a and mx mechanisms unless necessary, as each one consumes a lookup.

Common Mistakes

  • Multiple SPF records. A domain must have only one SPF TXT record. If you publish two, SPF evaluation returns a permerror. To add a new service, edit your existing record rather than creating a second one.
  • Using +all. This authorises the entire internet to send as your domain. Never use it.
  • Forgetting third-party senders. If you use services like Mailchimp, HubSpot, Zendesk, or a transactional email provider, they must be included in your SPF record or they will fail authentication.
  • Overly broad records. Including every service "just in case" wastes lookups and expands your attack surface. Only include services that actively send email as your domain.

Building Your SPF Record

Follow this process to create an effective SPF record:

  1. Inventory your senders. List every system, service, and server that sends email using your domain. Check with marketing, support, IT, and engineering teams.
  2. Gather their SPF requirements. Each service will document their recommended include or IP ranges.
  3. Count your lookups. Add up the DNS lookups and ensure you stay under 10.
  4. Publish and test. Publish your record and use DMARCWatch to monitor whether legitimate mail passes SPF.

A well-constructed SPF record for a typical organisation might look like this:

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

This record authorises Google Workspace, SendGrid, and a single server IP, then hard-fails everything else. It uses approximately 5 DNS lookups, leaving room for future additions.

← Back to Guides