How secure is sending mail via SMTP?
How secure is sending mail via SMTP?
In short: Sending mails via SMTP is not secure at all. But don't worry, it can be improved.
The Simple Mail Transfer Protocol (SMTP) is one of the most frequently used network protocols in the Internet and is crucial for sending emails between individual mail servers, such as Gmail, GMX or T-Online. The protocol was standardized in 1981 in RFC 788 and is therefore one of the oldest network protocols. However, it was never designed with the intention of ensuring secure mail delivery. Up until today, it has been regarded purely as a transport protocol for emails.
Until the 1990s, it was common practice on the Internet for mail servers to act as so-called “Open Relays”. Any user was able to send emails with any sender and recipient addresses via these mail servers using the Simple Message Transfer Protocol (SMTP). This was increasingly abused by spammers who used these servers to distribute emails with forged sender addresses. Nowadays, one of the most critical misconfigurations is when a mail server allows unrestricted forwarding of emails without checking the sender’s address or requiring prior authentication. The SMTP protocol itself offers no direct protection against this. The sender’s address must therefore be checked by the mail server itself before an email is forwarded to the recipient’s mail server. It is advisable to configure the mail server in such a way that an email is only forwarded after the respective user of the sending mailbox has been authenticated within the SMTP session and the sender address has been checked to ensure that it matches the respective mailbox. Authentication was first introduced as an extension to the SMTP protocol in 1999 with RFC 2554.
In difference to HTTPS, SMTP does not use explicit encryption via SSL/TLS. The communication channel between two mail servers will always be established unencrypted. Initially, there was no standardized way to send emails via an encrypted channel. In 1999, RFC 2487 introduced an extension to the SMTP protocol known as STARTTLS, which enables encryption. This made it possible to encrypt the initially unencrypted communication channel via SSL/TLS.
However, there are still two fundamental problems with STARTTLS for SMTP. Firstly, the use of STARTTLS is still optional today. According to the standard, it is not necessary to secure the connection cryptographically before the mail is transmitted. Secondly, the authenticity of the remote peer’s certificate is not checked during TLS negotiation. It is therefore not necessary for the TLS certificate used by the mail server to have been issued by a publicly recognized certification authority (CA), and the domain name specified in the certificate does not have to match the email domain of the sending mail server.
To address the problems mentioned above, numerous mechanisms have been introduced over the years to make mail transmission more secure, regardless of the SMTP protocol. The most important of these include:
SPF, DKIM and DMARC are compatible with each other and can be used to protect the own mail domain against misuse. In concrete terms, this prevents third parties from sending emails in the name of the own domain.
Using SPF, it can be specified which IP addresses are authorized to send emails on behalf of a domain (e.g. example.com). This is implemented by means of a DNS entry for the own domain, in which the authorized IP addresses are published. The receiving mail server queries the DNS entry of the sending mail domain and checks whether the IP address of the sending mail server is included. It is also possible to define within the DNS entry how the receiving mail server should behave in case of a non-matching IP address. For example, it can be specified that the email is rejected or marked as spam in the recipient’s mailbox. A typical DNS entry for SPF looks like this:
With the help of DKIM, it is possible to digitally sign an outgoing email from the sending mail server. The signature includes in particular the email address information (sender and recipient address) and is created with the private key of the sending mail server and attached to the email. The corresponding public key is published via a DNS entry of the sender domain and is retrieved by the receiving mail server in order to verify the signature and thus the integrity of the received email. An example DNS entry for publishing the public key is shown below:
Based on the SPF and DKIM mechanisms, DMARC was introduced to further restrict the misuse of the recipient’s own mail domain. The DMARC policy defines how the recipient mail system should authenticate emails and how to proceed in case of a violation. The policy is published via a DNS entry of the sender domain and is retrieved by the receiving mail server. The authentication check is performed using SPF and DKIM. For a successful check of a received email according to DMARC, either the SPF or DKIM check must be successful, and the sender domain must match the domain in the sender’s email address. In addition, the policy can specify which measures should be taken if the check fails. For example, the email can either be discarded or quarantined. A typical DNS entry for DMARC looks like this:
:
As part of the so-called rua tag of the policy, it is possible to specify an email address via which the results of the DMARC checks of the own domain are to be sent. This procedure is an effective instrument for identifying misuse of the own mail domain. The DMARC reports, which are usually aggregated, contain a list of all mail servers, including the IP addresses, which have sent emails in the name of the mail domain in question to the respective recipient domain in the past period. The results of the SPF and/or DKIM checks are also included. The evaluation of this information enables the identification of mail servers used by spammers and the reporting of the corresponding IP addresses to public spam lists or IP blacklists. These lists are usually used by major email providers such as Gmail or Microsoft to directly block SMTP connections from such IP addresses.
Although DMARC, SPF and DKIM are not mandatory for sending emails, they are widely used nowadays. It helps to enhance the reputation of the own mail domain and reduces the risk of the own emails being classified as spam by other mail servers if the previously mentioned mechanisms are not implemented for the own mail domain.
In addition, it is recommended that the own mail server supports the SMTP extension STARTTLS and thus encrypted mail transmission and that a trustworthy certificate issued by a publicly recognized CA for the own mail domain is used during SSL/TLS negotiation. This helps to enhance the reputation of its own mail system. Although it is possible to force STARTTLS and certificate validation on some mail servers (e.g., Postfix), this would violate the corresponding RFC. This could result in emails from or to particularly old mail servers not being delivered. To minimize the risk of sending emails unencrypted on the Internet, the use of MTA-STS can be helpful.
In the context of administering a mail infrastructure, it is possible to use MTA-STS to transmit information to the sending mail server via a DNS entry that the own mail server supports transport encryption using STARTTLS and that a certificate check can be performed.
It should be mentioned that end users generally have no possibility to influence the configuration of mail servers. This applies to both sending and receiving emails. It is also generally not possible for end users to check the proper implementation of the above-mentioned measures. However, end users have the alternative of using end-to-end encryption via S/MIME or PGP.
Should you wish to put your infrastructure to the test, our experts from the Offensive Security division will be happy to advise you.
The Simple Mail Transfer Protocol (SMTP) is one of the most frequently used network protocols in the Internet and is crucial for sending emails between individual mail servers, such as Gmail, GMX or T-Online. The protocol was standardized in 1981 in RFC 788 and is therefore one of the oldest network protocols. However, it was never designed with the intention of ensuring secure mail delivery. Up until today, it has been regarded purely as a transport protocol for emails.
Until the 1990s, it was common practice on the Internet for mail servers to act as so-called “Open Relays”. Any user was able to send emails with any sender and recipient addresses via these mail servers using the Simple Message Transfer Protocol (SMTP). This was increasingly abused by spammers who used these servers to distribute emails with forged sender addresses. Nowadays, one of the most critical misconfigurations is when a mail server allows unrestricted forwarding of emails without checking the sender’s address or requiring prior authentication. The SMTP protocol itself offers no direct protection against this. The sender’s address must therefore be checked by the mail server itself before an email is forwarded to the recipient’s mail server. It is advisable to configure the mail server in such a way that an email is only forwarded after the respective user of the sending mailbox has been authenticated within the SMTP session and the sender address has been checked to ensure that it matches the respective mailbox. Authentication was first introduced as an extension to the SMTP protocol in 1999 with RFC 2554.
In difference to HTTPS, SMTP does not use explicit encryption via SSL/TLS. The communication channel between two mail servers will always be established unencrypted. Initially, there was no standardized way to send emails via an encrypted channel. In 1999, RFC 2487 introduced an extension to the SMTP protocol known as STARTTLS, which enables encryption. This made it possible to encrypt the initially unencrypted communication channel via SSL/TLS.
However, there are still two fundamental problems with STARTTLS for SMTP. Firstly, the use of STARTTLS is still optional today. According to the standard, it is not necessary to secure the connection cryptographically before the mail is transmitted. Secondly, the authenticity of the remote peer’s certificate is not checked during TLS negotiation. It is therefore not necessary for the TLS certificate used by the mail server to have been issued by a publicly recognized certification authority (CA), and the domain name specified in the certificate does not have to match the email domain of the sending mail server.
To address the problems mentioned above, numerous mechanisms have been introduced over the years to make mail transmission more secure, regardless of the SMTP protocol. The most important of these include:
- SPF (Sender Policy Framework),
- DKIM (DomainKeys Identified Mail),
- DMARC (Domain-based Message Authentication, Reporting & Conformance),
- MTA-STS (Mail Transfer Agent-Strict Transport Security)
SPF, DKIM and DMARC are compatible with each other and can be used to protect the own mail domain against misuse. In concrete terms, this prevents third parties from sending emails in the name of the own domain.
Using SPF, it can be specified which IP addresses are authorized to send emails on behalf of a domain (e.g. example.com). This is implemented by means of a DNS entry for the own domain, in which the authorized IP addresses are published. The receiving mail server queries the DNS entry of the sending mail domain and checks whether the IP address of the sending mail server is included. It is also possible to define within the DNS entry how the receiving mail server should behave in case of a non-matching IP address. For example, it can be specified that the email is rejected or marked as spam in the recipient’s mailbox. A typical DNS entry for SPF looks like this:
With the help of DKIM, it is possible to digitally sign an outgoing email from the sending mail server. The signature includes in particular the email address information (sender and recipient address) and is created with the private key of the sending mail server and attached to the email. The corresponding public key is published via a DNS entry of the sender domain and is retrieved by the receiving mail server in order to verify the signature and thus the integrity of the received email. An example DNS entry for publishing the public key is shown below:Based on the SPF and DKIM mechanisms, DMARC was introduced to further restrict the misuse of the recipient’s own mail domain. The DMARC policy defines how the recipient mail system should authenticate emails and how to proceed in case of a violation. The policy is published via a DNS entry of the sender domain and is retrieved by the receiving mail server. The authentication check is performed using SPF and DKIM. For a successful check of a received email according to DMARC, either the SPF or DKIM check must be successful, and the sender domain must match the domain in the sender’s email address. In addition, the policy can specify which measures should be taken if the check fails. For example, the email can either be discarded or quarantined. A typical DNS entry for DMARC looks like this::
As part of the so-called rua tag of the policy, it is possible to specify an email address via which the results of the DMARC checks of the own domain are to be sent. This procedure is an effective instrument for identifying misuse of the own mail domain. The DMARC reports, which are usually aggregated, contain a list of all mail servers, including the IP addresses, which have sent emails in the name of the mail domain in question to the respective recipient domain in the past period. The results of the SPF and/or DKIM checks are also included. The evaluation of this information enables the identification of mail servers used by spammers and the reporting of the corresponding IP addresses to public spam lists or IP blacklists. These lists are usually used by major email providers such as Gmail or Microsoft to directly block SMTP connections from such IP addresses.Although DMARC, SPF and DKIM are not mandatory for sending emails, they are widely used nowadays. It helps to enhance the reputation of the own mail domain and reduces the risk of the own emails being classified as spam by other mail servers if the previously mentioned mechanisms are not implemented for the own mail domain.
In addition, it is recommended that the own mail server supports the SMTP extension STARTTLS and thus encrypted mail transmission and that a trustworthy certificate issued by a publicly recognized CA for the own mail domain is used during SSL/TLS negotiation. This helps to enhance the reputation of its own mail system. Although it is possible to force STARTTLS and certificate validation on some mail servers (e.g., Postfix), this would violate the corresponding RFC. This could result in emails from or to particularly old mail servers not being delivered. To minimize the risk of sending emails unencrypted on the Internet, the use of MTA-STS can be helpful.
In the context of administering a mail infrastructure, it is possible to use MTA-STS to transmit information to the sending mail server via a DNS entry that the own mail server supports transport encryption using STARTTLS and that a certificate check can be performed.
It should be mentioned that end users generally have no possibility to influence the configuration of mail servers. This applies to both sending and receiving emails. It is also generally not possible for end users to check the proper implementation of the above-mentioned measures. However, end users have the alternative of using end-to-end encryption via S/MIME or PGP.
Should you wish to put your infrastructure to the test, our experts from the Offensive Security division will be happy to advise you.