Email Has Many Parts

Email started as a way for anybody, as themselves or as someone else, to send anything to anyone else, who could also be themselves or someone else. It was very simple with just two parts: a sender and a receiver. Now email is a vital communication medium that is mature enough to allow reliable communication between trusted parties. It has lots of parts that encrypt, autenticate, sign, and otherwise protect it.

TL;DR; Email works most of the time, but it does break. The modern security measures bolted onto Email increase the number of “moving parts”, which increases the likelihood that something will break. More parts is more overall functionality but also more things to break. If you rely on email and care about email security, you should be checking that everything is working. CheckTLS can do the checking.
Jump straight to the how to below.

Are All The Parts Working

CheckTLS started as a way for a healthcare provider to check, as they were about to email a test result, that they could legally send Protected Health Information (PHI) to that email recipient.

CheckTLS quickly evolved to be more proactive: to check ahead of time that email addresses, and whole email systems, were compliant with all the legal and regulatory requirements surrounding PHI, PII (Personally Identifiable Information), PCI (Payment Card Information), etc.

Specific CheckTLS Tests: CheckTLS can test almost everything there is about email and email security. Users can create tests that target:

Automate CheckTLS Tests: A test, what we call a "Batch", can be programmed to probe specific targets and query specific features, and multiple Batches can be stored on CheckTLS.

Monitor CheckTLS Tests: Batches can be scheduled to run daily or weekly, and they can be instructed to only alert the user if something changed or failed.

Specific CheckTLS Tests

CheckTLS can test how you send and receive email. See Quick Tests on the homepage.

CheckTLS can test modern email security and privacy, and authentication technologies such as TLS, DNSSEC, SPF, DKIM, DMARC, BIMI, DANE, MTA-STS, TLS-RPT. See On-line Real Time Testing.

CheckTLS can test and email system "end-to-end", meaning from when an email is first being sent to when it is finally received. See testthru in the About Batch documentation.

You can extract specific details about your email system such as your MTA-STS policy details, results of DNS lookups for MX, MTASTS, and TLSA records, or such details for individual MX hosts in your email cluster. CheckTLS provides test results in XML so you can extract a specific detail, for example the SSL Version is shown as <SSLVersion>TLSv1_3</SSLVersion>.

Automate CheckTLS Tests

CheckTLS tests can be written as programs and stored on our servers. Almost every test that you can design on the interactive website can be programmed in XML and saved. We call a saved XML program a Batch.

These XML Batches can be run on demand or scheduled to run periodically. Results can be emailed or fetched from unique URLs. The XML program can define when to send results, for example to only send an email if something failed.

Monitor CheckTLS Tests

Beyond defining when to send results, CheckTLS Batches can be monitored directly. The XML program can define what "success" is, for example a minimum score or TLS version. Users can then use a WebService to monitor the Batch for success.

The CheckTLS monitor feature is designed to be fail-safe. We allow you to tell the difference between a CheckTLS failure a test failure. There is nothing for you to do if we cannot perform a test, but you certainly want to know if we were able to perform the test and it found a problem. See How To Monitor for step-by-step instructions on how to setup a simple Batch and monitor it.

Vagaries

Because of the way the Internet works, CheckTLS tests can return a different result for identical tests. We use the term Vagaries to describe this effect.

At its most basic level, the Internet is unreliable. Deliberately so -- it uses redundancy and higher level protocols (See OSI Model) to construct a system that is very reliable.

CheckTLS probes one facet of the Internet, that is email, very deeply. Our tests look behind the redundancies and error corrections to show details about email systems. We see failures and issues that would be corrected before they would be noticed by users.

This leads to two results: One, CheckTLS can find small weaknesses and failures that are not noticable. Two, CheckTLS tests are susceptable to the aforementioned Vagaries.

When CheckTLS tests a system that would error-correct, our test will show the error, not the auto-correction. Which means that the same test, done a minute later, might return a different result as various Internet parts reset.

A Real-World Example

Mimecast

Mimecast is a large email outsource company. They do the email for thousands of companies, and they take email security very seriously. Because they are so large, and because they require reliability, they have upwards of 20 MX hosts for any one client. (You can see this by testing one of the case study clients Mimecast lists on their homepage.)

Mimecast has whitelisted CheckTLS so that our clients can check their own email as hosted by Mimecast. Otherwise the barrage of tests to all their MX hosts at once would trigger them to an attack. And Mimecast certainly uses CheckTLS at times for an outside look at their systems. Thank you, Mimecast!

If any one of these MX hosts gets busy or has a glitch of any kind, it will stop receiving email, telling a sender "try again". When the sender tries again, they will likely get a different MX host that is working better. This is exactly how email is supposed to work and it's why Mimecast has multiple MX hosts. Anyone checking would say "email is working", even if one MX has a problem.

But what if one MX has a real issue, not just a temporary busy or glitch? Email is still working fine -- all the other MX hosts are picking up the traffic. A monitoring tool checking that emails are getting through will report that all is well. But the techs at Mimecast need to know that one of their MX hosts is failing.

That is where the testing that CheckTLS does is valuable. Our tests do not do the "retry" thing. They show in real-time what is going on. This lets the techs at Mimecast use CheckTLS to look deeper into their email system to see the status of every MX host. When a failure occurs, the tech can refresh the screen and see if the problem was just a random glitch or is a permanent problem.

Monitoring Mimecast

Of course, Mimecast certainly has a better monitoring system than a tech sitting at a PC clicking refresh on a CheckTLS test. But let's explore how Mimecast could use CheckTLS to monitor their email infrastructure.

Check Each Host

Mimecast could write a test (see Batch Test) that tests each MX host. This would look like: <BatchTest TestType="receiver"> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.177</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.221</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.242</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.141</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.145</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.181</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.102</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.107</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">207.211.30.237</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.221</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.242</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.141</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.145</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.181</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.102</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.107</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">170.10.128.144</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">170.10.128.225</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">170.10.128.245</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">205.139.110.144</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">205.139.110.225</Target> <Target SNI="us-smtp-o365-outbound-1.mimecast.com">205.139.110.245</Target> <Delivery> <To>checktls@mimecast.com</To> <Format>text</Format> </Delivery> </BatchTest>

When everything is working perfectly this test would return one line for each MX host showing the score (ConfidenceFactor) and IP address: 114 205.139.110.177 114 207.211.30.221 114 207.211.30.242 114 207.211.30.141 114 207.211.30.145 114 207.211.30.181 114 207.211.30.102 114 207.211.30.107 114 207.211.30.237 114 205.139.110.221 114 205.139.110.242 114 205.139.110.141 114 205.139.110.145 114 205.139.110.181 114 205.139.110.102 114 205.139.110.107 114 170.10.128.144 114 170.10.128.225 114 170.10.128.245 114 205.139.110.144 114 205.139.110.225 114 205.139.110.245

Obviously any MX host that doesn't score 114 is suspect.

While they may want an email every day with all the results, if they are a little less paranoid they might only want to get an email if one or more hosts have a problem. A BatchTest can have logic to suppress the email if all the targets are OK. This would look like: <BatchTest TestType="receiver"> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.177</Target> ... lines deleted ... <Target SNI="us-smtp-o365-outbound-1.mimecast.com">205.139.110.245</Target> <Delivery> <To>checktls@mimecast.com</To> <Format>text</Format> <Suppress Function="minimum" Test="ge" Value="114" /> </Delivery> </BatchTest>

This test would only send an email if one or more targets scored less than 114 (i.e. suppress if minimum is greater than or equal to 114)

Only See Problem Hosts

The above test can be rewritten to only output hosts that do not score high enough: <BatchTest TestType="receiver"> <Target SNI="us-smtp-inbound-1.mimecast.com"><Suppress Function="minimum" Test="ge" Value="114"/>205.139.110.177</Target> ... lines deleted ... <Target SNI="us-smtp-o365-outbound-1.mimecast.com"><Suppress Function="minimum" Test="ge" Value="114"/>205.139.110.245</Target> <Delivery> <To>checktls@mimecast.com</To> <Format>text</Format> </Delivery> </BatchTest>

If there were no problems, there would be no output.
But if the SSL certificate on the second MX host expired, and that was the only problem on any MX host, the output of this test would be: 112 207.211.30.221

The above test shows the suppress node on every target line, but BatchTest allows you to list the suppress node once and have it included on every line: <BatchTest TestType="receiver"> <Target><Suppress Function="minimum" Test="ge" Value="114"/>DEFAULT</Target> <Target SNI="us-smtp-inbound-1.mimecast.com">205.139.110.177</Target> ... lines deleted ... <Target SNI="us-smtp-o365-outbound-1.mimecast.com">205.139.110.245</Target> <Delivery> <To>checktls@mimecast.com</To> <Format>text</Format> </Delivery> </BatchTest>

Other Options

The above test can be rewritten in other ways to alert techs to problems. Rather than just showing a decreased score, the test could be programmed to pull out specific issues like certificate expiration, host unreachable, DNS problem, etc. Testing could include adding MTA-STS and DANE tests to each host or tracking their response time. Beyond failures, test can be programmed to warn when an SSL Certificate is close to its expiration date. See the documentation on Batch Tests throughout the CheckTLS site for more information.