CheckTLS Data is controlled by several policies. Our Terms of Use is the master agreement between our users and us. Our Privacy Policy explains how we treat your personal data and protect your privacy. This document describes our policy regarding protecting and storing your data.

Our Philosophy

CheckTLS is about security, and we are very protective of security and privacy. As the above referenced policies state, we will never sell or otherwise provide your information. We use common sense data protection, for example hardened servers with only SSH key access. Our data protection and retention philosophy is very simple: the best way for us to protect information is to not have it in the first place.

CheckTLS does real-time testing of the security of email systems. Anything we test is accessible from the Internet, so most of our "data" is public IP addresses, ports, and domain names. Since our data is publicly available, we do not take extraordinary measures to protect it.

Other than when necessary for a test, we do not encrypt data. This means your login and password, while protected, are readable by us. This means your test history, while protected, is readable by us.

When testing an email address, use just the domain part. We strip everything but the domain part anyway, so providing more than that is just a security risk.

CheckTLS subscribers are asked for contact information. We ask that you use roles and not individuals, for example "checktls@mycompany.com" instead of "Bill.Smith@mycompany.com". That way the contact information we have is not personally identifiable information (PII).

Subscribers may also enter authentication information into CheckTLS. The ability of CheckTLS to test private systems is very important to those very few users who have such systems. We ask that when you test a private system that requires authorization (LOGIN, CRAM-MD5, NTLM), or a special IP address or port, that you use temporary credentials, or that you change or remove them when you are finished.

Enumerating Some Risks

What are your risks in use CheckTLS?

Someone could "see" what domains you are testing.
While that likely means they could see some of the domains that you email to, even that isn't a sure thing. Companies test more domains than just the ones they use. Remember that this is just the domain, not a full email address.

Someone could "see" your CheckTLS userid and password.
A subscription is only $25, so the value of stealing credentials is low. Compromised userid/password means that person could run tests under your subscription. Since subscribers can run 100,000 tests per month, even if someone runs a few tests "on you" it's not a big deal. If they do 100,000 test a month on "on you" we will notice and fix the problem.

Someone could "see" your specific test options.
We see little value in knowing that you tested a domain for TLS version 1.2, or other settings. Anyone can do the same test themselves. There is some risk if you test a private system that requires special credentials, but as we say above, you should change those after testing is completed.

Data Retention

There are three types of CheckTLS data: Authorization, Target, and Stored ("Batch").

Authorization Data

Authorization Data is your CustomerCode, CustomerPassword, UserCode, and UserPassword (see FAQ: Why two different credentials). These fields are stored in a password protected SQL database on a hardened dedicated database server. They are backed up daily with weekly and monthly copies replicated to other on-line and off-line stores.

Authorization Data also includes contact name and email address. To eliminate any Personally Identifiable Information (PII) concerns, we ask that you use a role, for example "CheckTLS@MyCompany.com" instead of a personal email.

The monthly copies of Authorization Data are kept for three years.

Target Data

Target Data is data provided by a user when running a CheckTLS test. The simplest and most common Target Data is an email address entered on the //email/testTo: page. Target Data includes any options entered on a test page, for example whether the user chose to test MTA-STS, DANE, specific MX host(s), specific TLS version(s), etc. When testing a private system, authorization credentials will be included in Target Data, so users should "change the password" when they are finished testing.

Target Data can include authorization into private email systems, for example LOGIN, CRAM-MD5, NTLM, or a special IP address or port. We ask that you use temporary credentials, or that you change or remove them when you are finished.

Users should not expect Target Data to be backed-up or be in any way recoverable.

Some Target Data in some log files is presently kept forever.

Stored Data

Stored Data is data stored in Batches. Stored Data is Target Data, but it has different retention. Stored Data is backed up daily with weekly and monthly copies replicated to other on-line and off-line stores.

The monthly copies of Stored Data are presently kept forever.

Meta Data

When uploading files to CheckTLS, Windows metadata, such as file owner and creation date, are not captured or stored.