SPF debugging


Someone mentioned on a mailing list that mail “from” intuit.com was being filed in the gmail spam folder, with the warning “Our systems couldn’t verify that this message was really sent by intuit.com“. That warning means that Gmail thinks it may be phishing mail. Given they’re a well-known financial services organization, I’m sure there is a lot of phishing mail claiming to be from them.
But I’d expect that a company the size of Intuit would be authenticating their mail, and that Gmail should be able to use that authentication to know that the mail wasn’t a phish.
Clearly something is broken somewhere. Lets take a look.
Looking at the headers, the mail was being sent from Salesforce, and (despite Salesforce offering DKIM) it wasn’t DKIM signed by anyone. So … look at SPF.
SPF passes:

Received-SPF: pass (google.com: domain of
designates as permitted sender) client-ip=;

SPF proper doesn’t say anything about the visible From: header; it looks at the (invisible) salesforce return path instead, so the formal SPF check passing says nothing about whether it’s legitimate intuit mail or not.
But you can use SPF to answer the more general question “Is legitimate mail from this domain sent from that IP address?”. Gmail could potentially use that information to distinguish between a phish and a legitimate mail. A quick look at the TXT records for intuit.com shows they have an SPF record that includes several others, and one of those in turn includes salesforce.com, so it’s possible.
That’s a lot of includes, though. And we know that if your SPF record has too many terms that will trigger DNS queries it will exceed the limit of ten queries and any SPF check using it will fail. I’ve recently added features to our SPF tool to check for that, so it’s a good time to try that out.
There’s the problem. This SPF record is too big and too deeply nested and the SPF specification says that must lead to an SPF “PermError” failure. If Gmail were to try and use SPF to answer “Might this mail be authorized by intuit.com?” any SPF library would say “No”.

About the author

1 comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • I have also found SF/ET to not sign messages with DKIM and the way they do their DNS/handling of SPF really boggles my mind because for some it should not be passing as there is no mention on the sending “From” domain that SF/ET can send mail on the sender’s behalf from that IP. In your case Laura the “From” domain does mention SF/ET but not in the case I have seen.

By steve

Recent Posts


Follow Us