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
mintcustomersupport=intuit.com__0-8zwx1w6zmvdihu@3k2i3a0a5qw8r5.e-a8tlmay.na14.bnc.salesforce.com
designates 204.14.232.69 as permitted sender) client-ip=204.14.232.69;

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.
http://tools.wordtothewise.com/spf/check/intuit.com
SPF__intuit_com
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”.
 

Related Posts

IPv6 and authentication

I just saw a post over on the mailop mailing list where someone had been bitten by some of the IPv6 email issues I discussed a couple of months ago.
They have dual-stack smarthosts – meaning that their smarthosts have both IPv4 and IPv6 addresses, and will choose one or the other to send mail over. Some domains they send to use Office 365 and opted-in to receiving mail over IPv6, so their smarthosts decided to send that mail preferentially over IPv6.
The mail wasn’t authenticated, so it started bouncing. This is probably going to happen more and more over the next year or so as domain owners increasingly accept mail over IPv6.
If your smarthosts are dual stack, make sure that your workflow authenticates all the mail you send to avoid this sort of delivery issue.
One mistake I’ve seen several companies make is to have solid SPF authentication for all the domains they send – but not for their IPv6 address space. Check that all your SPF records include your IPv6 ranges. While you’re doing that keep in mind that having too many DNS records for SPF can cause problems, and try not too bloat the SPF records you have your customers include.

Read More

Salesforce SPF and now DKIM support

Salesforce has published a SPF record for sending emails from Salesforce for years and with the Spring ’15 release, they will provide the option to sign with DKIM.
The SPF record is straight forward, include:_spf.salesforce.com which includes _spf.google.com, _spfblock.salesforce.com, several IP address blocks, mx, and ends with a SoftFail ~all.
Salesforce Knowledge Article Number: 000006347 goes in-depth with information regarding their SPF Record.

Read More

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More