Email Message Structure

To understand how SPF (Sender Policy Framework) and DKIM works is to know the difference between email envelope and email header.

In short: Like paper mail letters, e-mail messages have at least two kinds of sender addresses: one on the envelope and one in the letterhead.

The envelope sender address (sometimes also called the return-path) is used during the transport of the message from mail server to mail server, e.g. to return the message to the sender in the case of a delivery failure. It is usually not displayed to the user by mail programs.

In the email envelope, first there is the HELO identity, which names the mail server (MTA) that is sending the message. The MAIL FROM identity is the e-mail address that is responsible for sending the message and where delivery errors (bounces) will eventually be reported. And the RCPT TO identity is the message's recipient address. The envelope identities are used during the transport of the message and are, in general, discarded upon delivery (however the MAIL FROM is usually retained in the message header as Return-Path and can be displayed in mail clients by selecting the "Show all headers" option). The typical symptom of forged envelope sender identities are misdirected bounces.

The header sender address of an e-mail message is contained in the From or Sender header and is what is displayed to the user by mail programs. Generally, mail servers do not care about the header sender address when delivering a message.

email message structure

More precisely: The email header contains another set of identities (besides other meta information about the message, such as the subject and the sending date). The From identity denotes the address of the message's author. The Sender identity is listed explicitly only if the author is not the actual sender of the message. The To identity is again the recipient address. (Other, less important identities may occur in the header, see RFC 2822.) The header identities are irrelevant for message delivery and are solely meant for the use by the message's recipient – but they are what is displayed by mail clients. When the header sender address is forged, the recipient's mail client will display a misleading sender address and the recipient will thus be deceived about the message's real origin.

The Problem: Sender Address Forgery

Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages.

You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.

Email sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.

What is SPF (Sender Policy Framework)

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent email sender address forgery.

More precisely, the current version of SPF — called SPFv1 protects the envelope sender address, which is used for the delivery of messages.

Even more precisely: SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:

1. the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then

2. the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.

how SPF work

SPF in details

SPF authenticates the envelope HELO and MAIL FROM identities by comparing the sending mail server's IP address to the list of authorized sending IP addresses published by the sender domain's owner in a "v=spf1" DNS record. SPF has succeeded several older envelope sender authentication protocols. Currently SPF is the only widely deployed envelope authentication protocol.

Envelope sender authentication protocols like SPF are typically used early during the SMTP transaction, before the bulk of the message (its header and body) is transmitted. All of the following protocols require that an entire message be received before it can be rejected, due to the rules of the SMTP protocol. As a result, SPF continues to be an essential front-line defense against sender address forgery when deploying protection for the header fields and body. By rejecting envelope forgeries early, not only network traffic can be saved but also computing power for further protection measures, thus making the entire process more efficient.

Helo/Ehelo Identity

The HELO identity derives from either the SMTP HELO or EHLO command (see RFC 2821). These commands supply the SMTP client (sending host) for the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the HELO/EHLO identity to be malformed or an IP address literal. At the time of this writing, many legitimate E-Mails are delivered with invalid HELO/EHLO domains.

MAIL FROM Identity

The MAIL FROM identity derives from the SMTP MAIL command (see RFC 2821). This command supplies the reverse-path for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message.

RFC 2821 allows the reverse-path to be null. In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the MAIL FROM identity to be the mailbox composed of the localpart postmaster and the HELO identity (which may or may not have been checked separately before).

An Example SPF Policy

Let's look at an example to give you an idea of how SPF works. Bob owns the domain example.net. He also sometimes sends mail through his Gmail account and contacted GMail's support to identify the correct SPF record for GMail. Since he often receives bounces about messages he didn't send, he decides to publish an SPF record in order to reduce the abuse of his domain in e-mail envelopes:

example.net.  TXT  "v=spf1 mx a:pluto.example.net include:_spf.google.com -all"

The parts of the SPF record mean the following:

SPF vs DKIM

Sources

• http://www.openspf.org/Introduction
• http://www.openspf.org/Related_Solutions
• http://www.openspf.org/RFC_4408