Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages and validating the identities of the any message MTAs 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, a large number of 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.
- 1 Rationale
- 2 Nature of the problem
- 3 Authentication methods in widespread use
- 4 Other methods
- 5 Authentication-Results
- 6 See also
- 7 References
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.
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 RFC 5321 define SMTP (the envelope), while STD 11 and RFC 5322 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 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 on the left 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: <firstname.lastname@example.org> 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 for <email@example.com>; Tue, 05 Feb 2013 08:44:50 -0800 (PST) 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 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.
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:
Sending from within ADMD's network (MUA 1)
- The ADMD's MSA authenticates the user, either based on its IP address or some other SMTP Authentication means. Depending on the recipient address, the message can follow the normal path or pass through a mailing list or a forwarding service.[note 1] B can be an outbound SMTP proxy or a smarthost.[note 2]
- If the local network does not block outbound port 25 connections,[note 3] the user can deploy some "direct-to-mx" software.[note 4] Typically, zombies and other malicious hosts behave that way.
- If the MUA is badly configured, it can also use a different relay, such as an outmoded open relay, that often doesn't authenticate the user.
Roaming user (MUA 2)
- Most of the times it is still possible to use one's own ADMD MSA.[note 5]
- Outbound connections to port 25 can be intercepted and tunneled to a transparent proxy.[note 4]
- A MUA can be configured to use an SMTP relay that the local network provider offers as a bonus.[note 4]
- An e-card can send mail on behalf of a customer who typed email addresses on the local keyboard; some web forms can be considered to work similarly.[note 4]
Authentication methods in widespread use
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
HELO SMTP command soon after the connection is set up, and a
Mail from: 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 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
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
Subject:, 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.
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.
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 allows the specification of a policy for messages signed by the author's domain. A message has to go through DKIM authentication first, then ADSP can demand a punishing treatment if the message is not signed by the author domain(s) —as per the
From: header field.
The ADSP record for
example.com, if any, is published in the DNS under the label
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.
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
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.
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
Received: 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.
RFC 7601 defines a trace header field
Authentication-Results: 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.
Authentication-Results: receiver.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass firstname.lastname@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.
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.
- For example, a user can instruct Gmail to forward messages to a different email address. The sender is not necessarily aware of that.
- Properly configured proxies appear as part of the author ADMD.
- Some ADMDs block outbound connection to port 25 (SMTP) to avoid this. This proactive technique is described in RFC 5068. In addition, some block inbound SMTP connections from IPs listed as dialup/DSL/cable.
- In this case the author's ADMD is not involved at all.
- Some ISPs block port 587, although RFC 5068 clearly says:
Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.
- Hang Hu; Peng Peng; Gang Wang (2017). "Towards the Adoption of Anti-spoofing Protocols". arXiv:1711.06654 [cs.CR].
- kerner, Sean Michael. "DMARC Email Security Adoption Grows in U.S. Government". eWeek. Retrieved 24 November 2018.
- John Klensin (October 2008). "Trace Information". Simple Mail Transfer Protocol. IETF. sec. 4.4. doi:10.17487/RFC5321. RFC 5321. https://tools.ietf.org/html/rfc5321#section-4.4.
- John Klensin (October 2008). Simple Mail Transfer Protocol. IETF. doi:10.17487/RFC5321. RFC 5321. https://tools.ietf.org/html/rfc5321. Retrieved 1 February 2013. "When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. This trace record indicates the identity of the host that sent the message, the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines."
- Scott Kitterman (April 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. IETF. doi:10.17487/RFC7208. RFC 7208. https://tools.ietf.org/html/rfc7208. Retrieved 26 April 2014. "There are three places that techniques can be used to ameliorate unintended SPF failures with mediators."
- J. Klensin (October 2008). "Alias". Simple Mail Transfer Protocol. IETF. sec. 3.9.1. doi:10.17487/RFC5321. RFC 5321. https://tools.ietf.org/html/rfc5321#section-3.9.1. Retrieved 15 February 2013.
- 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.
- Scott Kitterman (Nov 21, 2009). "How reliable is it to block/reject on SPF fail?". spf-help. gossamer-threads.com.
I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders.
- D. Crocker; T. Hansen; M. Kucherawy, eds. (September 2011). DomainKeys Identified Mail (DKIM) Signatures. IETF. doi:10.17487/RFC6376. RFC 6376. https://tools.ietf.org/html/rfc6376. Retrieved 18 February 2013. "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message, which they are authorized to use."
- Dave Crocker (16 Oct 2007). "DKIM Frequently Asked Questions". DKIM.org. Retrieved 17 February 2013.
- E. Allman; J. Fenton; M. Delany; J. Levine (August 2009). DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). IETF. doi:10.17487/RFC5616. RFC 5616. https://tools.ietf.org/html/rfc5616. Retrieved 18 February 2013.
- Barry Leiba; Mike Thomas; Dave Crocker (2011), "Author Domain Signing Practices (ADSP): Point and Counterpoint", Internet Computing, 15 (1): 76–80, doi:10.1109/MIC.2011.1
- P. Hoffman; J. Levine; A. Hathcock (April 2009). Vouch By Reference. IETF. doi:10.17487/RFC5518. RFC 5518. https://tools.ietf.org/html/rfc5518. Retrieved 18 February 2013.
- Murray Kucherawy (August 2015). Message Header Field for Indicating Message Authentication Status. IETF. doi:10.17487/RFC7601. RFC 7601. https://tools.ietf.org/html/rfc7601. Retrieved 30 September 2015.
- H. Eidnes; G. de Groot; P. Vixie (March 1998). Classless IN-ADDR.ARPA delegation. IETF. doi:10.17487/RFC2317. RFC 2317. https://tools.ietf.org/html/rfc2317. Retrieved 18 February 2013.
- Murray S. Kucherawy (19 April 2016). "draft authmethod dnswl". apps-discuss (Mailing list). IETF. Retrieved 27 April 2016.
The zone itself is not part of the message, so it's not a candidate for a dedicated ptype