Sender Policy Framework (SPF) is one of two primary types of email authentication mechanisms used by email senders today (the other being DKIM). SPF is a “simpler” protocol than DKIM, in that SPF is based around a text record for your domain name that contains the IP addresses of the mail servers that are allowed to send mail on your behalf.
You can lookup the SPF record for Spam Resource here, using my XNND DNS Tools website. As of this writing, that SPF record looks like this:
It contains two regular IPv4 IP addresses, one IPv6 IP address, and an “include” mechanism that references Google’s SPF record. Decoding this tells us that I want those three servers (with those three IP addresses) to be able to send mail using my domain name spamresource.com, and the “include” for Google is because I am a user of GSuite/Google for Business, and thus I want to use Google to send mail as spamresource.com, too.
The last bit of it ends in the "all" mechanism, with one of three "modifiers:" ~all, -all or ?all. Here's what each one does.
Using ?all means "neutral/no" policy defined. This is sort of useless. You might see an ISP do this to say, "I'm not sure what all of my IP addresses are, but here, at least you have these ones, you can perhaps choose to whitelist my mail based on these." Cranky nerd jerks who want to fight about whether or not SPF should even exist will sometimes use this, as well. (If you find a "+all" mechanism, then you've definitely found one of those.)
Using ~all means you're setting a "soft fail" policy. You see this most often. The sender is saying "I am pretty sure I've listed all of my IPs in my SPF record, but I'm hedging my bets slightly."
Using -all means you're setting a "hard fail" policy. The sender is saying "I've for sure gotten my SPF record right, this is all of my IPs." It implies that ISPs should treat mail harshly if it references that domain but fails SPF
As you can see in my spamresource.com example, I use -all, “dash all.” Which one you should use is a complex question and I’ve blogged on that question in more detail over here. "Dash all" is more secure, but more risky; if you fumble your SPF implementation and use dash all, you're more likely to see legitimate mail bounce. But if you get it right, this setting helps reject spoofed mail more readily.
When an ISP checks inbound mail to see if it passes SPF authentication, it doesn’t actually check the visible from address. It checks the “return path” or “envelope sender” domain, instead. When you’re sending from something like a Gmail account, those addresses are the same, but if you’re using an ESP or CRM platform to serve up email messages, it may have a unique “bounce domain” setting that applies to this return path domain. That means that if your mail sends with a bounce address of bounces@bounce.spamresource.com, you need to give bounce.spamresource.com an SPF record. An SPF record for the top level spamresource.com will not “trickle down” to subdomains.
Marketing senders should definitely implement both SPF and DKIM as much as possible. One is enough most of the time, but you want both, so that one will backstop the other in case of failure. Email forwarding “breaks” SPF authentication, and content or header modification can break a DKIM signature. Having the other in place during either scenario can help make your email still appear legitimate to a receiving mailbox provider.
SPF "includes" can be problematic in that adding too many references to external service providers in this way can result in an SPF record that requires more than ten DNS lookups to be processed; this is against spec and not recommended. In my non-scientific observation, it does seem, though, that large ISPs grant leeway to email senders and do not broadly seem to enforce the ten lookup limit. Still; best to get it within spec as much as possible.
SPF is a broadly adopted email authentication technology, and it is defined in RFC 7208.
Microsoft used to utilize a similar, but slightly different email authentication called Sender ID. Sender ID is no more. If you find guidance that suggests that you should implement Sender ID, it is probably (very) out of date.
And finally, don't forget to check out the DELIVTERMS section here on Spam Resource, where we define the common terms used in email technology and deliverability.
Sender Policy Framework (SPF) is one of two primary types of email authentication mechanisms used by email senders today (the other being DKIM). SPF is a “simpler” protocol than DKIM, in that SPF is based around a text record for your domain name that contains the IP addresses of the mail servers that are allowed to send mail on your behalf.
You can lookup the SPF record for Spam Resource here, using my XNND DNS Tools website. As of this writing, that SPF record looks like this:
ip4:213.138.100.131 ip6:2607:f2f8:a760::2 ip4:206.125.175.2 include:_spf.google.com -all
It contains two regular IPv4 IP addresses, one IPv6 IP address, and an “include” mechanism that references Google’s SPF record. Decoding this tells us that I want those three servers (with those three IP addresses) to be able to send mail using my domain name spamresource.com, and the “include” for Google is because I am a user of GSuite/Google for Business, and thus I want to use Google to send mail as spamresource.com, too.
The last bit of it ends in the "all" mechanism, with one of three "modifiers:" ~all, -all or ?all. Here's what each one does.
As you can see in my spamresource.com example, I use -all, “dash all.” Which one you should use is a complex question and I’ve blogged on that question in more detail over here. "Dash all" is more secure, but more risky; if you fumble your SPF implementation and use dash all, you're more likely to see legitimate mail bounce. But if you get it right, this setting helps reject spoofed mail more readily.
When an ISP checks inbound mail to see if it passes SPF authentication, it doesn’t actually check the visible from address. It checks the “return path” or “envelope sender” domain, instead. When you’re sending from something like a Gmail account, those addresses are the same, but if you’re using an ESP or CRM platform to serve up email messages, it may have a unique “bounce domain” setting that applies to this return path domain. That means that if your mail sends with a bounce address of bounces@bounce.spamresource.com, you need to give bounce.spamresource.com an SPF record. An SPF record for the top level spamresource.com will not “trickle down” to subdomains.
Marketing senders should definitely implement both SPF and DKIM as much as possible. One is enough most of the time, but you want both, so that one will backstop the other in case of failure. Email forwarding “breaks” SPF authentication, and content or header modification can break a DKIM signature. Having the other in place during either scenario can help make your email still appear legitimate to a receiving mailbox provider.
SPF "includes" can be problematic in that adding too many references to external service providers in this way can result in an SPF record that requires more than ten DNS lookups to be processed; this is against spec and not recommended. In my non-scientific observation, it does seem, though, that large ISPs grant leeway to email senders and do not broadly seem to enforce the ten lookup limit. Still; best to get it within spec as much as possible.
SPF is a broadly adopted email authentication technology, and it is defined in RFC 7208.
Microsoft used to utilize a similar, but slightly different email authentication called Sender ID. Sender ID is no more. If you find guidance that suggests that you should implement Sender ID, it is probably (very) out of date.
And finally, don't forget to check out the DELIVTERMS section here on Spam Resource, where we define the common terms used in email technology and deliverability.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.