Email authentication
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 fraud. 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 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 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: A mail user agent (MUA) knows the "outgoing mail" SMTP server from its configuration. A 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: Return-Path: <author@example.com> Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from B.example.com (b.example.com [192.0.2.1]) Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100 Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 2013 17:44:42 +0100 It is important to realize that the first few lines at the top of the header are usually  trusted by the recipient. In fact, those lines are written by machines in the recipient's Administrative Management Domain (ADMD), which act upon her or his explicit mandate. By contrast, the lines that prove the involvement of A and B, as well as of the purported author's MUA could be a counterfeit created by C. The codice_1 field shown above is an epoch-making piece of the header. The codice_2 is written by E, the mail delivery agent (MDA), based on the message "envelope". Additional trace fields, designed for email authentication, can populate the top of the header. Normally , messages sent out by an author's ADMD go directly to the destination's MX (that is B → D in the figures). The sender's ADMD can add authentication tokens only if the message goes through its boxes. The most common cases can be schematized as follows: Authentication methods in widespread use. SPF. SPF allows the receiver to check that an email claimed to have come from a specific domain comes from an IP address authorized by that domain's administrators. Usually, a domain administrator will authorize the IP addresses used by their own outbound MTAs, including any proxy  or smarthost. The IP address of the sending MTA is guaranteed to be valid by the Transmission Control Protocol, as it establishes the connection by checking that the remote host is reachable. The receiving mail server receives the codice_3 SMTP command soon after the connection is set up, and a codice_4 at the beginning of each message. Both of them can contain a domain name. The SPF verifier queries the Domain Name System (DNS) for a matching SPF record, which if it exists will specify the IP addresses authorized by that domain's administrator. The result can be "pass", "fail , or some intermediate result - and systems will generally take this into account in their anti-spam filtering. DKIM. DKIM checks the message content", deploying digital signatures. Rather than using digital certificates, the keys for signature-verification are distributed via the DNS. That way, a message gets associated to a domain name. A DKIM-compliant domain administrator generates one or more pairs of asymmetric keys, then hands private keys to the signing MTA, and publishes public keys on the DNS. The DNS labels are structured as codice_5, where "selector" identifies the key pair, and codice_6 is a fixed keyword, followed by  the signing domain's name so that publication occurs under the authority of that domain's ADMD. Just before injecting a message into the SMTP transport system, the signing MTA creates a digital signature that covers selected fields of the header and the body (or just its beginning). The signature should cover substantive header fields such as codice_7, codice_8, codice_9, and codice_10, and then is added to the message header itself, as a trace field. Any number of relays can receive and forward the message and at every hop, the signature can be verified by retrieving the public key from  the DNS. As long as intermediate relays don't modify signed parts of a message, its DKIM-signatures remain valid. DMARC. DMARC allows the specification of a policy for authenticated messages. It is built on top of two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the codice_7 field presented to end users; how the receiver should deal with failures - and a  reporting mechanism for actions performed under those policies. Other methods. A range of other methods have been proposed, but are now either deprecated or have not yet gained widespread support. These have included Sender ID, Certified Server Validation, DomainKeys and those below: ADSP. ADSP allowed the specification of a policy for messages signed by the author's domain. A message had to go through DKIM authentication first, then ADSP could demand a punishing treatment if the message was not signed by the author domain(s) —as per the codice_7 header field. ADSP was demoted to historic in November 2013. VBR. VBR  adds a vouch to an already authenticated identity. This method requires some globally recognized authorities that certify the reputation of domains. A sender can apply for a reference at a vouching authority. The reference, if accepted, is published on the DNS branch managed by that authority. A vouched sender should add a codice_13 header field to the messages it sends. It should also add a DKIM signature, or use some other authentication method, such as SPF. A receiver, after validating the sender's identity, can verify the vouch claimed in codice_13 by looking up the reference. iprev. Applications should avoid  using this method as a means of authentication. Nevertheless, it is often carried out and its results, if any, written in the codice_1 header field besides the TCP information required by the SMTP specification. The IP reverse, confirmed by looking up the IP address of the name just found, is just an indication that the IP was set up properly in the DNS. The reverse resolution of a range of IP addresses can be delegated to the ADMD that uses them, or can remain managed by the network provider. In the latter case, no useful identity related to the message  can be obtained. DNSWL. Looking up a DNSWL (DNS-based whitelist) may provide an assessment of the sender, possibly including its identification. Authentication-Results. RFC 8601 defines a trace header field codice_16 where a receiver can record the results of email authentication checks that it carried out. Multiple results for multiple "methods" can be reported in the same field, separated by semicolons and wrapped as appropriate. For example, the following field is purportedly written by codice_17 and reports SPF and DKIM results: Authentication-Results: receiver.example.org; The first token after the field name, codice_17, is the ID of the authentication server , a token known as an "authserv-id". A receiver supporting RFC 8601 is responsible to remove (or rename) any false header claiming to belong to its domain so that downstream filters cannot get confused. However, those filters still need to be configured, as they have to know which identities the domain may use. For a Mail User Agent (MUA), it is slightly harder to learn what identities it can trust. Since users can receive email from multiple domains—e.g., if they have multiple email addresses -— any of those domains could let codice_16 fields pass through because they looked neutral . That way, a malicious sender can forge an "authserv-id" that the user would trust if the message arrived from a different domain. A legitimate codice_16 typically appears just above a codice_1 field by the same domain from which the message was relayed. Additional codice_1 fields may appear between that and the top of the header, as the message got transferred internally between servers belonging to that same, trusted ADMD. The Internet Assigned Numbers Authority maintains a registry of Email Authentication Parameters. Not all parameters need to be registered, though. For example, there can be local "policy" values designed for  a site's internal use only, which correspond to local configuration and need no registration.