Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.
The original base of Internet email, Simple Mail Transfer Protocol (SMTP), has no such feature, so forged sender addresses in emails (a practice known as email spoofing) have been widely used in phishing, email spam, and various types of frauds. To combat this, many competing email authentication proposals have been developed, but only fairly recently have three been widely adopted – SPF, DKIM and DMARC. The results of such validation can be used in automated email filtering, or can assist recipients when selecting an appropriate action.
This article does not cover user authentication of email submission and retrieval.
Rationale
In the early 1980s, when Simple Mail Transfer Protocol (SMTP) was designed, it provided for no real verification of sending user or system. This was not a problem while email systems were run by trusted corporations and universities, but since the commercialization of the Internet in the early 1990s, spam, phishing, and other crimes have been found to increasingly involve email.
Email authentication is a necessary first step towards identifying the origin of messages, and thereby making policies and laws more enforceable.
Hinging on domain ownership is a stance that emerged in the early 2000. It implies a coarse-grained authentication, given that domains appear on the right part of email addresses, after the at sign. Fine-grain authentication, at user level, can be achieved by other means, such as Pretty Good Privacy and S/MIME. At present, digital identity needs to be managed by each individual.
An outstanding rationale for email authentication is the ability to automate email filtering at receiving servers. That way, spoofed messages can be rejected before they arrive to a user's Inbox. While protocols strive to devise ways to reliably block distrusted mail, security indicators can tag unauthenticated messages that still reach the Inbox. A 2018 study shows that security indicators can lower the click-through ratio by more than ten points, 48.9% to 37.2% of the users who open spoofed messages.
Nature of the problem
SMTP defines message transport, not the message content. Thus, it defines the mail envelope and its parameters, such as the envelope sender, but not the header (except trace information) nor the body of the message itself. STD 10 and define SMTP (the envelope), while STD 11 and define the message (header and body), formally referred to as the Internet Message Format.
SMTP defines the trace information of a message, which is saved in the header using the following two fields: Received: when an SMTP server accepts a message it inserts this trace record at the top of the header (last to first). Return-Path: when the delivery SMTP server makes the final delivery of a message, it inserts this field at the top of the header.
A mail user agent (MUA) knows the outgoing mail SMTP server from its configuration. An MTA (or a relay server) typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name.
The path depicted below can be reconstructed on the ground of the trace header fields that each host adds to the top of the header when it receives the message: