How to Use CheckTLS.com

The steps below walk you through what you can do on this site, in order of increasing difficulty:

• Quick look into your email (same two tests from our Home page)
• Why how you send is more important
• Deeper look at your email
  • SMTP, TLS Version, Cipher List
  • Certificate: signing, cross-signing, CA Root, expiring
  • DNS, MTA-STS, SMTP Reporting, DANE
  • SPF, DKIM, DMARC
• More Than Just Email
• Navigating CheckTLS.com
• Work Efficiently
• Require your email to be encrypted (and why you don't want to)
• Run our tests on your computers or website (WebServices)
• Verify your email end-to-end
• Check lots of addresses at once
• Schedule repeated testing
• Continuously monitor your email

Follow the first few steps to get an idea of what we do and how we do it. Peruse the first paragraph of the sections below to get an idea of what else we can do and why. Bookmark this page and come back to it as you think of other questions about your email. The more you know about CheckTLS.com, the more valuable it becomes!

Quick Look Into Your Email

Quick Look: Getting Email

Do a quick check of your own email address. Will it accept TLS encrypted message from the Internet? Google says 90% of email systems do.

See TestReceiver for more about this test.

Quick Look: Sending Email

It is more important to protect email you send because you are responsible for protecting email until it is accepted by the receiver.

    From: CheckTLS Test Sender TLS <testsender@CheckTLS.com>
 Subject: SUCCESSFUL

See TestSender for more about this test.

Why How You Send Is More Important

Because you are responsible for protecting emails you send, you need to know if your recipients will let you use encryption. By default almost every email system will fall back to plain text if the recipient won't encrypt. See Mandatory TLS below for why yours will too.

Run the same test as above on addresses you send to. Will they accept TLS encrypted message from the Internet? Most will, but you will find a few that do not.

we do not keep or use any addresses, see our privacy policy

If you email someone that does not pass this test, you are sending to them in plain text. That is probably illegal and certainly violates common sense.

See TestReceiver for more about this test.

Deeper Look At Your Email

A basic email server has two pieces that must work together: the email server and the MX DNS entry that points to it. The simple test above checks the email server(s), the DNS MX record(s), and that the two are working together.

The safety measures the Internet has invented to protect wanted email and reduce unwanted email add more pieces. Each new piece has to fit correctly into the whole. CheckTLS can help you configure these measures and fit them properly into your whole.

CheckTLS does two things: test individual pieces of an email system, and test all the pieces working together. This combination of isolated feature testing and total systemic testing, in real-time on real-live systems, is unique to CheckTLS.

Once installed, it is just as important to keep your email system working correctly, efficiently, and safely. We allow subscribers to save the tests they use in installing and configuring their email systems and run them repeatedly on demand or on a schedule. CheckTLS lets you monitor not just that some email is getting through, but that all mail is getting through and that all your security measures are working properly.

Deeper Look: Receiving Email

Find out more about what goes into the "score" (Confidence Factor℠) that we compute for your email address and the addresses of people you email with.

Deeper Look Receiving: Show More Detail

The //email/testTo: above that reported on whether or not your or someone else's emailbox can receive email with TLS encryption can show many details about an email system. The Show Detail button above or here shows these details.

This new window shows our server testing your email system in real time. It shows the details of what went into your Confidence Factor℠.

It shows a matrix of each SMTP step for each of your MX hosts. The squares in the matrix indicate the success or failure of the step, and how long that step took.

Beneath that are the complete transcripts of the SMTP "conversations" our servers had with your servers. Included in each transcript are annotations that describe what happened at certain steps and/or that show more information about what was going on in that step, such as the contents of the SSL Certificate used.

We encourage you to run this test on different email systems to get a better understanding of what the details show and how well-tuned email systems look.

Bookmark //email/testTo: and come back to it as you find other addresses or think of other things you want to know about an email system. This test is very powerful and can uncover lots of things about an email system.

Deeper Look Receiving Detail: What To Look For

Receiving Detail Look For: MX DNS Entries

Make sure that the MX hosts listed are what you expect. We see "forgotten" MX hosts, left over from upgrades where people forget to remove the old ones when they finish testing the new ones. Those old MX host can have old certificates, insecure SSL Versions, and incorrect end-user delivery options, resulting in insecure or completely lost emails.

Receiving Detail Look For: MX Hosts

Be sure each MX host is properly configured. We see mis-matched certificates and other settings, which cause inconsistent email results, and inconsistent results are the hardest to diagnose.

Receiving Detail Look For: TLS Version

Obviously check that each MX host can "starttls". Check that each one offers the version(s) of TLS (SSL) that you want, and only those versions. Use the SSL Version option in //email/testTo: to test both that the versions you want do work, and that the versions you do not want are refused.

Receiving Detail Look For: Certificates

While certificate verification does not typically cause email to revert to plain text, an expired or improperly signed certificate will prevent some senders from being able to send to you. The more security conscious a trading partner is, the more likely they are to refuse to send email to a site with a certificate weakness. These security conscious trading partners are likely to be your most important trading partners.

Deeper Look Receiving: Email Protection (MTA-STS, SMTP TLS Reporting)

SMTP MTA Strict Transport Security (MTA-STS) tells the Internet that your email can receive email using TLS, and whether or not you require it. MTA-STS has several "moving parts" that have to be in sync: a DNS record, a policy file, and policy settings that match other DNS records. Any errors may mean your email is less secure than you expect and can even result in email loss.

Adding a SMTP TLS Reporting DNS record tells the Internet how to inform you if there are any errors with your TLS.

Google has added MTA-STS and SMTP TLS Reporting to gmail: gmail supports MTA-STS and TLS Reporting

The tests above test your MTA-STS and TLSRPT by default.

Deeper Look Receiving: Email Protection (DANE)

Domain-based Authentication of Named Entities (DANE) is an arguably even more secure way to ensure TLS security, however it is more difficult to set up and administer, and it requires special DNS servers (DNSSEC) at your domains' SOA.

DANE has many parts that all need to work together. Some of these parts must be renewed every year, and the remaining parts updated to match the newly renewed parts. Many parts and constant updates means DANE requires ongoing maintenance and testing.

CheckTLS not only verifies that a DANE implementation is correct, it exposes all the parts to help you find and fix problems. If you use or are considering DANE, you need CheckTLS.

The tests above test your DANE implementation by default.

Deeper Look Receiving: Test Specific Items

The //email/testTo: allows you to tune the test to target specific features of your email system.

The test parameters you can tune are documented in the More Options instructions and in the Test Documentation, and includes items like:

Output Format

show more or less information about each server

Show Test Progress

show test results one at a time in real time

MX Host/Port

test a specific single host, possibly at a non-standard port
useful when debugging one particular server

IPv4/IPv6

test via IPv4 and/or IPv6

MX Count

only test a subset of all MX hosts

Ignore No Connects

Check CRL/OCSP

see if a security certificate has been revoked (maybe compromised or stolen)

SSL Version

check what SSL/TLS version(s) work

SSL Cipher List

check what SSL Cipher(s) work

CA Certs

verify using your own Certificate Authority

Auth User/Pass

test private email systems that authenticate with UserID/Password

Client Cert/Key

test private email systems that authenticate with a client certificate

Open the More Options section here:

Deeper Look: Sending Email

The //email/testFrom: above that reported on whether or not you can send email with TLS encryption can also tell you the details of the encryption your emailer can do, and it can report on other protections that the Internet has developed to improve your email reliability, deliver-ability, and security.

Deeper Look Sending: SSL Version and Cipher List

If you include the strings "SSL Version Used" and "SSL Cipher Used" in the body of the email you send us, CheckTLS will include that information in the results email we send back. Try It
The return email will have additional information about your implementation of SSL:

    From: CheckTLS Test Sender TLS <testsender@CheckTLS.com>
 Subject: SUCCESSFUL

See TestSender for more about this test.

Deeper Look Sending: Email Protection (SPF, DKIM, DMARC)

Sender Policy Framework (SPF) DNS records list what IP addresses are allowed to send your email. When email gets delivered, the receiver checks that it came from one of your published IP addresses. SPF prevents someone else from sending an email that pretends to be from you.

Domain Keys Identified Mail (DKIM) protects the email from modification. It adds a private-key encrypted checksum of various parts of an email to the email header. The receiver uses a DKIM DNS record public-key to decrypt the checksums and thereby verify each part. Protecting the email headers assures the email really came from you. Protecting the email content assures no one changed the message.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) works with SPF and DKIM to further protect email. It adds instructions for working with SPF and DKIM and what to do if one fails.

If you include the strings "SPF", "DKIM", and/or "DMARC" in the body of the email you send us, CheckTLS will check your implementation of those security features. Try It

Unlike other on-line tests that test your SPF, DKIM, and DMARC settings, we test SPF, DKIM, and DMARC on a real email from your live email system.

See TestSender for more about this test.

More Than Just Email

CheckTLS.com testing is comprehensive. Our tests look for everything we can find out about every server we can find. By looking at everything, we can find weaknesses or vulnerabilities that do not show during normal operations. Exploits and data loss are usually the result of a bad actor exploiting a weakness that no one knew about.

For example, many sites on the Internet will check your webserver by fetching a webpage and seeing if it was secure. By changing the Port from 25 to 443, the same //email/testTo: that reports on email servers can do a comprehensive test of your https web infrastructure:

Use CheckTLS.com whenever you want to look at your SSL infrastructure in real time!

Navigating CheckTLS.com

Our site is designed like a computer directory. The root is the home page, which we refer to as // or //home. The major branches are the top-level menu choices on the horizontal bar on the top of every page:
| email | cloud | help | subscription | faq | | |
which are referred to as
//email
//cloud
//help
//subscription
//faq
The remaining menu items are Contact Us (), Search (), and Translate ().

The major branches have sub-branches, for example:

//email/testTo:

TestReceiver

//email/testFrom:

TestSender

//subscription/signup

New Subscription Sign-Up

Work Efficiently

Our design lets you start small but then slowly dig deeper one step at a time. Move easily from a systemic view to very specific feature testing. Parameters are saved from one test run to the next, so you only change what you need.

DNS is a big piece of complex email systems, and working with DNS is hard because caching and TTL mean you have to wait for changes to take effect. Our tests have options to bypass caching and TTL, so you can make changes and see their effects immediately.

Simple versions of CheckTLS tests are available other places on the Internet. Much of the deep testing we do is available from command line or installable tools. CheckTLS puts lots of email tools together in one place with all the power of command line and installed utilities.

By making incremental testing easy and by using fresh data, we can do hours of testing in a few minutes. By putting lots of email tools together in one place with all the power of command line and installed utilities, we can do all your testing in one place. We think you'll find that CheckTLS.com is indispensable for working on email systems.

Require Email Encryption ("Mandatory TLS")

Most modern email systems can do strong email encryption using TLS, and they can be told to require it. So why not turn on this so called "Mandatory TLS" and guarantee that all Internet email is protected?

Because 10% of email systems are not capable of TLS, and no one is willing to forego 10% of their email. Especially since email bounces are inconsistent: they can take minutes, hours, days, or sometimes the sender is never informed that their email was not delivered.

Some companies do use Mandatory TLS with selective trading partners. Two companies with solid TLS support can turn on Mandatory TLS between themselves and protect their email that way.

Of course, if both sides have working TLS, then how do you know that your email won't fall back to plain text if the other side stops doing TLS? CheckTLS designed tests that can verify that your Mandatory TLS will not fall back to plain text. And like many tests, it can then monitor your Mandatory TLS to be sure it doesn't fall back in the future as things change.

Mandatory TLS: Email You Receive

Mandatory TLS: Email You Send

Send Us a message for us to test, and just like the above test we will email you back the test results. Mandatory TLS testing takes a little longer since we have to try to send insecurely first.

Run Our Tests On Your Computers Or Website (WebServices)

Most CheckTLS tests are available as webservices. You can embed them into web pages on your site, or call them from your production systems.

WebServices: Put CheckTLS Tests On Your Website

You can embed our tests onto your website and make them look like your own tests. For example, the page you are reading has many of our tests embedded in it the same way as our customers embed these tests on their own sites. View the HTML and JavaScript source to this page for examples, and see our embed page for more information.

WebServices: Machine Readable Results (XML)

Healthcare companies that deliver results via email directly from their patient care systems can use our //email/testTo: ("TestReceiver") test stay HIPAA compliant. They program their RIS to call our webservice before emailing the result.

Verify Your Email End-To-End

CheckTLS can test your email system end-to-end, watching it receive a message and then turn around and send it back to us. We call this a "Batch Thru" test, and you can format the results many ways, but a typical result looks like:

You can get information about how your email system received the email, forwarded it, and sent it back, and how long each step took. The timing numbers are useful for monitoring the overall health of your email system.

See the next section below for more information about Batch testing, and the Thru section of the Batch Test documentation for specifics of the Thru test.

Check Lots Of Addresses At Once

You can send a "Batch" of addresses to CheckTLS and have them all tested. Batches have many uses: all your different email addresses, a group of important addresses you send to, the new vendors in your purchasing system, etc.

A Batch typically runs our //email/testTo: ("TestReceiver") on the list of addresses. All of the options available in //email/testTo: ("TestReceiver") can be tested in the Batch.

BatchTest results can be just a score:

or a pass/fail:

or show details:

See BatchTest Output for more results formats.

Schedule Repeated Testing

Batches can be stored on CheckTLS and scheduled to run regularly: monthly, weekly, daily, hourly, or any combination. The Batch can be programmed to only alert you if something changes. Protect yourself without signing up for a lot of useless noise.

Continuously Monitor Your Email

You can monitor scheduled batches so you know that silence is golden. When you set a Batch to only alert you if something changes, you need to protect against the Batch itself failing, not the thing(s) it was testing. Our Monitor webservice tells you when a Batch last ran and what it's result was. Hook this to Nagios, OpenView, Tivoli, etc. and know you tested your systems and they passed.

For example, we monitor our own email end-to-end every ten minutes checking this result: