SPF record

The sender policy framework is not new. It’s been out there for quite long. However for the past week it has been a serious issue at the office.
The company I work for right now has contact with lots of important transport companies and email is a very important communication tool.
For some reason about a month ago some of our clients started complaining that our emails were being marked as spam. The easiest solution was to ask them to mark us as not spam, which some of them did. However there were a few of our customer that didn’t wanted to do that. First thing I did was call with my email service provider to ask them to check the issue for me.
They came back to me with the solution to request our customers to add us to their safe lists and start marking our emails as Not Spam… I told them that some of our customers didn’t wanted to do that and my provider said they couldn’t do anything else because everything seemed to be working fine.
My company’s CEO was pissed at me because of this issue. He suggested us to create a new domain from which he could send emails which were not being marked as spam. After discussing the pros and cons he decided we did as he said…
Anyway, time went by and I forgot about the issue till a couple of days ago when he came back to me complaining that the issue was repeating with the new domain and that the initial problem hadn’t been solved.
Of course this was partly my fault and I was pissed because the email service provider was stating it wasn’t our fault and everything was ok. So I started searching on Google to see if other people ever experienced something similar and I did found a lot of similar situations but one fought my attention, it said something about SPF… what is that?
To make the story short SPF is a DNS record. It was created as a mean to validate the origin of an email sender so it would make it a little more difficult for a spammer to reach anyone.
It works in a very simple way. You send an email from your_account@yourDomain.com to recipient@hisDomain.com. Your message travels through the internet and arrives to the email server at hisDomain.com. When the message arrives the server queries the DNS records for yourDomain.com. If it founds the SPF record it will read the confs to validate wether the message you just sent comes from an authorised server, the SPF policy will even tell other servers what to do with unauthorized messages. They can be rejected, marked as spam or accepted cleanly.
So I started reading about SPF thoroughly here.
It’s really interesting and a good first step to protect your email domain from being used as spam.
At the end I added the SPF record authorising both exchange IP addresses, email domains and an additional IP6 IP to send valid emails on behalf of my company.
A great tool to start making the SPF record can be found in Microsoft’s domain here here (Thanks to Debra Peterson for her follow up on this broken link).
I tested the configurations against these great tools:
SPF Query tools
They worked great. Next I did a test sending email to a gmail account. Once I received the email I opened the message and checked out the headers which read like this:

Received-SPF: pass (google.com: domain of noreply@[MYDOMAIN.COM] designates [IP6_ADDRESS] as permitted sender) client-ip=[IP6_ADDRESS];
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of noreply@[MYDOMAIN.COM] designates [IP6_ADDRESS] as permitted sender) smtp.mail=noreply@[MYDOMAIN.COM]

So there it is, my confs are working great and my emails are no longer arriving as spam.
I’m just a little disappointed that my email provider wasn’t aware of this until I brought it up after a followup call.

Tags: ,

Comments are closed.