SPF ?all

I was updating my SPF library and discovered that the example code snippets didn’t work any more, as at some point in 2024 AOL switched their SPF record from “(lots of stuff]) ~all” to “(lots of stuff) ?all”. Nothing particularly surprising, folks change their setups occasionally. I updated the example code to expect a neutral response rather than softfail and all the tests pass.

So what does SPF “?all” mean, and why are you more likely to see it now?

Pretty much every SPF record ends with -all, ~all, ?all or +all. That final word describes what the SPF result is if none of the previous mechanisms - address ranges, includes, etc. - matches.

+all (plus all) is just silly. It says that mail coming from any of the IP addresses in the record is authorized, but so is mail coming from everywhere else on the Internet.

-all (dash all) is claiming to be strict. It says that mail coming from an IP address not in the SPF record is not authorized and should be rejected or discarded. This breaks an awful lot of legitimate email - forwarding, mailing lists and so on - so most mailbox providers treat it much the same as ~all.

~all (tilde all) means that the sender expects legitimate mail to come only from the listed IP addresses, but accepts that it may come from elsewhere. If it comes from an IP in the record it’s authorized. If not, then it’s not authorized but it may still be legitimate.

?all (query all) means that the sender is explicitly not asserting whether mail from IP addresses not in the record is authorized or not.

(This is all simplified a bit, though it matches what you’ll see in practice. Check out RFC 7208 if you really want the details.)

I used to describe “?all” as meaning “the sender has heard of SPF but wants no truck with it”.

Now, though, it’s part of an idiom for treating an SPF result differently depending on whether you’re using the result directly, or just as part of a DMARC evaluation. If you receive mail from an IP address not in the SPF record and it ends with “?all” then you should treat SPF as failing when evaluating DMARC based on it (so DMARC will fail unless the email has an aligned DKIM signature). But if you receive the same mail and use SPF to decide whether to deliver it or not then you should treat SPF as not failing.

This allows senders to publish a list of IP addresses they expect mail to come from in an SPF record and use that to cause DMARC to pass for mail from those addresses, while still avoiding any risk of forwarded email being rejected due to an SPF failure.

SPF modifiers like “?” or “-” can appear in front of any mechanism, as well as in front of the final “all”, but you’ll seldom see that in use (other than an occasional “+” in front of a mechanism, which just means the same as having no modifier).

DMARCbis - the slightly updated version of DMARC - describes the general case of using a “?” modifier to mark a permissive source of email like this:

Security considerations from the authentication methods used by DMARC are incorporated here by reference.

Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTA which is authorized to do so. SPF policies map domain names to sets of authorized MTAs (see Section 11.4 of [RFC7208]). Validated DKIM signatures indicate that an email was transmitted by an MTA with access to a private key that matches the published DKIM key record.

Whenever mail is sent, there is a risk that an overly permissive source may send mail that will receive a DMARC pass result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARC pass results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner’s intended message handling for DMARC validation failures.

To avoid this risk one must ensure that no unauthorized source can add DKIM signatures to the domain’s mail or transmit mail which will evaluate as SPF pass. If, nonetheless, a Domain Owner wishes to include a permissive source in a domain’s SPF record, the source can be excluded from DMARC consideration by using the “?” qualifier on the SPF record mechanism associated with that source. The DMARC working group had a lively discussion about possibly eliminating SPF entirely as an underlying Authentication Mechanism for DMARC, but consensus was not reached, and the suggestion to use the “?” qualifier for permissive sources is presented here instead.