What Is an SPF Record and Why Do You Need One

What is SPF

SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It allows domain owners to specify which mail servers are authorized to send emails on their behalf.

An SPF record is a line of text stored as a TXT record in your domain's DNS. When a recipient receives an email from your domain, their mail server queries DNS, reads the SPF record, and verifies whether the sending server is on the list of authorized senders.

If the server isn't on the list, the email fails SPF authentication — and the recipient's server may reject it or route it to spam.

How SPF works

The entire process happens automatically with every email delivery:

1. You send an email from your domain (e.g., example.com).
2. The receiving mail server identifies the IP address of the server that delivered the email.
3. The server queries DNS for the TXT record of example.com and retrieves the SPF record.
4. It compares the sending server's IP address against the list of authorized addresses in the SPF record.
5. The result is evaluated as pass (authorized), fail (unauthorized), softfail (suspicious), or neutral (no assertion).

The entire check takes a fraction of a second and happens on the recipient's side — as the sender, you only need to publish the correct SPF record.

Anatomy of an SPF record

An SPF record always starts with the version identifier v=spf1 and ends with the all mechanism, which determines what happens to emails from unauthorized servers.

Mechanisms

The ptr mechanism is deprecated in RFC 7208 and should not be used in practice.

Qualifiers

Each mechanism can have a prefix (qualifier) that determines the result:

How to read an SPF record

Example record for a domain using Google Workspace and a dedicated mail server:

v=spf1 include:_spf.google.com ip4:198.51.100.10 -all

• v=spf1 — protocol version (required)
• include:_spf.google.com — authorizes all Google Workspace servers
• ip4:198.51.100.10 — authorizes a specific IP address for the dedicated server
• -all — reject everything else (fail)

Why you need SPF

Protection against spoofing

Without an SPF record, anyone can send an email that appears to come from your domain. An attacker doesn't need access to your server — they simply set the "From" header to your address. This technique is called email spoofing and is the foundation of most phishing attacks.

An SPF record with -all tells recipients: "Emails from my domain can only come from these servers. Reject anything else."

Email deliverability

Major providers (Gmail, Outlook, Yahoo) require SPF as a baseline condition for inbox delivery. Since February 2024, Google and Yahoo require SPF or DKIM plus a DMARC record (at minimum p=none) for all senders. Bulk senders (over 5,000 messages per day) must have both SPF and DKIM.

Without an SPF record, your emails — including invoices, order confirmations, and critical business communications — risk landing in spam.

Domain reputation protection

Every domain has a reputation with mail providers. If someone abuses your domain to send spam or phishing emails, your reputation drops and legitimate emails stop reaching inboxes. An SPF record prevents this scenario.

SPF limitations

SPF is the foundation of email authentication, but it's not sufficient on its own. Understanding its limitations helps you set up protection correctly.

The 10 DNS lookup limit

According to RFC 7208 (section 4.6.4), SPF evaluation may trigger a maximum of 10 DNS lookups. The mechanisms include, a, mx, ptr, exists, and the redirect modifier count toward this limit. The ip4, ip6, and all mechanisms do not trigger DNS lookups.

Exceeding the limit causes a PermError — SPF authentication fails regardless of whether the sending server is authorized.

For domains with multiple mailing services (Google Workspace, marketing platform, helpdesk, billing system), you can hit this limit quickly. Each include can trigger additional nested lookups.

SPF doesn't verify the From header

SPF checks the envelope sender address (MAIL FROM), not the "From" header that recipients see in their email client. An attacker can pass SPF from their own server while inserting your address in the "From" header.

This is why SPF needs to be complemented with DKIM (verifies message integrity) and DMARC (aligns SPF and DKIM with the From header address).

SPF and forwarding

When an email is forwarded, the sending server changes but the envelope address remains the same. The new server isn't in the original domain's SPF record, so SPF authentication fails. The ARC (Authenticated Received Chain) protocol helps mitigate this problem by preserving authentication results across the forwarding chain.

How to set up SPF

1. Map all your senders — identify every server and service that sends emails from your domain (corporate mail, marketing, helpdesk, billing).
2. Build your SPF record — use include and ip4/ip6 mechanisms to authorize all legitimate senders.
3. Start with ~all — use softfail during initial deployment to avoid blocking legitimate emails you may have missed.
4. Publish the record in DNS — add the TXT record to your domain's DNS.
5. Verify the record — check the syntax and functionality of your SPF record.
6. Switch to -all — after confirming all legitimate emails pass, tighten the policy to fail.

SPF is the foundation, not the whole solution

An SPF record is the first layer of protection for your email communications. It tells the world which servers may send emails on behalf of your domain, and helps protect both your reputation and deliverability.

But SPF alone isn't enough. Set up DKIM for message integrity verification and DMARC to tie both protocols to the address recipients actually see.

Most importantly — email authentication is not a one-time setup. DNS records change, new sending services get added, IP addresses expire. Ongoing monitoring ensures your protection stays effective. Check your SPF record to see if it's properly configured.