Preventing Spam E-mail with SPF Records

Anyone who has managed e-mail for a domain knows the horror of seeing spam messages apparently originating from the domain under your control.

For example, you manage e-mail for example.com, and suddenly start seeing spam e-mail purportedly originating from [email protected] in your actual [email protected] inbox.

What happened? Has my account been compromised? Have I lost my mind?

It turns out that it isn’t terribly difficult to spoof e-mail addresses. Actually, it’s very easy.

So, how can you prevent spammers from sending spoofed e-mail seeming to originate from your domain name?

There are several methods available, one of the most elementary of which is SPF .

Envelope Address vs. Header Address

First, it is important to note that an e-mail has two ‘sender’ addresses. There is the envelope sender address and the header sender address. The envelope sender address is used to actually route e-mail between mail servers, and properly route return messages. The header sender address is used by e-mail clients to display who the e-mail originated from.

For an analogy, we can look to the standard mail or post system. The envelope sender address would be equivalent to the return address on the envelope of a letter. The header sender address would be equivalent to the address on the letterhead of the letter contained within the envelope.

Sender Policy Framework

SPF, or Sender Policy Framework, helps prevent spoofing or forgery of a particular envelope sender address by placing restrictions on mail servers that can legitimately use that envelope sender address. Generally, this is on a domain level. If the domain in the envelope sender address is valid, then the envelop sender address itself is considered valid.

If a mail server isn’t authorized to use a particular envelope sender address, but does so anyway, messages from that source have a high likelihood of being illegitimate. Conversely, if a mail server is authorized to use a particular envelop sender address, e-mail originating from that source can be trusted with a much higher degree of certainty.

SPF makes no guarantee of the header sender address within e-mail that it handles – it only ensures that the e-mail originated from a mail server for that particular domain.

SPF operates via a two-fold mechanism: SPF records which specify a policy for a domain, and mail servers which verify that an e-mail conforms to the SPF policy for that domain.

SPF records, which define the policy, are published as DNS TXT records. Mail servers can then query the public SPF record for a particular domain to determine if an e-mail conforms to the policy. The logic is that only the domain owner would be able to publish associated DNS records, meaning that any e-mail conforming to the policy of a certain domain should contain a valid envelope sender address as defined by the owners of the domain.

SPF Records

The syntax of the actual SPF record is rather specific. Generally, the SPF record uses a set of parameters to reference which servers are trusted (or not trusted) to send e-mail for the domain. The references can include other DNS records, other SPF records, or specific IP addresses. Simply listing the parameter, or using a ”+” indicates that the source is trusted. Using a ”-” indicates that the source is not trusted, and that mail from that source should be rejected.

For example, a SPF record of….

v=spf1 a mx ip4:10.132.0.10/24 include:_spf.google.com -all

…specifies that valid e-mail origin servers for the domain are:

• Named in the domain’s A records (“a”); or
• Named in the domain’s MX records (“mx”); or
• Have an IP address of 10.132.0.10 (“ip4:10.132.0.10/24”); or
• Are specified in the SPF record found at _spf.google.com (“include:_spf.google.com”)

It also specifies that all other servers do not conform to the policy (“-all”).

Validating SPF Records

Many services, including Google Mail, support SPF validation. Mail servers for these services will check the SPF policy defined for the domain specified in the envelope sender address of e-mail. Depending on the results of the SPF validation, mail servers decide how to deliver e-mail. For example, the service may decide to deliver the e-mail, reject the e-mail, or deliver the e-mail but mark it as spam.

The results of the SPF validation can be influenced by the SPF record. For example, using ”~” instead of ”-” such as in ”~all” vs. “-all” can indicate that the source is a ‘soft fail’. This means that the mail server should be treated as neutral, and not explicitly trusted or distrusted.

E-mail that has been SPF validated usually contains the validation information in the mail headers.

Pass:

Received-SPF: pass (google.com: domain of [email protected] designates
10.132.0.10 as permitted sender) client-ip=10.132.0.10;

Neutral:

Received-SPF: neutral (google.com: 10.132.0.10 is neither permitted nor denied
by best guess record for domain of [email protected]) client-ip=10.132.0.10;

Fail:

Received-SPF: fail (google.com: domain of [email protected] does not designate
 10.132.0.10 as permitted sender) client-ip=10.132.0.10;

Summary

Sender Policy Framework is one of the many methods available to help reduce the incidence of spoofed e-mails from your site. It operates by identifying mail servers which are trusted or authorized to originate e-mails for a particular domain. While it relies upon the delivering mail server to make the final judgement call and action, it can effectively reduce incidence of envelope header address forgery within services which support it (such as Google Mail).