Call Us! [visitorlocation]
Call Us! [visitorlocation]

Need Help?

Our experts will login to your server within 30 minutes 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

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

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

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!


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.
Server Management

Submit a Comment

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

Privacy Preference Center


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]


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


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


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.