Provided your host machine has SMTP verbs installed, it is technically an email server. Spammers target domain names who are registered and active on the public DNS and simply use that as a spoofing address for spamming or change the reply to address and/or hack into web servers and host a fake webpage to conduct Phishing attempts to steal usernames and passwords.

It’s pretty easy to demonstrate this.

I used domain abc.com and xyz.com (examples) – one with and one without SPF implemented respectively.

Used telnet to drop a test email to my live account using abc.com and xyz.com email addresses

Email landed in my live.com Junk email folder for Abc.com

Email landed in my live.com Inbox folder for Xyz.com

This shows that if you have an SPF record in place, it is less likely that Spammers will target your domain address to send bulk emails to the internet simply because SPAM filters will check the SPF record and reject those emails. Additionally an SPF protected domain won’t get blacklisted very easily. Email servers, AOL for example requires your domain to be SPF compliant so they can perform a reverse lookup and approve the email that is coming in.

How does SPF work?

Everytime a source sender email address is hardcoded when an SMTP session or dialog is established between 2 email servers. Say there are 6 hops from source to target and if one server in the hop rejects the email, the unauthorized client will get a force rejection and the message transfer agent (MTA) in that email system will issue an NDR (Non Delivery Report) to the original source sender email address. If all the servers in the hop accepts and acknowledges the source Sender email address MTA will inject a Return-Path field in message header.

With the help of an SPF record, emails will be rejected by email servers globally (provided you use a reliable SPAM Gateway) since these Return-Path addresses and server ip’s and URL’s designated to send emails aren’t added to the SPF records. In summary if you don’t have an SPF record in place you will have random employees complain that their emails are landing in recipient Junk folders frequently – not for all staff but for some. SPF’s can also help your domain from getting blacklisted or at least minimize the damage in the event someone targets your domain name.

Let’s also take an example where one of your employee email credentials got compromised on the internet as a result of a phishing attack. At this point, spammers will try combinations like owa.domain.com, webmail.domain.com, email.domain.com etc and send mass emails which is unfortunately an SPF PASS. To mitigate this, you need to send monthly notifications to educate users on Phishing attempts and how they can be targeted. I always suggest my clients to “LIMIT” the number of emails per user per hour to an agreeable number and to have an alerting system in place in the event someone starts sending mass email. In my experience a typical company of 10000 users limits their outgoing email count to the internet to 500 emails per user per hour – varies with business.

A typical Phishing attack looks similar to this:

SPF responses are of several types – PASS, Neutral, None, Fail etc

In the above shown example of Message header, the domain DO NOT have an SPF record in place so the response is Received-SPF: none

How to create an SPF record:

Well creating an SPF record is a no brainer. All you need to do is to create a TXT record in your public DNS.

So if your domain name is abc.com – navigate to Whois.SC and check which NameServer it points to and you need to make the changes on that Name Server provider.

I am being specific because I have seen people registering their domain name with GoDaddy and Name Servers and pointed to EasyDNS. In this case GoDaddy is going to be your domain registrar but EasyDNS hosts your DNS on the public internet.

Before creating an SPF record you need to have your mailflow network diagram in place. Simply because you don’t want to miss adding an email servers or public ip to the SPF record.

I use ExRCA.com Message header analyzer to find out the route taken by my email and probe and make sure we don’t have multiple gateways addresses routing external emailflow:

Once you have all the ip’s listed down, simple create a TXT record in the format. I normally put the TTL value to 5 minutes if I am editing the SPF record:

We have an issue when receiving email spoofed as our own domain acme.co for example.

We have a valid SPF record published with our registrar (DNS TXT type 16) and an mx record of mail.acme.co. Running it through mxtoolbox everything appears correct and passes. We have Exchange 2013 is configured for a hard fail should an organization not have a valid SPF record. When we receive a spoofed email from user@acme.co however we get a result of ‘none’. Thinking out loud I am guessing it is checking the local domain and dns on AD which is acme.co where it does not have an SPF record?