Skip to main content
protocols.pageprotocols.page

SPF

TXT recordRFC 7208

Sender Policy Framework

SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record that lists which IP addresses are authorized to send email for a domain. The receiving server looks up the SPF record of the envelope From domain and checks if the sending server's IP is in the authorized list. SPF passes if the IP matches, fails if it does not. SPF alone does not prevent display-name spoofing -- that requires DMARC.

How it works

The receiving MTA extracts the envelope From domain (MAIL FROM) during the SMTP session. It performs a DNS TXT lookup for that domain, parses the SPF record, and evaluates each mechanism left-to-right. The first matching mechanism determines the result. If no mechanism matches, the result is the default (neutral or specified by the all mechanism at the end).

Details

SPF authorizes outbound mail servers at the IP level.

How it works: 1. Your domain publishes a TXT record at its DNS apex (e.g., example.com). 2. The record lists authorized sending IPs and IP ranges using mechanisms: ip4:, ip6:, a:, mx:, include:. 3. When a receiving server gets mail from example.com, it checks the envelope From domain's SPF record. 4. If the sending IP matches an authorized mechanism, SPF passes. If not, SPF fails. 5. The ~all (softfail) or -all (hardfail) qualifier at the end specifies what to do with unauthorized senders.

Qualifiers: + pass (default, can be omitted) - fail (unauthorized, reject or mark as spam) ~ softfail (unauthorized but accept; useful during migration) ? neutral (no assertion)

SPF limits: Maximum 10 DNS lookups per SPF evaluation (include:, a:, mx: each count). Exceeding 10 is a permanent error (PermError). This is a common operational problem when using many email service providers (Mailchimp, SendGrid, HubSpot, Salesforce) each with their own include:.

SPF does not protect the From header (the header users see). It only protects the envelope sender (MAIL FROM, the SMTP-level address). A phisher can pass SPF on the envelope while spoofing the From header. That is why DMARC is needed.

DNS record example

TXT record syntax
; Simple SPF record: authorize Google Workspace + SendGrid
example.com.  IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; Include explanation:
;   v=spf1          = SPF version 1 (required)
;   include:X       = authorize all IPs in X's SPF record
;   ip4:203.0.113.5 = authorize a specific IP
;   mx              = authorize IPs in the domain's MX records
;   -all            = fail all other senders (hardfail, recommended)
;   ~all            = softfail all others (accept but mark suspicious)

; Check result (receiving server runs):
;   dig TXT example.com
;   Parse: is sending IP in any mechanism? → pass/fail/softfail

On failure

Softfail (~all): message accepted but marked with a header (X-Received-SPF: softfail). Receiving server typically delivers but may apply a spam score penalty. Hardfail (-all): message may be rejected outright or treated as spam depending on the receiving server's policy. SPF alone does not cause rejection in most receivers -- DMARC policy determines the enforcement action.

Limitations

  • !Does not protect the From header users see -- only the SMTP envelope sender
  • !10 DNS lookup limit makes it fragile with multiple email providers
  • !Forwarded email breaks SPF: when mail is forwarded, the forwarding server's IP is not in the original SPF record
  • !No cryptographic signing -- IP spoofing within the authorized range still passes

See Also

All Email Auth MechanismsSMTP OverviewRFC 7208 specification