Debugging and fixing email errors is a common task we perform in our Outsourced Web Hosting Support services provided to shared server owners.
Among the common mail server errors, ‘403 4.7.0 TLS handshake failed’ error happens when a sender tries to send mail to a recipient using secure TLS protocol.
The error message that will be displayed to the sender is:
----- The following addresses had permanent fatal errors -----
What is ‘403 4.7.0 TLS handshake failed’ error?
The error happens in mail servers that try to use TLS protocol for email transmission. TLS protocol is used for encrypting the data that is transmitted during email communication.
The sender and recipient mail servers have a set of public and private keys. These keys are used to encrypt and decrypt messages during the secure email transmission.
TLS ensures email encryption via a “handshake” protocol. During handshake, server authentication is done, cipher suites for encryption are matched and keys are shared between the two servers.
When this handshaking attempt fails during a secure email transmission, it shows the error message ‘403 4.7.0 TLS handshake failed’, to the sender.
What causes the error ‘403 4.7.0 TLS handshake failed’?
Handshaking for secure TLS transmission can fail due to these main reasons:
1. SSL certificate errors
For TLS secure transmission, the servers communicating with each other should have SSL certificates installed. These certificates can be self-signed or issued by a certificate authority (CA).
SSL certificates have a validity period, after which they would expire. So, if a mail server that was working fine with TLS suddenly starts giving error, it could be due to expired SSL certificate.
Mail servers can also have their own self-signed certificates. Since they are less trusted than the ones issued by an authority, some recipient servers may reject self-signed certificates.
The following message can show in the mail error logs:
TLS client disconnected cleanly (rejected our certificate?)
2. SSL protocol or cipher issues
While it is recommended that all servers should use the latest secure version of SSL protocol, some unmanaged servers may still be using the old protocols and weak ciphers.
SSLv2 and SSLv3 are old insecure protocols that are disabled in most secure servers due to their vulnerabilities. So servers that still have them configured, may not be secure.
Same case is noted with the use of Ciphers, the codes used for data encryption. For security purposes, weak ciphers such as RC4 should be disabled in the server.
Recipient mail servers that adopt secure TLS practices may not establish secure connection with insecure sender mail servers. Then the error ‘403 4.7.0 TLS handshake failed’ gets displayed.
3. SSL connection errors
SSL connectivity issues between the sender and recipient server can also lead to the error . Firewall settings or other network problems can cause this.
‘STARTTLS‘ is the command that initiates the TLS handshake and secure connection. To test if the TLS connectivity of a mail server is working fine, use the command:
openssl s_client -starttls smtp -connect host:port
Verify TLS connection for mail server
By examining the results of this command, we can identify the connectivity issues or issues with the certificate or the TLS protocol.
4. MX record not resolving properly
Sometimes, it is possible that the sender mail server is unable to establish a connection with the recipient mail server, due to its MX records not resolving properly.
To verify if a mail server is resolving fine, use the command:
dig domain.com mx
If no results are obtained in the ‘ANSWER SECTION’, that means the MX record is not resolving and the sender would be unable to connect to the recipient.
5. Issues with e-mail client
Some versions of email client software such as CommuniGate Pro, InterChange, Eudora, etc. are reported to give errors when configured using TLS.
In those cases, sending mails from these email clients using TLS protocol would fail and give the error ‘403 4.7.0 TLS handshake failed’.
In commonly used mail clients such as Outlook, Thunderbird, Outlook Express, etc., if the SSL settings are not configured correctly, the TLS handshake will not work.
How to fix the error ‘403 4.7.0 TLS handshake failed’ in cPanel/WHM Exim servers
cPanel/WHM servers uses Exim mail server. While disabling TLS security is the easiest way out to get rid off this error, it is not recommended due to security concerns.
So here are some of the fixes to attempt, based on the issue identified:
- 1. If the SSL certificate is expired or is having issues, the solution is very simple – Renew or fix it!
- 2. To disable the old SSL protocol and use strong cipher keys, edit the Exim configuration from the WHM:
Click on ‘Home >> Service Configuration >> Exim Configuration Manager’.
Enter the Cipher code in the tls_require_ciphers text box:
- 3. Debugging SSL connectivity issues can be done with the help of tools such as ‘traceroute‘ and ‘telnet‘. The fix for this varies depending on whether its the firewall or the network that is causing the error.
Sometimes the issue may be at the recipient mail server too, such as firewalls or wrong MX records or other DNS issues. Switching the mail client of sender helps, if the issue is related to that.
- 4. To exempt a particular recipient domain from the TLS connection, add this line under ‘remote_smtp’ section in exim.conf file.
hosts_avoid_tls = recipient_com
How to fix the error ‘403 4.7.0 TLS handshake failed’ in Exchange servers
- 1. To remove the SSL certificate that is causing the error, Right click ‘PROPERTIES’ on the default SMTP Server then ‘ACCESS – CERTIFICATE’.
- 2. Disable outdated protocols such as SSLv2 and SSLv3. Enable the secure protocol TLS 1.1 or 1.2.
- 3. Update the Cipher suites to the strong cipher set.
- 4. It is also possible to set the authentication method to Basic Authentication, instead of TLS in Exchange server. Use theAuthenticationtab to configure security options for incoming SMTP connections.
How to fix the error ‘403 4.7.0 TLS handshake failed’ in Plesk Qmail servers
Plesk uses qmail mail server. Programs such as fixcrio, that runs along with qmail server, can cause errors related to TLS.
Verifying the TLS certificate and key files helps to fix the issue with those. These files are found in /var/qmail/control/ directory.
In qmail-remote, the qmail program for remote mail delivery, TLS sessions can be controlled with the file ‘tlsdestinations’. Here, we can define the TLS settings for email delivery to specific recipients.
How to fix the error ‘403 4.7.0 TLS handshake failed’ in RedHat, CentOS and OpenSuse servers with Sendmail
Along with the error message “403 4.7.0 TLS handshake failed”, it is possible to identify the recipient domain which has the TLS connectivity issue.
Edit the configuration file “/etc/mail/access” and add the line:
Since “/etc/mail/access” is a database, after creating that text file and editing it, use ‘makemap‘ to create the database map.
makemap hash /etc/mail/access.db < /etc/mail/access
Restart the mail server. This will exempt that domain from TLS email transmission and the mails would deliver fine without errors.
How to fix the error ‘403 4.7.0 TLS handshake failed’ in email clients such as Outlook Express and Thunderbird
Configuring the email client correctly is also important to use secure email transmission. Here’s how to do it.
In Thunderbird, ‘Edit–>Account Settings’ and in ‘Outgoing Server (SMTP)’ settings, select ‘TLS’ from ‘Use secure connection’.
For Outlook Express, Go to ‘Tools–>Accounts’. Select your mail account and click on properties. Go to ‘Advance’ tab and for ‘Outgoing Mail(SMTP)’, select ‘This server requires secure connections(SSL)’.
Today we saw why ‘403 4.7.0 TLS handshake failed’ error happens in mail servers and how to fix those issues.
But editing the mail server settings should be done with utmost caution. A wrong setting can cause your mail server to stop working.
At Bobcares, we keep the mail servers secure by following the best TLS/SSL practices, which helps us to avoid this error for our customers.
We also give recommendations to server owners on how to manage their server resources effectively. If you’d like to know how to get the best out of your servers, we’d be happy to talk to you.