We’ve run into an interesting edge case involving SenderID and Google’s SPF record — though the same thing would happen with any other spf1 record.
Say you’ve got a domain with this SenderID record in DNS:
example.com TXT “spf2.0/pra ip4:10.11.12.0/24 include:aspmx.googlemail.com -all”
What that record means is to use the PRA algorithm, authorize mail from any IPv4 address within 10.11.12.0/24 (10.11.12.0 through 10.11.12.255), also authorize whatever’s in the record for aspmx.googlemail.com, and don’t authorize anything else.
Thing is, aspmx.googlemail.com redirects to _spf.google.com, which doesn’t have an spf2.0/pra record. It only has an spf1 record, and spf1 doesn’t have the PRA algorithm. So, what should a receiving site do?
The strict interpretation would be to ignore the spf1 record, thereby effectively ignoring the include: statement. This probably isn’t what example.com wants, though, which is probably why Microsoft interprets the included spf1 statement as if it were spf2.
In other words: even though Google has only published spf1, Microsoft is interpreting the record as spf2 (SenderID) when included in an spf2 statement.
(There’s a bit more discussion about this in a bug I submitted for the Mail::SPF perl library.)
Which is right? Doesn’t really matter, since Microsoft (Hotmail, MSN, and Windows Live Mail) is the only major mailbox provider who checks SenderID at all — and they interpret included SPF records. It’s possible that there’s a smaller site out there somewhere where they’d interpret the records differently, but we haven’t found it.