Email authentication

In the early 1980s, when Simple Mail Transfer Protocol (SMTP) was designed, it provided for no real verification of sending user or system.

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.

Those lines are written by machines in the recipient's Administrative Management Domain (ADMD), which act upon their 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.

[7][8] 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.

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).

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.

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 From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

These have included Sender ID, Certified Server Validation, DomainKeys and those below: ADSP allowed the specification of a policy for messages signed by the author's domain.

The reverse resolution of a range of IP addresses can be delegated to the ADMD that uses them,[17] or can remain managed by the network provider.

RFC 8601 defines a trace header field Authentication-Results: where a receiver can record the results of email authentication checks that it carried out.

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.

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.