Home » Blog » Do You Really Need an SPF Record?

Do You Really Need an SPF Record?

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?

Photo by Jason Blackeye on Unsplash

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Blog


  1. Mike Donovan says:

    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.

    • 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.

      • Michael Donovan says:

        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!

Leave a Reply

Your email address will not be published. Required fields are marked *