English Nederlands Español Italiano 日本語 Français
Log in

SPF Guidelines

SPF (Sender Policy Framework) is a free, open DNS-based standard that lets a domain owner publish an explicit list of servers allowed to send email on that domain’s behalf. It’s one of the two building blocks DMARC relies on, alongside DKIM.

Think of it like a guest list at the door

SPF is like a guest list at the entrance of a venue: it says which addresses (IP addresses) are allowed to say they’re sending on behalf of a given domain. If a sender’s address isn’t on the list, the “door” — the receiving mail server — knows something is off.

Why it matters

Without an SPF record, anyone can put your domain in the “from” address of an email and there is nothing in DNS to say whether that’s legitimate. SPF closes that gap by letting receiving mail servers check the sending server’s IP address against a list you publish yourself. It directly affects deliverability: mailbox providers use SPF, together with DKIM and DMARC, to decide whether a message looks genuine.

How it works

SPF is checked against the envelope sender — the technical “return path” address used during the SMTP conversation between mail servers (RFC 5321.MailFrom), which is not always the same as the “From” address a reader sees in their inbox. The receiving server looks up the SPF TXT record for that domain, compares it against the IP address the message actually came from, and the result is a pass or a fail.

Every domain should have an SPF record — including domains that never send email, which should explicitly say so (see Security, below). SPF is not inherited by subdomains: each (sub)domain that sends mail needs its own explicit record.

I need more information

The plain-language version above covers what most people need. The rest of this article is the detailed reference: the exact syntax rules, security recommendations, and standards this is all based on.

General

  • Every domain (sending and non-sending) should have an SPF TXT record.
  • A domain should only have one SPF TXT record.
  • SPF records are published as DNS TXT resource records. Don’t use the dedicated SPF record type (RR type 99) — it’s obsolete.
  • TXT records are limited to 255 characters per string, but can consist of multiple strings back to back — this is known as a multi-string TXT record.
  • Verify the syntax of the SPF record before publishing it to DNS; you can check it with an SPF checker.
  • Avoid duplicate entries or netblocks within one SPF record.
  • SPF is not inherited: publish SPF records explicitly on every (sub)domain that sends mail.
  • Order the mechanisms in an SPF record from most important/highest email volume (left) to least important (right), so the record can be evaluated quickly.
  • Every mail server hostname used in HELO/EHLO should have its own SPF record authorising that hostname (typically v=spf1 a -all), which requires a valid “A” record for that hostname.

Good to know

SPF is no longer used on its own as a decision-making mechanism in modern email filtering — in practice, receivers won’t block a message solely because of an SPF result. It still matters because DMARC uses it as one of its two authentication signals.

Configuration

  • SPF records should always start with v=spf1 and end with ~all (soft fail) or -all (hard fail).
  • SPF records are limited to 10 DNS lookups. The mechanisms that count towards this limit are: a, mx, include, ptr (obsolete), redirect, and exists.
  • SPF is checked against the domain used in the envelope-from/MailFrom/return-path during the SMTP transaction. If a sender uses a different domain there, it doesn’t need to be added to your organisational domain’s SPF record.
  • The include mechanism delegates part of the record to a third party. A third party can introduce syntax errors, or push you over the 10-lookup limit if they later add mechanisms of their own — worth monitoring if you’re already close to the limit.
  • include can accidentally create lookup loops between records; avoid this.
  • The exists mechanism should only be used in specific, deliberate cases, since it hands responsibility for the whole result to another lookup.
  • Don’t use the ptr mechanism — it’s deprecated (RFC 7208, Section 5.5).

Security

  • Keep SPF records dedicated, short, and to the point. Don’t over-authorise: for example, don’t publish a /24 netblock if only 2–3 addresses in it actually send mail.
  • Domains that should never send email should still have an SPF record that fails explicitly: v=spf1 -all, ideally also published as a wildcard record where technically possible: Hostname: *.example.com. | Type: TXT | Value: "v=spf1 -all".
  • Avoid ?all (neutral result) and never use +all (allows literally anyone to send as you).
  • Review your SPF record periodically — monthly or at minimum annually — to check it still matches your actual sending infrastructure.

References & further reading

  • RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email: rfc-editor.org/rfc/rfc7208
  • M3AAWG Best Practices for Managing SPF Records – the Messaging, Malware and Mobile Anti-Abuse Working Group’s best-common-practice document, a good complementary reference to the RFC itself.