SPF (Sender Policy Framework)

SPF (Sender Policy Framework) is an email authentication standard, defined in RFC 7208, that lets a domain publish a DNS TXT record listing the servers allowed to send mail on its behalf. Receivers check the connecting server against that list.

Deliverability & Email InfrastructureUpdated September 30, 2026

In short

SPF is a DNS record that tells receiving servers which IP addresses may send email for your domain.

Key points

  1. SPF is published as a single TXT DNS Record starting with v=spf1, followed by mechanisms such as include:, ip4: and a final all qualifier [1].
  2. SPF checks the envelope sender, the Return-Path domain used in the SMTP MAIL FROM command, not the visible From address [1].
  3. Evaluation may trigger at most 10 DNS lookups; exceeding that limit causes a permerror, which receivers treat as a failure [1].
  4. Gmail requires all senders to set up SPF or DKIM (DomainKeys Identified Mail), and bulk senders to set up both along with DMARC [2].
  5. For DMARC to pass through SPF, the Return-Path domain must align with the From domain, which is the idea behind Domain Alignment [4].
  6. SPF breaks on forwarding, because the forwarding server is not in the original domain's list; DKIM (DomainKeys Identified Mail) survives forwarding better.

How an SPF check works

When a server connects to deliver mail, it announces an envelope sender in the SMTP MAIL FROM command. The receiver takes the domain from that address, looks up its SPF TXT record, and walks through the mechanisms from left to right until one matches the connecting IP address [1]. Each mechanism has a qualifier: pass (+), fail (-), softfail (~) or neutral (?). A typical record for a company using Google Workspace looks like v=spf1 include:_spf.google.com ~all, which authorizes Google's servers and softfails everything else [3]. The result is recorded in the Authentication-Results header that appears among the Email Headers. SPF on its own only says that a server may send for a domain; it says nothing about the From address the reader sees, which is why DMARC exists.

Common SPF mistakes

The most frequent problem is publishing two SPF records for the same domain, which RFC 7208 treats as a permanent error [1]. The fix is to merge them into one record. The second is the 10-lookup limit. Each include:, a, mx, ptr, exists and redirect term costs a lookup, and nested includes from several vendors add up quickly. Teams that add a CRM, a help desk and a marketing platform can exceed the limit without noticing, and then every message fails. A third mistake is ending the record with +all, which authorizes the entire internet. Finally, SPF only protects the domain used in the Return-Path, so a subdomain or Secondary Sending Domain that sends mail needs its own record. Checking the record after every vendor change avoids silent failures.

SPF in the wider authentication stack

SPF is one of three standards that make up modern Email Authentication. DKIM (DomainKeys Identified Mail) adds a cryptographic signature tied to a domain, and DMARC tells receivers what to do when neither check passes for the From domain. Microsoft's documentation describes SPF as the first layer and recommends configuring all three for every custom domain [4]. Since February 2024, Gmail and Yahoo require bulk senders to have SPF and DKIM in place with a DMARC policy, and Outlook added matching rules for senders of more than 5,000 messages a day in 2025 [2]. For Cold Email teams, SPF is rarely the cause of poor Inbox Placement on its own, but a broken record will hurt Sender Reputation quickly because messages start failing authentication at scale.

Sources
  1. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — IETF
  2. Email sender guidelines — Gmail Help
  3. Set up SPF — Google Workspace Admin Help
  4. Set up SPF to identify valid email sources for your Microsoft 365 domain — Microsoft Learn
External sources open in a new tab.

Related terms

DKIM (DomainKeys Identified Mail)

DKIM signs each email with a private key so receivers can confirm, using a public key in DNS, that a domain vouched for it and it was not altered.

DMARC

DMARC checks that SPF or DKIM passed for the domain in the From address, and tells receivers what to do and whom to report to when it did not.

Email Authentication

Email authentication proves to receiving servers that your domain actually sent your mail, and it is now mandatory for reaching Gmail, Yahoo and Outlook at volume.

Domain Alignment

Alignment means the domain that passed SPF or DKIM is the same domain the recipient sees in the From line.

Return-Path

The Return-Path is the hidden address where bounces go, and it is the domain SPF actually checks.

DNS Record

DNS records are the public settings for a domain, and email uses them to find mail servers and to publish authentication policies.

Mentioned in
Auto-ApproveBIMIBulk Sender RequirementsDomain ReputationEmail BlocklistEmail DeliverabilityEmail HeadersEmail Service Provider (ESP)Feedback Loop (FBL)Google Postmaster ToolsHard BounceInbox PlacementMX RecordOAuthSales Engagement PlatformSecondary Sending DomainSender PersonaSender ReputationSMTPSoft BounceSpam FilterSpam Trigger WordsTransactional Email

Outreach without the busywork.

PineLead finds new B2B prospects every day, qualifies them against your criteria and writes the first email in your voice. You approve — PineLead sends.

Start free with 100 credits →