What Is an SPF Record?

SPF, short for Sender Policy Framework, is an email authentication standard defined in RFC 7208. It lets the owner of a domain publish a list of servers that are allowed to send email on that domain's behalf. The list lives in DNS as an ordinary TXT record that begins with v=spf1. When a receiving mail server sees a message claiming to come from your domain, it looks up that record and checks whether the sending server's IP address is authorized. If it is, the message passes SPF; if not, your record tells the receiver how suspicious to be.

SPF matters for two practical reasons. First, it makes it harder for spammers to forge your domain in the envelope sender of their messages, which protects your reputation. Second, major mailbox providers now expect authenticated mail, so a correct SPF record is one of the basic requirements for reliable inbox placement. SPF is not a complete solution on its own — it works alongside DKIM and DMARC — but it is usually the first record to set up and the easiest to get wrong.

How SPF Is Checked

SPF is typically evaluated early in the SMTP conversation, often before the message body has been transferred. The receiver takes the domain from the envelope sender — the MAIL FROM address, also called the Return-Path — and queries DNS for a TXT record starting with v=spf1. If the envelope sender is empty, as it is for bounce messages, the receiver uses the domain announced in the HELO greeting instead.

Note that this is not the From address users see in their mail client. SPF deliberately operates on the hidden envelope, which is one reason DMARC exists — to connect the envelope domain back to the visible From domain.

The record is read left to right, and the first mechanism that matches the connecting IP determines the result. There are seven possible outcomes: pass (the IP is authorized), fail (explicitly not authorized), softfail (probably not authorized), neutral (the domain makes no assertion), none (no record found), temperror (a temporary DNS problem), and permerror (the record is broken). A fail rarely causes outright rejection by itself; most providers feed the SPF result into their DMARC evaluation and broader filtering, so a broken record hurts you gradually rather than dramatically.

SPF Syntax and Mechanisms

Mechanisms are the building blocks of an SPF record, and each one describes a set of IP addresses:

• ip4 and ip6 name addresses or CIDR ranges directly and cost nothing to evaluate.
• a matches the IP addresses a hostname resolves to.
• mx matches the mail servers listed for a domain.
• include pulls in another domain's SPF record — this is how you authorize a third-party provider. If the included record would return a pass for the connecting IP, the mechanism matches. Importantly, a fail produced inside an included record just means the include does not match and evaluation continues, so an include never inherits another domain's failure policy.
• all matches everything that nothing earlier matched, and always goes last.

Two more mechanisms exist but are less common: exists matches if a constructed hostname resolves to any address, and ptr matches based on reverse DNS. RFC 7208 discourages ptr because it is slow and unreliable.

Qualifiers: + ~ - ?

Every mechanism can be prefixed with a qualifier that decides what happens on a match. + means pass and is the default, so mx and +mx are identical. - means fail, ~ means softfail, and ? means neutral.

In practice, qualifiers matter most on the final all mechanism:

• -all tells receivers to treat unlisted senders as not authorized.
• ~all asks them to be suspicious of unlisted senders (softfail).
• +all authorizes the entire internet, which defeats the point of SPF entirely.

Two modifiers round out the syntax: redirect= hands evaluation to another domain's record entirely, and exp= points to an explanation string returned with failures.

The 10-Lookup Limit and PermError

RFC 7208 caps the number of DNS-querying mechanisms at ten per evaluation. The mechanisms include, a, mx, ptr, exists, and the redirect modifier all count — and nested includes count too, because the limit applies to the whole tree, not just your top-level record. The literal ip4 and ip6 mechanisms and the all mechanism cost no lookups.

Cross the limit and receivers return permerror, which most DMARC evaluations treat the same as an SPF failure. There are sub-limits as well: a single mx mechanism must not trigger more than ten address lookups, and if more than two lookups return no answer at all (a void lookup), the evaluation may also fail with permerror. Void lookups usually come from stale includes pointing at vendors you stopped using years ago.

Another frequent permerror cause is publishing more than one SPF record: a domain must have exactly one TXT record beginning with v=spf1. If receivers find two, neither counts.

Next Steps

Once you understand the pieces, the practical work is identifying your senders and assembling them into a single record — see our guide on how to set up SPF. To confirm your record parses correctly and stays under the ten-lookup limit, run it through our SPF record checker. And because SPF only covers the envelope and breaks under forwarding, pair it with DMARC and DKIM for full coverage.