How to Create an SPF Record Step by Step

Before you start

An SPF record (Sender Policy Framework) is a TXT record in your domain's DNS that specifies which servers are authorized to send emails on behalf of your domain. If you're new to SPF, start with What Is an SPF Record and Why Do You Need One.

To create an SPF record, you need:

• Access to DNS management for your domain (registrar or DNS hosting provider)
• A list of all services and servers that send emails from your domain
• Basic familiarity with DNS records (adding a TXT record)

Map all your senders

The most common cause of a broken SPF record is a missing legitimate sender. Go through every system that sends emails from your domain:

• Corporate email — Google Workspace, Microsoft 365, self-hosted mail server
• Web server — contact forms, website notifications
• Billing / invoicing — QuickBooks, FreshBooks, Xero, Stripe
• Marketing — Mailchimp, HubSpot, ActiveCampaign
• Helpdesk / CRM — Freshdesk, Zendesk, Salesforce
• Transactional email — SendGrid, Mailgun, Amazon SES, Postmark

For each service, find its SPF include string (the service identifier you add to your SPF record) — it's typically in the service's documentation under "DNS setup" or "Email authentication."

Common include strings

Some services (e.g., Mailchimp, Postmark) use their own domain in the envelope address and don't require an SPF include in your record — always check the current documentation for the specific service.

For self-hosted servers, use the ip4: or ip6: mechanism with the server's IP address.

Build your SPF record

Every SPF record has three parts:

1. Version — always v=spf1
2. Mechanisms — the list of authorized senders
3. Policy — what to do with unauthorized senders (-all or ~all)

Example: domain with Google Workspace and a dedicated server

v=spf1 include:_spf.google.com ip4:198.51.100.10 -all

Example: domain with Microsoft 365 and SendGrid

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

Example: domain with multiple services

v=spf1 include:_spf.google.com include:sendgrid.net include:email.freshdesk.com ip4:203.0.113.5 -all

Choosing a policy: -all vs. ~all

Recommended approach: start with ~all, monitor DMARC reports for a few weeks, and switch to -all once you've confirmed all legitimate emails pass.

Publish the record in DNS

Log in to your domain's DNS management panel and add a new TXT record:

Critical rule: a domain may only have one SPF record. If a TXT record starting with v=spf1 already exists, don't create a new one — edit the existing record and add the new mechanisms to it. Multiple SPF records cause a PermError per RFC 7208 (section 4.5), and SPF authentication will fail.

Verify the record

After publishing the record in DNS (propagation can take up to 48 hours, typically 5–30 minutes), verify:

1. Syntax — is the record properly formatted?
2. DNS lookups — does it stay within the 10 DNS lookup limit?
3. Coverage — are all authorized servers included?

Check your SPF record with the SPFmonitor analyzer — it validates syntax, DNS lookup count, nested includes, and overall configuration.

Watch the 10 DNS lookup limit

Per RFC 7208 (section 4.6.4), SPF evaluation may trigger a maximum of 10 DNS lookups. The mechanisms include, a, mx, ptr (deprecated but still counted), exists, and the redirect modifier count toward this limit. The ip4, ip6, and all mechanisms don't trigger DNS lookups.

Each include can contain further nested include records — and those count too. The number of nested lookups depends on the specific service and can change over time — verify the current state with the SPF record analyzer.

How to count DNS lookups

If you're approaching the limit, consider:

• Replacing include with ip4/ip6 — if the service uses stable IP addresses
• Removing unused services — discontinued a service? Remove its include
• SPF flattening — a technique that replaces nested includes with IP addresses (requires automation since IPs can change)

Common mistakes when creating an SPF record

Multiple SPF records on one domain

A domain may have only one TXT record starting with v=spf1. When adding a new service, edit the existing record — don't add a second one.

Wrong (two separate records):

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

Correct (one merged record):

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

Using +all

The +all mechanism authorizes any server to send emails from your domain — it effectively disables SPF protection. Never use it.

Missing a sender

If you forget to include a legitimate sender (typically a billing system or CRM), its emails will be rejected when using -all. This is why mapping your senders in the first step is critical.

Exceeding the DNS lookup limit

Each additional service increases the DNS lookup count. Exceeding the limit of 10 causes a PermError — SPF authentication fails for all emails, including authorized ones.

Complete your setup with DKIM and DMARC

A working SPF record is the foundation, but it doesn't provide complete protection on its own. SPF doesn't verify the From header (the address recipients see) — it only checks the envelope sender (the bounce address).

For comprehensive email authentication, you also need:

• DKIM (DomainKeys Identified Mail) — verifies that the email content hasn't been altered in transit
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) — aligns SPF and DKIM with the From header address and defines how to handle unauthenticated emails

Email authentication is not a one-time setup. DNS records change, new sending services get added, IP addresses expire. Ongoing domain monitoring ensures your protection stays effective.