See the //email/testTo: ("TestReceiver") Full Documentation for complete information.
Type in the email address of someone that you send email to.
Leave the Output Level set to "Detail".
Click the Run Test button.
When you click Run Test, //email/testTo: ("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.
Confidence Factor
For all Output Levels TestReceiver shows 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 preference. It computes a single number for the given email address that is our opinion on how securely it will receive email.
The Confidence Factor line shows the numerical grade of the target, the maximum grade the target could get, the grade's percent of maximum, and what grade a fully tested (e.g. with MTASTS and DANE testing) best-in-class email system would get.
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.
Detail
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.
More Options adds these input fields:
- Show Test Progress
- Show MX tests in real-time. A MX test is displayed live in the browser as it happens. All MXs are tested one after the other instead of at once, so we recommend using this option for just one specific MX.
- Quick Test
- Just do a quick "yes" or "no" test. This replaces the Confidence Factor with a Confidence QFactor, which may be a faster and better right-this-instant measure of security. It sets IGNORENOCONNECT=on, CHECKOCSP=off, MXPREFLIMIT=50%, MXHOSTLIMIT=1, STOPAFTER=EHLO2, TIMEOUT=11, CACHEMIN=60, CACHEMAX=300. These can then be overridden by setting them explicitly.
- Check MTA-STS
- Lookup and verify SMTP MTA Strict Transport Security (MTA-STS) and SMTP TLS Reporting settings. The largest email provider in the world enabled these in 2019: see About MTA-STS and TLS reporting - G Suite Admin Help.
- Check DANE
- Lookup and verify DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA settings. DANE allows X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).
- Check Cert Sigs
- Check which certificates signed which other certificates./dd>
- Relax "*" match
- Allow wild-card certs to match multiple levels of server name (see rfc-2818 section 3.1 paragraph 4).
- 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.
- 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. This can be a hostname (which will be DNS looked-up), or an IP address, or "name[ip]" which will connect(ip) but verify_hostname(name).
- 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.
- MX Pref Limit
- Limit the number of MX Preferences to test. Can be either a number or a percent (put % after digits). Leave blank to test all MX records. MX Host Limit (below) counts hosts, MX Entry Limit counts MXs (one MX Entry can have multiple Addresses), and MX Pref Limit counts MX Preferences (one preference can have multiple Entries).
- MX Entry Limit
- Limit the number of MX Entries (in preference order) to test. Can be either a number or a percent (put % after digits). Leave blank to test all MX records. MX Host Limit (next) counts hosts, MX Entry Limit counts MXs (one MX Entry can have multiple Addresses), and MX Pref Limit (above) counts MX Preferences (one preference can have multiple Entries).
- MX Host Limit
- Limit the number of MX Hosts to test. Can be either a number or a percent (put % after digits). Leave blank to test all hosts. MX Pref Limit (above) counts MX Preferences (one preference can have multiple Entries), MX Entry Limit (above) counts MX Entries (one MX Entry can have multiple Addresses), and MX Host Limit counts hosts. With IgnoreNoConnect (below), MX Host Limit will stop after the first N hosts respond (in any preference order).
- Ignore No Connects
- Remove all MX hosts that do not allow us to connect, as if they were not in the DNS MX lookup in the first place. Used to prevent hosts that are off-line from reducing the Confidence Factor.
- Stop After
- Stop the SMTP conversation after this step, one of (ANSWER,CONNECT,EHLO1,STARTTLS,EHLO2,MAILFROM,RCPTTO,DATA). Leave blank to run all.
- IPv4
- Test IPv4 MX hosts.
- IPv6
- Test IPv6 MX hosts. Currently our hosting company Digital Ocean blocks this.
- No DNS Cache
- Bypass all DNS caching. Starts by looking up the GTLD from the global root servers and follows the authority (SOA) chain up to the entered domain name.
Use this when changing or debugging DNS issues to see results immediately without having to wait for DNS entries to time out. (Obviously your changes will still have to timeout for the rest of the world.)
The test reports the server path it found from the root servers to the final SOA.
- DNS Host
- The DNS host to use for all lookups (MX, MTA-STS, DANE, etc). Use this to test how your email interacts with DNS entries, possibly before you publish new DNS.
- 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.
- Direct TLS
- Start TLS immediately after connecting to server and before sending or receiving any commands or data (typically used with port 465).
- Check CRL
- Check if certificate is revoked on its Certificate Revocation List (CRL). Note: this can take several minutes and may time-out, but if you wait 10 minutes and try again it will work because we cache CRLs.
- Check OCSP
- Check if certificate is revoked by its Online Certificate Status Protocol (OCSP).
- SSL Version
- Sets the version(s) of the SSL protocol that can be used. 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 ':' (colon).
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.
- SSL Cipher List
- Sets the list of TLSv1.2 and below ciphersuites. See cipherslist in the OpenSSL ciphers documentation.
- TLS1.3 Cipher Suite
- Sets the list of TLSv1.3 ciphersuites. See -ciphersuites in the OpenSSL ciphers documentation.
- 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.
- SMTP Auth
- 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. SMTP Auth specifies which AUTH mechanism to use (plain, login, CRAM-MD5, NTLM)
- AUTH User
- The userid for authentication.
- AUTH Pass
- The password for authentication.
- Client Cert
- The Client Certificate to send.
- Client Key
- The Client Certificate Key to send.
- XSL URL
- This adds the specified XSL stylesheet URL to the XML output. It is up to whatever system receives the XML to apply the stylesheet. See TestReceiver XSL for more information.
- XSL to Run
- This applys the specified XSL to the XML. The translated XML is output in place of the original. You can enter the XSL itself or a URL from which to retrieve the XSL. See TestReceiver XSL for more information.
- SOCKS
-
Test from your IP address using SOCKS.
Format is [user[:pass]@]host:port, e.g.
host:port
user@host:port (SOCKS4)
user:pass@host:port (SOCKS5) - SMTP Detail XML
- For XML Output Formats only, turn this on to include the SMTP log as CDATA in the XML output. See the TestReceiver Full Documentation for more information.
The following options are restricted. They can only be used on systems that you directly control and that will not report CheckTLS as a threat. Improper use will harm CheckTLS.com and we will block your access and cancel your subscription without refund.
These options are not useful for testing the security of an email server. They do not affect the Confidence Factor and have no bearing on the security of emails.
- RCPT TO
-
Send an SMTP "RCPT TO" command.
Note that this option can be seen as a "sender callout" (See Calllback Verification). Sender callouts are a controversial subject with strong opinions both ways. (Google "sender callout" to see various opinions.)
- Send Email
-
Actually send a test email message.
Note that this will send one email per MX, which on a large email system could be many emails to the same address. Use either the Quick or the eMail MX Host options above to target just one MX host.
See what else you can test.