Reduce email forgery by using SPF DNS records

June 10th, 2013 by William Smith

Here’s the problem:

Super Uber Bank is the largest bank in the world and spammers are using its name because of its recognizability. They’re sending email that looks like it’s coming from “Super Uber Bank Technical Support”. Super Uber Bank’s customers are clicking on links in those spam messages, which take them to a credit card phishing site, and those customers are handing over all their account information and passwords.

Email forgery is simple. Nothing stops me from setting my email address to “Super Uber Bank Technical Support <>” and sending you a message with a link to my credit card phishing site. Few email service providers require their customers to use valid email addresses when sending mail. Spammers just use their own servers anyway.

This puts the onus on the recipient’s mail server to validate incoming messages before passing them to you to read. Spam filtering is an art as much as a science and the software has to balance between what may be legitimate email but looks like spam and what is spam but looks legitimate.

Sender Policy Framework (SPF) records are DNS entries for a domain that provide the names of its authoritative email servers and sending domains. Continuing the Super Uber Bank story:

Super Uber Bank often uses a third party marketing company that specializes in mass-marketing emails. So, it decides to implement an SPF record for its domain. In that record, Super Uber Bank includes its marketing company’s domain  ”” as authoritative for sending mail on its behalf.

An SPF record is a simple text (TXT) or resource record added to the authoritative DNS servers for a domain. It sits alongside any A host records, MX records, CNAMEs, etc.   A            MX
@                            TXT     v=spf1 ip4: -all

In this case the third line is the SPF record. The “@” symbol is shorthand for the current domain ( “TXT” denotes this is a text record, which for DNS servers requires a value or “v=spf1 ip4: -all”.

The text of the value breaks down like this:

v=spf1                              This is the version of SPF record being used
ip4:                  Allow mail from my own server at this IP address     Include this as a valid sending domain
-all                                Reject anything that doesn't match this criteria

And so the story ends:

The spammers are using open relays from a variety of seedy ISPs to send their phishing scams. However, when a Super Uber Bank customer’s email server receives one of these bogus Super Uber Bank Technical Support messages, it compares the address of the sending server to the addresses and domains Super Uber Bank has in its SPF record. Because the server is not in the SPF record the customer’s email server rejects the message without sending it to the customer.

Incorrectly implemented SPF records can stop mail flowing altogether; therefore, customers should consult their ISPs and, likewise, ISPs should consult with their customers before implementation. Some services such as Google Apps and Office 365 have published SPF record information for their customers.

The SPF Project offers a plethora of information for end-users, service providers and support technicians. Their site also includes links for mailing lists and references for SPF consultants who can assist with more complex email scenarios.

Comments are closed.