SPF (Sender Policy Framework)

Without a valid SPF record, your marketing emails, transactional notifications, and sales outreach are all at higher risk of landing in spam — or being rejected entirely. Since Gmail and Yahoo rolled out their 2024 bulk sender requirements, SPF is no longer optional for any serious email programme.

What is SPF (Sender Policy Framework)?

SPF is an email authentication standard defined in RFC 7208. It works through the Domain Name System (DNS): the domain owner publishes a TXT record that lists the IP addresses and mail servers permitted to send email from that domain. Every time an email claiming to be from your domain arrives at a receiving server, that server queries your DNS for the SPF record and checks whether the sending IP is authorised.

The concept is simple: if an attacker tries to send a phishing email pretending to be from your domain, the sending server will not be on your approved list, and the receiving server can detect and block the fraud.

SPF addresses a fundamental weakness in the original SMTP protocol: email was designed in the 1970s with no built-in authentication. Any server could send mail claiming to be from any domain. SPF (standardised in 2006) was the first widely adopted solution to that problem.

Why SPF matters for email deliverability

In February 2024, Google and Yahoo implemented new requirements for bulk email senders (those sending more than 5,000 messages per day to Gmail or Yahoo addresses). SPF authentication became a mandatory requirement — not a best practice, but a hard requirement. Bulk senders without SPF face message rejection.

Beyond compliance with sender requirements, SPF improves deliverability in three concrete ways:

1. Inbox placement. Spam filters weigh authentication signals heavily. Passing SPF gives your messages a better chance of reaching the inbox rather than the spam folder.
2. Domain reputation protection. If a spammer spoofs your domain to send phishing emails, recipients who report those emails as spam damage your domain's sending reputation — even though you did not send them. SPF reduces the likelihood of successful spoofing.
3. DMARC policy enforcement. DMARC requires either SPF or DKIM to pass (and align with the From domain). Without SPF, you rely entirely on DKIM for DMARC compliance — and if DKIM breaks (as it can during email forwarding), you have no backup authentication.

How SPF works step by step

Here is what happens during the SPF check for a single incoming email:

1. A sending server attempts to deliver email to a receiving server, claiming to be from "hello@yourdomain.com".
2. The receiving server extracts the domain from the envelope sender address (not the visible From header, but the SMTP MAIL FROM command).
3. The receiving server queries DNS for the TXT record at "yourdomain.com" that starts with "v=spf1".
4. The SPF record lists authorised IPs and includes. The server checks whether the sending server's IP matches any entry.
5. The server returns a result: Pass, Fail, SoftFail, Neutral, None, TempError, or PermError.
6. The receiving server uses that result, along with DKIM and DMARC results, to decide whether to deliver, quarantine, or reject the message.

Anatomy of an SPF record

An SPF record is a DNS TXT record with a specific syntax. Here is a typical example:

Breaking this down:

• v=spf1 — version tag. Must be first. Tells the parser this is an SPF record.
• ip4:203.0.113.0/24 — authorises an IPv4 address range. Use ip6: for IPv6.
• include:_spf.google.com — tells the parser to also check Google's SPF record (for Google Workspace senders).
• include:sendgrid.net — authorises SendGrid's mail servers (for transactional email).
• -all — hard fail. Any server not listed above should be rejected.

How to set up SPF for your domain

Setting up SPF requires access to your domain's DNS settings. The process takes under 10 minutes once you know which services send email on your behalf.

1. Inventory all your sending sources. List every service that sends email from your domain: your mail server (Google Workspace, Microsoft 365, etc.), transactional email providers (SendGrid, Mailgun, Postmark), marketing automation platforms (Mailchimp, HubSpot), and CRM tools (Salesforce, Pipedrive).
2. Get the SPF include string for each provider. Every major email service provider publishes their SPF include string in their documentation. For example, Google Workspace uses "include:_spf.google.com", SendGrid uses "include:sendgrid.net".
3. Write your SPF record. Combine all includes into a single TXT record. Keep the record under 10 DNS lookups.
4. Add the TXT record to your DNS. Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, etc.) and add a TXT record at your root domain with your SPF string as the value.
5. Test the record. Use MXToolbox SPF Checker, Google Admin Toolbox, or dmarcian's SPF Surveyor to verify the record is correctly published and resolves within the 10-lookup limit.
6. Monitor with DMARC reports. Once SPF is live, set up a DMARC record to receive aggregate reports showing which sources are passing or failing SPF. This surfaces unknown sending sources you may have missed.

Common SPF mistakes

• Multiple SPF records. You can only have one SPF TXT record per domain. Multiple records cause a PermError. If you need to add a new sending source, edit the existing record — do not create a second one.
• Using "+all" (pass all). Setting "+all" at the end means any server can send on behalf of your domain, defeating the entire purpose of SPF. Always end with "-all" or at minimum "~all".
• Forgetting third-party senders. If your CRM, marketing automation platform, or transactional email provider is not in your SPF record, their emails will fail SPF and may not be delivered.
• Not checking subdomains. SPF records apply only to the exact domain they are published on. "yourdomain.com" SPF does not cover "mail.yourdomain.com" — subdomains need their own SPF records or an explicit redirect.
• Ignoring the 512-character limit. Some older DNS implementations do not support SPF records longer than 512 characters. If your record is very long due to many includes, consider SPF flattening.

SPF vs DKIM vs DMARC

Email authentication works best as a layered system. Here is how the three protocols divide responsibility:

SPF best practices for 2026

1. Publish SPF on every domain and subdomain you own — including domains you never send email from. For non-sending domains, use "v=spf1 -all" to explicitly block all email.
2. Keep the 10-lookup limit in mind. Monitor your SPF record complexity. Tools like dmarcian's SPF Surveyor show your current lookup count. Add a buffer — staying at 7-8 lookups leaves room for future senders.
3. Pair SPF with DKIM and DMARC immediately. SPF alone gives you authentication for one scenario (direct sends). DKIM covers forwarded email. DMARC ties the policies together and gives you visibility via aggregate reports.
4. Use DMARC reports to find unknown senders. Set up DMARC with "p=none" and a reporting address to collect aggregate reports. Within a few weeks, the reports will reveal every service sending email from your domain — including ones you forgot about.
5. Move to "-all" (hard fail) once your list is complete. Start with "~all" during the discovery phase. Once you are confident your SPF record includes every legitimate sender, switch to "-all" for maximum spoofing protection.

Frequently asked questions

Related glossary terms

Sources

Akshay VR

Marketing Head · theStacc · ex-Sr Marketing Specialist, ARKA 360 · Malappuram, Kerala

Akshay leads editorial and content operations at theStacc. He writes about SEO craft, content operations, and the technical decisions that underpin deliverability — including setting up email authentication the right way.

LinkedIn Author page More terms by Akshay