Fighting Spam and Phishing with SPF

Everybody knows that unsolicited email advertising, commonly referred to as spam, and its even more evil descendant, phishing, can be both an annoyance and a security risk to an organization. Everyday phishers send emails purporting to be from organizations you do business with, attempting to convince the recipient to provide sensitive information, typically of a financial nature.

Sender Policy Framework (SPF) records are designed to protect against forged emails and reduce the number of incoming spam messages a mail system (and sometimes users) have to process. Many times spammers or phishers send email with a forged From address, hoping that the domain name they forge will catch a victim’s attention or at least be allowed through spam filters. An SPF record is a DNS TXT record that a mail server or spam filter will access to verify the source of email messages as they arrive. Many email services began checking SPF records as early as 2004.

Enabling SPF record checking in your mail server software or spam filtering software varies by vendor. Many Open Source email platforms support SPF record checking natively, and plugins (both free and commercial) are available for Microsoft Exchange platforms. You should, however, do more than just implement SPF record checking—you should place an SPF record in your own DNS entries to help fight spam and reduce the chance that a phishing attack utilizing your domain name is successful. Larger organizations might host their own external DNS servers, while others rely on their Web-hosting or domain-registration company’s DNS servers.

To add a TXT record in Windows DNS, select Administrative Tools under the Start menu, then choose DNS. From there, navigate to Forward Lookup Zones, then to the domain to which you want to add a TXT record. Right-click an empty space and select Other New Records. From there, choose Text (TXT). You can name the TXT record anything you want. Strings of code need to be entered into the Text field. For most organizations, the following TXT record value is acceptable to implement SPF:

  “v=spf1 a mx –all”

This string essentially states that if the mail is received from an IP address that’s listed in the sending domain’s A or mail exchanger (MX) records, the mail is legitimate and should be processed. If specific IPs send email that isn’t part of the A or MX records, they can be included using the ip4: mechanism, as the following shows:

  “v=spf1 a mx ip4:1.1.1.1 –all”

In this example, the IP address of the additional mail server is 1.1.1.1.

Prior to implementing SPF, you must make sure that you’ve identified each IP that mail originates from and each domain name used by your organization. For domains that mail should never be sent from, the following SPF record can be used:

  “v=spf1 –all”

This SPF record states that the domain has no IPs that send mail, and the mail system receiving mail from this domain should automatically reject the message.

As with all things technical, you need to test your implementation to ensure it functions as you expect. The Sender Policy Framework Web site (www.openspf.org) has some excellent tools to help you implement and test your SPF records.

If the vast majority of DNS records contained SPF values and if the vast majority of email servers used SPF to check for valid email server IP addresses, the volume of spam and phishing email would be significantly reduced. We could then all go about the business of doing business without the nuisance and security risks associated with spam and phishing.

—Nolan Garrett,
Co-Founder and Chief IT Consultant,
Intrinium, and Jeff Jones,
Co-Founder and Chief Security
Consultant, Intrinium