Setting up SPF is one of the most important steps in email authentication, especially if you send mail through Microsoft 365, Google Workspace, Mailchimp, SendGrid, or a custom server.
This guide explains how to set up SPF record for email, why it matters for deliverability, and how to publish a record that actually works.
What SPF Does for Email Authentication
SPF, or Sender Policy Framework, is a DNS-based email authentication standard that tells receiving mail servers which hosts are allowed to send email for your domain.
When a message arrives, the recipient server checks the domain’s SPF record against the sending IP address.
If the IP address is authorized, the message can pass SPF validation.
If not, the message may be flagged, filtered, quarantined, or rejected depending on the recipient’s anti-spam policy.
SPF is widely used alongside DKIM and DMARC.
Together, these records help prove that a message is legitimate and reduce the risk of spoofing and phishing.
Before You Create an SPF Record
Before you publish anything in DNS, list every service that sends mail using your domain.
SPF only works when the record includes all legitimate senders.
- Your website server or transactional app server
- Google Workspace or Microsoft 365
- Email marketing platforms such as Mailchimp, Klaviyo, or Brevo
- Help desk tools like Zendesk or Freshdesk
- CRM or automation tools that send notifications
You also need access to your domain’s DNS management panel, usually provided by your registrar or DNS host such as Cloudflare, GoDaddy, Namecheap, Route 53, or a managed DNS provider.
How to Set Up SPF Record for Email
The SPF record is published as a TXT record in DNS.
It starts with a version tag and then lists approved senders using mechanisms such as include, ip4, and ip6.
Step 1: Inventory all sending sources
Collect the domains, IP addresses, and third-party services that send mail from your domain.
This is the most important part of the process because missing one sender can break email delivery for legitimate messages.
For example, your business might send email from:
- Google Workspace for employee email
- Mailchimp for newsletters
- A web app on a cloud VPS for receipts
Step 2: Build a single SPF policy
SPF should usually be published as one TXT record per domain.
A basic record often begins with v=spf1 and ends with an all mechanism that defines how strict the policy is.
Example for a business using Google Workspace and Mailchimp:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
This means Google and Mailchimp are allowed, and messages from other sources should soft fail.
If you send mail from a dedicated server, you may add IP addresses like this:
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Step 3: Publish the record in DNS
Log in to your DNS provider, open the DNS zone for your domain, and create a TXT record at the root host, usually represented as @ or the domain name itself.
Paste the SPF string into the value field.
If your provider offers a TTL setting, the default is usually fine.
Lower TTLs can speed up testing, but standard values are acceptable for production use.
Step 4: Wait for DNS propagation
DNS changes are not instant everywhere.
Propagation may take a few minutes or several hours depending on the provider and cached DNS responses.
After publishing, verify the record using an SPF checker, DNS lookup tool, or email authentication testing service.
Look for syntax errors, missing senders, and multiple SPF records on the same domain.
SPF Record Syntax Explained
Understanding the parts of an SPF record makes troubleshooting much easier.
v=spf1identifies the record as SPF version 1ip4andip6authorize specific IPv4 or IPv6 addressesincludedelegates authorization to another domain’s SPF policyaauthorizes the A record of a domainmxauthorizes the mail servers listed in MX recordsalldefines the default result for all other senders
The qualifier before all matters:
~allmeans soft fail-allmeans hard fail?allmeans neutral+allis effectively open and should be avoided
For most organizations, ~all is a safe starting point while you confirm every legitimate sender.
Once the setup is stable, some teams move to -all for stricter enforcement.
Common SPF Mistakes That Break Email Delivery
SPF is simple in concept, but a few common errors cause major problems.
Publishing multiple SPF records
A domain should have only one SPF TXT record.
If you create separate records for different tools, many receivers will treat the configuration as invalid.
Forgetting a third-party sender
If a platform sends on your behalf and is not listed in SPF, those messages may fail authentication.
This is common with newsletters, help desk emails, and application alerts.
Hitting the 10 DNS lookup limit
SPF has a hard limit of 10 DNS lookups during evaluation.
Too many include, mx, a, or redirect mechanisms can cause SPF to fail.
To reduce lookup pressure, remove unnecessary services, replace broad includes with explicit IP addresses when possible, and avoid stacking multiple vendor records without reviewing the total lookup count.
Using SPF for forwarding scenarios
SPF can fail when email is forwarded because the forwarding server’s IP is not authorized by the original sender’s domain.
This is one reason DMARC and DKIM are also important.
Examples of SPF Records for Real-World Setups
Google Workspace only
v=spf1 include:_spf.google.com ~all
Microsoft 365 only
v=spf1 include:spf.protection.outlook.com ~all
Website server plus Google Workspace
v=spf1 ip4:198.51.100.25 include:_spf.google.com ~all
Multiple services including a marketing platform
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 ~all
Always verify the exact SPF include values recommended by each vendor, since service providers update their DNS records and documentation over time.
How to Test and Validate Your SPF Record
After publishing, test your SPF record using multiple checks rather than relying on a single tool.
- Use a DNS TXT lookup to confirm the record is visible
- Send a test email to a mailbox that shows authentication results
- Review the full headers for SPF pass, fail, or soft fail
- Use an email deliverability platform or SPF validator to spot syntax issues
When testing message headers, look for terms such as spf=pass, spf=fail, or spf=softfail.
These results show whether the receiver matched the sending IP to your policy.
How SPF Works with DKIM and DMARC
SPF alone does not protect a domain completely.
DKIM adds a cryptographic signature to the message, and DMARC tells receivers how to handle authentication failures and provides reporting.
In modern email security, the usual pattern is:
- SPF authorizes where mail can come from
- DKIM proves the message was not altered in transit
- DMARC enforces policy and aligns authentication with the visible From domain
For best deliverability, configure all three records together.
When to Review or Update Your SPF Record
SPF records should not be treated as one-time setup.
Review them whenever your email stack changes.
- You add a new marketing platform
- You switch hosting providers or mail servers
- You migrate from one suite to another
- You change IP addresses on your sending server
- You want to tighten enforcement from
~allto-all
Regular maintenance helps keep legitimate messages out of spam folders and prevents outages caused by outdated DNS entries.