What SPF records should you publish?

When it comes to SPF records there seems to be a lot of confusion. I mean, a decade after I posted it Authenticating SPF is still the most frequently visited post on the site. And, of course, there are hundreds of other pages out there that discuss SPF and what to publish. Still, there are common questions.

Most recently I’ve been addressing questions about what SPF records need to be published. In the older post, I talk about how to publish, but don’t talk about what domains should be included. It’s probably time to do that.

What is SPF?

SPF is Sender Policy Framework. It allows domain owners to specify what IP addresses are expected to send mail from that domain.

What does SPF authenticate?

Primarily, SPF authenticates the address in the Mail From:. This is not the domain that the final recipient sees in their mail client. The Mail From is also known as the envelope from, the bounce domain, the return path, the 5321.from, and other names..

The SPF spec also says that a lookup can be performed on the HELO value. During the SMTP transaction the first step is for the connecting server to introduce itself to the receiving server. These values can be things like “mx.wordtothewise.com” or “mail116-221.us32.msgfocus.com” It’s not a requirement to check this value, but it is an option.

What records should you publish?

SPF records should be published for the mail from address. I typically recommend publishing ~all. Back in 2009, I said there wasn’t much different in how ~all and -all were handled. This was true then, but recently I’ve become aware of a few large providers actively rejecting mail in cases where a -all is published and the sending IP is not in the SPF record.

It’s not uncommon for mail to be forwarded without altering the Mail From: causing SPF to become invalid. This is one of the reasons many ISPs didn’t reject based on SPF. With the advent of DMARC, it seems some ISPs are more confident in the accuracy of SPF records and thus are rejecting based on it. In light of these rejections, unless you really want mail rejected I still recommend using ~all.

What about the from address?

There are still a lot of ESPs and tutorials out there that suggest publishing SPF for the email address in the friendly from. Many years ago this was best practice because Microsoft would check SPF for the From address. It’s not going to hurt anything if you publish a SPF record for this domain, but it’s usually unnecessary.

Related Posts

SPF ?all

The most read post on the blog is Authenticating with SPF: -all or ~all. In fact, it’s in the top 5 posts every single day. We still get comments on it, too. Usually from folks who disagree with my recommendations.
I still stand by my recommendations, though. It doesn’t really matter if you choose ~all or -all in your SPF records. Why? No major provider is rejecting mail solely because of a SPF fail. They may bulk the mail, but they won’t reject it. That’s why, in a deliverability context, it doesn’t matter which one you choose.
My one rule for SPF is never use ?all. Just. No. In the spec, ?all is “testing” mode. But it really is a signifier that the person who put the SPF record together doesn’t know what they’re doing. Unless they really are testing, but even then you shouldn’t see ?all on records for weeks or months.
~ or – never ?

Read More

Fun with opinions

Over the last few weeks I’ve seen a couple people get on mailing lists and make pronouncements about email. It’s great to have opinions and it’s great to share them. But they’re always a little bit right… and a little bit wrong.

Read More

Are they using DKIM?

It’s easy to tell if a domain is using SPF – look up the TXT record for the domain and see if any of them begin with “v=spf1”. If one does, they’re using SPF. If none do, they’re not. (If more than one does? They’re publishing invalid SPF.)
AOL are publishing SPF. Geocities aren’t.
For DKIM it’s harder, as a DKIM key isn’t published at a well-known place in DNS. Instead, each signed email includes a “selector” and you look up a record by combining that selector with the fixed string “._domainkey.” and the domain.
If you have DKIM-signed mail from them then you can find the selector (s=) in the DKIM-Signature header and look up the key. For example, Amazon are using a selector of “taugkdi5ljtmsua4uibbmo5mda3r2q3v”, so I can look up TXT records for “taugkdi5ljtmsua4uibbmo5mda3r2q3v._domainkey.amazon.com“, see that there’s a TXT record returned and know there’s a DKIM key.
That’s a particularly obscure selector, probably one they’re using to track DKIM lookups to the user the mail was sent to, but even if a company is using a selector like “jun2016” you’re unlikely to be able to guess it.
But there’s a detail in the DNS spec that says that if a hostname exists, meaning it’s in DNS, then all the hostnames “above” it in the DNS tree also exist (even if there are no DNS records for them). So if anything,_domainkey.example.com exists in DNS, so does _domainkey.example.com. And, conversely, if _domainkey.example.com doesn’t exist, no subdomain of it exists either.
What does it mean for a hostname to exist in DNS? That’s defined by the two most common responses you get to a DNS query.
One is “NOERROR” – it means that the hostname you asked about exists, even if there are no resource records returned for the particular record type you asked about.
The other is “NXDOMAIN” – it means that the hostname you asked about doesn’t exist, for any record type.
So if you look up _domainkey.aol.com you’ll see a “NOERROR” response, and know that AOL have published DKIM public keys and so are probably using DKIM.
(This is where Steve tries to find a domain that isn’t publishing DKIM keys … Ah! Al’s blog!)
If you look up _domainkey.spamresource.com you’ll see an “NXDOMAIN” response, so you know Al isn’t publishing any DKIM public keys, so isn’t sending any DKIM signed mail using that domain.
This isn’t 100% reliable, unfortunately. Some nameservers will (wrongly) return an NXDOMAIN even if there are subdomains, so you might sometimes get an NXDOMAIN even for a domain that is publishing DKIM. shrug
Sometimes you’ll see an actual TXT record in response – e.g. Yahoo or EBay – that’s detritus left over from the days of DomainKeys, a DomainKeys policy record, and it means nothing today.

Read More