For some time now I’ve considered Sender Policy Framework (SPF) records an essential part of domain name ownership. As it turns out there’s still some debate in tech forums as to whether SPF records are required or not.
SPF records are used to prevent spammers from spoofing your domain name. Recipient servers can use the SPF record you publish in DNS to determine whether an email that they have received has come from an authorized server or not. They can then make a decision about how to treat that email. You can read a more detailed run down of SPF records here.
Over recent years SPF has gone from a “nice to have” to a “must have”. Even if they aren’t perfect, they are quite effective and are part of being a good email citizen on the internet. But some email admins don’t see it that way, despite the fact that without an SPF record:
- Spammers can spoof your domain name to spam other networks, harming your brand’s reputation.
- Attackers can spoof your domain name for phishing and whaling attacks, potentially leading to ransomware, malware, and financial loss or fraud.
- Other email servers on the internet may reject your email because they can’t determine its legitimacy.
Any of those should be enough to spur you into action and implement an SPF record, and all three together are quite alarming. Even though I am personally a bit slack in creating an SPF record for every single one of my domain names, I do try to ensure that all my email domains have SPF records (so that my mail doesn’t get rejected), and any other important website domains also have SPF records even when I don’t use those domains for email (the SPF record still prevents spoofing).
It’s 2017. If you aren’t using SPF records by now, are you even doing your job as an email admin properly?
Update March 2018 – Changes rolling out to Office 365 ATP pretty much end this debate. Without good SPF/DKIM/DMARC for your domain, expect to get junked a lot.
Photo by Jason Blackeye on Unsplash
Hey, Thanks for giving such information, keep updating such information this article is worth to read and get information related to SPF record
Hi Paul, I know this is quite an old post now. I was wondering about the need to update your SPF if your On-prem to M365 Hybrid connector is responsible for sending ALL emails out, rather than just your inter-org ones. So, no emails from on-prem would go directly to destinations, but would all go via EOP, and then EOP would send them onwards. Kind of like uses EOP as a Smarthost for your on-prem emails. Thank you.
Message to the blog keeper (Paul?),
If you’re going to limit comment length, you should include that info here where we’re typing in our comment. I just spent 1.5 hours helping Nuge93 only to be told, “Your comment is too long”. I then went back to shorten it (and parse it into 2 comments) only to have them both removed. I consider this rude and unprofessional and frankly, this is why people don’t try to help on sites like this. I understand you have to guard against spammers and excessively long posts but, often, helping someone and trying to be clear means a lengthy comment.
Gabe
@Nuge93
Let’s draw up two scenarios…you as a sender and you as a receiver. Hopefully this will clarify all your questions.
As a sender, you have an email server. Your domain is nuge93.com and your server’s IP address is 1.2.3.4. You would set your SPF record to be v=spf1 ip4:1.2.3.4 ~all. Since this is done at the DNS level, your nuge93.com domain and 1.2.3.4 address are now synonymous (at least from an SPF standpoint). So, when my receiving server sees your email come in, and because I have my server configured to judge SPF records, you’re email will receive an “SPF Pass” and will go on through to the next step of my filter system. This doesn’t mean it will necessarily make it to my Inbox, but it definitely doesn’t get stopped at the SPF checkpoint. Where this helps you and me is when a spammer who sends me an email and claims it’s “from JoeSchmoe@nuge93.com” but his server’s IP is 5.6.7.8, my server will mark that as “SPF Fail”. However, this also doesn’t mean it will NOT make it to my inbox…every server is configured to handle SPF differently (and some to ignore the record altogether).
…see my next post for the rest (this blog doesn’t allow excessive posts to protect against copy/pasting log files and such)
As a receiver, you decide what you want to do with an income mailer’s SPF record. First, you can either decide to consider the sender’s SPF record or ignore it. If you want your server to scrutinize the record then you can also decide what happens if there’s a failure. So, if someone sends you an email that’s from “president@whitehouse.org” but the IP address originates from a Nigerian server, this is clearly a spammer and the SPF check will fail. You’re server will treat it accordingly.
Now that I’ve typed all of this out I’m realizing that your confusion might be at the SPF record’s set up. When configuring your record, you can choose to use a soft fail (~all) or a hard fail (-all). I think of it this way. Since I know my internal email server is the only email server that will ever legitimately send an email with my domain and IP address, I chose to put a hard fail (-all) on my spf record. In the above example, this would tell a receiving server, “Hey if you get an email that claims it’s from nuge93.com but the address is NOT 1.2.3.4, then JUNK IT!” As for soft fails, think of that as saying to the receiver, “If you get an email that claims it’s from nuge93.com but the address is NOT 1.2.3.4, then you can accept it if you want, but mark it as suspicious”
Thanks for putting in the effort with this reply (replies). Not sure if anyone else has said thanks for it’s great when somebody takes the time.
I just learned today on Amazon’s site that SPF was depricated in April of 2014?
Here’s the Amazon page: https://aws.amazon.com/premiumsupport/knowledge-center/spf-record-mail-provider/
…and they link to this IETF page: https://tools.ietf.org/html/rfc7208#section-14.1
Sometimes it just seems that the good guys fight with each other on policy so much that the spammer’s job gets easier and easier.
I didn’t dig through the entirety of that IETF reference but a while ago, there was an actual DNS record type called SPF, which is deprecated and my guess here in 2020 is not at all in use. So SPF is now implemented by using TXT records, and is very much alive and required.
The SPF *record type* (as separate and distinct from a TXT record containing SPF) is deprecated. SPF itself (via TXT record) is not.
Paul,
I’m very new to SPF records so please excuse me but if an SPF record is created, does that mean that only those IP addresses listed in the SPF record,
get through to the intended recipient?
Or is it a for sure those that are listed in the SPF record get through, and those that aren’t listed, are allowed/blocked based on the ISP filter?
What I’m trying to figure out or confirm, is once an SPF is created, if it’s an all or none setting.
Thanks for any information you can provide.
I absolutely agree. There are so many companies that aren’t setting this up. My biggest problem is with major Email hosting companies. They know SPF records should be set up, but they aren’t approaching their clients they host email for to advised them this needs to be done. So many of our clients are in small companies and none of them have this set up nor do they know of it. These companies are very small they don’t have IT departments, its a real struggle for them.
Hosting companies have to take proactive action and let their clients know etc.
Pingback: Paul: Do You Really Need an SPF Record? – Seo On Exchange
Pingback: Do You Really Need an SPF Record? | COMPUGEDDON
Although maintaining SPF records is becoming the norm, so is using service providers who spoof corporate addresses. Its very common now to have payroll or helpdesk providers use the corporate email address in the reply to make the end user think these functions are handled internally…or at least remind the user that these are company emails.
This make making SPF records difficult to maintain. I work at a modest size global company. In the US alone, we have 20 companies spoofing our email address by design. I can’t tell you globally how many vendors are doing this for us. And they come and go all the time. So in short, easier said than done.
The Real Person!
The Real Person!
Yes, I agree. So what I do is start from the assumption that SPF is mandatory for my organization’s domains. Then look at how to make that manageable in a world of external SaaS systems.
If you can use the SPF requirement as part of your SaaS selection criteria and implementation planning then that makes life a little easier. Retrofitting is a little harder, but doable with persistence and the backing of your infosec ppl (or anyone important enough to help you push through the changes).
Some SaaS providers make it easy by providing a single DNS name to include for your existing SPF record. Others aren’t as prepared for this, and just give you a list of IPs that may or may not change some day without notice.
Often I end up implementing a subdomain for specific purposes or specific SaaS providers. Let’s say your marketing team loves to send out customer satisfaction surveys using a SaaS application. Give them a domain of “surveys.domain.com” to use, and configure the SPF record to authorize that SaaS app, and keep it separate from your main domain (which should be treated as super critical to your company and brand, and not allowed to be polluted by other systems).
Keep in mind that from and reply-to are different, so while an external payroll SaaS app might send from payroll@blah.domain.com, employees can hit reply and have the replies go to payroll@domain.com (as long as your SaaS app supports that, which gets back to the selection process I mentioned earlier).
I know it’s not an easy win for everyone, but it’s win that is worth fighting for.
This is not the first time I have heard the subdomain suggestion. I’m glad to hear you validate this approach. I will push harder on this now because once in this configuration for all of your vendors, you could put a transport rule in something like….
“If the email originates outside the company and is using our root domain as the address, reject it!”
You have renewed my energy for this project!
Just give your providers an own subdomain, own DKIM-key and DMARC policy for the new subdomain. No spoofing!
Paul, can you speak to DMARC and DKIM in addition to SPF?
The Real Person!
The Real Person!
They’re another layer of the solution. There’s some good guidance out there, like this series by Jaap:
https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/
Andy also has a bunch of related tips you can search for here:
http://no-one-uses-email-anymore.com/
What about postfix guides?
I don’t use Postfix at all, so I don’t have any info to share.