Importance of periodically validating your Sender Policy Framework record

A frequent topic of my blogs is the need to confirm that what you did 6 months ago is still valid today.  While there are improved methods for protecting your domain from being spoofed (such as DKIM/DMARC), one of the core methods is using the Sender Policy Framework (SPF) record.  This DNS record essentially defines which hosts and IP addresses are authorized to send on behalf of your domain.  It is the recipient’s responsibility to verify that the IP that sent the mail is in your authorized list and act accordingly.

What issues do we see?

The issues that we frequently see with people’s DNS records is that either they were set up improperly, had a typo introduced over time, or reference invalid DNS entries which causes validation failures.

Some of the more common examples are:

  • 2 TXT records with “v=spf1 ……” information in them.
    • There should only be 1 “v=spf1” record.
  • “IPv4:1.2.3.4”
    • Should be “IP4:1.2.3.4”
  • “IP4:1.2.3.4a:mail.company.com”
    • Should be “IP4:1.2.3.4 a:mail.company.com” (missing a space after the 4)
  • “a:oldmailserver.company.com”
    • No DNS record exists for that host and causes a ‘permerror’ while performing the SPF validation
  • “include:mailservice.company.dead”
    • The 3rd party service is no longer around, so DNS fails for it causing a ‘permerror’ while doing the SPF validation
    • Also, make sure you’re still using that 3rd party service for sending mails.

When there are errors in the SPF validation, the recipient system tends to accept the email, making it easier to spoof your domain.  That’s why it is important to make sure that there aren’t any errors in your SPF record.

How to identify and resolve these issues

The simple way is to review your DNS records periodically with fresh eyes and make sure all the entries are valid.  There are tools on the Internet that you can run to validate the syntax of the SPF record; those are great for detecting syntax errors and dead DNS records.

If you are using Office 365 for email, we offer a solution that checks a number of security items in the environment on a weekly basis, including checking for DNS issues with your SPF record so you can rectify it quickly.

However, your eyes are still going to be required to validate that the 3rd party solutions you’re including are actually being used for the service.  And the IP addresses you have listed are still yours and not from an ISP you moved away from.

Two more tips from the real world

One recommendation is around IP addresses: if you need to explicitly list IP addresses for another vendor (one that doesn’t provide a DNS record for you to use with the “include”), you need to create your own DNS record.  For example, if your domain is “mycompany.com” and the service you’re using is called “Mass Mailing Enterprises” and they send mails out from 1.2.3.4, then you may want to create a DNS record of:

spfmassmailingenterprises.mycompany.com       text =

“v=spf1 ip4:1.2.3.4 -all”

Then, inside of your SPF record for your mycompany.com, you can then add

include: spfmassmailingenterprises.mycompany.com

This will allow you to know what IP 1.2.3.4 is.  If the vendor notifies you that their IPs are changing, you simply update your DNS record to reflect the IP changes.  If you stop working with that vendor, you just clean up your DNS records.   Otherwise, you’ll have “ip4:1.2.3.4” mixed in with all the IPs you own and might be carrying around unnecessary debris that you should have cleared off.

The other recommendation: make sure you’re using “-all” (fail, or commonly referenced as hard fail).  We see a lot of organizations specifying “~all” (soft fail) because they’re not quite sure if they have identified all the servers that are authorized to send mail on their behalf.  Using “~all” is fine for a temporary fix while you’re validating everything.  However, finish validating your senders and change the record to use “-all”.   This will allow recipients to act confidently with your provided information versus potentially allowing spoofed mails in because you’re not sure who is authorized or not.

Hopefully you’ll add that to your list of items to review every couple of months.  If you’d like to learn more about some of our automation that we can provide to help with this task and much more, contact us at info@peters.com. We are happy to help!

By | 2018-12-18T11:48:30+00:00 May 14th, 2018|Infrastructure Services|Comments Off on Importance of periodically validating your Sender Policy Framework record

About the Author:

John has been with Peters & Associates for over two decades. Over the years, John has diligently worked on the delivery of solutions matched to organizational business issues. As technologies have evolved, John has adapted skill-sets to continually exceed customer expectations and outcomes. John is a DePaul University alum with a Master’s in Computer Science with minors in Math and Physics. John’s capabilities are validated by industry certifications and accolades including CISSP, CCNP, MCSE, and many others. John has primary mentoring and managerial responsibilities over a dedicated engineering staff. With client satisfaction as a guiding star, John aligns delivery, escalation, consistency, and on-going training to make sure customers receive value day-in, day-out.