SPF Records - Powered by Kayako SupportSuite Help Desk Software

09 Sep 2010

Support Center » Knowledgebase » SPF Records

	SPF Records

Article What does SPF stand for?
Sender Policy Framework

What is SPF used for?

Primarily it is used to stop "spoofing" of e-mail addresses. SPF allows the owner of an Internet domain to use special format of DNS TXT records to specify which machines are authorized to transmit e-mail for that domain. For example, the owner of the example.org domain can designate which machines are authorized to send e-mail whose e-mail address in the Return-Path ends with "@example.org". Receivers checking SPF can then reject any e-mail that claims to come from that domain, but fails in a check against the IPs listed in the sender policy of this domain.

SPF protects the address in the Return-Path, that is the address to which bounces would be sent if the mail is not delivered. While the address in the Return-Path often matches other originator addresses in the mail header like "From:" or "Sender:" this is not necessarily the case, and SPF does not prevent forgeries of these other addresses.

But how does it work?

SPF protects the address in the Return-Path, that is the address to which bounces would be sent if the mail is not delivered. While the address in the Return-Path often matches other originator addresses in the mail header like "From:" or "Sender:" this is not necessarily the case, and SPF does not prevent forgeries of these other addresses.

Spammers can send e-mail with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain. However, doing so makes the spam easier to trace and prosecute. An SPF PASS result from unknown strangers still guarantees that auto-replies like error messages (bounces) cannot hit innocent bystanders.

What is the benefit of using SPF?

The main benefit of SPF is to people whose e-mail addresses are forged in the Return-Paths. They receive a large mass of unsolicited error messages and other auto-replies, making it difficult to use e-mail normally. If such people use SPF to specify their legitimate sending IPs with a FAIL result for all other IPs, then receivers checking SPF can reject forgeries, already reducing the amount of back-scatter. More important spammers knowing their trade will avoid forging SPF FAIL protected addresses, because they want to reach as many of their primary victims as possible - there are more than enough unprotected addresses for this abuse.

SPF has potential advantages beyond helping identify unwanted e-mail. In particular, if a sender provides SPF information, then receivers can use SPF PASS results in combination with a white list to identify known reliable senders. Scenarios like compromised systems and shared sending mailers limit this use, but at least auto-replies cannot hit innocent bystanders.

How do I implement SPF?

Implementing SPF has two parts:

* Domains identify the machines authorized to send e-mail on their behalf. Domains do this by adding an additional record to their existing DNS information.
* Receivers can request and use SPF information. They use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.

Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records are laid out like this (in typical DNS-syntax):

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

"v=" defines the version of SPF used. The following words provide mechanisms to use to determine if a domain is eligible to send mail. The "a" and "mx" specify the systems permitted to send messages for the given domain. The "-all" at the end specifies that, if the previous mechanisms did not match, the message should be rejected.

Qualifiers

Each mechanism can be combined with one of four qualifiers:

* + for a PASS result, this can be omitted, +mx is the same as mx.
* ? for a NEUTRAL result interpreted like NONE (no policy).
* ~ for SOFTFAIL, a debugging aid between NEUTRAL and FAIL.
* - for FAIL, the mail should be rejected (see below).

[edit] Modifiers

The modifiers allow for future extensions of the framework. So far only the two modifiers defined in the RFC 4408 are widely deployed.

exp=some.example.com gives the name of a domain with a DNS TXT record, which is interpreted using SPF's macro language to get an explanation for FAIL results, typically an URL, added to the SMTP error code. This baroque feature is rarely used.

redirect=some.example.com can be used instead of the ALL-mechanism to link to the policy record of another domain. This modifier is easier to understand than the somewhat similar INCLUDE-mechanism.

Article Details

Article ID:

252

Created On:

17 Nov 2008 2:28 PM