SPF

Back
How to set up SPF on my Qmailtoaster

Erik Espinoza 01:15, 11 Sep 2005 (PDT)

Dan McAllister 16:33, 28 November 2008 (EST)

What is SPF

SPF is a tool used to defend against SPAM -- unwanted email messages. Originally named "Sender Permitted From", the re-named "Sender Policy Framework" was created in 2003, and is an attempt to identify and control one specific type of SPAM: forged messages.

A forged email message is one that purports to be from some domain (or some user at some domain) that it is not. For example, claiming to be an update for Microsoft Windows from microsoft.com, when in fact, the message comes from a Russian address.

To accomplish this, SPF creates a way to allow domain owners to specify which mail sources are legitimate for their domain; and by exclusion, which ones are not.

While certainly not all SPAM is forged, virtually all forgeries are SPAM. Therefore, SPF is just ONE tool (of several) for controlling SPAM in the QMail Toaster.

How is SPF implemented?

SPF uses DNS, which is already heavily used by mail servers (MX records are used to determine the mail receivers for a domain) to create a list of valid mail senders for a domain.

There are two distinct parts to SPF:

• The identification of an SPF policy for the SENDING domain, and
• The processing of an SPF policy for the RECEIVING domain

On the sending domain side, the changes are entirely in DNS: just as you must create MX records in your domain's DNS to identify mail servers that accept mail, you now will need to identify those hosts that are allowed to send mail. (See "Configuring SPF for my outbound messages" below.)

On the receiving domain side, the changes are implemented in the mail server itself. Specifically, we insert a step in the mail receive process where we check two separate entries:

• the MAIL_FROM header (the sender's self-proclaimed return address)
• the HELO (or ELOH) identity of the sending server

We then configure how to handle messages that fail SPF checking: perhaps you delete them, perhaps you tag them in some way... or, perhaps you're just testing and you ignore it altogether. (See "Configuring Qmail Toaster for processing SPF for my inbound messages" below.)

---

Configuring SPF for my outbound messages

As noted above, we'll use DNS to define to others what hosts (IP addresses) are valid senders for our domain(s). To be backward compatible, and to allow SPF to be implemented without updating DNS servers, the initial implementation of SPF uses TXT records to specify your domain's SPF settings.

It should be noted here (for completeness) that a new record type (99) was created in 2006 (RFC 4408). The new record looks exactly like the TXT record used before, except SPF replaces TXT. If you're using bind version 9.4 or later, you can simply change TXT to SPF on your configuration line -- the formats are identical. However, for at least the next 5 years or so, you should implement BOTH formats (TXT and SPF), to maintain backward compatibility. If you're using djbdns (the default with the QMail Toaster), you can only enter the TXT format.

If you are using a hosted DNS -

This may occur if you registered your name with a web hosting company, or a DNS hosting service, and in this instance, you'll need to go online and create the TXT (and, perhaps, SPF) record for your domain(s).

NOTE: There are some hosting services that either don't know of, or specifically deny your access to TXT (or SPF) records. In this case, either chose a new hosting company or live with the increasing number of bounces as ISP's begin to migrate to an "SPF is REQUIRED" policy. Also, remember that the SPF record itself is relatively new -- some very good hosting services may not have yet upgraded their systems to allow for both the TXT and SPF formats. As long as you can enter the TXT entry, you'll be good for a few years.

If you're hosting your own DNS -

You will need to create the SPF records within your zone file for each domain for which you will be hosting mail.

Do not make this overly complicated: You need to have exactly 1 TXT (and perhaps 1 SPF) record for each domain -- that is, the part after the @ in the email address. You do not need TXT or SPF entries for each host, and you definitely should not apply SPF to wildcard DNS entries.

By far, the most common entries for an SPF definition will be:

     domain.tld. IN TXT "v=spf1 a mx -all"
     domain.tld. IN SPF "v=spf1 a mx -all"

Which translates into:

• domain.tld: This DNS entry is for the domain domain.tld
• v=spf1: This is an SPF record, not Sender ID or anything else
• a: The IP address of this domain name alone (usually a web server) is a valid source of mail messages for this domain (resolves from "host domain.tld.")
• mx: All of the MX identified mail servers for this domain are also valid sources of mail messages for this domain (resolves from "dig mx domain.tld.")
• -all: nothing else is a valid sender of messages for this domain.

However, there are more options:

• Use ipv4:x.x.x.x to identify a specific host that is valid
• Use ipv4:x.x.x.x/y to identify a range of hosts (like a subnet-mask)
• Use a:domain.tld to specify a DNS entry that identifies valid mail sources
• Use include:domain.tld. to identify someone else's SPF settings you want to import
• Visit this website to read about ALL of the syntax options
• Use this tool to build your own SPF record

NOTE: To keep things simple, if you need more than the "v=spf1 a mx -all" provides, consider creating an A record in your domain called "senders" and listing all of your valid sending IPs in that record. Then use an SPF record like: "v=spf1 a:senders.domain.tld mx -all"

ALSO NOTE: Many sites will show you an example with the -all changed to a ~all (tilde vs. dash)... the ~all means non-specified addresses should be marked as "soft-fail" -- which is usually NOT blocked. This is fine for your testing phase, but should be changed to a dash when your testing is completed... to that forged messages from your own domain fail, instead of softfail.

Finally, you can send a test message here and get a reply with the results of multiple checks, including SPF, that will test your DNS entries for SPF.

---

Configuring Qmail Toaster for processing SPF for my inbound messages

Luckily, the plug-ins are already present in the QMail Toaster. All you need to do is to decide what you want to do with messages that don't pass SPF testing.

The Qmail Toaster configuration consists of one character in this one file:

    /var/qmail/control/spfbehavior

Complete information is available here, but in summary the values are:

• 0: Never do SPF lookups, don't create Received-SPF headers
• 1: Only create Received-SPF headers, never block
• 2: Use temporary errors when you have DNS lookup problems
• 3: Reject mails when SPF resolves to fail (deny)
• 4: Reject mails when SPF resolves to softfail or fail
• 5: Reject mails when SPF resolves to neutral, softfail, or fail
• 6: Reject mails when SPF does not resolve to pass

Currently, the QMail Toaster installation scripts default your setting to 3 -- which is probably best.

Values bigger than 3 are strongly discouraged, you probably want to go with 2 or 3.

Important: This setting can be overridden using the environment variable SPFBEHAVIOR, e.g. from tcpserver rules.

Finally: If the environment variable RELAYCLIENT is set, SPF checks won't run at all. (This also includes SMTP-AUTH and similar patches)

---

So how does it all work together?

Say I get mail from jake@qmt.com (a FAKE e-mail address, to be sure!):

• I do a DNS TXT lookup for the domain -- effectively, a "dig txt qmt.com", or a more up-to-date, "dig spf qmt.com"
• I look up the SPF records there (and see "v=spf1 a mx -all")
• I look up the A record & MX record(s) of the domain (dig a qmt.com & dig mx qmt.com)
• I compare the IP address SENDING the message against the IP addresses discovered above
• If there is a match, you PASS SPF checking
• If there is NO match, you FAIL SPF checking & I block you (the -all)

Some Final Notes:

SPF is NOT Sender ID

The latter is a Microsoft "alternative" to SPF, which in typical Microsoft fashion, can break the former. Furthermore, again in typical Microsoft form, they have no intention of fixing "their" format. (NOTE: Sender ID is not better than, and does not come from SPF. The implementations on the receiver side are significantly different. The fact that Sender ID's "identifier" is "spf2.0" is a misnomer, and some would claim it is an attempt by Microsoft to convince users that Sender ID is SPF version 2.0 -- it is not.) Click here for a more in-depth discussion of SPF vs. Sender ID.

Yahoo and some other large ISPs are requiring domain key verification. This is also installed in the QMail Toaster, but is not configured by default (currently). DomainKeys are discussed here.