What Is an SPF Record? How It Works

What an SPF record does

An SPF record is a DNS TXT record that says which mail servers are allowed to send for a domain.

SPF stands for Sender Policy Framework. When a mailbox provider receives a message, it can compare the sending server with the SPF policy published by the domain used in the SMTP envelope sender, also called MAIL FROM or return-path. SPF can also be checked against the HELO or EHLO identity in some cases. If the server is authorized, SPF can pass. If it is not authorized, SPF can fail, softfail, or return another SPF result depending on the published policy and DNS evaluation.

A simple SPF record looks like this: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. The v=spf1 tag identifies the record. The include, ip4, ip6, a, and mx mechanisms authorize senders. The final ~all or -all tells receivers what the domain owner says about everything else.

SPF is not a complete proof of identity by itself. It checks the server that sent the message for the envelope or HELO domain, not necessarily the visible From address a person sees in their inbox. That is why SPF is usually managed with DKIM and DMARC, not as a stand-alone deliverability fix.

How SPF affects deliverability

SPF gives Gmail, Outlook, and other mailbox providers one important trust signal, but it does not force inbox placement.

Mailbox providers decide whether to place mail in the inbox, spam, junk, or rejection path using many signals: authentication, sending domain reputation, IP reputation, user complaints, content, engagement, blocklists, DNS quality, and local policy. Google says unauthenticated mail and mail from senders missing required authentication is more likely to be rejected or marked as spam. Microsoft has also published SPF, DKIM, and DMARC requirements for high-volume senders to Outlook.com consumer mailboxes. The general rule is simple: SPF helps prove that your infrastructure is authorized, but the inbox decision belongs to the receiving mailbox provider.

If SPF is missing, wrong, or too broad, legitimate mail may look unauthenticated or easier to spoof. If it is too strict before all senders are listed, real mail can fail SPF. If your sending IP is on a blocklist, your MX or reverse DNS is broken, or your domain has a weak reputation, SPF passing will not rescue the campaign.

• Publish one SPF TXT record at the DNS name used by your envelope sender or HELO identity, often the root domain or a bounce subdomain.
• List every real sender, including Google Workspace, Microsoft 365, CRM tools, billing systems, support desks, and marketing platforms.
• Remove vendors you no longer use so old services cannot keep sending as you.
• Keep the record within the SPF DNS lookup limit.
• Use InboxRadar's free domain scorecard to check SPF, DKIM, DMARC, MX, and drift in one pass.

Softfail, hard fail, and the 10 lookup limit

Most SPF problems come from stale senders, duplicate records, and records that become too expensive for receivers to evaluate.

The ending matters. ~all means softfail: the domain owner says other servers are probably not authorized. -all means fail: the domain owner says other servers are not authorized. Many domains start with ~all while they audit mail sources, then move toward -all after SPF, DKIM, and DMARC are stable. ?all is neutral and gives receivers little useful guidance.

RFC 7208 sets a limit of 10 DNS-querying mechanisms and modifiers during SPF evaluation. Mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect count toward that limit, including nested includes. Literal ip4, ip6, and all mechanisms do not add DNS lookups. If evaluation needs too many lookups, the SPF result is a permanent error. This often happens when a domain includes several vendors, and those vendors include more vendors behind the scenes.

Do not publish two SPF records for the same name. Receivers expect one SPF policy at a name. Two competing v=spf1 TXT records cause a permanent error, even if each record looks valid on its own.

Where DKIM and DMARC fit

SPF authorizes sending servers. DKIM signs messages. DMARC connects those checks to the visible From domain.

DKIM adds a cryptographic signature to a message. The sending service signs with a private key, and receivers find the matching public key in DNS using the DKIM selector and signing domain. Selectors let a domain run more than one DKIM key and rotate keys without breaking all mail at once. DKIM is especially useful because it can survive normal forwarding better than SPF.

DMARC checks whether SPF or DKIM passed for a domain aligned with the visible From domain. A DMARC policy can be p=none for monitoring, p=quarantine to ask receivers to treat DMARC failures as suspicious, or p=reject to ask receivers to reject DMARC failures. A rua=mailto: tag in the DMARC record asks receivers for aggregate reports that help show which sources are sending for your domain and whether they pass SPF, DKIM, and DMARC.

For a healthy domain, SPF, DKIM, and DMARC should all be present and aligned where possible. SPF should include authorized envelope or HELO senders. DKIM should sign with the sending domain or an aligned domain. DMARC should start with monitoring, then move carefully toward enforcement after reports show that real mail is passing.

• Check SPF against RFC 7208 and keep it within 10 DNS-querying mechanisms and modifiers.
• Turn on DKIM for every service that sends mail from your domain.
• Publish DMARC with reporting so you can see missed vendors and spoofing attempts.
• Review blocklists, MX records, reverse DNS, and sender reputation before blaming SPF alone.
• Read the broader spam placement guide if SPF passes but mail still lands in junk.

Common SPF record mistakes

A good SPF record is short, current, and tied to the way your business actually sends mail.

Common mistakes include copying a vendor example without adding every sender, leaving old vendors in place, using broad IP ranges, publishing duplicate records, and nesting too many include mechanisms. Another common mistake is treating SPF as proof that the visible From address is protected. Without DMARC alignment, a message can pass SPF for one domain while showing a different From domain to the reader.

Use official sources when the exact requirement matters. SPF is defined in RFC 7208 and DKIM in RFC 6376. DMARC was originally defined in RFC 7489, and the current DMARC protocol is RFC 9989 with aggregate reporting in RFC 9990. For mailbox provider rules, check the current Google sender guidelines and Microsoft sender requirements because enforcement details can change.