See the TestReceiver Full Documentation for complete information.

How to run it

Type in the email address of someone that you send email to.

Leave the Output Level set to "Detail".

Click the Run Test button.

What it does

When you click Run Test, TestReceiver performs all the steps that Internet email systems go through to send email. It records every command and byte of data it sends and every answer and byte of data that the other email system sends. TestReceiver never actually sends an email, it just gets as close as possible, learning as much about the remote system as it can.

Because CheckTLS focuses on security, TestReceiver tries to establish a secure (TLS) connection with the recipient's system. Along with recording everything, it looks at the security of the recipient's system for things like: certificate contents and signers, encryption algorithms, key lengths, hostname mis-matches, incorrect wild-card usage, weak cyphers, etc.

What it shows

Confidence Factor

For all Output Levels, the first thing TestReceiver shows is our unique Confidence Factor. This is our "grade" (zero to 100) for the recipient's email system. It takes into account all the security information gathered while it was connected with the recipient's email system. For domains with multiple email servers (MX hosts), it weighs how many there are and their priority. It computes a single number for the given email address that is our opinion on how securly it will receive email.

We suggest that a Confidence Factor of 90 or above indicates that the email address is "secure".

MX Matrix

The next level of output is the MX Matrix. TestReceiver groups the steps of sending an email into 8 stages. The MX Matrix shows, for each MX host, how long each stage took and whether it was successful or not. Use the MX Matrix to look deeper into an email system, both down the matrix (by MX Host) and across the matrix (by stage), to show where strengths and weaknesses are in the system.

See the TestReceiver Full Documentation for more information about the MX Matrix stages.


The next levels of output are all Detail. Detail is the log of TestReceiver's interaction with the recipient's email system. Depending on the Output Level chosen it also shows what is inside the remote system's SSL Certificates and the details of the SSL connection established with the remote system.

See the TestReceiver Full Documentation for more information about what the Detail levels show.

FULL version fields

The FULL version has these additional input fields:

MX Host
A specific MX host to test. Use this to focus on a single MX host, or when DNS does not return the right MX hosts.
MX Port
The TCP port to use to talk to the email server, almost always 25 (SMTP) but can be 465 or 587. Leave blank to use 25.
Direct TLS
Start TLS immediately after connecting to server and before sending or receiving any commands or data (typically used with port 465).
Compel TLS
Try starting TLS even if server does not offer it, i.e. send a STARTTLS command even if server did not offer 250 STARTTLS.
Relax "*" match
Allow wild-card certs to match multiple levels of server name (see rfc-2818 section 3.1 paragraph 4).
SSL Version
Sets the version of the SSL protocol used to transmit data. From the OpenSSL documentation:

'SSLv23' uses a handshake compatible with SSL2.0, SSL3.0 and TLS1.x, while 'SSLv2', 'SSLv3', 'TLSv1', 'TLSv1_1' or 'TLSv1_2' restrict handshake and protocol to the specified version. All values are case-insensitive. Instead of 'TLSv1_1' and 'TLSv1_2' one can also use 'TLSv11' and 'TLSv12'. Support for 'TLSv1_1' and 'TLSv1_2' requires recent versions of Net::SSLeay and openssl.

Independent from the handshake format you can limit to set of accepted SSL versions by adding !version separated by ':'.

The CheckTLS default SSL Version is 'SSLv23' which allows any handshake version for testing purposes. CheckTLS issues a warning if the handshake negotiated is SSL2.0 and SSL3.0 which have serious security issues and should not be used anymore.

Most production systems use the default SSL Version 'SSLv23:!SSLv3:!SSLv2' which means that the handshake format is compatible to SSL2.0 and higher, but that the successful handshake is limited to TLS1.0 and higher, that is no SSL2.0 or SSL3.0 because both of these versions have serious security issues and should not be used anymore. You can also use !TLSv1_1 and !TLSv1_2 to disable TLS versions 1.1 and 1.2 while still allowing TLS version 1.0.

Setting the version instead to 'TLSv1' might break interaction with older clients, which need and SSL2.0 compatible handshake. On the other side some clients just close the connection when they receive a TLS version 1.1 request. In this case setting the version to 'SSLv23:!SSLv2:!SSLv3:!TLSv1_1:!TLSv1_2' might help.

Send Email

Actually send a test email message. Requires a Corporate Level Subscription, and we limit use of this feature to prevent abuse.

This is not necessary for testing because our test does everything that sending an email does except put text into the message. Send Email does not affect our Confidence Factor score.

Note that this will send one email per MX, which on a large email system could be many emails to the same address. Use the eMail MX Host option above to target just one MX host.

To help minimize unauthorized use, some email systems require authentication (i.e. login/password) to access email. The "AUTH" fields allow you to connect to these systems. AUTH Type specifies which AUTH mechanism to use (plain, login, CRAM-MD5, NTLM)
The userid for authentication.
The password for authentication.
SMTP TimeOut
How long (in seconds, default 30) to wait for the SMTP server to respond to a command. Use this if you are getting time-out errors on a slow connection or while testing a slow/busy server. While this allows you to test a slow system, needing more than 30 seconds indicates a problem and regular email will frequently fail.
CRL Check
Use Certificate Revocation List (CRL) to check if any Certificates are revoked.
OCSP Check
Use Online Certificate Status Protocol (OCSP) to check if any Certificates are revoked.
CA Certs
A PEM encoded Certificate or Certificate Chain of trusted Certificate Authorities to use to determine if the server's certificate is properly signed. Use Show Our CA List to see the Chain used by CheckTLS.
Send Client Cert
Send the Client Certificate and Key immediately below to the server.
Client Cert
The Client Certificate to send.
Client Key
The Client Certificate Key to send.
Input Fields
TestReceiver parameter entry
  1. - + (less/more output)
FULL version

Run many tests at once and schedule them in a Batch.
We can help you with email compliance for regulations such as HIPAA, PCI-DSS, SOX, GLB, etc.

Test Results

Test results will show here when a test is run.