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

July 2015: The Month in Email

Once again, we reviewed some of the ways brands are trying (or might try) to improve engagement with customers. LinkedIn, who frequently top lists of unwanted-but-legitimate email, announced that they’ll be sending less mail. Josh wrote about giving subscribers options for both the type and frequency of messages, and about setting expectations for new subscribers. In each case, it’s about respecting that customers really want to engage with brands in the email channel, but don’t want the permission they’ve granted to be abused. I also wrote a brief post following up on our June discussion on purchased lists, and as you’d predict, I continue to discourage companies from mailing to these recipients.

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