What is an SPF record, and how do you read one?

What does an SPF record actually contain?

SPF (Sender Policy Framework) is defined in RFC 7208 as a single DNS TXT record published at the domain's own name, not a subdomain. Every valid record starts with the version tag v=spf1, followed by a space-separated list of mechanisms that each match or do not match the server currently trying to send mail, evaluated left to right until one matches.

A domain must publish at most one SPF record. RFC 7208 treats multiple v=spf1 TXT records on the same name as an error (a PermError) rather than combining them, so a domain using several mail providers needs one record that lists or includes all of them, never several separate records.

What do the mechanisms and qualifiers mean?

Each mechanism can carry one of four qualifiers, placed directly in front of it, and RFC 7208 section 5 defines them as:

• + (pass) - the default when no qualifier is written; the sending server is authorized.
• - (fail) - the sending server is explicitly not authorized; a strict receiver may reject the message.
• ~ (softfail) - the sender is probably not authorized, but the record is not asking for an outright rejection; often used while rolling out a policy.
• ? (neutral) - no assertion either way.

The mechanisms themselves cover the common ways a domain authorizes senders:

• a - matches if the connecting server's IP address is one of the domain's own A or AAAA records.
• mx - matches if the connecting IP belongs to one of the domain's own MX hosts.
• ip4 / ip6 - matches an exact address or CIDR range, for example ip4:203.0.113.0/24.
• include - evaluates another domain's SPF record and only counts as a match if that lookup itself returns pass; this is how a domain authorizes a third-party sender such as an email platform without copying its IP ranges by hand.
• all - matches everything, and by convention sits last as the catch-all for any sender the earlier mechanisms did not already match.

What is the 10 DNS lookup limit, and how does it get blown?

SPF evaluation is not allowed to run forever. RFC 7208 section 4.6.4 requires that "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation," counting every include, a, mx, ptr and exists mechanism plus a redirect modifier as one lookup each. Mechanisms that need no DNS query to test - ip4, ip6 and all - do not count. Going over the limit ends evaluation in a PermError, which most receivers treat as SPF providing no usable answer for that message at all.

The limit is easy to hit by accident because include is recursive: each third-party service a domain adds - one for its email marketing tool, one for a helpdesk, one for its CRM - can itself include further domains, and every layer counts against the same shared total of 10. Three or four typical include entries, each pulling in its own nested includes, can approach the limit even though the domain's own record looks short. A record such as v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org mx -all looks like three lookups at a glance, but if any one of those included domains itself includes two or three more providers underneath, the real total climbs well past what the record's own line length suggests. The only way to know the actual count is to resolve every include in the chain and add them up, not to count the mechanisms visible in the top-level record.

Why is +all dangerous?

Ending a record with +all (or leaving off the qualifier, since + is the default) means the record explicitly authorizes every sender in existence, since all always matches. That does not tighten anything; it makes SPF pass for literally anyone claiming to send as that domain, which defeats the entire purpose of publishing the record. A record intended to protect a domain should end in -all once every legitimate sender is accounted for, or ~all while still confirming the list is complete, never +all.

Some SPF records are published this way by mistake rather than intent - copied from an old tutorial, or left over from a testing phase that was never finished - and a domain with +all in production gets no real protection from SPF at all, even though the record technically exists and technically validates. Checking the last mechanism in a record is the first thing worth confirming when reviewing SPF, before worrying about anything else in the record.

A complete example

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

This record authorizes one specific IP address, delegates to Google's own SPF record for any server Google Workspace uses to send on the domain's behalf, authorizes the domain's own MX hosts, and hard-fails everything else. It uses two of the ten available lookups: one for the include and one for the mx mechanism.

Why does SPF alone break on forwarding?

SPF checks the IP address of the server making the connection against the domain in the envelope sender (the MAIL FROM address, distinct from the visible From: header a person reads). Plain forwarding relays the message from a different server than the one that originally sent it, so the connecting IP no longer matches the original domain's SPF record, and the check fails at the final recipient even though the message itself is legitimate. This is one reason SPF is not the whole picture: DKIM, a signature-based check that travels with the message content, does not depend on which server relays the mail. SPF also has nothing to do with which mail server actually receives a domain's incoming mail - that is the job of the MX record.

Frequently asked questions

Can a domain have more than one SPF record?

No. RFC 7208 treats two or more v=spf1 TXT records at the same name as an error. Combine every authorized sender into one record instead.

Does SPF check the address a person sees in their inbox?

No. SPF evaluates the envelope sender used during the SMTP transaction, not the visible From: header. Tying those two together is what DMARC alignment does, covered later in this cluster.

What does the redirect modifier do?

It replaces the whole evaluation with another domain's SPF record, rather than adding to the current one the way include does. It is used when one domain's policy should simply be another domain's policy in full.

How do I check how many lookups my record uses?

Resolve the record and count the include, a, mx, ptr and exists terms, then check any domain named in an include the same way, since its lookups count too. The MX lookup tool is useful alongside this for confirming which hosts a domain's own mx mechanism would pull in.

Is SPF enough on its own to stop spoofed email?

Not by itself. It only says which servers may send for a domain; it says nothing about the visible sender name a recipient reads, and it does not survive simple forwarding. DKIM and DMARC, covered in the next two guides, close those gaps.