Internet email, like the Internet itself, is designed to be robust and to work around problems. With email that means sending email in plain text if anything goes wrong with encryption. Today, unfortunately, that can be against policy, contract obligations, and might be illegal.
Email systems have responded with "Mandatory" (also called "Forced" or "Required") TLS. These systems let you maintain a list of domains that HAVE TO use encryption. If anything goes wrong with encryption, the email message will either wait and retry later or bounce back to the sender.
There are also in-line hardware devices and on-line services that you can route your email through to make sure everything is secure.
All of these options require on-going maintenance: keeping the list of domains up-to-date in your email Mandatory TLS settings, or hardware and software maintenance on in-line devices, or managing the on-line service. The devices and online services cost money as well.
Everything fails eventually, and these Mandatory TLS settings, devices, and services are no exception. Your security policies should include regularly testing that they are working as expected.
To test Mandatory TLS, you need an email system that does not work right: one where encryption fails, so you can be sure your "HAVE TO" have TLS stops the email message from sending or receiving.
In addition to the normal email tests, CheckTLS provides two "Mandatory" TLS tests. These simulate TLS failures and, like our other test, watch what your system(s) do.
Just the same as with normal secure email, we can quickly and easily make sure Mandatory encryption measures are working and continue to work. You can test almost everthing about email with CheckTLS.
Makes sure that the receiver will ONLY accept an email if it is sent securely. It makes sure the receiver will NOT accept an unprotected email.
While email security is mostly the responsibility of the sender, in a high security and/or privacy situation the receiver too has a responsibility to make sure the sender meets security requirements. RFC 3207, the Internet standard for TLS email, states "A publicly-referenced SMTP server MUST NOT require use of [TLS] in order to deliver mail locally." This implies that security conscious organizations have a normal email receiver for normal email (e.g. email@example.com) and a "TLS only" receiver for secure email (e.g. firstname.lastname@example.org).
TestReceiverAssureTLS does the same testing as TestReceiver, but it does not accept the receiver's invitation to use TLS. Instead, it tries to trick the receiver into receiving the email insecurely. TestReceiverAssureTLS is looking for the email transfer to fail, meaning the receiver will not receive email without protection. If the receiver accepts the email, the test fails; if the receiver rejects the email, the test succeeds.
Note: this test is only useful for sites that have setup "Mandatory TLS" to receive email from one or more domains. You should add "AssureTLS.CheckTLS.com" in your list of "Mandatory TLS" domains before running the test.
Makes sure that the sender will ONLY send an email if can be sent securely. It makes sure the sender will NOT send an unprotected email. RFC 3207, the Internet standard for TLS email, says the sender "must decide whether or not" to send email if the receiver will not do TLS. In high security and/or privacy situations there is no decision: the sender can never send insecure email.
TestSenderAssureTLS does the same testing as TestSender, but it does not offer, nor does it accept, TLS. Instead, it tries to trick the sender into sending the email insecurely. TestSenderAssureTLS is looking for the email transfer to fail, meaning the sender will not send email without protection. If the sender does send the email, the test fails; if the sender refuses to send the email, the test succeeds.
Using TestSenderAssureTLS is similar to TestSender, except the address you send to is test@TestSenderAssureTLS.CheckTLS.com. A correctly configured sender will eventually give up without sending the mail and either bounce it or queue it to retry later. TestSenderAssureTLS does wait up to 30 minutes in case the sender tries to send the message again, so it can "accept" it and prevent it from trying over and over and eventually bouncing it back to you. It simply throws the second attempt away.
Note: this test is only useful for sites that have setup "Mandatory TLS" to send mail to one or more domains. You should add "AssureTLS.CheckTLS.com" to your list of "Mandatory TLS" domains before running the test. You should also add CheckTLS.com domain to your regular list of allowed domains so the returned report is not inadvertently marked as spam. See Basic Sender Test for how to use this test and the test code provided.