How to Create and Configure an SPF Record

Master SPF record syntax including mechanisms, qualifiers, and the 10 DNS lookup limit. Avoid common mistakes and validate your record with free tools.

email spf

How to Create and Configure an SPF Record

The Sender Policy Framework (SPF) is a DNS-based email authentication method defined in RFC 7208. It allows domain owners to specify which IP addresses and servers are authorized to send email on behalf of their domain. Misconfigured SPF records are one of the most common causes of deliverability failures, and they are also one of the easiest to fix once you understand the syntax.

What an SPF Record Does

When a receiving mail server accepts an inbound message, it extracts the domain from the envelope sender (the MAIL FROM address used during the SMTP transaction, per RFC 5321) and queries DNS for a TXT record beginning with v=spf1. The server then evaluates the mechanisms in the record against the connecting IP address. The result determines whether SPF passes, fails, or returns an error.

SPF does not validate the "From" header that users see in their email client. For that level of protection, SPF must be paired with DMARC, which enforces alignment between the envelope sender and the visible "From" domain.

SPF Record Syntax

An SPF record is a single DNS TXT record published at the root of your domain. It follows this general structure:

v=spf1 [mechanisms] [qualifier]all

Mechanisms

Mechanisms define the rules for matching a sending IP. They are evaluated left to right, and the first match determines the result.

ip4: and ip6: -- Match a specific IPv4 or IPv6 address or CIDR range. These are the most explicit and efficient mechanisms because they do not require additional DNS lookups.

v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 -all

include: -- Delegates SPF evaluation to another domain's SPF record. This is how you authorize third-party senders like Google Workspace, Microsoft 365, SendGrid, or Mailchimp. Each include triggers one or more DNS lookups.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

a -- Matches if the sending IP corresponds to an A or AAAA record for the domain (or a specified domain). Costs one DNS lookup.

mx -- Matches if the sending IP corresponds to an MX record for the domain. Costs one DNS lookup plus one for each MX host resolved.

exists: -- Matches if a DNS A record exists for the specified domain. Used in advanced macro-based configurations.

redirect= -- Replaces the current SPF evaluation with the SPF record of another domain. Useful for organizations that manage SPF centrally.

Qualifiers

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

Qualifier Meaning Result
+ Pass (default if omitted) Authorized
- Fail Not authorized; reject
~ SoftFail Not authorized; accept but mark
? Neutral No assertion

The all mechanism at the end of the record acts as a catch-all. The qualifier you place before it defines what happens to senders that do not match any previous mechanism:

  • -all -- Hard fail. Recommended for domains with a known, complete sender list.
  • ~all -- Soft fail. Messages from unauthorized IPs are accepted but flagged. Useful during initial deployment.
  • ?all -- Neutral. Effectively disables SPF enforcement. Not recommended.

The 10 DNS Lookup Limit

RFC 7208 imposes a hard limit of 10 DNS lookups during SPF evaluation. Every include, a, mx, redirect, and exists mechanism counts toward this limit. If evaluation exceeds 10 lookups, the result is a PermError, and SPF fails for all messages.

This limit catches many organizations off guard. A single include:_spf.google.com can consume multiple lookups because Google's SPF record itself contains nested includes. Add a few more third-party services, and you hit the ceiling quickly.

Strategies to Stay Under the Limit

  • Audit your includes. Remove any services you no longer use.
  • Use ip4/ip6 where possible. Direct IP references cost zero lookups.
  • Flatten your record. Replace include mechanisms with the resolved IP addresses. The downside is that you must update your record whenever the provider changes their IPs.
  • Use subdomains. Route marketing email through marketing.example.com with its own SPF record. Each subdomain gets its own 10-lookup budget.

Common SPF Mistakes

Multiple SPF records. A domain must have exactly one SPF TXT record (per RFC 7208, Section 3.2). Publishing two or more causes a PermError, and every SPF check fails. If you need to authorize multiple senders, combine them into a single record.

Using +all. This qualifier authorizes every IP on the internet to send as your domain. It defeats the purpose of SPF entirely.

Forgetting the v=spf1 prefix. Without it, the TXT record is not recognized as an SPF record and is ignored.

Not accounting for transactional senders. CRM platforms, helpdesk tools, and monitoring systems that send email on your behalf need to be included. Missing even one can cause intermittent SPF failures that are difficult to diagnose.

Ignoring SPF for non-sending domains. Domains that do not send email should still publish an SPF record of v=spf1 -all to prevent spoofing.

Validating Your SPF Record

After publishing or modifying your SPF record, always validate it. The InboxTooling SPF checker parses your record, counts DNS lookups, identifies syntax errors, and reports the final evaluation result. For a broader authentication check that includes DKIM and DMARC alongside SPF, use the full domain analysis.

DNS propagation can take up to 48 hours depending on TTL settings, although most changes are visible within minutes when using low TTL values. If your changes do not appear immediately, wait and re-check.

SPF and Major Providers

Gmail and Yahoo require a valid SPF record for bulk senders. Microsoft 365 uses SPF as one input into its composite authentication score. In all cases, a correctly configured SPF record with a -all or ~all qualifier is a baseline requirement for reliable inbox delivery.

FAQ

How does SPF work?

SPF (Sender Policy Framework) works by allowing domain owners to publish a DNS TXT record that lists every IP address and server authorized to send email on behalf of that domain. When a receiving mail server gets a message, it looks up the sender's domain SPF record and checks whether the sending server's IP is included. If the IP matches, the SPF check passes; if not, the result is a fail, softfail, or neutral depending on the record's qualifier.

What is SPF record syntax?

An SPF record always starts with v=spf1 and contains one or more mechanisms such as ip4:, ip6:, a, mx, and include:, followed by a qualifier at the end like -all (hard fail) or ~all (soft fail). Each mechanism tells receiving servers which sources are permitted to send mail. You can validate your record syntax instantly with the SPF Check tool.

What is the SPF 10 DNS lookup limit?

The SPF specification (RFC 7208) limits SPF evaluation to a maximum of 10 DNS lookups per check. Each include, a, mx, and redirect mechanism counts toward this limit, and nested includes count recursively. Exceeding 10 lookups results in a PermError, which means SPF effectively fails for every message sent from your domain.

What are the most common SPF mistakes?

The most common mistakes are publishing multiple SPF records on the same domain (only one is allowed), exceeding the 10 DNS lookup limit by adding too many include statements, and using +all which authorizes every server on the internet to send as your domain. Another frequent error is forgetting to add third-party senders like marketing platforms or CRM tools to your SPF record. Use the Full Report to catch these issues quickly.

What is the difference between SPF and DKIM?

SPF validates the sending server's IP address against a list of authorized senders, while DKIM validates the message itself by attaching a cryptographic signature to the email headers. SPF breaks when email is forwarded because the forwarding server's IP is not in the original domain's SPF record, whereas DKIM signatures survive forwarding as long as the signed headers and body are not modified. For the strongest protection, use both SPF and DKIM together with a DMARC policy.


Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.

Frequently Asked Questions

How does SPF work?

SPF (Sender Policy Framework) works by allowing domain owners to publish a DNS TXT record that lists every IP address and server authorized to send email on behalf of that domain. When a receiving mail server gets a message, it looks up the sender's domain SPF record and checks whether the sending server's IP is included. If the IP matches, the SPF check passes; if not, the result is a fail, softfail, or neutral depending on the record's qualifier.

What is SPF record syntax?

An SPF record always starts with v=spf1 and contains one or more mechanisms such as ip4:, ip6:, a, mx, and include:, followed by a qualifier at the end like -all (hard fail) or ~all (soft fail). Each mechanism tells receiving servers which sources are permitted to send mail. You can validate your record syntax instantly with the SPF Check tool.

What is the SPF 10 DNS lookup limit?

The SPF specification (RFC 7208) limits SPF evaluation to a maximum of 10 DNS lookups per check. Each include, a, mx, and redirect mechanism counts toward this limit, and nested includes count recursively. Exceeding 10 lookups results in a PermError, which means SPF effectively fails for every message sent from your domain.

What are the most common SPF mistakes?

The most common mistakes are publishing multiple SPF records on the same domain (only one is allowed), exceeding the 10 DNS lookup limit by adding too many include statements, and using +all which authorizes every server on the internet to send as your domain. Another frequent error is forgetting to add third-party senders like marketing platforms or CRM tools to your SPF record. Use the Full Report to catch these issues quickly.

What is the difference between SPF and DKIM?

SPF validates the sending server's IP address against a list of authorized senders, while DKIM validates the message itself by attaching a cryptographic signature to the email headers. SPF breaks when email is forwarded because the forwarding server's IP is not in the original domain's SPF record, whereas DKIM signatures survive forwarding as long as the signed headers and body are not modified. For the strongest protection, use both SPF and DKIM together with a DMARC policy.


Stay on top of your email infrastructure. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.