Sender Policy Framework (SPF)

What it is

SPF lets a domain publish, in a single DNS TXT record, the list of servers allowed to send email using that domain in the SMTP envelope sender (the Return-Path / MAIL FROM address).

A receiving server looks up the SPF record of the envelope sender domain and checks whether the connecting IP address matches. The result (pass, fail, softfail, neutral, none, permerror, temperror) feeds into spam filtering and into DMARC.

How it works

• The record lives at the domain itself as a TXT record that starts with v=spf1.
• Mechanisms are evaluated left to right: ip4, ip6, a, mx, include, exists. The first match decides the result.
• Each mechanism can carry a qualifier: + (pass, default), - (fail), ~ (softfail) or ? (neutral).
• The final all mechanism catches everything else. -all is strict, ~all is the common "monitor" setting.
• include, a, mx, ptr, exists and redirect each cost a DNS lookup. More than 10 lookups is a permerror and SPF fails for every message.

Examples

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

v=spf1 -all

Common mistakes

• More than one SPF record

  Two TXT records starting with v=spf1 is a permerror. Merge them into one.

• Exceeding 10 DNS lookups

  Every include may pull in nested includes. Remove unused vendors or flatten to ip4/ip6 ranges.

• Using +all

  Authorizes the whole Internet to send as you. Never use it.

• Forgetting a sender

  CRMs, ticketing and invoicing tools often send as your domain. Inventory them before switching to -all.

• Using ptr

  The ptr mechanism is deprecated, slow and unreliable. Use ip4/ip6 or include instead.

Specifications

• RFC 7208