Setting Up SPF Records: A Complete Guide

Introduction

When an email arrives at Gmail or Outlook, the receiving server asks a simple question: "Is the server that sent this email actually allowed to send mail for this domain?" The answer comes from your SPF record, a short text entry in your DNS that lists every server authorized to send email on your behalf.

Without an SPF record—or with one that's incorrectly configured—your legitimate emails may be marked as spam, and attackers can impersonate your domain with impunity. In 2025, every major email provider checks SPF as part of its authentication pipeline. It's no longer optional.

How SPF Works

SPF is elegantly simple. You publish a TXT record in your DNS that contains a list of IP addresses and hostnames authorized to send email. When a receiving mail server gets a message claiming to be from your domain, it looks up your SPF record, checks whether the sending server's IP is on the approved list, and acts accordingly.

The receiving server checks the MAIL FROM domain (also called the envelope sender or return-path), not the From: header that the recipient sees. This distinction matters: SPF authenticates the envelope sender, while DMARC aligns the envelope sender with the header sender to prevent spoofing.

Here's what a basic SPF record looks like:

v=spf1 ip4:192.0.2.1 include:spf.protection.outlook.com -all

This record says: "Only the IP 192.0.2.1 and servers authorized by Microsoft's SPF record can send mail for my domain. Reject everything else."

SPF Syntax Essentials

Understanding SPF syntax lets you build accurate records without guessing. Here are the key mechanisms:

ip4: and ip6: — Authorize specific IP addresses or CIDR ranges. Use these for servers with static IPs, like your office mail server.

include: — Include another domain's SPF record. Use this for third-party services like Google Workspace, Microsoft 365, or SendGrid. The included domain is recursively evaluated.

a: — Authorize the IP of a specific hostname. a:mail.yourdomain.com means the IP that mail.yourdomain.com resolves to is authorized.

mx: — Authorize the IPs of your domain's MX (mail exchanger) records. Convenient but can be overly broad if your MX records point to a shared hosting provider.

all — The catch-all at the end. Prefixed with - (reject), ~ (softfail), or + (pass). Always use -all for a reject policy or ~all while testing.

Modifiers like redirect= point the entire SPF check to another domain's record, while exp= provides a custom error message for SMTP rejects.

Common SPF Mistakes to Avoid

Too many DNS lookups. SPF has a hard limit of 10 DNS lookups per evaluation. Every include:, a:, and mx: mechanism counts as a lookup—and nested includes inside third-party records count too. If you exceed 10, SPF returns a "permerror" and email delivery may fail. Flatten your SPF record by resolving includes to IPs where possible, or use a dedicated SPF hosting service.

Multiple SPF records. You can only have one SPF record per domain. If you add a second TXT record starting with v=spf1, receiving servers may reject both. Always consolidate into a single record.

Using +all. A record ending in +all authorizes every server on the internet to send mail for your domain. This is worse than having no record at all.

Forgetting about subdomains. SPF records only apply to the domain they're published on unless you explicitly cover subdomains. If your marketing platform sends from news.yourdomain.com, that subdomain needs its own SPF record.

Neglecting ptr: deprecation. The ptr: mechanism is deprecated and should never be used. It causes excessive DNS queries and is trivially bypassed.

Creating Your SPF Record

Step 1: Inventory your email senders. List every service that sends email using your domain: your email host (Google Workspace, Microsoft 365), your CRM (Salesforce, HubSpot), your transactional email provider (Postmark, SendGrid), your marketing platform (Mailchimp, ConvertKit), and any on-premises servers.

Step 2: Find each service's SPF include. Reputable email providers publish their SPF include values in their documentation. For example, Google Workspace uses include:_spf.google.com and Microsoft 365 uses include:spf.protection.outlook.com.

Step 3: Build your record. Combine all includes and IPs into a single string, ending with your chosen all mechanism. Keep it under 255 characters per string (DNS has a packet size limit, though modern resolvers handle longer records).

Step 4: Test before publishing. Use an SPF validation tool to check your record for syntax errors and DNS lookup count. Never publish an untested SPF record.

Step 5: Monitor with DMARC. Once SPF is live, set up DMARC with p=none and watch the reports to verify all legitimate email passes authentication.

How ScanSentinel Helps

ScanSentinel's email security scanner automatically checks your domain for SPF record presence, syntax validity, and best-practice compliance. It flags missing records, duplicate records, records ending in +all, and records that exceed the 10-lookup limit. The platform also cross-references SPF with DKIM and DMARC to give you a complete email authentication score.

When issues are found, ScanSentinel provides specific, actionable recommendations tailored to your current DNS configuration. You don't need to be an email authentication expert to get it right.