Sender Policy Framework (SPF) is a painless way to control email that claims to be from your domain. It is designed to block others from sending mail from an address in your domain name, which is currently very popular with spam and virus email. Adding a single text (TXT) record to your DNS is all it takes.

Everyone should be publishing SPF records today even if you don't yet use SPF checking on your own inbound SMTP mail. If you do not publish this information anyone can spoof mail from your domain without restriction and virtually without your knowledge. Did you ever wonder why you get bounce messages for mail you never sent? This is most likely because you are either not yet publishing your own SPF record or the other mail server is not yet checking SPF on the mail it receives.

Adding SPF

Adding one of the following text records to your domain is a very good place to start.

Or for a much faster lookup, use your public IP address and a netmask that covers your whole network:

It is important to replace the example.net. part with your domain name and the IP address (172.30.173.0) with your actual public IP so this will correctly describe you.

This record can be added and edited through the IPAD's web manager or by directly editing the DNS zone file(s). It is strongly suggested to add the TXT record through the web manager so it can make sure the serial (version) numbers in each of the modified zones are correctly updated.

A Real World Example

It just so happens that paypal.com has SPF records and you can use these to find the IP addresses for their valid mail servers.

Here is how I did it.

Open the IPAD's web manager and go to Support/Tools/Name Server Lookup. I use the web manager because it is much easier to cut and paste the answers for multiple levels of DNS name resolution.

Type or copy the following line into the box:

This returns two SPF records. I'll walk through the version 1 (v=spf1) line. (Apologies for the line wrap.)

At the end the ~all (note the tilde) means they are not really sure if this is a complete list. So other mail servers should soft fail mail from servers not in the list just in case. The mx part at the front means any IP address you find by looking up the MX records for "paypal.com" are also valid for sending mail. Resolving the MX record is left as an exercise for the reader.

They also use a lot of INCLUDE: domains, which may be required for their size but is NOT wise in cases where all of the mail servers are in the same building or the same subnet.

To get the full answer I copied each of the domain names following the INCLUDE: parts, one at a time, into the NSLOOKUP window (keeping the -q=txt -rec part and did another lookup.

The really sad part is that they have a nested tree of INCLUDE domains pointing to SPF records with even more INCLUDE domains. This is very bad form because it creates extra load on their DNS servers and makes it take longer for our mail server to validate mail from their domain. And to make things worse, if mail is not validated and accepted before the SMTP session times out, their mail server is forced to try the whole process all over again at a later time adding extra work load to everyone involved.

This is why it is so important to keep the SPF record short, logical and to the point without duplicated overlapping redundant repetitively redundant duplication.

For example, it is a very bad idea to use a rule like:

This example requires a minimum of three DNS lookup operations ( MX lookup followed by A lookup, reverse DNS to find the PTR). But if all three resolve to the same 172.21.173.1 IP address, the three rules overlap with no additional protection.

Some believe it is a good idea to use the MX option because that helps to populate the remote mail server's DNS cache so reply mail gets back to you quicker, but this happens at the cost of slowing down received mail with additional DNS work. This is a choice you must make for yourself and only has a chance of working if your have long enough TTL times in all of your DNS zones.

If the MX records for your domain do not include all SMTP servers that can send mail from your domain, then give the IP4: addresses as a whole class C (/24) block even if that block includes other machines. It is a lot easier (and a very smart idea) for you to add routing filters to prevent spam from those other machines than it is to continually update your SPF records for all of your domains every time you need to move a mail server to a different IP address within your block.

First published 2007-02-07. The last major review or update of this information was on 2009-05-20. Your feedback using the form below helps us correct errors and omissions on this page.