//email/testFrom: ("TestSender") looks backward at the sending end of an Internet eMail transfer to test the software, server, or appliance that sends email to the Internet. These include the sendmail type devices mentioned in TestReceiver, and for most organizations it is the same device that receives Internet email. Just because it is the same device does not mean that if secure email is working in one direction it will also be working in the other direction. The two setups are very different.

TestSender is Important

It is the sender's responsibility to assure that confidential information is protected during email transport. The receiver's responsibility starts when they receive the information. Senders must make sure sensitive emails are encrypted.

CheckTLS TestSender is Unique

Several Internet sites will probe your email address. We know that CheckTLS is the most comprehensive, but all of these are looking at how you receive email.

Only CheckTLS has tests that look at how you send email. Our technology lets you create custom mailers that you can send to.

For example, if you program your mailer to deprecate TLS 1.0 (as you should), what exactly does your mailer do when it encounters an old email domain that only uses TLS 1.0? CheckTLS is the only site on the Internet that lets you build such an old mailer and send a message to it.

CheckTLS is the only site that can prove your mailer will enforce your sending rules. And how you send is more important than how you receive.

Using TestSender

Using //email/testFrom: is a two-step process.

//email/testFrom: cannot tell your email system "send me an email". You'll need to do that, and before you do, you have to tell //email/testFrom: it's coming, and you do that by starting a Listener.

TestSender Listener

If you are a CheckTLS Subscriber, you have a permanent Listener and unlimited access to //email/testFrom:. You can retrieve your permanent TS Passcode, which goes in the Subject: of your test emails and connects the email to your Listener, by opening your Subscription on the //subscription/edit:edit page.

Visitors to CheckTLS must browse to the //email/testFrom: page to start a Listener each time they want to test. Starting the Listener will generate a one-time TS Passcode that goes in the test email Subject: and connects the email to the Listener.

To start the test, send an email to test@TestSender.CheckTLS.com with your TS Passcode in the Subject: line. When your email system connects to CheckTLS to send us your email, //email/testFrom: answers instead and tests your sender as it sends the email.

As a convenience, the //email/testFrom: webpage has a link that will start the email on your PC with the proper To: and Subject:.

Before using //email/testFrom:, you should add CheckTLS.com to your list of allowed domains so the returned report is not inadvertently marked as spam.

Should you wish to include other text besides the one-time-use code in the Subject of your email, i.e. if you have subscribed to CheckTLS and are automating may tests, just enclose the one-time-use code (for subscribers, your permanent Sender Test passcode) in parenthesis, like this: Subject: Test number 12 (whizzywhig) on Tuesday

Automating TestSender

Since Subscribers have unlimited access to //email/testFrom: without visiting the //email/testFrom: page, they can automate Sender tests. Because there is no way for us to tell your email system to "send us an email", you automate Sender testing by telling your email system to automatically send an email to our //email/testFrom: address (see above). That starts the test, just as if you started it from the //email/testFrom: webpage.

See Batch Test, and especially the section on Batch Thru Test for a better way to automate Sender testing.

Saving the Results

Corporate Subscribers can choose to have their //email/testFrom: results saved on our webservers instead of being emailed back to the sending (i.e. tested) address. Use this when testing a sender that cannot (or should not) receive email, for example mailing lists, digests, LISTSERVs, pager notifications.

Understanding the Results

Results are emailed back to the address from which you sent the test email. The email shows whether or not the test was successful in the Subject: and also in the body of the text. This email is formatted in very simple html, so it is both readable even in non-html mailers and is also easily parsed by another computer or Excel.

Normal Result Email

The reply email looks like:

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

SUCCESSFUL //email/testFrom:

Your email was sent securely using TLS.

Failure Result Email

The reply email looks like:

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

FAILED //email/testFrom:

Your email was sent, however it was NOT SENT SECURELY using TLS.

Show Extra Items Result Email

If you Select Extra Items to Show when starting a Listener at //email/testFrom: the result email shows the fields you selected:

TLS Status
Show "Successful" or "Unsuccessful" (same as the email title, but easier to search/parse).
Text Result
Format the reply (result) email as text/plain (i.e. not HTML).
Email Headers
Show the From: Via: Date: and Subject: headers from the originating email.
SSL Version Used
Show the version of SSL used (SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2, TLSv1_3).
SSL Cipher Used
Show the cipher used (see openssl.org).
Cert Sent by Sender
Show the Cert sent by the client.
SNI Used By Sender
Show the SNI name used by the client.
SPF Info
Show SPF (Sender Policy Framework) lookup and result.
Show DKIM (DomainKeys Identified Mail) signature, lookup, and result.
Show DMARC (Domain-based Message Authentication, Reporting, and Conformance) lookup and result.
Show the entire SMTP (Simple Mail Transport Protocol conversation between your client and our server.
The conversation shows all of the commands and responses sent to and from the two servers as they transfer the email. In front of the log is a brief reminder of how to read it.
Any obvious errors found during the test are boxed in with asterisks so they're easy to find in the log: **************************************** *** ********** Error Note ********** *** *** *** *** Sender used HELO instead of EHLO *** **************************************** ****************************************

Tests that use the next two fields take ten or more minutes to finish because your emailer has to try to send it twice. You can only have one test running at a time or the "send twice" logic will report incorrect results.

Set SSL Version
Sets the version(s) of the SSL protocol that can be used: SSLv2, SSLv3, TLSv1, TLSv11, TLSv12, TLSv13, SSLv23 (SSL2.0, SSL3.0 and TLS1.x). All values are case-insensitive.
You can limit to set of accepted SSL versions by adding !version separated by ':', e.g. !TLSv1_1!TLSv1_2!TLSv1_3 to disable TLS versions 1.1, 1.2, and 1.3 while still allowing TLS version 1.0.
Set SSL Cipher List
Sets the list of Ciphers that can be used, e.g. something like 'ALL:!LOW:!EXP:!aNULL'. Look into the OpenSSL documentation for more details.

A reply email with all of the Extra Fields selected looks like:

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

SUCCESSFUL //email/testFrom:

Your email was sent securely using TLS.

Date:2019-03-28 18:34:38 EDT
ClientCert:Subject Name: /OU=Domain Control Validated/CN=*.checktls.com Issuer Name: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
SPF_mfrom.Record:v=spf1 a mx -all
SPF_mfrom:pass: local="yourdomain.com: is authorized to use 'yourdomain.com' in 'mfrom' identity (mechanism 'a' matched)"
SPF_helo:none: local="mailer.yourdomain.com: No applicable sender policy available"
DKIM:pass: signature="@yourdomain.com" result="pass"
DKIM_policy.sender:"o=~"(default), result="accept"
DKIM_policy.author:"o=~"(default), result="accept"
DKIM_policy.ADSP:""(default), result="accept"

(this email intentionally has limited formatting) The transcript of the eMail SMTP session is below, with: --> this is a line from your email system to us (~~> when encrypted) <-- this is a line to your email system from us (<~~ when encrypted) === this is a line about the tls negotiation (cypher, cert, etc) *** this is an error, warning, or info line that the test found <-- 220 ts6.checktls.com ESMTP TestSender Thu, 28 Mar 2019 18:34:38 -0400 --> EHLO mailer.yourdomain.com <-- 250-ts6.checktls.com Hello mailer.yourdomain.com [], pleased to meet you <-- 250-ENHANCEDSTATUSCODES <-- 250-8BITMIME <-- 250-STARTTLS <-- 250 HELP --> STARTTLS <-- 220 Ready to start TLS ==== tls negotiation successful ==== ~~> EHLO mailer.yourdomain.com <~~ 250-ts6.checktls.com Hello mailer.yourdomain.com [], pleased to meet you <~~ 250-ENHANCEDSTATUSCODES <~~ 250-8BITMIME <~~ 250 HELP ~~> MAIL FROM:<you@yourdomain.com> <~~ 250 Ok - mail from you@yourdomain.com ~~> RCPT TO:<test@TestSender.CheckTLS.com> <~~ 250 Ok - recipient test@TestSender.CheckTLS.com ~~> DATA <~~ 354 Send data. End with CRLF.CRLF ~~> DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=checktls.com; s=default; ~~> \011t=1553812478; bh=9SOurAJMztVjUzL/ObtwLNnUl4c=; ~~> \011h=From:To:Subject:Date; ~~> \011b=L6M3B8qd7tE8zcny0MB76iKVYCYWY8z9S3IWxqauP0cjR8fsNbeis2aB/+THCDG25 ~~> \011 v1fnSKuZnfD+jeN8vlWJWwN7aP/nwTTWNdf5XdNi8CdhIfctjUoW1ZXwT+sZpp3ffU ~~> \011 1/l0URxMaRSwukjK8hYHebPUTFObi95kscVZTcOI=TcOI= ~~> From: <you@yourdomain.com> ~~> To: <test@TestSender.CheckTLS.com> ~~> Subject: yourpasscode ~~> Date: Thu, 28 Mar 2019 18:34:38 -0400 ~~> ~~> onelinemessage ~~> . <~~ 250 Ok ~~> QUIT <~~ 221 ts6.checktls.com closing connection