SPFSender Policy Framework

A DNS record listing which servers may send mail for your domain. One of three core email-auth checks.

SPF — Sender Policy Framework, defined in RFC 7208 — answers one question: “is this server allowed to send for me?” How it differs from DKIM and DMARC is covered in SPF, DKIM, and DMARC and the deliverability guide.

How it works

You publish a single TXT record on your domain that begins with v=spf1 and lists the sources permitted to send mail. Common mechanisms are ip4 and ip6 for specific addresses, a and mx to authorise your own hosts, and include to delegate to a provider’s SPF record. The record ends with an all mechanism whose qualifier sets the default: -all means hard fail (treat anything not listed as unauthorised), ~all means soft fail (accept but mark suspicious), and ?all is neutral. A receiving server looks up the record and checks whether the connecting IP is authorised.

What SPF actually checks

This is the detail people get wrong: SPF validates the envelope sender — the MAIL FROM address, also called the Return-Path — not the From: header the recipient sees. The two can differ. That gap is why SPF alone can’t stop spoofing of the visible From address, and why DMARC exists: DMARC requires the SPF-authenticated domain to align with the From-header domain.

Common pitfalls

• The ten-lookup limit. Evaluating an SPF record may trigger at most 10 DNS-querying mechanisms (each include, a, mx, ptr, and exists counts). Exceed it and the result is permerror, which receivers generally treat as a failure. Chaining many provider includes is the usual cause.
• Forwarding breaks SPF. When a message is forwarded, the forwarding server’s IP usually isn’t in the original domain’s record, so SPF fails. DKIM survives forwarding because it signs the message itself.
• One record only. A domain must publish exactly one v=spf1 TXT record; publishing two also produces permerror.
• The standalone SPF DNS record type (type 99) is deprecated by RFC 7208 — publish the policy as a TXT record.

A worked example

An e-commerce store sends order email through one transactional provider and replies through its help desk. Its record might read v=spf1 include:_spf.theprovider.example include:_spf.thehelpdesk.example -all — authorising both senders and rejecting everything else. If it later adds a marketing tool with its own include, it has to watch the running lookup count so the record doesn’t tip over ten and start failing for every recipient.

How Cherryrise handles it

Cherryrise signs outbound mail as your own domain using BYODKIM, so DKIM authenticates regardless of forwarding. SPF still matters for the envelope, so the setup flow tells you which include to add and flags it if your domain’s record is missing or already near the lookup limit. SPF, DKIM, and a DMARC policy together are what keep replies out of the spam folder.