How to Create an SPF Record: Complete Setup Guide

Why You Need an SPF Record

SPF (Sender Policy Framework) is a DNS-based email authentication protocol that helps prevent email spoofing. Without an SPF record, any server in the world can send emails claiming to be from your domain — and receiving servers have no way to verify that claim.

Publishing an SPF record protects your brand reputation, reduces the risk of your domain being used in phishing attacks, and improves email deliverability. SPF is also a prerequisite for DMARC, which combines SPF and DKIM to provide complete email authentication.

Understanding SPF Mechanisms

SPF records use mechanisms to define which servers are allowed to send email for your domain. Here are the most common mechanisms:

• include — References another domain's SPF record. Used for third-party senders like Google Workspace or Microsoft 365. Example: include:_spf.google.com
• ip4 — Authorizes a specific IPv4 address or range. Example: ip4:203.0.113.0/24
• ip6 — Authorizes a specific IPv6 address or range. Example: ip6:2001:db8::/32
• a — Authorizes the IP address(es) that the domain's A record points to. Useful if your web server also sends email.
• mx — Authorizes the IP addresses of all servers listed in the domain's MX records. Useful for domains where the mail server also sends outbound email.
• all — A catch-all mechanism that always matches. Typically used at the end of the record with a qualifier to define the default behavior for unlisted senders.

Understanding SPF Qualifiers

Each mechanism can be prefixed with a qualifier that determines what happens when it matches:

• + (Pass) — The sender is authorized. This is the default if no qualifier is specified.
• - (Fail) — The sender is explicitly not authorized. Receiving servers should reject the email.
• ~ (SoftFail) — The sender is probably not authorized. The email is accepted but flagged. Most commonly used with ~all.
• ? (Neutral) — No assertion is made about the sender. Treated as if no SPF record existed for that mechanism.

For maximum protection, use -all (hard fail) at the end of your record. If you are still testing, use ~all (soft fail) until you are confident all legitimate senders are included.

The 10 DNS Lookup Limit

One of the most critical constraints in SPF is the 10 DNS lookup limit. The SPF specification (RFC 7208) limits the number of DNS lookups to 10 per SPF evaluation. Each include, a, mx, and redirect mechanism triggers one or more DNS lookups. Nested includes count toward the total.

If your SPF record exceeds 10 lookups, the entire SPF check returns a PermError, and your email authentication fails. This is a common problem for organizations using many third-party email services.

To solve this, use our SPF Flattener tool to resolve all includes into IP addresses, reducing your lookup count. Note that ip4 and ip6 mechanisms do not count toward the limit.

Step 1: Identify Your Email Senders

Before writing your SPF record, create a complete list of every server and service that sends email on behalf of your domain. Common senders include:

• Your email provider (Google Workspace, Microsoft 365, Zoho)
• Marketing platforms (Mailchimp, HubSpot, SendGrid, Brevo)
• Transactional email services (Amazon SES, Postmark, Mailgun)
• CRM and support tools (Salesforce, Zendesk, Freshdesk)
• Your own web server (if it sends emails directly)

Each service will have its own SPF include directive. Check your provider's documentation for the exact value.

Step 2: Build Your SPF Record

Use our free SPF Generator to build your record. A typical SPF record for a company using Google Workspace and Mailchimp looks like this:

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

This record authorizes Google's mail servers and Mailchimp's servers, and hard fails everything else. Always start with v=spf1 and end with an all mechanism.

Step 3: Add to DNS

Add your SPF record as a DNS TXT record at the root of your domain (host name @). Important rules to follow:

• Only one SPF record per domain. If you already have one, edit it instead of creating a second record.
• The record must be a TXT record, not an SPF record type (the SPF DNS record type was deprecated in RFC 7208).
• Keep the record under 255 characters per DNS string. For longer records, your DNS provider will automatically split them into multiple strings.

Step 4: Test and Validate

After publishing your SPF record, verify it immediately using our SPF Checker tool. It will validate your record syntax, count DNS lookups, resolve all includes, and flag any issues.

Send test emails from each authorized service and verify they pass SPF checks. Check email headers for Authentication-Results to confirm SPF passes. If you have DMARC configured, your aggregate reports will also show SPF results.

Common SPF Mistakes

• Exceeding 10 DNS lookups. This is the most common SPF error. Each include adds at least one lookup, and nested includes add more. Use our SPF Flattener to stay within the limit.
• Publishing multiple SPF records. Only one TXT record starting with v=spf1 should exist per domain. Multiple records cause a PermError.
• Using +all. Never use +all — it authorizes every server in the world to send email as your domain. Always use -all or ~all.
• Forgetting third-party senders. If a legitimate service is not included in your SPF record, its emails will fail SPF checks and may be rejected.
• Not updating after provider changes. When you switch email providers or add new services, update your SPF record immediately.
• Using the ptr mechanism. The ptr mechanism is deprecated and should not be used. It is slow, unreliable, and adds unnecessary DNS load.

SPF Best Practices

• Use -all (hard fail) once you have confirmed all legitimate senders are included. This provides the strongest protection.
• Minimize DNS lookups. Replace a and mx mechanisms with direct ip4/ip6 entries where possible to conserve lookups.
• Audit regularly. Review your SPF record quarterly to remove decommissioned services and add new ones.
• Combine with DKIM and DMARC. SPF alone is not enough. Set up DMARC to enforce authentication and get visibility into your email traffic.
• Protect subdomains. Publish SPF records for subdomains that send email. For subdomains that do not send email, publish v=spf1 -all to prevent spoofing.