SPF Overview

You can help eliminate the spam problem by making it easy to detect forgeries. Protect your e-mail address reputation with a simple DNS technique.

SPF by Example

Suppose example.com wants to publish SPF. It expects MTAs
everywhere to read its SPF record and use it to reject
forgery attempts. It hopes SPF reduces the volume of
joe-job bounces and bogus abuse reports. So it adds the following line to
its zone file:

example.com. IN TXT "v=spf1 a mx ptr -all"

The v=spf1 version string identifies this as an SPF
record. The -all means reject all mail by default. Domains that don't send
any mail, such as
altavista.com, can get by with simply v=spf1 -all. But
if the domain does send mail, it declares mechanisms that
describe how legitimate mail should look. Mechanisms go in
the middle, before -all. The first mechanism to match
provides a result for the SPF query. -all always matches
and so belongs at the end.

Basic SPF

A: the A mechanism means the IP address of example.com is
permitted to send mail from example.com.
If you want to say the IP address of some-other.com is
permitted, you can say a:some-other.com.
You can use as many A mechanisms as you want.

MX: the MX mechanism means the MX servers for example.com
all are permitted to send mail from example.com.
If you want to say the MX servers for some-other.com are
permitted, you can say mx:some-other.com.
You can use as many MX mechanisms as you want.

PTR: the PTR mechanism says if a host has a PTR record that
ends in example.com, it is permitted to send mail from
example.com. This would be a good choice for Yahoo, whose
mail server names all end in yahoo.com. It would be a bad
choice for a broadband provider like Comcast.
If you want to say servers whose names end in
some-other.com are permitted to send mail from example.com,
you can say ptr:some-other.com.
You can use as many PTR mechanisms as you want.

IP4: to say the class C network of 192.0.2.0 is permitted to
send mail from example.com, you would write
ip4:192.0.2.0/24.

Mechanisms are interpreted left-to-right. Using v=spf1 a mx ptr
-all first would check whether the connecting client was found
in the A record for the domain or, failing that, in its list
of MX servers. Then the MTA would check to see whether the
hostname of the client matched the domain. If none of the
mechanisms matched, -all would be evaluated, the result
would be fail and the MTA would be justified in rejecting
the mail.

A, MX, PTR and IP4 are enough for the overwhelming
majority of domains. The setup wizard at
spf.pobox.com/wizard.html can help you configure SPF
for your domain. But if your situation is complex, you can
use the mechanisms described in the “Advanced SPF” sidebar.

Extensibility

SPF has a number of built-in mechanisms. The basic ones let
you designate the hosts that send mail from your domain.
This works well for almost all domains out there,
because each domain's mail comes only from a small set of
hosts. But if mail from your domain is distinguished in
some other way, say you always sign it with S/MIME, instead of typing a or mx you
can type smime.

Using designated sender mechanisms (A, MX, PTR and IP4) is
one possible approach to sender authentication. New sender
authentication methods are being developed. SPF is extensible, though, so
it can
work gracefully with them. SPF plugins that
understand future extension mechanisms will be able to interpret them
correctly. SPF plugins that don't understand those
mechanisms will return unknown, and your domain will be
treated as though it did not have an SPF record at all.

Protecting Subdomains and MX Servers

Today, spammers forge domain names. Tomorrow, they might
forge hostnames. They might try to joe-job your laptop by making up
username@ibook.example.com.
It's a good idea to protect your subdomains as well. You
should start with your MX servers and move on to other hosts
with A records. Here's why.

Bounce messages are sent with MAIL FROM: <>. The null
sender address ensures that bounces don't themselves bounce
and create a loop. When SPF sees the null sender address,
it falls back to the hostname given in the HELO command.
When your MTA sends a bounce message, it announces its
hostname in the HELO command it sends. If that hostname has
an SPF A mechanism listed, the message passes. So SPF
prevents HELO forgery as well.

Comments

Comment viewing options

I read this article after reading the May 2004 article because my subscription just started up. So, interestingly, everything seemed to flow. Thank goodness Linux Journal posts their articles!

I found this one here because I read the other article and thought "Hey, I need to do/learn this! Where's that previous article." A few clicks later, there it was. :)

I can understand the first person's frustrational comment about the definition of SPF. I explained a little of what I was doing to my signifigant other, and the initial response, after defining SPF, was "Oh, I thought it was like sunblock. You know, like SPF-15, SPF-45.."

In a way, it is like sunblock. It prevents your systems from burning up from processing all of that spam!

I think you are missing out on some experience when it comes to technical writing. Technical lingo should be explained, but not to the depth of the PDR (Physician's Desk Refeence). Because the industry is so acronym-laden, many have found a common style to use the acronum once and place an explanation in parantheses afterwards, describing the acronym or term, but after that, to use the acronym (only) as the meaning has been explained. The initial reference can be seen in my reference to the PDR above.
And finally, but most importantly, material should be written|developed|edited so a reader doesn't have to read a sentence more than once for comprehension. Have you ever found yourself halfway into a sentence (technical, romance, etc. and say, "Huh?" then go back to the beginning of the sentence and start reading it again? That's an example of a bad book. Bad book! Bad bad book.