Email authentication, or validation, is a collection of techniques aimed at equipping messages of the email transport system with verifiable information about their origin. It is a coarse-grained authentication, usually at Administrative Management Domain (ADMD) level or message transfer agent level, and implies no sort of authorization. That is, the purpose of email authentication is to validate the digital identity of the ADMDs or MTAs who participated in transferring and possibly modifying a message. The results of such validation can then be used in email filtering, and can assist recipients when selecting an appropriate action or reply to an incoming message.
This article does not cover user authentication, although it is ubiquitous in networking, including email submission and retrieval.
This coarse-grain, domain-level authentication relies on ADMDs being able to control their users' behavior, blocking those who engage in spam, phishing, and even more serious crimes. ADMDs identify their users individually —that is, use fine-grain authentication— in order for their mail submission agents to block effectively. An ADMD can still grant a relative level of anonymity to its users, so long as they comply with its policy.
Other fine-grain authentication schemes, such as S/MIME and PGP, are used to implement end-to-end encryption or authentication across ADMDs. Users are expected to work out their own policies and methods by themselves, which is so difficult that usage of those schemes is sparse.
A 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 record (Mail eXchange) DNS resource record for each recipient's domain name
trace header fields that each host adds to the top of the header when it receives the message:
Return-Path: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 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 Received: field shown above is an epoch-making piece of the header. The Return-Path: is written by E, the MDA, based on the message envelope. Additional trace fields, designed for email authentication, can populate the top of the header.
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)by C.example.net (which is me) with ESMTP id 936ADB8838C forReceived: 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 ; Tue, 05 Feb 2013 08:44:50 -0800 (PST)
Normally, messages sent out by an author's ADMD go directly to the destination's MX record (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:
Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.
SPF checks whether the sender's IP address is authorized by one of the identified ADMDs.
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.IP Address forgery is possible, but generally involves a lower level of criminal behavior (breaking and entering, wiretapping, etc.), which are too risky for a typical hacker or spammer, or insecure servers not implementing RFC 1948, see also Transmission Control Protocol#Connection hijacking. The MX receives the HELO SMTP command soon after the connection is set up, and receives a bounce address at the beginning of each message. Both of them can contain a domain name. The SPF verifier queries the Domain Name System (DNS) for an SPF record labelled with that name. An SPF-compliant ADMD should publish that record beforehand, declaring which IP addresses are, or are not, authorized to use the domain name on the label. The verifier then finds the record's directive that matches the IP address of the sending MTA, and returns the associated result. It can be "pass", "fail", or some intermediate result. When the result is "pass", the corresponding domain name is the authenticated identity.
Usually, ADMDs authorize the IP addresses used by their own outbound MTAs, including any proxy or smarthost. That way, messages sent by an ADMD's boxes get authenticated if they flow through the normal path. Otherwise, unless the intermediate relay (sometimes called mediator) takes specific measures, SPF authentication does not succeed. Those specific measures consist of altering the bounce address, which mailing lists routinely do while forwarding services in general do not.
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 ADMD 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 ''selector''._domainkey.example.com, where selector identifies the key pair, and _domainkey 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 From:, To:, Date:, and Subject:, which can be chosen on a per-message basis, and then is added to the message header itself, as a trace field. Any number of relays can receive and forward the message. At any hop, the signature can be verified by retrieving the public key from the DNS. If the signature verifies successfully, the domain name is the authenticated identity.
The purpose of a DKIM-signature is not to assure message integrity. Often, it does not even guarantee that a message author's data, as per a signed From: field, has a real name or a valid mailbox. The parts to be signed are chosen so as to identify the message unequivocally. A valid signature just states that the message did actually flow through a box operated by that ADMD.
As long as intermediate relays don't modify signed parts of a message, its DKIM-signatures remain valid. Any relay who participates in transferring the message can sign it in turn. While intermediate relays usually can add header fields without breaking existing DKIM-signatures, changing character set, adding a tag to the subject, adding a footer, or "fixing" the MIME structure of a message are likely to break them. Many mailing lists do such changes. The protocol cannot guarantee the survivability of signatures after transit, even in the absence of malice, and prescribes no particular action in that case.
The ADSP record for example.com, if any, is published in the DNS under the label _adsp._domainkey.example.com.
ADSP is designed for domains heavily abused by phishing and similar fraud. They may want to forgo mail facilities such as mailing lists and non delivery reports, which can happen to remain unsigned, in exchange for a cut in abuse.
ADSP was demoted to historic in November 2013.
The "R" of DMARC, reporting, consists in supplying feedback to the author domain on how its authentication methods do, thereby providing for informed policy crafting.
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 VBR-Info: 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 VBR-Info: by looking up the reference.
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.
Authentication-Results: receiver.example.org;The first token after the field name, receiver.example.org, is the ID of the authentication server, a token known as an authserv-id. A receiver supporting RFC 7601 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.spf=pass smtp.mailfrom=example.com; dkim=pass email@example.com
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 Authentication-Results: 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 Authentication-Results: typically appears just above a Received: field by the same domain from which the message was relayed. Additional Received: 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. On the other hand, this header field is meant to report results based on data already present in the message. Data retrieved from third parties, such as global reputation systems, are not compliant with RFC 7601. For example, an attempt to register how to add DNSWL results to this field was rejected on that basis.