TestReceiver

//email/testTo: ("TestReceiver") looks forward at the receiving end of an Internet eMail transfer to test the software, server, or appliance that receives email. These include unix sendmail or a sendmail-like product (Postfix, Qmail), Microsoft Exchange, or a router or security device with email capability (Barracuda, Pix).

TestReceiver does not actually send an email. It just makes sure that if it did, the email would be secure.

Confidence Factor
TestReceiver outputs a Confidence Factor for the tested email address. The Confidence Factor is a zero to 121 (or more) measure of how confident we are that an email to the address would be sent securely. It measures only that TLS will be used to receive email; it does not consider whether or not the email address is valid.

It measures the number, preference, and quality of all the MX hosts for the address. It looks at the strength of encryption (SSL version(s) and cipher(s)). It looks at the certificate(s) and their signatures.

The Confidence Factor has these "breakpoints":

0-49

no encryption

50

unreachable (i.e. not tested)

51-63

bad encryption (SSL v2 v3)

64-74

very weak encryption (TLS v1)

75-87

weak encryption (TLS v1.1)

88-103

good encryption (TLS v1.2)

104+

strong encryption (TLS v1.3)

A CF of 50 typically means we could not connect to any email servers, so we could not test anything, and so we give the address a 50-50 chance of success.

Generally, if your Confidence Factor℠ is 90 or better, your email has the necessary encryption required by most security standards.

But if your Confidence Factor℠ is less than 90, your email needs work. This is the right place to start. See Solve Secure Email Problems.

Confidence QFactor
The Quick option under More Options does a quick "yes" or "no" test. It takes a quick measure of just the one server that a message from you will probably go to. For small email systems this is their only server (MX host), but for large email systems it could be just one of tens of servers.

A Confidence QFactor differs from our rigorous Confidence Factor because the Confidence Factor in three ways:

• systemic rigor
• point-in-time
• speed (potentially)

The Confidence Factor does a rigorous test of an entire email system. The Confidence QFactor does a quick look at just one host.

The QFactor picks the one host it thinks will be used right at this moment, while the full Factor test, by looking at everything, is a better measure of the long term security and maturity of an email system.

The Quick option sets these parameters:

STOPAFTER = EHLO2

stop as soon as we know encryption will work

CHECKOCSP = off

speed up the test by not checking for revoked certificates (they don't affect encryption)

TIMEOUT = 11

99% of systems that are going to answer do it in 11 seconds or less

IGNORENOCONNECT = on

ignore any host that doesn't answer

MXHOSTLIMIT = 1

take the first host that answers

Focus on specific aspects of email, and work in real-time with no-wait-for-cache using settings in More Options.

Depending on the Output Format selected (see below), the test also shows information about MX hosts, SMTP stages, SMTP commands and responses, details about the certificates and ciphers used, and even the contents of each packet.

Input Parameters

eMail Target

The (recipient) address to test

Output Format

How much detail to show (see next section)

Output Formats

Score

Shows just the Confidence Factor for this address.

Matrix

Shows the above plus a matrix showing each test step for each Mail eXchanger (MX). See "Understanding the Output" below for info about the steps.

(real-time)

The levels below can all display test results in real-time as the test is running (subject to browser buffering). Each step is timed so you can see where your system is spending all its time. See the Show Test Progress setting under More Options (click on the plus sign to open More Options).

SMTP

Shows the above plus each SMTP message sent to and from the email server. Test details are displayed real-time as the test is running (subject to browser buffering).

Detail

Shows the above plus summary information about the certificates used. Also shows certificate revocations by CRL (Certificate Revocation List and/or by OCSP (Online Certificate Status Protocol).

CertDetail

Shows the above plus details about the recipient's SSL Certificate.

SSLDetail

Shows the above plus details about the SSL connection.

Debug

Only shows the traffic between the two ends. Does not tease out any information like the above Detail levels, nor does it show the Matrix or the Confidence Factor. Note: this output is only useful for the most hard-core debugging, which should be using a packet analyzer instead.

SSLProbe

Probes the first MX and shows extensive information about protocols, ciphers, and vulnerabilities using testssl.sh. CheckTLS does not vouch for testssl.sh results, nor do we support or answer questions about it. testssl.sh is provided here "as is".

Understanding the Output

Confidence Factor (Score)

This proprietary score rates what we feel are the chances that an email sent to the tested address right now would go securely. It ranges from 0 (no chance) to 90-plus (pretty sure thing). It takes into account the order and strength of each Mail eXchanger (MX) listed for the recipient's domain, and the strength, precision, and validity of the recipient's SSL certificates.

MX/Steps Matrix (Matrix)

This matrix lists, for each MX, the MX preference and the steps TestReceiver took in proofing the server. Each step shows OK/FAIL and how long (milliseconds) the step took to complete. See the Wikipedia MX_record article for info on MX servers.

The steps are in order:

Answer

Indicates we can connect to the server. This shows the server exists, is on, is connected to the Internet, and is listening for connections.

Connect

Indicates we are allowed to connect to the server. This shows the server allows connections from most domains and IP addresses (since it allowed CheckTLS to connect).

HELO

Indicates that most domains and IP addresses can talk to this server (since it allowed CheckTLS to "say hello" with the SMTP HELO/EHLO command).

TLS

Indicates that the server says it can do TLS.

Cert

Indicates that the server's SSL Certificate is good. Currently this means the cert's: hostname matches the server, encryption is good, authorization chain is valid, and it's not self signed. Note: this is a very stringent test, and most senders will still send even if these requirements are not met.

Secure

Indicates that the server does, in fact, do TLS. This shows that we were able to turn on encryption for everything going to and from the server.

From

Indicates that the server will let most domains and IP addresses send mail to this server (since it let CheckTLS start an email from the @checktls.com domain).

To

Indicates that the server will accept mail for the tested email address. This means the address is probably valid. This is only reported if you entered an email address rather than just a domain.

Data

Indicates that we were able to start an email to the tested address. This is only reported if you selected Send Email under More Options.

Email

Indicates that we were able to finish the email to the tested address. This means the email was sent, although it still could get caught in a SPAM filter. This is only reported if you selected Send Email under More Options.

SMTP Messages (Detail)

This shows the RFC 2821 SMTP commands from the sender and responses from the receiver. Each command or response is time stamped in milliseconds since the start of the test. Important parts of the conversation are highlighted, and some information about the SSL certificate being used is included. For example:

Certificate 1 of 4 in chain:
subject= /OU=Domain Control Validated/CN=*.checktls.com
issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2

Certificate 2 of 4 in chain:
subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2

Certificate 3 of 4 in chain:
subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

Certificate 4 of 4 in chain:
subject= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

Cert Info (CertDetail)

Shows detailed information about the Public Key Certificate being used, and any Intermediate Certificates. It shows the encoded certificate itself as well as the decoded and parsed fields from it. If the remote server sent a certificate chain (used to verify/sign the remote server's certificate), those certificates and their fields are also shown.

SSL Info (SSLDetail)

Shows detailed information about the SSL connection. This includes the SSL negotiation and the decrypted packets sent and received.

Raw Traffic (Debug)

Debug output runs a different program internally and does not "watch" the test the way all the other levels do. It does not determine success or failure nor any of the timings, so it does not output the Confidence Factor nor the Matrix. It does not highlight important events in the traffic, nor does it decode certificates. The output is just the unparsed and unformatted, albeit decrypted, data traffic between the two email servers. For example:

Test From Your IP Address

CheckTLS can route your tests through your own IP address space. Use your connectivity, reliability, and reputation to run your tests. See the SOCKS parameter under the expandable More Options section of //email/testTo: ("TestReceiver").

You will have to run a SOCKS (see https://en.wikipedia.org/wiki/SOCKS) proxy, but SOCKS proxies are safe, light weight, mature, and easy to setup. You can control access to the proxy by our IP range and/or user/password authentication. Or you can subscribe to a commercial SOCKS service (google “SOCKS5”). We recommend socks-relay.sourceforge.io. It is free and the source code is available for you to audit.

Contact Us with any questions or for help with using this feature.

TestReceiver More Options

These additional input fields are documented in the expandable Instruction/Info section at the top of the TestReceiver screen. See the expandable section titled More Options.

Check The Latest EMail Security Enhancements

• Check SMTP MTA Strict Transport Security (MTA-STS) (see below).
• Check DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA(see below).
• Check DNS Security Extensions (DNSSEC)(see below).
• Allow TestReceiver to test the entire SMTP conversation (actually send an email, requires SOCKS option so emails come from user's IP).

IPv6

Everything available with IPv4 addresses is available with IPv6.

Individual MX Hosts

Test individual servers. It can target a specific MX server but feed it the regular domain address, for example testing mx3.mydomain.com with an email addressed to myname@mydomain.com. This can uncover problems masked by the fall-back and redundancy built into many email systems.

Limit MX Hosts

Limit the number of mail exchanger (MX) hosts by preference or by number. Some large email systems list tens of email exchange hosts. You can limit to the first X or % (number or percent) of MX entries in preference order, or the first X or % hosts (in preference and then alphabetical order).

Turn off DNS (Domain Name System) Cache or Use Your Own DNS Server

Turn off DNS caching so all lookups (MX, A/AAAA, MTA-STS, DANE, etc.) start from the global root servers and follow the authority chain up in real time to the SOA for the domain. Tell CheckTLS to use a different SOA name server, not the "real" one. Unique to CheckTLS, these let you see the effects of DNS changes immediately without risking your production services or waiting for DNS changes to propagate through the Internet.

Protocols, Ciphers, Authorities, Name Matching, Client Certificates

Choose which SSL protocols and ciphers are allowed, and what Certificate Authorities are acceptable, and how to match hostnames. Send client certificates to servers that request or require one. These options allow very detailed testing of email receivers.

Revoked Certificates

Check for revoked certificates (security problems) with Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).

Direct TLS

Test services that do not need a STARTTLS. TestReceiver will connect and immediately negotiate an SSL session. For example, "Direct TLS" and a short "SMTP Timeput" can be used to test a web server. Put the server address in MX Host, 443 in MX Port, check Direct TLS, and put 3 in the SMTP Timeout.

Compel TLS

Try forcing an email server that does not offer TLS to use it anyway.

Custom/Private Systems

TestReceiver can test non-standard email systems, or specific portions of an email system, or private email systems. Testing custom/private email systems requires them to be reachable from the Internet, but it can use non-standard SMTP ports (i.e. other than port 25) and/or it can authenticate into private systems.

MTA-STS

TestReceiver can test if an email system correctly implements MTA-STS. See Wikipedia: SMTP MTA STrict Transport Security and RFC-8461: SMTP MTA Strict Transport Security (MTA-STS).

DANE

TestReceiver can test if an email system correctly implements DANE. See Wikipedia: DNS-based Authentication of Named Entities and RFC-6698: DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA.

DNSSEC

TestReceiver can verify that all DNS entries used in email and related security technologies correctly implement DNSSEC. See Wikipedia: Domain Name System Security Extensions and RFC=9364: DNS Security Extensions (DNSSEC).

Automating TestReceiver

See About Batch, and especially the section on Batch Receiver Test for a better way to automate Receiver testing.

Other Uses

With higher Output Format (see below), TestReceiver provides visibility into any SMTP session. It was designed to test if email can be received securely, but because it continues testing even if TLS fails, it can also show the inner workings of non-TLS email servers.

When using TestReceiver "off-label", for example to verify email addresses or open up the inner workings of SMTP email conversations, the Confidence Factor should be ignored. Use the detailed Output Format (see below) to determine the success of your test.