Thu, 28 Feb 2019 Frequently Asked Questions

CheckTLS Source IP Addresses and Domain Names
What is the difference between Professional and Corporate Level Subscriptions?
Why Do You "Score" TLS Instead of Giving a Yes or No Answer?
May We Use the CheckTLS Name and/or Logo?
How Do I Fix My Email?
Do You Have a Non-Working TLS Host I Can Test With?
Why Two Different Credentials: CustomerCode and UserCode?
CheckTLS Shows Hostname Verify Error But OpenSSL Does Not?
Why Is My Email Slow?
CheckTLS Security
What is MXConfidenceFactor?

Wed, 24 Apr 2019 CheckTLS Source IP Addresses

Add the following IP addresses and domain names to any network filters and/or domain Whitelists at your site.

IP Addresses:

  • 2604:a880:800:a1::2b2:f001
  • 2604:a880:800:10::273:a001
  • Domain Names:
  • *
  • Adding our IP address range to any network filters makes sure our tests are able to do the testing you request from our site.Our tests are non-invasive, non-intrusive, and non-obtrusive. They require no changes to your or any other system. They cause no extra processing and should not trip any security alarms.

    Adding our domain to any Whitelists also makes sure our tests can do the testing you request, and it also makes sure any results we email to you get through to you and don't end up in a junk folder or thrown away.

    Back to Top

    Thu, 25 Jul 2019 What is the difference between Professional and Corporate Level Subscriptions?

    Corporate is everything in Professional plus the ability to store batches (lists) of addresses and test them automatically on a schedule.

    Professional is access to the raw tools, Corporate makes them easy to use over and over.

    Professional tests things one time, Corporate is "set it and forget it" continuous monitoring of one or more email systems.

    You can achieve HIPAA Compliance with Corporate. See email compliance

    Corporate also has Internet Packet Sniffer and Protocol Analyzer -- very powerful tools that take some time to learn and setup.

    Back to Top

    Mon, 30 Apr 2018 Why Do You "Score" TLS Instead of Giving a Yes or No Answer?

    TLS is not Yes or No. Take for example a domain that has a primary and a secondary (backup) MX host. If the primary has TLS but the secondary does not, is email to that domain encrypted or not?

    Our Confidence Factor℠ takes this into account. It accounts for two or more MX hosts, how they are prioritized, how good each of their TLS configurations are, such as what versions and cyphers they are using, etc.

    Even for single MX hosts, the Confidence Factor℠ considers versions, cypher strengths, key sizes, certificates, DNS setup and name matching, etc.

    Note that two or more MX hosts are common in medium sized organizations. They have their own email system, but subscribe to a cloud email provider as a backup. Their own email system has a higher MX priority than the backup, so the primary is always tried and used first. It is only when their own email system is down for maintenance or has a problem that the cloud provider receives their email. The backup typically stores the email and sends it to the primary when the primary comes back online. That connection may or may not be secure also, depending if the backup can send using encryption.

    That's why we created the Confidence Factor℠. It shows the shades of gray. We suggest that a CF of 90 and above is good. But we don't unequivocally say "yes" unless it's 100%. And even then your own policy may demand a higher degree of encryption, etc. We provide the tools for you to explore your, and your customers', levels of email security.

    Back to Top

    Fri, 06 Sep 2019 May We Use the CheckTLS Name and/or Logo?

    Yes, Corporate Subscribers may publish their affiliation with CheckTLS on-line and on printed or other media.

    We currently have no requirements for this use, but we ask that you include "CheckTLS℠" as part of your use.

    As part of this published affiliation you may use any of our service marks such as CheckTLS℠, ForceTLS℠, MonitorTLS℠, "Verified TLS"℠, and "Confidence Factor"℠.

    Back to Top

    Mon, 30 Apr 2018 How Do I Fix My Email?

    My email fails one or more of your tests.

    XYZ company will not do business with us unless we pass your test(s).

    You must secure your email system. Usually this means TLS encrypting email you send to others and accepting TLS encrypted email from others.

    Securing your email system is outside the scope of our site. Try searching the Internet for "howto TLS" and the name of your email software, e.g. "Office 365".

    You can also search the Internet for local consultants that can help you with your email system.

    Back to Top

    Mon, 30 Apr 2018 Do You Have a Non-Working TLS Host I Can Test With?

    Yes. You can use

    Obviously, is a working TLS host you can test with.

    Back to Top

    Tue, 01 May 2018 Why Two Different Credentials: CustomerCode and UserCode?

    Individuals have their own UserCode and Password.

    Corporate Subscriptions have a separate CustomerCode and Password.

    UserCodes allow Individuals to login to CheckTLS and interact with it. CustomerCodes allow unattended use of Web Services.

    Having separate credential types allows Individuals to keep their credentials secret and not listed in the source code for Web Service calls.

    Corporate Subscribers can see their CustomerCode and CustomerPass HERE.

    Back to Top

    Fri, 06 Sep 2019 CheckTLS Shows Hostname Verify Error But OpenSSL Does Not?


    Before configuring enforced SMTP/TLS for specific recipient domains I usually check the configuration of that recipient domain's mail server with

    Now I have a case which I do not understand: [ed note: all domain names changed for privacy]

    MX records are pointing to servers with domain name ending with The certificates CN = * states: [001.084] Cert VALIDATED: [001.084] Cert Hostname DOES NOT VERIFY ( != * | DNS:* | [001.084] (see RFC-2818 section 3.1 paragraph 4 for info on wildcard ("*") matching) [001.084] So email is encrypted but the host is not verified

    But when I test with openssl I receive: Verify return code: 0 (ok)

    And when I enforce SMTP/TLS (it's a sendmail MTA) for domain, mails are being delivered and the log says: tls_verify=OK

    I can see the following SMTP banner and response from the SMTP server in the greeting section after the EHLO submitted by the SMTP client:

    Does this mean that it's sufficient if a certificate CN matches the SMTP banner for openssl to regard an SMTP/TLS connection as verified?

    This looks somewhat confusing to me.

    Can you provide me some more information about this specific topic? I'm especially interested in what names are involved in certificate verification during an SMTP/TLS handshake.


    You are asking how various programs use three different hostnames:

    MX Host
    The host ( identified to receive email for a domain ( It comes from looking up the recipient's domain in the Internet Domain Name System.
    CN Entry
    The host or host-wildcard ( given in the SSL Certificate of the MX Host.
    HELO/EHLO Host
    The hostname returned in response to an SMTP HELO/EHLO command
    HELO/EHLO Host

    A site can return any hostname in their HELO/EHLO response, so it is not a reliable security constraint. However many mailers will log a security warning when they find a mis-match between what they are expecting in the HELO/EHLO response and what they receive.

    The more detailed Output Format levels of the CheckTLS Test To: (TestReceiver) test show the HELO/EHLO response but CheckTLS does not try to match it against anything and it does not affect the Confidence Factor.

    CN Entry

    The CN Entry is a field included in a site's SSL Certificate. Because the certificate is encrypted and should be signed by a trusted Certificate Authority, the CN Entry is a reliable security constraint.

    The CheckTLS Test To: (TestReceiver) test does use the CN Entry as part of its hostname verification and a mis-match does affect the Confidence Factor.

    MX Host

    The MX Host comes from a DNS lookup. A DNS lookup is not completely secure, and there are projects working on making it more secure, but MX Hosts from DNS lookups are considered a reliable security constraint.

    The CheckTLS Test To: (TestReceiver) test does use the MX Host as part of its hostname verification and a mis-match does affect the Confidence Factor.

    But Why Does CheckTLS Complain When OpenSSL and My Mailer Do Not?

    Current versions of openssl do not check for any hostname matches. It reports the name but does not use it. You can see this for yourself using:

    openssl s_client -connect -starttls smtp -servername

    This tells openssl to connect to one of our MX Hosts and to expect it to be named "". openssl happily and without reporting anything out of the ordinary connects to our host, even though it clearly the host it connected to ( has nothing to do with

    Most mailers do check that the MX Host match the CN Entry, but they just log a warning (which no one ever sees) and continue to send the email. This is consistent with the traditional Internet mantra of "the data must get through".

    Some mailers can be configured, or may even be configured out of the box, to fail if the MX Host does not match the CN Entry. Security is becoming more prevalent in today's world.

    Thank you CheckTLS!

    CheckTLS does compare the two reliable security constraint names.

    Since a mis-match typically does not prevent email from going through, CheckTLS only warns about mis-matches (in yellow) and includes a note that email will be encrypted (i.e. safe from prying eyes) but there is a small chance it is being sent to the wrong place. And since it is their certificate that is encrypting the email, they will be able to read it.

    CheckTLS also helps diagnose if your mailer is configured to fail mail when the MX does not match the CN. This can happen without a mail administrator's knowledge, say with a software upgrade, or a new trading partner. Suddenly email stops working, and it is not clear why. CheckTLS shows you the problem.

    Back to Top

    Fri, 06 Sep 2019 Why Is My Email Slow?

    There are uncountable reasons why email may be slow, so CheckTLS cannot tell you exactly what is wrong with yours. But CheckTLS can show you exactly how much time each step of an email transfer is taking, so you know where to focus your efforts.

    Run our Test To: (TestReceiver) test with the Output Format set to "Detail". The output shows every line sent to and from your email server, complete with the time each step took.

    For example the below real-world test (the names have been changed to protect the guilty) shows an email server that is taking just over 20 seconds to issue the very first sign-on message (see hilite below).

    "" is an email provider for multiple domains (including, and we suspect that takes a long time to figure out what it is supposed to do with email for

    CheckTLS does have all of the forward and backward DNS records properly configured for, so this server's issue is not in standard email verification DNS timeouts. should show this to and demand they fix it. Or get a better email provider.


    looking up MX hosts on domain ""

    1. (preference:10)

    Trying TLS on[] (10):

    seconds test stage and result
    [000.113] Connected to server
    [020.271] <-- ESMTP Exim 4.89 #1 Sun, 03 Dec 2017 17:16:33 +0000
    220-We do not authorize the use of this system to transport unsolicited,
    220 and/or bulk e-mail.
    [020.272] We are allowed to connect
    [020.272]  --> EHLO
    [020.375] <-- Hello []
    250-SIZE 52428800
    250 HELP
    [020.375] We can use this server
    [020.376] TLS is an option on this server
    [020.376]  --> STARTTLS
    [020.483] <--  220 TLS go ahead
    [020.483] STARTTLS command works on this server
    [020.722] SSLVersion in use: TLSv1.2
    [020.722] Cipher in use: ECDHE-RSA-AES128-SHA256
    [020.722] Connection converted to SSL of output deleted...

    Back to Top

    Fri, 29 Jun 2018 CheckTLS Security

    CheckTLS keeps two types of data from our users: test logs and stored tests (Batches).

    Information about tests you run is stored in test logs. These logs are kept for a short time and are only readable by CheckTLS staff.

    Only Corporate subscribers can store information on our site. Corporate subscribers require a usercode and password to access this stored information. Each subscriber only has access to their own data.

    Subscription information (usercode/password, company info) and each subscriber's own data is stored in a password protected database; this password is separate from subscriber passwords and is only known to CheckTLS staff.

    All CheckTLS users only have access to web pages and web services published on the site. Only CheckTLS staff have any access to the underlying OS.

    All our hosts are protected by firewalls.

    The site has strict Acceptable Use and Privacy policies.

    Please do not give us confidential information. Do not put the same password or password scheme in CheckTLS that you use for important things. If you feel your test targets are secret, you can use upload saved test(BatchUpload) which only stores the targets on our site for the duration of the test.

    While we take security very seriously, obviously, our position is that if someone breaks into an account on CheckTLS, then all they can do is run some tests. Since most of these tests are available for free on the site anyway, the value of hacking CheckTLS is low so we hope attackers will go after more valuable targets.

    Back to Top

    Thu, 28 Feb 2019 What is MXConfidenceFactor?

    <MXConfidenceFactor> is included in some XML detail output formats of TestReceiver.

    It is a technical measure of an MX host. It measures how many successful steps the SMTP conversation went with that host. It does not consider things like TLS versions, certificate validity, encryption method, etc.

    Its scores are as follows:

    RCPT TO100

    Back to Top