Code Locket Menu

A Warning About SPF

Blog post created on 2014-12-14

Sys AdminEmail

SPF, or Sender Policy Framework is a system designed and intended to reduce email spoofing and by consequence phishing. Conceptually the system is simple to understand. A domain owner publishes, using the Domain Name System (DNS), an SPF record that can be used by a third party to verify, to a certain extent, the legitimacy of incoming emails. The SPF record, in its most basic form, allows to specify what IP ranges/networks are allowed to send emails for a given domain. Let's work by example:

This is excellent, and if someone has SPF configured, it would drastically reduce the potential of phishing by disallowing everyone to send emails portraying to be them, or does it? Until recently, and mislead by many articles like this one that can be easily found on the web, I thought it did. To some extent this is true, but not in the way I understood it.

Two From Addresses

Just like normal post, emails have two From addresses: The envelope address and the message header address, both highlighted below in a sample SMTP dialogue.

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<spf-configured@example.org>
S: 250 Ok
C: RCPT TO:<end-user@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Not Me" <not-me@bank.com>
C: To: "End User" <end-user@example.com>
C: Date: Tue, 14 December 2014 19:00:00 +0100
C: Subject: Password Reset
C:
C: Hello End User,
C: This is not an official email from bank.com but it is SPF valid.
C: Since you cannot see the envelope header you are not aware of this.
C: Therefore please reset your password using the attachment provided.
C: Not Me,
C: bank.com
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

The first, is used at SMTP level for routing purposes and usually is not seen by the receiving party. The second, that is an integral part of the email content, is what is displayed, on most email clients, to the end user.

This is where the problem lies: SPF, in its basic form, checks only the envelope address and not the message header address. When I set up SPF I thought it checked both or at the very least, the latter. By consequence, assuming I have SPF configured correctly for my domain (example.org in the listing above), I can still send a valid SPF email even if I spoof the message header address to be anything I like, e.g. michael@bank.com. Scammers hence only need access to an email server that has SPF configured for a random domain to send SPF valid emails. If they cannot find one, they could easily set one up. Due to this we could argue that, although SPF is improving security and must be configured, this subtle point is actually giving a false sense of security to some system administrators which, like me, did not pay close attention to the SPF implementation details. I am not sure why this is the default behaviour but the answer can probably be found looking into the relevant mailing list archives.

The Wikipedia page of SPF does actually warn about the difference but it is not very prominent: While the address in the Return-Path often matches other originator addresses in the mail header such as From or Sender, this is not necessarily the case, and SPF does not prevent forgery of these other addresses.

I hope this might help others and if you get as far as configuring SPF then you should really also configure DKIM. This prevents email spoofing more generally, although it is more difficult to configure. If I have made any mistakes please let me know on the comments below.