On-line Real Time Email Authentication Testing and Verification Using CheckTLS

On-line Real Time Email Authentication Testing and Verification Using CheckTLS.

CheckTLS.com can test whether the Email Authentication Technologies that you have installed are correctly authenticating your email, and whether the Email Authentication Technologies you use to authenticate someone else's email are correctly deciding which emails are authentic and which are not.

Can the world tell that an email that purports to be from you is really from you, and can you tell that an email that comes from your trading partner is really from that trading partner?

While it is important to test any new security feature as you install and implement it, it is just as important to regularly verify that each security feature is still working and working correctly.

TL;DR; We describe how to test Email Authentication technologies in four areas:

Sender tells Receiver how to verify the Sender (Senders test their setup)
Receiver tells Sender how to verify the Receiver (Receivers test their setup)
Sender uses Receiver instructions to verify the Receiver (Senders test their response)
Receiver uses Sender instructions to verify the Sender (Receivers test their response)

The technologies testing described here are:

TLS (Transport Layer Security)
DNSSEC (Domain Name System Security Extensions)
SPF (Sender Policy Framework)
DKIM (DomainKeys Identified Mail)
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
BIMI (Brand Indicators for Message Authentication)
DANE (DNS-based Authentication)
MTA-STS (Mail Transfer Agent Strict Transport Security)
TLS-RPT (Transport Layer Security Reporting)

Email has two sides: Sender and Receiver. Each side can publish instructions for how the other side should authenticate it. And each side can follow the published instructions to authenticate the other. Here we provide instructions for how a Sender can test if they have correctly published (setup) one or more of the authentication technologies available to them, how a Receiver can test if they have correctly published (setup) one of more of the authentication technologies available to them, how a Sender can test if they correctly process (respond) a technology that a Receiver has published (setup), and how a Receiver can test if they correctly process (respond) a technology that a Sender as published (setup).

The table below shows for each email authentication technology, which side sets up the technology and which side checks the technology. Green background cells below are testable on CheckTLS and are described in the rest of this document. CheckTLS currently tests the "setup" sides and is working to add tests for the "respond" sides.

	who it protects	who checks it	what it does	Sender setup	Sender checks	Receiver setup	Receiver checks
TLS	Both	Both	encrypts (hides) email content, verifies Receiver's identity	enables TLS in their email system	that Receiver offers TLS	enables TLS in their email system	that Sender agrees to switch to TLS
DNSSEC	Both	Both	protects DNS records	enables DNSSEC		enables DNSSEC	that DNS records it fetches are authentically signed
SPF	Sender	Receiver	limits where email comes from	publishes DNS SPF record listing valid IP addresses		enables SPF	that email is coming from SPF listed IP address
DKIM	Sender	Receiver	protects email contents, verifies the Sender	publishes DNS DKIM record, signs outgoing email		enables DKIM	that the received email's signature is valid
DMARC	Sender	Receiver	prevents SPF or DKIM from being disabled, inform Senders of problems	publishes DNS DMARC record		enables DMARC	that either SPF or DKIM (or both) validated, report results to Senders
BIMI	Sender	Receiver	requires DMARC, gives reader a visual verification of authtication (Sender's logo)	uses DMARC, registers their logo, publishes DNS BIMI record pointing to the logo		enables BIMI	that email has BIMI header, DMARC passed, and logo is registered
DANE	Receiver	Sender	protects TLS	enables DANE	that the SSL Certificate sent by Receiver is authentic	publishes DNS TLSA records listing SSL Certificate requirements, uses DNSSEC
MTA-STS	Receiver	Sender	limits where email is sent to	enables MTA-STS	that it must use TLS and only sends email to servers listed in MTA-STS information	publishes MTA-STS information in DNS and HTTPS
TLS-RPT	Receiver	Sender	inform Receivers about issues with their TLS	enables TLS-RPT	reports any TLS problems to Receiver	publishes TLS-RPT record with how to send reports

What should Senders test?

Technologies used by Receivers (the entity getting an email) to verify Senders (the entity sending an email) include TLS, DNSSEC, SPF, DKIM, DMARC, and BIMI. For a Receiver to be able to use these, the Sender has to have set them up correctly. See below for how a Sender can test their TLS, DNSSEC, SPF, DKIM, DMARC, and BIMI setup: Senders test their setup.

The technologies used by Senders to verify Receivers include TLS, DNSSEC, DANE, MTA-STS, and TLS-RPT. For a Sender to use these, it must be configured to check each technology and told what to do if the technology cannot authenticate the Receiver. A Sender may still want to send the email even if it cannot authenticate the Receiver, for example because the email doesn't contain anything important or because the Sender has no other way to reach the Receiver. See below for how a Receiver can test how it handles failures of TLS, DNSSEC, DANE, MTA-STS, and TLS-RPT: Senders test their response.

What should Receivers test?

Technologies used by Senders (the entity sending an email) to verify Receivers (the entity that will get the email) include TLS, DNSSEC, DANE, MTA-STS, and TLS-RPT. For a Sender to be able to use these, the Receiver has to have sent them up correctly. See below for how a Receiver can test their TLS, DNSSEC, DANE, MTA-STS, and TLS-RPT setup: Receivers test their setup.

The technologies used by Receivers to verify Senders include TLS, DNSSEC, SPF, DKIM, DMARC, and BIMI. For a Receiver to use these, it must be configured to check each technology and told what to do if the technology cannot authenticate the Sender. A Receiver may still want to receive the email even if it cannot authenticate the Sender, but mark the email as suspect or move it to a special folder. See below for how a Sender can test how it handles failures of TLS, DNSSEC, SPF, DKIM, DMARC, and BIMI: Receivers test their response.

Senders test their setup.

TLS

TLS encrypts email contents and verifies the Receiver. For TLS to work correctly both Sender and Receiver have to have it enabled. Every modern email server has the capability to do TLS. Senders just need to turn it on.

To test if your Sender has TLS enabled, use the CheckTLS //email/testFrom: ("TestSender") test to see if your email system will use TLS to send an email. Follow the instructions to tell CheckTLS to listen for an email from you and exactly how to send that email. CheckTLS will email you back an email that says either "SUCCESSFUL...your email was sent securely using TLS", or "FAILED...your email was NOT SENT SECURELY using TLS".

You can view details about the TLS connection by opening the Select Extra Items to Show section of the CheckTLS //email/testFrom: ("TestSender") test and selecting the options for TLS Status, SSL Version Used, and SSL Cipher Used. Follow the instruction to send another email to CheckTLS and in the results email you will get from CheckTLS, look for lines like:


TLS:		Successful
SSLVersion:	TLSv1_3
SSLCipher:	TLS_AES_256_GCM_SHA384

DNSSEC

For all of the security features outlined here, DNS is used to provide one or more critical pieces of information necessary to make the feature work. DNSSEC (Domain Name System Security Extensions) protects DNS lookups from being removed, spoofed, altered, or extra answers added.

To test if your Sender has DNSSEC enabled, use the CheckTLS //email/testFrom: ("TestSender") test to see if the DNS lookups used to send email are protected by DNSSEC. Follow the instructions to tell CheckTLS to listen for an email from you and exactly how to send that email. Before starting the listener, expand the Select Extra Items to Show section and turn on Check DNSSEC. Your results, whether SUCCESS or FAIL, will show if DNSSEC protected with DNSSEC.

NOTE: the Check DNSSEC option is still in development at CheckTLS.com.

SPF

SPF verifies where an email comes from. To test if your Sender has SPF setup, use the CheckTLS //email/testFrom: ("TestSender") test to view your SPF record from DNS and check that a sent email comes from a server listed in that record. Add SPF to the test (under Select Extra Options to Show) and follow the instructions to run the test. In the results email you will get from CheckTLS, look for lines like (lines may wrap but each color should be a single line):


SPF   DNS     checktls.com   142.93.73.156,40.76.159.115,167.71.160.115
SPF   DNS     checktls.com   20 mail12-do.checktls.com.,10 mail11-do.checktls.com.
SPF   DNS     checktls.com   google-site-verification=AsgP5ibWfjEqqi7dy_fN_DWPtzfYcwn0ETAW96ICc04,"v=spf1 a mx a:whitelist.checktls.com a:spf.checktls.com -all",google-site-verification=AsgP5ibWfjEqqi7dy_fN_DWPtzfYcwn0ETAW96ICc04,"v=spf1 a mx a:whitelist.checktls.com a:spf.checktls.com -all"
SPF   DNS     default._domainkey.checktls.com   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkZxaMIXWH8NqafDS6Kzr6eNwlofpu+50Y+t9GpgXnCgt3mZTeoFr4kXcxNNfibzDHafcm8aT+Es3t1TOxlhYiqlyi60cVgRajwryRMkPCD4SvxU97V6gj5VFhfz1VtyaHUXYbJnGxShluWPa4AbXMmqey7dNDCPQKl5aOkILdPQIDAQAB"
SPF   DNS     mail11-do.checktls.com   134.209.47.28
SPF   DNS     mail12-do.checktls.com   104.131.118.193
SPF   DNS     spf.checktls.com   10.132.204.45,10.132.251.218,157.245.11.48,10.132.36.231,10.132.202.4,10.132.152.243,10.132.73.144,10.132.127.32,10.132.253.5,10.132.87.42,10.132.253.118,10.132.164.116
SPF   DNS     whitelist.checktls.com   134.209.169.224,104.131.168.30,142.93.73.156,104.131.118.193,167.71.160.115,134.209.47.28,40.76.159.115,165.227.190.238
SPF   helo    header   Received-SPF: none (www2-do.checktls.com: No applicable sender policy available) receiver=www2-do.checktls.com; identity=helo; helo=www2-do.checktls.com; client-ip=157.245.11.48
SPF   helo    local   www2-do.checktls.com: No applicable sender policy available
SPF   helo    result   none
SPF   helo    text   none (No applicable sender policy available)
SPF   mfrom   header   Received-SPF: pass (checktls.com: 157.245.11.48 is authorized to use 'checktls.com' in 'mfrom' identity (mechanism 'a:spf.checktls.com' matched)) receiver=www2-do.checktls.com; identity=mailfrom; envelope-from=checktls.com; helo=localhost; client-ip=157.245.11.48
SPF   mfrom   local   checktls.com: 157.245.11.48 is authorized to use 'checktls.com' in 'mfrom' identity (mechanism 'a:spf.checktls.com' matched)
SPF   mfrom   record   v=spf1 a mx a:whitelist.checktls.com a:spf.checktls.com -all
SPF   mfrom   result   pass
SPF   mfrom   text   pass (Mechanism 'a:spf.checktls.com' matched)

DKIM

DKIM "signs" an email to assure it is authentic and not changed. To test if your Sender has DKIM setup, use the CheckTLS //email/testFrom: ("TestSender") test to view your DKIM record from DNS and check that an email sent from you is properly signed. Add DKIM to the test (under Select Extra Options to Show) and follow the instructions to run the test. In the results email you will get from CheckTLS, look for lines like (lines may wrap but each color should be a single line):


DKIM    DNS         default._domainkey.checktls.com "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkZxaMIXWH8NqafDS6Kzr6eNwlofpu+50Y+t9GpgXnCgt3mZTeoFr4kXcxNNfibzDHafcm8aT+Es3t1TOxlhYiqlyi60cVgRajwryRMkPCD4SvxU97V6gj5VFhfz1VtyaHUXYbJnGxShluWPa4AbXMmqey7dNDCPQKl5aOkILdPQIDAQAB"
DKIM    POLICY      ADSP                            "" (default), result="accept"
DKIM    POLICY      author                          "o=~" (default), result="accept"
DKIM    POLICY      sender                          "o=-", location="checktls.com", result="accept"
DKIM    SIGNATURE   DETAIL                          pass
DKIM    SIGNATURE   IDENTITY                        @checktls.com
DKIM    result                                      pass

DMARC

DMARC verifies that either SPF or DKIM or both are working. To test if your Sender has DMARC setup, use the CheckTLS //email/testFrom: ("TestSender") test to view your DMARC record from DNS and check that an email sent from you passes either SPF or DKIM or both. Add DMARC and SPF and DKIM to the test (under Select Extra Options to Show) and follow the instructions to run the test. In the results email you will get from CheckTLS, look for lines like (lines may wrap but each color should be a single line):


DMARC      DNS         _dmarc.checktls.com             "v=DMARC1; p=quarantine"
DMARC      DNS         _domainkey.checktls.com         o=-
DMARC      DNS         checktls.com                    40.76.159.115,167.71.160.115,142.93.73.156
DMARC      DNS         checktls.com                    10 mail11-do.checktls.com.,20 mail12-do.checktls.com.,10 mail11-do.checktls.com.,20 mail12-do.checktls.com.,10 mail11-do.checktls.com.,20 mail12-do.checktls.com.
DMARC      DNS         checktls.com                    ns2-do.checktls.com.,ns1-do.checktls.com.
DMARC      DNS         checktls.com                    "v=spf1 a mx a:whitelist.checktls.com a:spf.checktls.com -all",google-site-verification=AsgP5ibWfjEqqi7dy_fN_DWPtzfYcwn0ETAW96ICc04,"v=spf1 a mx a:whitelist.checktls.com a:spf.checktls.com -all",google-site-verification=AsgP5ibWfjEqqi7dy_fN_DWPtzfYcwn0ETAW96ICc04
DMARC      DNS         default._domainkey.checktls.com "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkZxaMIXWH8NqafDS6Kzr6eNwlofpu+50Y+t9GpgXnCgt3mZTeoFr4kXcxNNfibzDHafcm8aT+Es3t1TOxlhYiqlyi60cVgRajwryRMkPCD4SvxU97V6gj5VFhfz1VtyaHUXYbJnGxShluWPa4AbXMmqey7dNDCPQKl5aOkILdPQIDAQAB"
DMARC      DNS         mail11-do.checktls.com          134.209.47.28
DMARC      DNS         mail12-do.checktls.com          104.131.118.193
DMARC      DNS         whitelist.checktls.com          165.227.190.238,134.209.47.28,134.209.169.224,104.131.118.193,104.131.168.30,142.93.73.156,167.71.160.115,40.76.159.115
DMARC      disposition                                 none
DMARC      dkim                                        pass
DMARC      dkim_align                                  strict
DMARC      dkim_meta   domain                          checktls.com
DMARC      dkim_meta   identity
DMARC      dkim_meta   selector                        default
DMARC      published   domain                          checktls.com
DMARC      published   p                               quarantine
DMARC      published   v                               DMARC1
DMARC      result                                      pass
DMARC      spf                                         pass
DMARC      spf_align                                   strict

BIMI

BIMI provides visual indication of an email's authenticity in your inbox. It displays the sender's logo next to any email from that sender if the email authenticates using BIMI rules. BIMI has several rules that an email and email sender must pass before the logo displays.

To meet the BIMI rules, a sender must:

create a logo in a specific form (square SVG) and register it
make the logo available at an https URL
use DMARC (which insludes SPF and DKIM)
specify a DMARC policy of quarantine or reject for 100% of their email
add a BIMI record to their domain's DNS
add a BIMI header to emails they send

To meet the BIMI rules an email must:

include a BIMI header
pass strict DMARC (which includes SPF and/or DKIM)
find the sender's BIMI record in DNS
find the sender's logo at the url in the BIMI DNS record

Receivers only display the sender's logo if the sender and the email meet all the rules. For the strictest BIMI (e.g. gmail), the sender must also get a Verified Mark Certificate, add it to their https webserver, and add it to their BIMI record in DNS.

To test if your Sender has BIMI setup, use the CheckTLS //email/testFrom: ("TestSender") test to view your BIMI record from DNS and check that an email sent from you has a proper BIMI header and passes strict DMARC. Add BIMI, SPF, DKIM, and DMARC to the test (under Select Extra Options to Show) and follow the instructions to run the test. In the results email you will get from CheckTLS, look for lines like (lines may wrap but each color should be a single line):


BIMI   domain   checktls.com
BIMI   header   v=BIMI1; s=default;
BIMI   values   bimi_object   n/a
BIMI   values   headers   BIMI_Indicator   ...stuff deleted...
BIMI   values   headers   BIMI_Location    v=BIMI1; l=https://www.checktls.com/images/checktlslogo.svg
BIMI   values   result   pass

Receivers test their setup.

TLS

To test if your Receiver has a TLS enabled with a good SSL Certificate, use the CheckTLS //email/testTo: ("TestReceiver") test to see if your email system will use TLS to receive email. Type just your domain name into the eMail Target field and change the Output Format to "Matrix", then click the Run Test button. In the resulting table, look at the TLS and Cert columns. If both say OK then you have TLS enabled and a good SSL Certificate.

DNSSEC

To test if your Receiver has DNSSEC enabled, use the CheckTLS //email/testTo: ("TestReceiver") test to see if the DNS lookups used to receive email are protected by DNSSEC. Type just your domain name into the eMail Target field and change the Output Format to "Detail". Expand the More Options section and turn on Check DNSSEC, then click the Run Test button. Scroll down past the inputs to the green results under Test Results. In the lookup section, any lines with a green "{DNSSEC}" on the right side were looked up in DNS and authenticated. Any lines with a red "{no DNSSEC}" were looked up in DNS but were not authenticated. Any lines with a red "unresolvable" were not found in DNS, for example:

[000.055]    	MX:A-->mail1.checktls.com	134.209.47.28{DNSSEC}
[000.059]    	MX:A-->mail1.nodnssec.com	104.131.118.193{DNSSEC}
[000.059]    	MX:A-->noentry.checktls.com	unresolvable {DNSSEC}
[000.059]    	MX:A-->noentry.nodnssec.com	unresolvable {DNSSEC}

DANE

DANE helps authenticate email by informing the Internet that "this domain uses TLS", and "this domain's SSL Certificate is signed by only this (these) CA(s)".

To test if your Receiver has DANE enabled, use the CheckTLS //email/testTo: ("TestReceiver") test. Type just your domain name into the eMail Target field and set the Output Format to "Detail". Expand the More Options section and turn on Check DANE, then click the Run Test button. Scroll down to the Results section to view the results matrix. If the DANE column shows a green OK then your email server has DANE setup correctly. If the DANE column shows a red error, then something is not setup correctly. Look through the greenbar detail results for clues to what could be wrong.

MX Server	Pref	TLS	Secure	DANE	Score
mail11-do.checktls.com [134.209.47.28:25]	10	OK (1ms)	OK (48ms)	OK	121.00
mail12-do.checktls.com [104.131.118.193:25]	20	OK (1ms)	OK (46ms)	no TLSA(s)	91.00
Average		100%	100%	50%	106

MTA-STS

MTA-STS helps authenticate email by informing the Internet that "this domain uses TLS", and "these are the only mail servers that receive email for me". While MTA-STS is similar to DANE, it uses HTTPS (web) rather than DNS to publish its information.

To test if your Receiver has MTA-STS enabled, use the CheckTLS //email/testTo: ("TestReceiver") test. Type just your domain name into the eMail Target field and set the Output Format to "Detail". Expand the More Options section and turn on Check MTA-STS, then click the Run Test button. Scroll down to the Results section to view the results matrix. If the MTA-STS column shows a green OK then your email server has MTA-STS setup correctly. If the MTA-STS column shows a red error, then something is not setup correctly. Look through the greenbar detail results for clues to what could be wrong.

MX Server	Pref	TLS	Secure	MTASTS	Score
mail11-do.checktls.com [134.209.47.28:25]	10	OK (1ms)	OK (48ms)	OK	121.00
mail12-do.checktls.com [104.131.118.193:25]	20	OK (1ms)	OK (46ms)	no _mta_sts DNS	91.00
Average		100%	100%	50%	106

TLS-RPT

Senders test their response.

TLS

TLS encrypts email contents and verifies the Receiver. To test what your Sender will do when a Receiver does not use TLS, use the CheckTLS //email/testMandatoryFrom: ("TestSenderAssureTLS") test to see if your email system will send an email without TLS. Follow the instructions to tell CheckTLS to listen for an email from you and then exactly how to send that email. CheckTLS will email you back an email with the test result. If it says "SUCCESSFUL...your email server would not fallback to insecure mode" then your Sender will not send email to a server that does not use TLS. If it says "FAILED...we received your Mandatory TLS mail without TLS" then your Sender will send email that is not protected by TLS.

NOTE: most email servers are configured to "get the email through no matter what", meaning this test will say FAILED. This is not a problem because you do want to receive (most) emails even if TLS is not working — you will silently miss about 3-5% of emails if you turn on so called "Mandatory TLS".

DNSSEC

No testing available yet.

DANE

No testing available yet.

MTA-STS

No testing available yet.

TLS-RPT

No testing available yet.

Receivers test their response.

TLS

TLS encrypts email contents and verifies the Receiver. To test what your Receiver will do when a Sender does not use TLS, use the CheckTLS //email/testMandatoryTo: ("TestReceiverAssureTLS") test to see if your email system will receive email without TLS. Type just your domain name into the eMail Target field and change the Output Format to "Matrix", then click the Run Test button. In the resulting table, look at the AssureTLS column. If it says OK then your Receiver will not accept email that is not protected by TLS. If it says FAIL, then your Receiver will accept email that is not protected by TLS.

DNSSEC

No testing available yet.

SPF

No testing available yet.

DKIM

No testing available yet.

DMARC

No testing available yet.

BIMI

No testing available yet.