Need help?

Our experts have had an average response time of 11.43 minutes in March 2024 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

How to fix email error ‘403 4.7.0 TLS handshake failed’ in cPanel, Plesk, Exim, Qmail, Exchange and SendMail servers

by | Sep 6, 2016

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 -----
 
 (reason: 403 4.7.0 TLS handshake failed.)

 

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.

Read: How to fix error ‘421 Too many concurrent SMTP connections’ in cPanel and DirectAdmin servers

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.

Read: Top 7 TLS/SSL best practices – An easy guide to make encryption unbreakable

3. SSL connection errors

SSL connectivity issues between the sender and recipient server can also lead to the error ‘403 4.7.0 TLS handshake failed’. 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

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.

Read2 common causes for Email Error 551, and How to fix it

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:

ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:!SSLv2:!SSLv3

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

Read: Disable RC4 ciphers in cPanel/WHM servers – Why and How to do it?

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 the Authentication tab 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:

Try_TLS:domain.com NO

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

Read: Top 5 causes for email error “451 Temporary local problem – please try later” and How to fix it

In short..

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.

Read: How to fix email error “554 5.7.1 : Relay access denied”

 

Get a FREE consultation

Do you spend all day answering technical support queries?

Wish you had more time to focus on your business? Let us help you.

We free up your time by taking care of your customers and servers. Our engineers monitor your servers 24/7, and support your customers over help desk, live chat and phone.

Talk to our technical support specialist today to know how we can keep your service top notch!

TALK TO AN EXPERT NOW!


var google_conversion_label = "Blp0CLCojHIQ0aD71QM";

Bobcares provides Outsourced Hosting Support and Outsourced Server Management for online businesses. Our services include Hosting Support Services, server support, help desk support, live chat support and phone support.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Categories

Tags

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF