The Complete Guide to SPF Records

SPF (Sender Policy Framework) is one of the foundational technologies behind email deliverability. If you send email from your own domain, whether that's transactional messages, marketing campaigns, or everyday business communication, SPF determines whether those emails are trusted or treated as suspicious.

This guide covers everything you need to know about SPF. Each section gives you the essentials and links to deeper resources where you can learn more.

What SPF Is and Why It Matters

SPF is an email authentication standard, defined in RFC 7208, that lets you declare which servers are allowed to send email on behalf of your domain. You publish this declaration as a DNS record, and receiving mail servers check it every time they get an email claiming to be from you.

Think of it like a guest list at an event. Your domain is the venue, and the SPF record is the guest list posted at the door. When an email arrives claiming to be from your domain, the receiving server checks the list. If the sending server is on it, the email is more likely to be trusted. If not, it may be flagged or rejected.

Without SPF, anyone can send email that appears to come from your domain. Spammers and phishers exploit this constantly, sending fake invoices, password reset scams, and fraudulent messages that look like they came from your business. SPF stops them by giving you a way to say "only these servers speak for me."

SPF also directly impacts your inbox placement. Providers like Gmail, Outlook, and Yahoo all use SPF as a trust signal when deciding where to deliver your messages. Google's Email Sender Guidelines require SPF authentication for all senders. A properly configured SPF record improves your chances of landing in the inbox rather than the spam folder. Over time, consistent authentication builds your domain's sender reputation, which compounds into better deliverability across all your email.

If you're brand new to SPF, start with What is SPF? for a plain-English introduction that covers the basics without any technical jargon.

How SPF Authentication Works

When someone receives an email from your domain, their mail server performs a quick behind-the-scenes check. It looks up your domain's SPF record in DNS, then compares the sending server's IP address against the list of authorized sources in that record. If the IP matches, SPF passes. If it doesn't, the result is a fail, softfail, or neutral, depending on how your record is configured.

This entire process happens in milliseconds and is invisible to both sender and recipient. But the result has a real impact on whether your email reaches the inbox, lands in spam, or gets rejected entirely.

For a complete walkthrough of this process, read How SPF Works. It explains the authentication flow step by step, including how SPF interacts with the envelope sender address and what happens at each stage of evaluation.

SPF Record Syntax and Mechanisms

An SPF record is a single line of text published as a DNS TXT record. It always starts with v=spf1 and ends with an all mechanism that defines the default policy. Between those, you list the servers and services authorized to send email for your domain.

SPF uses several mechanisms to define authorized senders. Each serves a specific purpose:

The a mechanism authorizes the IP addresses associated with a domain's A or AAAA records. It's useful when your web server also sends email, but it can be misused when include is the better choice. Learn how it works and when to use it in The SPF "a" Mechanism Explained.

The include mechanism is how you authorize third-party email services. When you add include:_spf.google.com, you're telling the world that Google's mail servers can send email for your domain. This is the most common mechanism in modern SPF records. Read more in The SPF Include Mechanism.

The ip4 and ip6 mechanisms authorize specific IP addresses or ranges directly. These are useful for on-premise mail servers or services that provide IP addresses instead of include statements. See SPF ip4 and ip6 Mechanisms for syntax and examples.

The mx mechanism authorizes the servers listed in your domain's MX records. Since these are the servers that receive your email, they're often the same ones that send it. Learn more in the SPF "a" Mechanism guide, which covers mx as a related mechanism.

The all mechanism is the catch-all at the end of every SPF record. It defines what happens when an email comes from a server that doesn't match any other mechanism. The qualifier you use (-all, ~all, ?all, or +all) determines how strict your policy is. This is important enough to have its own guide.

The redirect modifier lets you point your domain's SPF evaluation to another domain's record entirely. This is different from include and is covered in The SPF Redirect Modifier.

The exists mechanism is an advanced option that checks whether a specific domain resolves in DNS. It's rarely needed but powerful for complex setups. Learn about it in The SPF Exists Mechanism.

For a complete reference of SPF syntax, see the SPF Syntax Guide. For real-world record examples, check out SPF Record Examples. And if you're curious about advanced dynamic evaluation, SPF Macros Explained covers that niche topic.

Setting Up SPF for Your Email Provider

The most important step in configuring SPF is making sure every service that sends email on your behalf is included in your record. Each provider has its own include statement or IP addresses that need to be added.

Most businesses are surprised by how many services actually send email on their behalf. Beyond your primary email provider, you likely have marketing tools, a CRM, a help desk, transactional email for your website, and possibly more. Every one of these needs to be authorized in your SPF record.

The general process is the same for every provider: find their SPF include statement (usually in their documentation or setup wizard), then add it to your SPF record. Here are our step-by-step guides for the most popular email services:

Business email platforms handle your day-to-day email. If you use Google Workspace or Microsoft 365, these guides walk you through the exact SPF configuration each requires. For smaller teams, Zoho Mail and Gmail (free accounts) have their own setup instructions.

Email marketing and automation tools send campaigns and automated sequences on your behalf. We have guides for Mailchimp, SendGrid, HubSpot, Brevo, Klaviyo, Constant Contact, ActiveCampaign, and ConvertKit.

Transactional email services handle password resets, order confirmations, and other triggered messages. See our guides for Amazon SES, Mailgun, and Postmark.

CRM and support platforms often send email on your behalf too. Check our guides for Salesforce, Zendesk, and Freshdesk.

Website platforms with built-in email features include Shopify, Squarespace, and Wix.

If you use more than one of these services, you'll need to combine them all into a single SPF record. Our guide on SPF for Multiple ESPs explains exactly how to do this without breaking anything.

Need help generating a record? SPF Creator builds one for you based on the services you select.

Adding SPF Records at Your DNS Host

Once you know what your SPF record should contain, you need to add it as a TXT record at whatever service manages your domain's DNS. Your DNS host is where you registered your domain or wherever you've pointed your nameservers. If you're not sure who manages your DNS, a WHOIS lookup on your domain will tell you.

The process is slightly different at each provider, but the concept is always the same: log in to your DNS management panel, create a new TXT record for your root domain (usually represented as @), and paste your SPF value into the record content field. Make sure you don't create a second SPF record if one already exists -- edit the existing one instead.

We have step-by-step guides with screenshots for the most popular DNS hosts and domain registrars:

Major DNS and hosting providers: Cloudflare, GoDaddy, Namecheap, Bluehost, SiteGround, Hostinger, and IONOS.

Cloud DNS services: AWS Route 53, DigitalOcean, and OVH.

Domain registrars: Porkbun, Hover, Gandi, and Squarespace Domains.

Using Multiple Email Services

Most growing businesses use more than one service that sends email. You might have Google Workspace for business email, SendGrid for transactional messages, and Mailchimp for newsletters. Each of these needs to be authorized in your SPF record, but here's the critical rule: you can only have one SPF record per domain.

This means you need to combine all your providers into a single record. Instead of creating separate SPF records for each service, you list all the include statements together:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all

The challenge comes when you have so many services that you exceed the 10 DNS lookup limit. Each include counts as one or more lookups, and the limit adds up fast. Our complete guide to SPF for Multiple ESPs covers strategies for combining providers, managing lookup limits, and using subdomains to split your email sending.

Troubleshooting SPF Issues

Even a well-configured SPF record can run into problems. Records break when you add new services, hit technical limits, or make small syntax mistakes that cause big authentication failures.

Start with the basics. The most common issues are covered in Common SPF Errors, which explains every SPF result code and what causes each one. If your emails are failing SPF but you can't figure out why, SPF Record Not Working is a systematic troubleshooting guide.

Record not found? If lookups show no SPF record at all, SPF Record Not Found walks through the most likely causes, from DNS misconfigurations to propagation delays.

Permanent errors and syntax problems are covered in SPF PermError, which explains what causes permanent evaluation failures and how to fix them. Temporary failures are less common but still worth understanding, covered in SPF TempError.

Record too long? SPF records are limited to 255 characters per DNS string (though they can span multiple strings). If yours is getting unwieldy, SPF Record Too Long explains your options.

Hitting the DNS lookup limit is one of the most common SPF problems for businesses using multiple email services. Per RFC 7208, Section 4.6.4, SPF allows a maximum of 10 DNS lookups per evaluation. Learn why this limit exists and how to stay under it in SPF 10 DNS Lookup Limit. If you need to reduce lookups, SPF Flattening Explained covers one popular approach, and SPF Void Lookups explains a related limit you might not know about.

Email forwarding problems are inherent to how SPF works. When an email is forwarded, the sending IP changes but the SPF record doesn't account for the new server. SPF and Email Forwarding explains the problem and workarounds.

Managing SPF across multiple domains or subdomains introduces its own challenges. See SPF Record Multiple Domains and SPF Record Inheritance for guidance on these scenarios. And if you want to do a thorough review of your current setup, SPF Record Audit provides a checklist.

SPF and Email Authentication

SPF doesn't work alone. It's one leg of a three-part email authentication system that also includes DKIM and DMARC. Understanding how they work together gives you the best protection against spoofing and the best chance of reaching the inbox.

DKIM (DomainKeys Identified Mail, RFC 6376) adds a digital signature to your emails that proves the message hasn't been altered in transit. Unlike SPF, which checks the sending server, DKIM checks the message itself. This means DKIM survives email forwarding, which is one of SPF's known weaknesses. You can check your DKIM setup at DKIM Test.

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) ties SPF and DKIM together. It lets you publish a policy that tells receiving servers what to do when both SPF and DKIM fail, and it sends you reports about who is sending email using your domain. Check your DMARC configuration at DMARC Record Checker.

SPF, DKIM, and DMARC Explained is the best starting point for understanding how these three standards complement each other and why you need all three.

SPF alignment is a concept that matters once you implement DMARC. It's about whether the domain in your SPF check matches the domain in your visible From address. Misalignment is a common cause of DMARC failures even when SPF passes. SPF Alignment Explained covers this in detail.

Softfail vs hardfail is a choice you'll make when writing your SPF record. The decision affects how receiving servers handle unauthorized emails. We recommend starting with softfail (~all) and moving to hardfail (-all) once you're confident your record is complete. SPF Softfail vs Hardfail helps you choose the right approach for your situation.

For quick answers to common questions, the SPF FAQ covers the most frequently asked questions we see. And for understanding how SPF records relate to other DNS record types, see SPF and DNS Records.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specification
• RFC 7489: DMARC — Domain-based Message Authentication, Reporting, and Conformance
• Google Email Sender Guidelines — Google's authentication requirements for senders

Check Your Email Authentication

You can check all three authentication standards, SPF, DKIM, and DMARC, using the Email Deliverability Checker. It gives you a complete picture of your domain's email authentication posture in one place.

For individual checks:

• SPF: Use the checker at the top of this page
• DKIM: DKIM Test
• DMARC: DMARC Record Checker