eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Editor’s Note: In Part 1 of her three-part series on e-mail authentication, Knowledge Center contributor Ellen Siegel shared a comprehensive, high-level overview of e-mail authentication. Here, in Part 2, Ellen delves into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. In Part 3, Ellen delves into the functionality and technical details of Domain Keys Identified Mail (DKIM).
As discussed in Part 1 of this three-part e-mail authentication series, e-mail authentication is a way of associating a verifiable identity with an e-mail. The industry has settled on two basic approaches to identity verification.
The first approach is path-based, based on the identity of the mail server that delivers the message. The second approach is cryptographic, relying on the fact that the private encryption key used to create a message’s digital signature would exist only on authorized mail servers. In the interest of clarity, this article will ignore some of the less common options and focus on the most common configurations.
In order to create and publish your own authentication records, you as an individual or a company must own and manage your own Domain Name System (DNS) domain. If you cannot add and modify records in your domain’s DNS entry, you will be unable to authenticate your outbound mail, unless you work with a service provider who can publish authentication records on your behalf.
The first step in setting up sender authentication is to do a thorough analysis of every source of mail sent on behalf of someone using your domain(s). That includes your own mail servers, as well as any authorized third parties who send mail with your domain in the From address. Remember that different mail servers may be used for specific functions such as corporate or marketing e-mail.
SPF and Sender ID: What They Are
SPF and Sender ID: What they are
SPF is an open-source protocol designed to prevent forgery by verifying a particular sender identity. Sender ID (Microsoft’s modified version of SPF) uses essentially the same process to validate a different, and usually more visible, domain identity: the Purported Responsible Address (PRA). The protocol used in SPF and Sender ID is an inexpensive solution for senders. The only processing change required for senders is the optional addition of a Sender header.
The Sender ID PRA identity is determined by applying a set of rules. Most commonly, the PRA resolves to either the From address visible in most e-mail clients or to the optional Sender header. The Sender header takes precedence when it is present; it enables the sender to specify an alternative to the From address domain as the location of the authentication credentials.
In contrast, the identity that is validated by SPF is the protocol-level identification of the delivering mail server, and is usually invisible to recipients. It is mirrored in the Return-Path header, the address to which mail delivery errors (or bounces) are sent. For individual e-mail addresses or small domains, it may sometimes be set to the user’s e-mail address. But, for larger and more professionally managed domains, it is usually a domain related to the mail server that sent the message.
SPF and Sender ID: How They Work
SPF and Sender ID: How they work
Both SPF and Sender ID work by requiring that senders publish their comprehensive list of authorized servers in the appropriate DNS domain(s)-for example, mye-maildomain.net. The list is published in a SPF record. Nothing more needs to be done on the sending side, except to make sure that the record remains up-to-date as mail servers are added or retired. No additional processing is required in Step 2 of the authentication flow.
On the receiving side, the verifier determines the domain to be authenticated, and then looks in that domain’s DNS entry for the list of authorized servers. If the list contains the address of the server that delivered the message to the receiver, then the message authentication succeeds. If the list does not contain the delivering server, then the authentication fails. If it finds no record, the result is neutral.
It is important to note that path-based authentication mechanisms such as SPF and Sender ID are very sensitive to breakage caused by forwarding. Although it is possible to deal with this problem by adding special Resent-From headers, very few forwarding mail servers add them. In order to avoid SPF and Sender ID validation failures, many sites choose to terminate their SPF records with “~all” rather than “-all”, which indicates a “soft” failure rather than an absolute violation.
Outbound E-mail
Outbound e-mail
SPF uses a version 1 SPF record and Sender ID uses a version 2 SPF record. Both versions use essentially the same syntax: once you construct one of them, you can generally use the same content for the other once you change the record identifier (SPF version 1 records begin with “v=spf1” and SPF version 2 records begin with “2.0/pra”). If you have access to the relevant DNS entries, it is generally a good idea to publish both version 1 and version 2 records.
The content of the record uses a special syntax to describe the servers you identified in the prerequisite step. They can be listed by IP address, by IP address range if there are several with related addresses, by domain name or by including an existing SPF record from another domain. The syntax complexity of SPF records generally depends on how widely dispersed your authorized mail servers are. Fortunately, there are wizards available to help construct both SPF version 1 records and SPF version 2 records.
One example of a fairly simple SPF version 1 record is shown in the output of the SPF wizard:
Or as an SPF version 2 record for Sender ID:
For domains that do not send any mail, the record can contain an empty list of authorized mail servers to prevent others from spoofing their domain in malicious e-mail:
Determining Where to Publish
Determining where to publish
For SPF, you will need to publish SPF version 1 records in the DNS domain(s) of each unique Return-Path address. For Sender ID, you will need to publish SPF version 2 records in the DNS domain of each unique PRA. Note that if you use a third party to send e-mail, you should ensure that they have valid SPF records for the domain(s) of their mail servers as well.
Inbound mail
If you’re setting up your mail servers to validate authentication for inbound mail, you will want to use a pre-existing open-source or commercial plug-in that works with your existing mail servers.
Here you can see a list of available SPF implementations, including mail servers that support SPF natively, and a list showing industry support for Sender ID. Each of these will have their own implementation specific documentation on how to install and configure the necessary packages.
Testing
To learn how to test your deployment, continue on to Part 3 of this three-part series on e-mail authentication.
Editor’s Note: In Part 1 of her three-part series on e-mail authentication, Knowledge Center contributor Ellen Siegel shared a comprehensive, high-level overview of e-mail authentication. Here, in Part 2, Ellen delved into the functionality and implementation details of Sender Policy Framework (SPF) and Sender ID authentication. In Part 3, Ellen delves into the functionality and technical details of Domain Keys Identified Mail (DKIM).
Ellen is a board member and technical committee co-chair for the E-mail Sender and Provider Coalition (ESPC) and an active member of the Messaging Anti-Abuse Working Group (MAAWG). She can be reached at [email protected].