Email spoofing is one of the most common attack vectors on the internet. Someone sends an email that appears to come from your domain, but it actually originates from a completely different server. The recipient sees your company name in the "From" field and trusts it. SPF (Sender Policy Framework) is the first line of defense against this, and setting it up correctly is one of the most important things you can do for your domain's email security.

This guide walks you through everything you need to know about SPF records: what they are, how they work, and exactly how to set one up for your domain.

What Is SPF and Why Does It Matter?#

SPF, or 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 email on behalf of their domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to verify that the sending server is actually authorized.

Why SPF Matters#

Without an SPF record, anyone can send email that appears to come from your domain. This creates several serious problems:

Email spoofing and phishing: Attackers can impersonate your brand to trick your customers, partners, or employees into revealing sensitive information or clicking malicious links.
Deliverability issues: Major email providers like Gmail, Outlook, and Yahoo use SPF as a signal when deciding whether to deliver an email to the inbox or send it to spam. Domains without SPF records are more likely to have their legitimate emails filtered.
Brand reputation damage: If spammers use your domain to send bulk junk mail, your domain's reputation score drops across email provider networks. This affects deliverability for all email you send, including legitimate business communications.
Compliance requirements: Many industry standards and regulations expect organizations to implement email authentication. SPF is the baseline.

How SPF Works#

Understanding the mechanics of SPF helps you set it up correctly and troubleshoot issues when they arise.

The SPF Check Process#

Your organization sends an email from you@yourdomain.com using your authorized mail server.
The receiving mail server extracts the domain from the envelope sender (the Return-Path header, not the From header).
The receiving server performs a DNS TXT lookup on yourdomain.com to retrieve the SPF record.
The server compares the sending server's IP address against the list of authorized IPs and hostnames in the SPF record.
Based on the comparison, the server returns one of these results:
- Pass: The sending server is authorized. The email proceeds normally.
- Fail: The sending server is not authorized, and the domain owner has explicitly said to reject unauthorized senders.
- SoftFail: The sending server is not authorized, but the domain owner is not confident enough to request outright rejection. The email is typically accepted but flagged.
- Neutral: The domain owner makes no assertion about the sending server.

The SPF Record Format#

An SPF record is a DNS TXT record published on your domain. It follows a specific syntax:

v=spf1 [mechanisms] [qualifier]

v=spf1 is required and identifies the record as SPF version 1.
Mechanisms define which servers are authorized.
The qualifier at the end defines the default policy for servers that do not match any mechanism.

Here is a real-world example:

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

This record says: Allow Google's mail servers, SendGrid's mail servers, and the specific IP address 203.0.113.50 to send email for this domain. Reject everyone else.

Step-by-Step SPF Setup#

Follow these steps to create and publish an SPF record for your domain.

Step 1: Identify All Your Email Sending Services#

Before writing your SPF record, you need a complete list of every service and server that sends email on behalf of your domain. This is the most commonly overlooked step, and missing a sending source will cause those emails to fail SPF checks.

Common email sending sources include:

Your email provider: Google Workspace, Microsoft 365, Zoho Mail, ProtonMail, etc.
Transactional email services: SendGrid, Mailgun, Amazon SES, Postmark, Resend, etc.
Marketing email platforms: Mailchimp, HubSpot, ActiveCampaign, ConvertKit, etc.
Your web server: If your website sends emails directly (contact form submissions, password resets, order confirmations).
CRM and support tools: Zendesk, Freshdesk, Intercom, Salesforce, etc.
Other SaaS tools: Any application that sends email using your domain.

Write down every service. Check with different departments in your organization. Marketing might use a platform that engineering does not know about, and vice versa.

Step 2: Gather the SPF Include Values#

Each email service provider publishes their own SPF include domain. Here are the include values for common providers:

Provider	SPF Include
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
SendGrid	`include:sendgrid.net`
Mailgun	`include:mailgun.org`
Amazon SES	`include:amazonses.com`
Mailchimp	`include:servers.mcsv.net`
Postmark	`include:spf.mtasv.net`
Zoho Mail	`include:zoho.com`
HubSpot	`include:hubspot-email.com`
Freshdesk	`include:email.freshdesk.com`

Check your provider's documentation for the exact include value. Providers occasionally update these, so always verify with the current docs.

Step 3: Build Your SPF Record#

Combine the version tag, all your include mechanisms, and a qualifier into a single record.

Template:

v=spf1 [include:provider1] [include:provider2] [ip4:your.server.ip] [qualifier]

Example for a business using Google Workspace and SendGrid:

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

Example for a business using Microsoft 365, Mailchimp, and a custom mail server:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 -all

Step 4: Choose Your Qualifier#

The qualifier at the end of your SPF record defines what happens when an email comes from a server that is not listed in your record:

-all (Fail): Unauthorized servers should be rejected. This is the recommended setting for maximum protection. It tells receiving servers that you are confident in your list and any email from an unlisted server is fraudulent.
~all (SoftFail): Unauthorized servers should be treated with suspicion but not outright rejected. Use this during initial setup or testing when you are not yet certain you have listed all legitimate sending sources.
?all (Neutral): No assertion is made. This provides almost no protection and is not recommended.
+all (Pass): Everyone is authorized. This completely defeats the purpose of SPF. Never use this.

Recommendation: Start with ~all during your initial rollout and testing period. Once you have confirmed that all legitimate email is passing SPF checks, switch to -all for full protection.

Step 5: Publish the Record in DNS#

Log into your DNS provider (Cloudflare, Route53, GoDaddy, Namecheap, etc.) and add or update the TXT record:

Navigate to your domain's DNS management page.
Add a new TXT record (or edit the existing SPF record if one exists).
Set the Host/Name to @ (this represents your root domain).
Set the Value/Content to your complete SPF record string.
Set the TTL to 3600 (1 hour) or your provider's default.
Save the record.

DNS changes can take up to 48 hours to propagate globally, though most changes are visible within 15 minutes to an hour.

Step 6: Verify Your SPF Record#

After publishing, verify that the record is correctly configured. You can use the Nova Uptime Email Health Checker to run a comprehensive check on your domain's email configuration, including SPF validation. The tool checks your SPF record syntax, evaluates your qualifier policy, counts DNS lookups, and identifies potential issues.

You can also verify from the command line:

dig TXT yourdomain.com +short

nslookup -type=TXT yourdomain.com

Look for the TXT record that starts with v=spf1. Confirm that all your expected include mechanisms are present and the qualifier is correct.

Understanding SPF Mechanisms#

SPF records support several mechanism types that give you flexibility in defining authorized senders.

`include`

References another domain's SPF record. This is the most common mechanism because it is how email service providers publish their authorized IP ranges.

include:_spf.google.com

When the receiving server encounters this, it performs an additional DNS lookup to retrieve Google's SPF record and checks the sending IP against Google's authorized ranges.

`ip4` and `ip6`

Specifies individual IP addresses or CIDR ranges that are authorized to send email.

ip4:203.0.113.50
ip4:198.51.100.0/24
ip6:2001:db8::/32

Use this for your own mail servers or any service where you know the specific IP addresses.

`a`

Authorizes the IP address that your domain's A record points to. If your web server also sends email, this is a concise way to authorize it.

`mx`

Authorizes the IP addresses of your domain's MX (mail exchange) servers. Since your MX servers receive email, they often need to send email as well (replies, bounces, forwards).

mx

`redirect`

Points to another domain's SPF record entirely, replacing your own. Different from include because it replaces rather than supplements.

redirect=_spf.example.com

Common SPF Mistakes and How to Avoid Them#

Mistake 1: Exceeding the 10 DNS Lookup Limit#

The SPF specification (RFC 7208) limits the total number of DNS lookups to 10. Each include, a, mx, and redirect mechanism counts as one lookup. Nested includes (an include that itself contains includes) also count toward this limit.

If your record exceeds 10 lookups, the SPF check returns a PermError result, and many receiving servers will treat this the same as having no SPF record at all.

How to fix it:

Replace include mechanisms with ip4/ip6 where possible (IP mechanisms do not count as DNS lookups).
Use SPF flattening tools to resolve includes into their underlying IP addresses.
Consolidate email services where feasible.
Remove includes for services you no longer use.

Mistake 2: Publishing Multiple SPF Records#

A domain must have exactly one SPF record. If you publish two TXT records that both start with v=spf1, the SPF check returns a PermError. This commonly happens when someone adds a new SPF record without removing or updating the existing one.

How to fix it: Merge all your authorized senders into a single SPF record.

Wrong:

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

Correct:

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

Mistake 3: Using `+all`

Setting +all as your qualifier means every server in the world is authorized to send email as your domain. This completely negates the purpose of SPF and is a serious security risk.

Mistake 4: Forgetting to Update After Changing Providers#

When you switch email providers, migrate marketing platforms, or add new SaaS tools, your SPF record needs to be updated. Old includes for services you no longer use waste DNS lookups, and missing includes for new services cause legitimate email to fail.

Mistake 5: Not Testing After Changes#

Every time you modify your SPF record, test it. Send test emails from all your services and verify they pass SPF checks. Use tools like the Nova Uptime Email Health Checker to validate your record syntax and configuration.

SPF and the Bigger Email Authentication Picture#

SPF is one of three major email authentication protocols. For comprehensive protection, you should implement all three:

SPF + DKIM + DMARC#

SPF verifies that the sending server is authorized for the domain.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails, verifying that the message was not altered in transit and was sent by an authorized party.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. It also provides reporting so you can see who is sending email as your domain.

Together, these three protocols provide robust protection against email spoofing and phishing. SPF alone is a strong start, but it is most effective when combined with DKIM and DMARC.

Testing Your SPF Record#

After setting up your SPF record, thorough testing is essential. Here is a testing checklist:

DNS verification: Confirm the record exists and is syntactically correct using DNS lookup tools.
Send test emails: Send emails from every authorized service and check the email headers on the receiving end for spf=pass.
Check the lookup count: Make sure your total DNS lookups are 10 or fewer.
Verify only one SPF record exists: Check that you do not have duplicate SPF TXT records.
Test with an unauthorized server: If possible, send an email from an unauthorized source and confirm it fails or soft-fails SPF.

The Nova Uptime Email Health Checker automates most of these checks. Enter your domain and get an instant report on your SPF record, including the specific policy strength, any syntax issues, and recommendations for improvement. It also checks your DKIM and DMARC configuration so you can see your complete email authentication posture in one place.

Maintaining Your SPF Record#

SPF is not a set-it-and-forget-it configuration. Schedule regular reviews:

Quarterly audits: Review your SPF record against your current list of email sending services. Remove old includes and add new ones.
After any infrastructure change: Whenever you add, remove, or change an email service provider, update your SPF record immediately.
After deliverability issues: If you notice emails landing in spam, check your SPF record first. A misconfigured record is one of the most common causes.
Automated monitoring: Use an email health monitoring tool to continuously check your SPF configuration and alert you if it breaks.

Summary#

Setting up SPF correctly is one of the highest-impact, lowest-effort improvements you can make to your domain's email security and deliverability. To recap:

List every service that sends email as your domain.
Gather the SPF include values for each service.
Build a single SPF record combining all authorized senders.
Start with ~all and graduate to -all once you have confirmed everything works.
Publish the TXT record in DNS.
Verify with the Nova Uptime Email Health Checker.
Review and update quarterly.

Your email reputation is built over months and can be destroyed in days. A properly configured SPF record is the foundation that keeps it protected.

Frequently Asked Questions#

How do I check my SPF record?#

Use a free SPF checker tool to look up and validate your SPF record. Enter your domain and the tool queries DNS for your TXT record, validates the syntax, counts DNS lookups (max 10 allowed), and checks your enforcement policy. You can also check with dig TXT yourdomain.com or nslookup -type=TXT yourdomain.com.

What does an SPF check do?#

An SPF check verifies that the server sending email on behalf of your domain is authorized in your SPF DNS record. Receiving mail servers perform this check automatically. If the sending IP is not listed in your SPF record, the email may be marked as spam or rejected depending on your DMARC policy.

How do I test my SPF record?#

After publishing your SPF record, test it by: (1) running a free SPF check, (2) sending a test email to Gmail and checking the "Show original" headers for spf=pass, or (3) using nslookup -type=TXT yourdomain.com to verify the record is published correctly.

What is the SPF 10-lookup limit?#

SPF records are limited to 10 DNS lookups. Each include:, a:, mx:, ptr:, and redirect= mechanism counts as one lookup. Exceeding this limit causes a permanent SPF failure (permerror), which means all your email fails SPF. Use the SPF Checker to count your current lookups.

Should I use -all or ~all in my SPF record?#

Use -all (hard fail) for maximum protection — it tells receiving servers to reject email from unauthorized sources. Use ~all (soft fail) during initial setup or migration. Once you have confirmed all legitimate senders are included, switch to -all. Our Email Health Checker checks your SPF policy and recommends the appropriate setting.

SPF Record Lookup & Validation Guide — Advanced SPF configuration and troubleshooting
SPF, DKIM & DMARC Complete Guide — How SPF fits into the full authentication stack
Email Deliverability Checklist — 15 steps including SPF setup
DMARC Setup: None to Reject — Configure DMARC after SPF is ready
Free SPF Checker — Validate your SPF record instantly