What Is SPF and How to Set Up an SPF Record

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which servers are allowed to send email on behalf of your domain. When someone receives an email from your-domain.com, their mail server checks the SPF record to see if the sending server is authorized. If it is not, the email is flagged as suspicious or rejected.

Without an SPF record, anyone can send email pretending to be from your domain. Spammers do this constantly. They forge the “From” address to make their spam look like it comes from a legitimate domain. SPF is the first line of defense against this. It does not stop all spoofing on its own (that requires DKIM and DMARC as well), but it is the foundation that the other mechanisms build on.

How SPF works#

The process happens automatically on every email delivery:

1. Someone sends an email from user@your-domain.com
2. The receiving mail server extracts the domain from the sender address
3. The receiving server performs a DNS lookup on your-domain.com and retrieves the TXT record that starts with  v=spf1
4. The server checks whether the IP address of the sending server matches any of the authorized sources in your SPF record
5. Based on the result, the receiving server marks the email as pass, fail, softfail, or neutral

If the sending server’s IP is listed in your SPF record (directly or through an include), the check passes. If it is not listed, the result depends on your “all” mechanism (covered below).

The entire check happens at the mail server level. The sender and recipient never see it unless the email fails and gets rejected or sent to spam.

SPF record syntax#

An SPF record is a DNS TXT record on your domain. It starts with v=spf1 and contains a series of mechanisms that define which servers are authorized to send email for your domain.

A basic SPF record:

v=spf1 include:_spf.google.com ~all

Breaking this down:

• v=spf1 — declares this is an SPF record, version 1. This must be the first element. Every SPF record starts with this.
• include:_spf.google.com — authorizes all servers that Google Workspace uses to send email.
• ~all — anything not matching the previous mechanisms gets a softfail (suspicious but not rejected).

Mechanisms

Mechanisms are the building blocks of an SPF record. Each one defines a source that is authorized to send email.

The “all” mechanism

The all mechanism appears at the end of every SPF record. It defines what happens when an email comes from a server that does not match any of the preceding mechanisms. The qualifier before all determines the policy:

~all vs -all

~all (softfail) is the safer choice for most domains. It tells receiving servers that unauthorized senders should be treated with suspicion, but leaves the final decision to the receiver’s spam filter. This gives you room for error: if you forgot to include a legitimate sending source, those emails get flagged rather than hard-rejected.

-all (hardfail) is stricter. Unauthorized senders are told to reject the email outright. This is stronger protection but can cause problems if your SPF record is incomplete. A transactional email service you forgot to include, a marketing tool someone on your team started using, a forwarding service that relays your emails — all of these break with -all if they are not in the record.

Start with ~all . Move to -all after you have verified that your SPF record covers every legitimate sending source and you have DMARC reporting in place to catch any misses.

Setting up SPF for common providers#

Google Workspace

v=spf1 include:_spf.google.com ~all

This covers all the servers Google uses for Gmail, Calendar invites, and other Google Workspace email.

Microsoft 365

v=spf1 include:spf.protection.outlook.com ~all

Covers all Microsoft 365 email servers.

Mailchimp

Mailchimp sends email through its own servers. To authorize them, add Mailchimp’s SPF include:

v=spf1 include:servers.mcsv.net ~all

If you also use Microsoft 365 for regular email, combine them:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

SendGrid

v=spf1 include:sendgrid.net ~all

Combined with Microsoft 365:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Multiple providers

You can include multiple providers in a single SPF record. Each include: adds another set of authorized servers:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net ~all

The order of mechanisms does not matter. The receiving server checks all of them. But keep an eye on the DNS lookup limit (covered in the common mistakes section below).

Your own server

If your web server sends email directly (for example, WordPress sending notification emails through the server’s local mail service), add its IP address:

v=spf1 ip4:203.0.113.50 include:spf.protection.outlook.com ~all

Replace 203.0.113.50 with your server’s actual IP address.

Adding an SPF record on GoDaddy#

1. Log in to your GoDaddy account
2. Go to My Products and find your domain
3. Click DNS (or Manage DNS)
4. Click Add Record
5. Select TXT as the record type
6. Set Name to  @  (this means the root domain)
7. Set Value to your SPF record (e.g.,  v=spf1 include:spf.protection.outlook.com ~all )
8. Set TTL to 1 hour (or the default)
9. Save

If a TXT record starting with v=spf1 already exists, edit that record instead of creating a new one. You must never have two SPF records on the same domain.

Adding an SPF record on Namecheap#

1. Log in to your Namecheap account
2. Go to Domain List and click Manage next to your domain
3. Go to the Advanced DNS tab
4. Click Add New Record
5. Select TXT Record
6. Set Host to  @
7. Set Value to your SPF record
8. Set TTL to Automatic
9. Save

Same rule: if an SPF record already exists, edit it. Do not create a second one.

Adding an SPF record on Hostney#

On Hostney, DNS records are managed through the control panel. Go to Hosting > DNS Zone Editor, add a TXT record for @ with your SPF value, and save. Changes propagate within the TTL period.

Since Hostney does not provide email services, your SPF record will reference your email provider (Microsoft 365, Google Workspace, or whichever service you use) rather than Hostney’s servers.

Verifying your SPF record#

After creating or modifying your SPF record, verify it is correct and resolving properly.

Using the Hostney DMARC checker

Go to tools.hostney.com/dmarc, enter your domain, and the tool checks your SPF, DKIM, and DMARC records. It shows the parsed SPF record, any syntax errors, and whether the record resolves correctly.

Using dig

From the command line:

dig +short TXT your-domain.com | grep spf

This queries the DNS TXT records for your domain and filters for the SPF record. You should see your complete SPF record in the output.

Using nslookup

On Windows:

nslookup -type=txt your-domain.com

Check from multiple locations

DNS changes take time to propagate. After adding or changing an SPF record, it may take up to the TTL duration (often 1 hour) for all DNS servers to see the update. If verification fails immediately after making a change, wait an hour and try again.

Common SPF mistakes#

Multiple SPF records

A domain must have exactly one SPF record. If you have two TXT records that both start with v=spf1 , the SPF check fails for every email because the receiving server does not know which record to use.

Wrong (two separate records):

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

Right (one combined record):

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

This is the single most common SPF mistake. It happens when someone adds a new provider by creating a new record instead of editing the existing one.

Exceeding the 10 DNS lookup limit

The SPF specification limits the number of DNS lookups to 10 per SPF check. Each include: , a , mx , and redirect mechanism counts as one lookup. Each include: can itself contain further include: mechanisms, and those count toward the limit too.

The ip4: and ip6: mechanisms do not count because they do not require a DNS lookup.

When you exceed 10 lookups, the SPF check returns a permanent error (permerror), and many receiving servers treat this as a fail. Your legitimate emails may be rejected or marked as spam.

To check your lookup count, use an SPF flattening tool or the Hostney DMARC checker at tools.hostney.com/dmarc. If you are over 10, consider:

• Replacing include: with ip4: where possible. If a sending service uses a small, stable set of IP addresses, you can list them directly instead of using include. The downside is that if the provider changes their IPs, your record breaks. Only do this for services with well-documented, static IP ranges.
• Using an SPF flattening service. These services resolve your include: mechanisms into IP addresses automatically and keep the flattened record updated. This reduces your lookup count but adds a dependency on the flattening service.
• Consolidating email providers. If you are using five different services that all send email from your domain, consider whether you actually need all five.

Using +all

v=spf1 +all

This authorizes every server on the internet to send email as your domain. It is equivalent to having no SPF record at all. Never use +all .

Forgetting transactional email services

Your domain might send email from more sources than you realize:

• Your email provider (Microsoft 365, Google Workspace)
• Your marketing tool (Mailchimp, HubSpot, Mailerlite)
• Your transactional email service (SendGrid, Postmark, Amazon SES)
• Your web server (WordPress notification emails, WooCommerce order confirmations)
• Your CRM (Salesforce, Zoho)
• Your helpdesk (Zendesk, Freshdesk)

Each one that sends email as your domain needs to be in your SPF record. Audit all the services connected to your domain before setting your SPF record.

If your WordPress site or WooCommerce store sends order confirmations and notification emails, those need to come from an authorized source too. Many sites route these through an SMTP plugin connected to their email provider or a transactional email service, which avoids the reliability issues of sending directly from the web server.

SPF on subdomains

SPF records are per-domain. An SPF record on example.com does not apply to mail.example.com or shop.example.com . If you send email from a subdomain, that subdomain needs its own SPF record.

If you do not send email from a subdomain, add an SPF record that explicitly says so:

v=spf1 -all

This tells receiving servers that no server is authorized to send email from that subdomain. It prevents spammers from using your subdomains for spoofing.

SPF alone is not enough#

SPF verifies that the sending server is authorized, but it has limitations:

• SPF checks the envelope sender, not the From header. The “From” address that the recipient sees in their email client can still be forged even if SPF passes. SPF checks the return-path address, which is a different field.
• SPF breaks with email forwarding. When an email is forwarded, the forwarding server’s IP is what the receiving server sees. That IP is not in the original sender’s SPF record, so the check fails. This is a known limitation of SPF.
• SPF does not provide encryption or message integrity. It only verifies the source server.

For complete email authentication, you need all three:

• SPF verifies which servers can send email from your domain
• DKIM adds a cryptographic signature to each email, proving it was not tampered with in transit
• DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when checks fail, and sends you reports about authentication results

Setting up all three gives receiving servers confidence that email from your domain is legitimate, which directly improves deliverability.