Let’s tie up a couple of loose ends (but by no means all the loose ends) when it comes to SPF. I would like to interpret the below SPF record:

v=spf1 a/24 mx/24 ptr ?all

Now that we are experts in SPF syntax, reading this is a snap. The version of SPF is 1.0, return a pass if the transmitting IP is in the same /24 net block as the domain’s A-record, or if the transmitting IP is in the same /24 net block as the domain’s mx record. Also, return a pass if any of the A-records for the hostnames are the same as the transmitting IP, or if a valid hostname ends in the same domain as the sender. If no match is made, fall back to SPF Neutral.

Does any of this sound familiar? It should, because it’s the almost the same algorithm that Gmail uses in their Best-Guess SPF. Recall that best guess matches on one of the following:

1. If the mx-record or A-record is in the same range, return a pass. This is the same as a/24 mx/24, except that Gmail is more restrictive by requiring an exact match rather than looking at a range.

2. If the reverse DNS matches the domain of the sending IP, return a pass. This is the same as the ptr mechanism.

Gmail’s other technique, PTR zone, is somewhat similar but not analogous. So, Gmail is implementing a modified form of SPF in an attempt to authenticate IPs.


Secondly, a question naturally arises about whether or not SPF can protect against spoofing the message From address, ie, the From address in the message headers.

The answer is that it does not, at least the way SPF was designed. It’s supposed to work on the envelope sender, the MAIL FROM in the SMTP command. The technical issues associated with protecting the "From:" header are more complicated.

In order to use the "From:" header as the subject of authentication with SPF, we need to be familiar with the following:

- mailing lists

- /etc/aliases-style forwarding

- MUA "resend this message to"

- web-generated email

- the Sender header

- the Resent-Sender and Resent-From headers

Looking at protection of the From: header will be the subject of the next few authentication posts when we take a look at SenderID.