• |email
  testTo: testFrom: testMandatoryTo: testMandatoryFrom:
• |cloud
  packet sniffer decode ssl cert make your own ssl cert decode CSR show our CA list show our Ciphers list
• |help
  contact us about us terms of use privacy policy authentication tests Mandatory TLS saving tests (Batch) baselining monitoring API site map HIPAA/GDPR how-to
• |subscription
  login about Subscriptions subscribe via PayPal one-time PayPal Subscription quote new Subscription setup & bill new Subscription
• |faq
• |
• |
• | |

How CheckTLS Tests are Organized

Each CheckTLS test is associated with one of two email "modes" — sending email or receiving email (the exceptions to this rule are the TLS, the DNSSEC, and the FCrDNS tests, which are associated with both email modes). CheckTLS has labeled the two modes "TestReceiver" and "TestSender". TestReceiver tests the security of receiving email servers. TestSender tests the security of sending email servers.

These two test modes (TestReceiver and Testsender) each test multiple Email Security Technologies. The technologies are shown below, and each technology is linked to a detailed explanation, below, of how a test mode (TestReceiver or TestSender) tests that technology and the results that the testing produces.

To help CheckTLS users remember whether they are testing a receiving email server or a sending email server, the testing options listed when the CheckTLS website's "email" main menu item is clicked are labeled "testTo:" for TestReceiver tests (the user is testing the server that receives email sent To: it), and labeled "TestFrom:" for TestSender tests (the user is testing the server that sends email sent From: it).

How to Run the TestReceiver CheckTLS Tests

When you select "TestTo:" option from the CheckTLS website's "email" main menu item, you are brought to the TestReceiver webpage. The "Input Fields" dialog box, shown below, is where you specify and configure which technologies you want TestReceiver to test in the receiving email server (the "eMail Target:" in the dialog box). Clicking the "More Options (MTA-STS, ...)" text expands the dialog box to display all of the TestReceiver tests that can be performed when the "Run Test" button is clicked.

Only the upper portion of the expanded "More Options (MTA-STS, ...)" is shown in the image above — there are many more options that can be included when you run TestReceiver. When you expand the "More Options (MTA-STS, ...)" you won't see an option to test TLS. That is because the TestReceiver automatically tests TLS every time it is run. Before you run TestReceiver, be sure that you have entered an email domain (preferred), a full email address (e.g. user@company.com), or an individual email server (hostname or ip address) in the "eMail Target" entry line. Leave the "Output Format" set to "Detail" so that you can view all of the results that get returned when TestReceiver is run. If you want to understand what each Input Field Option means and how it is used, click the "Instructions/Info" link located above the "Input Fields" label. A link to the complete documentation for TestReceiver will be provided.

THE RESULTS OF YOUR TestReceiver TESTING WILL BE DISPLAYED ON-SCREEN IN THE SECTION OF THE WEBPAGE LABELED "Test Results".

How to Run the TestSender CheckTLS Tests

When you select the "testFrom:" from the CheckTLS website's "email" main menu item you are brought to the TestSender webpage. The "Input Fields" dialog box, shown below, is where you specify and configure which technologies you want TestSender to test in your email server.

Because TestSender tests the security of your email server, there is no eMail Target: entry line for TestSender (like there is for TestReceiver tests). The "target" of TestSender tests is your sending email server. In order for CheckTLS to be able to test the security of your email server, you must send us a specially-crafted email using an email account on the email server whose security you wish to test. If you have multiple sending email servers, you must run TestSender tests, and therefor send us an email, from each server. Like TestReceiver, TestSender automatically tests the status of TLS. Clicking the "Select Extra Items to Include in Test" text displays a list of individual Email Security Technologies that can be tested with each TestSender run.

In the image above, TestSender will display results for the selected TLS, SPF, DKIM, DMARC, FCrDNS, BIMI, and DNSSEC technologies. The technologies you select are specified in the specially-crafted email (explanation of the email is in the next paragraph) that you send to us that initiates TestSender testing. Once a TestSender test has completed, we send the result of the test back to you in a Reply email. If you want to understand what each Input Field Extra Item means and how it is used, click the "Instruction/Info" link located above the "Input Fields" label. A link to the complete documentation for TestSender will be provided.

What is the Listener and why do I have to start it? The Listener is started on our CheckTLS TestSender servers, not on your email server. It listens for the specially-crafted email that you send to our TestSender servers. When you send the specially-crafted email, our Listener detects that the your email is being transmitted to us and we perform the TestSender tests. We use the information contained in the email to tell us how to report the results of our tests back to you. When you click the "Start Listener" button, two things happen:

1. The Listener is started on our CheckTLS TestSender servers
2. Instructions for creating the specially-crafted email are displayed on your computer (you may have to scroll down to view the instructions)

If your MAILTO: app has been associated with an email client, you can create the specially-crafted email automatically by clicking the "Click here to create the email" text near the bottom of the instructions. This will automatically start a new email and pre-populate it with the correct specially-crafted message, which will include:

From:

set to your default email account

To:

set to test@TestSender.CheckTLS.com

Subject:

unique password for just this one test

text strings

that indicate the "Select Extra Items to Include"

default body text

"This is a test message."

This is the specially-crafted email.

NOTE: If you have not associated an email client with MAILTO: links on webpages, some versions of Windows will automatically associate your Microsoft account email address with MAILTO: links on webpages if you click any MAILTO: link, including our "Click here to create the email" link.

If you do not want to use this default association, you can change the MAILTO: app to another email client by navigating to Settings>Apps>Default apps>Choose defaults by link type. Scroll down to the MAILTO: tile and click it.

If you do not have an email client associated with MAILTO: links on webpages, you will need to create the specially-crafted email manually. Start a new email that will be sent from an email account on the email server you want TestSender to test (the "From:" address in your email). Use the exact same values displayed in the instructions for the To:, Subject:, and email body.

When your specially-crafted email is complete, SEND it. Check your inbox in a minute or two for a Reply from our TestSender server with the results of your TestSender test. If the Reply email doesn't show up in your inbox, check your spam folder (and whitelist CheckTLS in the future if you know how). If the email does not show up anywhere, you can see if your email system "bounced" our results message by clicking the "HERE" link in the "check your logs for a bounce from your domain HERE" text at the very bottom of the instructions for creating the specially-crafted email page.

Viewing CheckTLS Test Results

Located at the end of this blog post are examples of the results produced by TestReceiver and TestSenter tests for the checktls.com website. We've included these example test results so that you can see exactly what your test results will look like (obviously with your data). As a reminder, the test results for TestReceiver tests will be presented on-screen shortly after you click the "Run Test" button. The test results for TestSender tests will not be displayed on-screen but will be retuned to you in a Reply email to the specially-crafted email that you send us.

In the following sections of this document the individual Email Security Technologies that are tested with the TestReceiver and TestSender email modes are explained in detail. In the explanation for each Email Security Technology there will be at least one "See It Below" button present. When clicked, the "See It Below" button will highlight (in a vivid blue color) the test results that are produced by the CheckTLS test that the "See It Below" button is associated with. An individual TestReceiver or TestSender run may test multiple Email Security Technologies. NOTE: When you click the "See It Below" button, your browser will display a small window with a message that says "(x) lines marked in results." This tells you how many lines are highlighted in the example test results so that you know how many test details to look for.

Because an individual TestReceiver or TestSender run may test multiple Email Security Technologies, and those highlighted results may be located far apart in the example checktls.com test results located at the end of this webpage, you will have to manually scroll the webpage down to veiw the highlighted test results.

If you find it inconvenient to keep scrolling down and then finding your place back above, this document can be opened in two side-by-side windows, with the second window only displaying the example checktls.com test results. This enables you to keep your place where you are reading on the "Using CheckTLS" web page while being able to use the second web page (we call it a "Second Window") to view highlighted test results. To open a second web page that displays example checktls.com TestReceiver and TestSender test results click the "Second Window" button, below.

Second Window

TestReceiver CheckTLS Email Security Technologies

How to test each of the individual Email Security Technologies that TestReceiver can test is described in detail below. As a reminder, TestReceiver tests are performed on receiving email servers. TestReceiver reports on how well an email server that receives your email implements an Email Security Technology.

Receiving Server: TLS (Transport Layer Security) Test

TestReceiver tests the degree to which receiving email servers use TLS.

Recall that TLS does three things: 1.) It encrypts the contents of an email so that the contents cannot be understood by any human or machine. 2.) It protects the contents from being altered so that the recipient receives exactly what the sender sent, and 3.) It authenticates that the receiving email server is allowed to receive email for the domain(s) that are present in the receiver's email address(es).

When you click the TestReceiver test's "Run Test" button, CheckTLS testss the TLS implementation of each email server specified by the "eMail Target" field. If the "eMail Target" has MX records attached to it in DNS, CheckTLS will check every email server that the recipient organization says can receive email (a recipient organization may have more than one receiving email server specified by its domain DNS MX record(s)). The results of the test can be displayed in real-time as the probing is performed. Once all probing is complete, the page is scrolled back to the top where a summary of the test results are displayed. The results page has a lot more information than just the summary of the tests results, but for TLS the important result on the test results page is the column in the summary labeled "TLS", which shows either "OK" or "FAIL".

When you ran the TestReceiver test, if you kept the "Output Format" field set to its default value of "Detail", you can scroll down the results page and see what information CheckTLS used to determine the status of TLS. So what should you look for in the Details to determine the quality of the receiver's TLS implementation?

TLS is used Check that TLS could be started. See It Below

Certificate Validity Check that every certificate is:

• not expired (or not too early either) See It Below
• signed by a trusted Certificate Authority (CA) (may use Intermediate Certificate(s)) See It Below
• not revoked See It Below

Site Certificate Details Check that the first certificate has a:

• Common Name (CN) or Subject Alternative Name (SAN) that matches the server's domain name See It Below
• Algorithm & Key length that is RSA & 2048 bits or more, or ECC (e.g. P-256) and 256 bits or more. (Avoid outdated algorithms like SHA-1 or MD5.) See It Below
• complete certificate chain to the trusted Certificate Authority (CA) See It Below

Protocol & Cipher Strength Check that the TLS connection has:

• Protocol version TLS 1.2 or higher. (Reject SSLv2, SSLv3, TLS 1.0, TLS 1.1) See It Below
• Strong ciphersuites, e.g. AES-GEM, ChaCha20-Poly1305. (Avoid weak ones like RC4, 3DES, NULL, EXPORT.) See It Below
• Forward secrecy. Look for ECDHE/DHE key exchange. See It Below

We encourage users to review the TestReceiver Documentation to learn what the individual Detail test results mean and more about what CheckTLS can do.

CheckTLS Testing DNSSEC (Domain Name System SECurity Extensions) for receiving email

Recall that DNS is a critical component of all the Email Security Technologies, and DNS is used by both Senders and Receivers in protecting and delivering email. Both the CheckTLS //email/testTo: ("TestReceiver") test and the CheckTLS //email/testFrom: ("TestSender") test can test their respective target's (sending or receiving) DNSSEC.

To test DNSSEC for how your DNS answers DNS queries that are used by email senders, use the CheckTLS //email/testTo: ("TestReceiver") test. Use the TestReceiver instructions above to test (Target) your own domain and select the DNSSEC option to see what an email sender will get when doing DNS queries for your domain.

In the TestReceiver output, CheckTLS reports on the status of DNSSEC on every DNS lookup that an email sender performs when sending email to your domain. See It Below

CheckTLS Testing FCrDNS (Forward-Confirmed Reverse DNS) for receiving email

Recall that FCrDNS is a two-step verification process used by mail server (like Gmail and Outlook) to prove that a sending IP address is legitimately associated with its claimed domain name. It is a highly-effective anti-spam measure. Both the CheckTLS //email/testTo: ("TestReceiver") test and the CheckTLS //email/testFrom: ("TestSender") test can test their respective target's (sending or receiving) FCrDNS.

To test FCrDNS for how hosts are configured for DNS queries that are used by your email receiver, use the CheckTLS //email/testTo: ("TestReceiver") test. Use the TestReceiver instructions above to test (Target) your own domain and select the FCrDNS option.

In the TestReceiver output, CheckTLS reports on the status of FCrDNS on every DNS lookup that an email sender performs when sending email to your domain. See It Below

CheckTLS Testing MTA-STS (Strict Transport Security)

Recall that Receivers use MTA-STS to announce that anyone sending email to them must use TLS, which both encrypts and authenticates the Receiver, and that email can only only be sent to specific hosts (MX). This makes it harder for a bad actor to redirect email intended for the Receiver.

To verify that your MTA-STS (Mail Transfer Agent Strict Transport Security) is set up correctly, use the CheckTLS //email/testTo: ("TestReceiver") test. Use the TestReceiver instructions above to test (Target) your own domain and select the MTA-STS option to see what an email sender will get when checking your MTA-STS.

CheckTLS reports if your MTA-STS is correct right at the top of the result in the Matrix section:

In checking if your MTA-STS is correct, CheckTLS looks at:

• MTA-STS DNS Record: Verifies that you have the appropriate DNS TXT record for your domain to indicate that you are using MTA-STS. It should look something like: _mta-sts.<yourdomain>. IN TXT "v=STSv1; id=20231015T000000Z;"
• MTA-STS Policy File (mta-sts.txt):
  • Verifies that you have an MTA-STS policy file, usually named mta-sts.txt, hosted at a specific location: https://mta-sts.<yourdomain>/.well-known/mta-sts.txt This file must be accessible using HTTPS without any errors.
  • Verifies the contents of the mta-sts.txt file, something like: version: STSv1 mode: enforce mx: mail.<yourdomain> ttl: 86400 The mode can be one of enforce, testing, or none. enforce is recommended for full security.
• MX Records: Verifies that your MX records (Mail Exchanger records) are set correctly for your domain. The MX records should point to the correct mail servers, which should match what's specified in your MTA-STS policy file (mx: field).
• Certificate Verification: Verifies that your mail servers have valid, trusted SSL/TLS certificates.

See It Below

CheckTLS Testing DANE (DNS-based Authentication of Named Entities)

Recall that Receivers use DANE to identify what SSL certificate(s) are valid for the Receiver's domain. It is a way to authenticate TLS entities without a Certificate Authority (CA), or to limit what CAs are trusted. This makes it harder for a bad actor to receive email intended for the Receiver.

To verify that your DANE (DNS-based Authentication of Named Entities) for SMTP is setup correctly, use the CheckTLS //email/testTo: ("TestReceiver") test. Use the TestReceiver instructions above to test (Target) your own domain and select the DANE option to see what an email sender will get when checking your DANE.

CheckTLS reports if your DANE is correct right at the top of the result in the Matrix section:

In checking if your DANE is correct, CheckTLS looks at:

• MX Records: Verify that your domain has valid MX records:
  • pointing to the correct mail servers
  • MX hosts have valid A/AAAA records
• DNSSEC: Verify that your DNS is signed correctly for your domain and your MX hostnames.
• TLSA Records: Verify that the DANE DNS TLSA records exist for all MX hostnames and are correct: _25._tcp.mail.example.com. IN TLSA 3 1 1 5e2b8b79c406a4a2e5d51f77d1bb8f2ed67e36d8e232ef09acb9e2fda88a0b0f
• MX Certificate matches TLSA record:
  • Verify that the certificate is valid (not expired, name matches).
  • Verify that the public key or certificate fingerprint matches the TLSA record hash.
• STARTTLS Support: Verify that TLS is supported and enabled

See It Below

CheckTLS Testing TLS (Transport Layer Security) for sending email

Recall that TLS does three things: It encrypts the contents of an email, making it so the email contents can not be seen by any human or machine. It protects the contents from being altered, so that the recipient gets exactly what the sender sent. And it authenticates that the server to which the receiver is preparing to send the email is allowed to receive email for the domain in the email address.

The CheckTLS //email/testFrom: ("TestSender") test is used to test a Sender’s TLS. By default TestSender tests TLS. Use the TestSender instructions above to select any additional TLS options, like SSL Versions and Ciphers, and then display the TestSender Setup Page. This link will go to the TestSender page and bring up the TestSender Setup Page for you.

In checking if your Sender TLS is correct, CheckTLS looks at whether or not it could establish a valid SSL/TLS connection to receive the test email that you send to CheckTLS.

Because the primary purpose of TestSender is to test TLS, the result is reported as success or failure; success meaning a SSL/TLS connection was used to receive your email, and failure meaning CheckTLS could not establish a good SSL/TLS connection with your server. See It Below

If you selected any additional TLS options before starting the test email to CheckTLS, these are reported along with the success or failure message. See It Below

CheckTLS Testing DNSSEC (Domain Name System SECurity Extensions) for sending email

Recall that DNS is a critical component of all the Email Security Technologies, and DNS is used by both Senders and Receivers in protecting and delivering email. Both the CheckTLS //email/testTo: ("TestReceiver") test and the CheckTLS //email/testFrom: ("TestSender") test can test their respective target's (sending or receiving) DNSSEC.

To test DNSSEC for how your DNS answers DNS queries that are used by your email sender, use the CheckTLS //email/testFrom: ("TestSender") test. Use the TestSender instructions above to select the DNSSEC option and display the TestSender Setup Page. This link will go to the TestSender page, select the FCrDNS option, and bring up the TestSender Setup Page for you.

In the TestSender output, CheckTLS reports on the status of DNSSEC on every DNS lookup that an email receiver performs when receiving email from your domain. See It Below

CheckTLS Testing FCrDNS (Forward-Confirmed Reverse DNS) for sending email

Recall that FCrDNS is a two-step verification process used by mail server (like Gmail and Outlook) to prove that a sending IP address is legitimately associated with its claimed domain name. It is a highly-effective anti-spam measure. Both the CheckTLS //email/testTo: ("TestReceiver") test and the CheckTLS //email/testFrom: ("TestSender") test can test their respective target's (sending or receiving) FCrDNS.

To test FCrDNS for how hosts are configured for DNS queries that are used by your email sender, use the CheckTLS //email/testFrom: ("TestSender") test. Use the TestSender instructions above to select the FCrDNS option and display the TestSender Setup Page. This link will go to the TestSender page, select the FCrDNS option, and bring up the TestSender Setup Page for you.

In the TestSender output, CheckTLS reports on the status of FCrDNS on every DNS lookup that an email receiver performs when receiving email from your domain. See It Below

CheckTLS Testing SPF (Sender Policy Framework)

Recall that Senders use SPF to list the IP addresses of the servers that can send email for the Sender’s domain. Any email that does not come from one of those listed servers is suspect and is almost certainly “bad”.

The CheckTLS //email/testFrom: ("TestSender") test is used to test a Sender’s SPF. Use the TestSender instructions above to select the SPF option and display the TestSender Setup Page. This link will go to the TestSender page, select the SPF option, and bring up the TestSender Setup Page for you.

SPF checks can be performed against the MAIL FROM (or Return-Path) domain and/or the HELO/EHLO hostname. CheckTLS reports if your SPF is correct for both of these checks: SPF mfrom result pass SPF helo result pass The SPF MAIL FROM check is better at checking the validity of an email because it looks at the physical IP address from which the sender is connecting and not the IP address from where the sender says it is connecting. Typically an SPF check will try the MAIL FROM first and then if that is missing it will try the HELO/EHLO.

In checking if your SPF MAIL FROM is correct, CheckTLS looks at:

• SPF DNS: record(s) exist for the domain in the MAIL FROM and are correctly formatted.
• IP address: did the connection from the sender come from an IP address listed in the SPF DNS record(s).

See It Below

In checking if your SPF HELO/EHLO is correct, CheckTLS looks at:

• SPF DNS: record(s) exist for the hostname in the HELO/EHLO SMTP command and are correctly formatted.
• IP address: did a DNS lookup of the HELO/EHLO hostname match an IP address listed in the SPF DNS record(s).

See It Below

CheckTLS Testing DKIM (DomainKeys Identified Mail)

Recall that Senders use DKIM to make sure your domain's outgoing email is properly authenticated and trusted by receiving mail servers. The CheckTLS //email/testFrom: ("TestSender") test is used to test a Sender’s DKIM. Use the TestSender instructions above to select the DKIM option and display the TestSender Setup Page. This link will go to the TestSender page, select the DKIM option, and bring up the TestSender Setup Page for you.

Every DKIM setup begins with a selector (e.g., selector1) and a corresponding DNS TXT record at: selector1._domainkey.yourdomain.com. In checking if your DKIM is correct, CheckTLS looks at:

• DKIM DNS TXT record: Verify that your domain has a valid DKIM DNS TXT record: See It Below
  • exists at the proper lookup, e.g. selector1._domainkey.yourdomain.com
  • is properly formatted and accurate with these fields:
    • v=DKIM1 (version)
    • k=cryptotype (the cryptographic key type used to sign)
    • p=publickey (the public key of the private key used to sign your email)
• emails are signed: See It Below
  • adds an RFC-822 email header: "DKIM-Signature"
  • header is properly formatted and accurate with these fields:
    • v=1 (version)
    • a=algorithm (uses a modern algorithm, e.g. rsa-sha256)
    • c=canonicalization (the canonicalization algorithm used to generate header hashes, usually "relaxed")
    • d=yourdomain (matches your domain)
    • s=selector (matches a selector in a DKIM DNS record)
    • t=timestamp (when the signature was created, usually a unix timestamp seconds since the epoch GMT)
    • h=headers (the email headers included in the message hash)
    • bh=hash (the hash value computed for the selected headers and full body of the message)
    • b=signature (the private key signature of the hash)
• email signature matches the contents of the received email and selected headers by:
  • computing a new hash of the message body using the a=algorithm in the DKIM-Signature header See It Below
  • verify that the new hash matches the bh=hash in the DKIM-Signature header See It Below
  • select and make canonical the headers listed in the h=headers field of the DKIM-Signature header See It Below
  • compute a new hash digest of the selected headers See It Below
  • use the s=selector and d=domain fields in the DKIM-Signature header to fetch the sender's public key from DNS See It Below
  • using the public key specified in the DKIM DNS record, decrypt the signature from the b=signature field in the DKIM-Signature header See It Below
  • verify that the new hash digest matches the decrypted hash digest See It Below

To understand how DKIM unequivocally assures that the message received is exactly what the sender sent, follow the above steps in reverse.

• The decrypted hash digest is known to be correct because pubic/private key encryption assures that the decrypted hash digest was encrypted by the sender's private key.
• The sender's private key is known to be correct because it comes from a separate, non-email, system (DNS) and can be further protected by DNSSEC.
• The important message headers in the received message are known to be unchanged from what the sender sent because a newly computed hash digest of the selected headers matches the decrypted hash digest.
• The body hash digest in the DKIM-Signature header is known to be correct because it is one of the important message headers that are known to be unchanged.
• The body of the message is known to be correct because the newly computed body hash digest matches the body hash digest in the DKIM-Signature header.

CheckTLS Testing DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Recall that Senders use DMARC to mandate SPF and/or DKIM, the two underlying email authentication methods, and requires one or both. It also enforces alignment between SPF/DKIM and the visible "From:" domain, and it tells receiving mail servers what to do if authentication fails. DMARC does not do authentication itself, rather it checks the results of SPF or DKIM or both, and that they match the domain in the From: header.

DMARC improves email authentication by announcing to the world, via a DNS DMARC record, that a domain does SPF and/or DKIM, so receivers know to check any received emails from that domain for SPF and/or DKIM. It also improves authentication by matching the From: address in the email to the domain, telling receivers "If you get an email from my domain, be sure to check SPF and/or DKIM", and "Any email from my domain has to explicitly come from a particular From: domain and only a particular From: domain". This prevents a sender from spoofing a sub-domain of your domain, for example "sales@spoofed.checktls.com".

The CheckTLS //email/testFrom: ("TestSender") test is used to test a Sender’s DMARC. Use the TestSender instructions above to select the DMARC option and display the TestSender Setup Page. Obviously because DMARC sits on top of SPF and/or DKIM, selecting one or both of these is also useful. This link will go to the TestSender page, select the DKIM option, and bring up the TestSender Setup Page for you.

In checking that your DMARC is correct, CheckTLS checks that your domain has a valid DMARC DNS TXT record, and that that one or both of SPF and DKIM are correct:

• That your domain has a valid DMARC DNS TXT record: See It Below
  • exists at the proper lookup, e.g. _dmarc.yourdomain.com
  • is properly formatted and accurate with these fields:
    • v=DMARC1 (version) REQUIRED
    • p=none|quarantine|reject (security policy) REQUIRED
    • rua=emailaddress (where aggregate security and delivery reports are sent) OPTIONAL
    • pct=number (the percentage of emails subjected to the DMARC policy) OPTIONAL
    • aspf=r|s (alignment mode for SPF) OPTIONAL
    • adkim=r|s (alignment mode for DKIM) OPTIONAL
• That SPF or DKIM or both were able to authenticate the message
  • SPF authenticates the message (message came from the right IP address) with either:
    • MFROM where the MAIL FROM (or Return-Path) domain matches a DNS SPF record See It Below
    • HELO where the SMTP HELO greeting matches a DNS SPF record See It Below
  • DKIM authenticates the message (message was not changed) See It Below
• If SPF authenticates the message, DMARC also checks that the Return-Path domain aligns with (matches) the From: message header ("spf-alignment") See It Below
• If DKIM authenticates the message, DMARC also checks that the signing domain (d= field from DKIM-Signature) aligns with (matches) the From: message header ("dkim-alignment") See It Below

When checking alignment, CheckTLS uses either "strict" or "relaxed" matching based on the aspf= (for SPF) or the adkim= (for DKIM) fields on the domain's DMARC DNS record. "strict" means the domains must exactly match from beginning to end, while "relaxed" means a subdomain can match a parent domains. For example sales.mycompany.com is a relaxed match of mycompany.com, but it is not a strict match.

CheckTLS Testing BIMI (Brand Indicators for Message Identification)

Recall that Senders use BIMI to mandate DMARC (which mandates SPF and/or DKIM also). Receivers that check BIMI will display your company's logo next to any emails received from your company that meet your BIMI requirements. Receivers will not display your logo, and possibly display an error, or quarantine, any emails received that do not meet your BIMI requirements.

The CheckTLS //email/testFrom: ("TestSender") test is used to test a Sender’s BIMI. Use the TestSender instructions above to select the BIMI option and display the TestSender Setup Page. Obviously because BIMI sits on top of DMARC, and therefore SPF and/or DKIM, selecting one or more of these is also useful. This link will go to the TestSender page, select the BIMI option, and bring up the TestSender Setup Page for you.

In checking that your BIMI is correct, CheckTLS looks at:

• if you have a valid BIMI header in your email See It Below
• if you have a valid BIMI record in DNS See It Below
• that your email system correctly implements DMARC (which checks SPF and/or DKIM) See It Below
• optionally that you have a Verified Mark Certificate (CheckTLS does not check this yet)

Data:

  Version: 3 (0x2)

  Serial Number: aa:2a:05:43:36:28:ee:dd

  Validity:

    Not Before: Oct  7 21:13:25 2025 GMT

    Not After: Nov  8 21:13:25 2026 GMT

  Subject:

    commonName =	*.checktls.com

  Issuer:

    countryName =	US

    stateOrProvinceName =	Arizona

    localityName =	Scottsdale

    organizationName =	GoDaddy.com, Inc.

    organizationalUnitName =	http://certs.godaddy.com/repository/

    commonName =	Go Daddy Secure Certificate Authority - G2

  Subject Public Key Info:

    Public Key Algorithm: rsaEncryption

    Public Key Bits: (2048 bit)

    Modulus:
      95:37:BB:F6:0B:C8:57:DB:D7:5D:20:02:91:AA:58:5D
      ...lines removed for brevity...
      62:A6:A1:80:AF:80:DE:46:2E:EE:1A:D9:6C:92:C1:9B

    Exponent: 65537 (0x10001)

    Key:
      -----BEGIN RSA PUBLIC KEY-----
      MIIBCgKCAQEAlTe79gvIV9vXXSACkapYXYs/Au9TVZhGhRax0CEjUMIn1Mer1+Jf
      NSbTHCgPc8mz2OIh1T0QeZYP/IYhhgNHPNw6cWYF39O3vfQQ2qBxXnZ+nhYefsR/
      8D6+eriV+Hmc8eVtgjwL9iGXAYuUMCHeh5RWQIaA2oYKsZHjNYfBZRCXGzTgEzm6
      vYL90/DCe+IsF+vam2egV5GJo+k11hZk7A+DcdfNeYn0o+TOLre7Km1rRxAax2Mc
      xDzdRfobcDybqc7OKHk0KA9ft7HwFKmZdyqUl3f/zk979uR3TT8MGW/RbOBxOaRu
      tGgS8sbiY6iSYqahgK+A3kYu7hrZbJLBmwIDAQAB
      -----END RSA PUBLIC KEY-----

  X509v3 Extensions:

    X509v3 Basic Constraints: critical

      CA:FALSE

    X509v3 Extended Key Usage: 

      TLS Web Server Authentication, TLS Web Client Authentication

    X509v3 Key Usage: critical

      Digital Signature, Key Encipherment

    X509v3 CRL Distribution Points: 

      
      Full Name:
        URI:http://crl.godaddy.com/gdig2s1-64703.crl

    X509v3 Certificate Policies: 

      Policy: 2.23.140.1.2.1
      Policy: 2.16.840.1.114413.1.7.23.1
        CPS: http://certificates.godaddy.com/repository/

    Authority Information Access: 

      OCSP - URI:http://ocsp.godaddy.com/
      CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt

    X509v3 Authority Key Identifier: 

      keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

    X509v3 Subject Alternative Name: 

      DNS:*.checktls.com, DNS:checktls.com, DNS:*.emailsentry.com, DNS:emailsentry.com, DNS:*.email-test.com, DNS:email-test.com, DNS:*.informationsecuritytest.com, DNS:informationsecuritytest.com, DNS:*.informationsecuritytesting.com, DNS:informationsecuritytesting.com, DNS:*.sniffynet.com, DNS:sniffynet.com, DNS:*.sniffinet.com, DNS:sniffinet.com, DNS:*.infosectesting.com, DNS:infosectesting.com

    X509v3 Subject Key Identifier: 

      38:9F:55:E1:59:28:FE:A2:BE:3D:42:B8:BF:E9:12:80:86:9E:16:7F

    CT Precertificate SCTs: 

      Signed Certificate Timestamp:
          Version   : v1 (0x0)
          Log ID    : D7:6D:7D:10:D1:A7:F5:77:C2:C7:E9:5F:D7:00:BF:F9:
                      82:C9:33:5A:65:E1:D0:B3:01:73:17:C0:C8:C5:69:77
          Timestamp : Oct  7 21:13:26.133 2025 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:45:02:20:63:3D:13:D7:95:F4:C3:49:61:02:37:C9:
                      B3:AE:4E:B8:A2:39:71:CA:A7:2C:B9:C4:CD:A4:F2:00:
                      C8:DE:84:33:02:21:00:FD:62:E4:9F:C5:5F:8E:12:6E:
                      BD:6C:DB:CB:4E:F3:31:38:2C:DE:E4:0D:8D:9C:07:BC:
                      DC:1F:39:5F:06:0E:70
      Signed Certificate Timestamp:
          Version   : v1 (0x0)
          Log ID    : AC:AB:30:70:6C:EB:EC:84:31:F4:13:D2:F4:91:5F:11:
                      1E:42:24:43:B1:F2:A6:8C:4F:3C:2B:3B:A7:1E:02:C3
          Timestamp : Oct  7 21:13:26.925 2025 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:44:02:20:1A:50:62:D6:4B:70:78:2B:8F:49:03:1B:
                      BF:B1:B0:03:7E:59:1E:81:71:57:4D:26:A9:9B:D9:87:
                      7A:52:BF:D2:02:20:60:A7:5C:23:A7:D5:98:B1:3C:28:
                      2E:36:96:E8:A5:D1:C4:8A:33:74:DA:5B:F4:1B:8C:2B:
                      64:5D:7B:19:07:EB
      Signed Certificate Timestamp:
          Version   : v1 (0x0)
          Log ID    : C2:31:7E:57:45:19:A3:45:EE:7F:38:DE:B2:90:41:EB:
                      C7:C2:21:5A:22:BF:7F:D5:B5:AD:76:9A:D9:0E:52:CD
          Timestamp : Oct  7 21:13:27.096 2025 GMT
          Extensions: none
          Signature : ecdsa-with-SHA256
                      30:45:02:21:00:C6:74:C2:49:3D:DC:3F:1A:4A:DD:6F:
                      31:5B:10:49:9C:68:29:44:0A:D7:D8:10:58:42:F4:75:
                      CC:51:B5:27:B8:02:20:1C:0B:65:85:E9:46:B6:6C:2F:
                      1E:5C:2A:EB:54:50:66:9C:AA:03:F2:88:A0:5B:EA:A4:
                      78:1D:DB:F0:78:5C:17

Digest: a4d7d86bfbd0b3538f2850ba49a3408d4fc7d0396e67423aeac397dfbc92b939

Signature: sha256WithRSAEncryption

  42:37:c0:11:36:bd:ba:8f:84:21:84:f6:d7:2d:79:78
      ...lines removed for brevity...
  51:96:bd:56:2c:e7:55:b2:41:c8:17:22:9f:74:26:47

Fingerprints:

  all$308207C4308206ACA003020102020900AA2A05433628EEDD300D0609
      ...lines removed for brevity...
  59114B41BFFDED339724296D7A55C48456CA8E6AF0DE341195EEC72C5196
  BD562CE755B241C817229F742647

  all$pub$30820122300D06092A864886F70D01010105000382010F003082
      ...lines removed for brevity...
  F014A999772A949777FFCE4F7BF6E4774D3F0C196FD16CE07139A46EB468
  12F2C6E263A89262A6A180AF80DE462EEE1AD96C92C19B0203010001

  sha256$a4d7d86bfbd0b3538f2850ba49a3408d4fc7d0396e67423aeac39
  7dfbc92b939

  sha256$pub$33086acb8b20f6f057ec3868e422e4df0c5e7739d210f843e
  e1750dc28d96a56

  sha512$4afb3a1d342e940874d3d7771f9f712ad8bbc31cfe842801ae4b7
  d7c773982ec9a383f5518699fb2b307b705caa7366d2f0234205ba32aff3
  ceba4be89330c40

  sha512$pub$5bab91b8fc4565f1ba26ada257cde59e14a331e98030864cc
  282739bec3fcc60b468e2ce64e71242b15caff1791b59a194e2e077e6232
  ebffb779cf84bdec919

Certificate:
  -----BEGIN CERTIFICATE-----
  MIIHxDCCBqygAwIBAgIJAKoqBUM2KO7dMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD
      ...lines removed for brevity...
  aXdkd2Yd2nQXPsMiZy5fS8scMZsV0II/658Lk1kRS0G//e0zlyQpbXpVxIRWyo5q
  8N40EZXuxyxRlr1WLOdVskHIFyKfdCZH
  -----END CERTIFICATE-----

TLSA 2 0 1 A4D7D86BFBD0B3538F2850BA49A3408D4FC7D0396E67423AEAC397DFBC92B939
TLSA 2 1 1 33086ACB8B20F6F057EC3868E422E4DF0C5E7739D210F843EE1750DC28D96A56
TLSA 2 0 2 4AFB3A1D342E940874D3D7771F9F712AD8BBC31CFE842801AE4B7D7C773982EC9A383F5518699FB2B307B705CAA7366D2F0234205BA32AFF3CEBA4BE89330C40
TLSA 2 1 2 5BAB91B8FC4565F1BA26ADA257CDE59E14A331E98030864CC282739BEC3FCC60B468E2CE64E71242B15CAFF1791B59A194E2E077E6232EBFFB779CF84BDEC919

Data:

  Version: 3 (0x2)

  Serial Number: 07

  Validity:

    Not Before: May  3 07:00:00 2011 GMT

    Not After: May  3 07:00:00 2031 GMT

  Subject:

    countryName =	US

    stateOrProvinceName =	Arizona

    localityName =	Scottsdale

    organizationName =	GoDaddy.com, Inc.

    organizationalUnitName =	http://certs.godaddy.com/repository/

    commonName =	Go Daddy Secure Certificate Authority - G2

  Issuer:

    countryName =	US

    stateOrProvinceName =	Arizona

    localityName =	Scottsdale

    organizationName =	GoDaddy.com, Inc.

    commonName =	Go Daddy Root Certificate Authority - G2

  Subject Public Key Info:

    Public Key Algorithm: rsaEncryption

    Public Key Bits: (2048 bit)

    Modulus:
      B9:E0:CB:10:D4:AF:76:BD:D4:93:62:EB:30:64:B8:81
      ...lines removed for brevity...
      54:35:4B:69:4E:BC:3B:D3:49:2E:1F:DC:C1:D2:52:FB

    Exponent: 65537 (0x10001)

    Key:
      -----BEGIN RSA PUBLIC KEY-----
      MIIBCgKCAQEAueDLENSvdr3Uk2LrMGS4gQhswwTZYheOL/8+Zc+PzmLmPFIc2hZF
      S1WreGtjg2KQzg9pbJnIGhSLTMxFM+qI3J6jryv+gGGdeVfEzy70PzA8XUf8mha8
      wzeWQVGOEUtU+Ci+0Iy+8DA4HvOwJvhmR2Nt3nEmR484R1PRRh2049wA6kWsvbxx
      2apvANvbzTA6eU9fTEf4He9bwsSdYDuxskOR2KQzTuqz1idPrSWKpcb01dCmrnQF
      ZFeItURV1C0qOj74uL3pMgoClGTEFjpQ8Uqu53kzrwwgB3/o3wQ5wmkCbGNS+nfB
      G8h0h8i5kxhQVDVLaU68O9NJLh/cwdJS+wIDAQAB
      -----END RSA PUBLIC KEY-----

  X509v3 Extensions:

    X509v3 Basic Constraints: critical

      CA:TRUE

    X509v3 Key Usage: critical

      Certificate Sign, CRL Sign

    X509v3 Subject Key Identifier: 

      40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

    X509v3 Authority Key Identifier: 

      keyid:3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE

    Authority Information Access: 

      OCSP - URI:http://ocsp.godaddy.com/

    X509v3 CRL Distribution Points: 

      
      Full Name:
        URI:http://crl.godaddy.com/gdroot-g2.crl

    X509v3 Certificate Policies: 

      Policy: X509v3 Any Policy
        CPS: https://certs.godaddy.com/repository/

Digest: 973a41276ffd01e027a2aad49e34c37846d3e976ff6a620b6712e33832041aa6

Signature: sha256WithRSAEncryption

  08:7e:6c:93:10:c8:38:b8:96:a9:90:4b:ff:a1:5f:4f
      ...lines removed for brevity...
  a1:26:7d:0a:09:a7:2e:04:a3:8d:bc:f8:bc:04:30:01

Fingerprints:

  all$308204D0308203B8A003020102020107300D06092A864886F70D0101
      ...lines removed for brevity...
  EDB12D763626DC04EB9FF7611F15DC876FEE469628ADA1267D0A09A72E04
  A38DBCF8BC043001

  all$pub$30820122300D06092A864886F70D01010105000382010F003082
      ...lines removed for brevity...
  C4163A50F14AAEE77933AF0C20077FE8DF0439C269026C6352FA77C11BC8
  7487C8B993185054354B694EBC3BD3492E1FDCC1D252FB0203010001

  sha256$973a41276ffd01e027a2aad49e34c37846d3e976ff6a620b6712e
  33832041aa6

  sha256$pub$f11c3dd048f74edb7c45192b83e5980d2f67ec84b4ddb9396
  e33ff5173ed698f

  sha512$42c5b22334cd08c727fdec4aca8df6ec645afa8dd7fc278d26a2c
  800c81d7cff86fc107e6d7f28f1a8e4faf0216fd4d2a9af22d69714ca909
  9e457d1b2d5188a

  sha512$pub$fb48c4f85ae0b07f8ef93d1915e32b161dade3bd070a39df5
  08570fd64e7298703f90bffa17fd636c29b8f4a69e8b7b14f0fd6f252520
  6f9f47331af89ef79db

Certificate:
  -----BEGIN CERTIFICATE-----
  MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx
      ...lines removed for brevity...
  GIo/ikGQI31bS/6kA1ibRrLDYGCD+H1QQc7CoZDDu+8CL9IVVO5EFdkKrqeKM+2x
  LXY2JtwE65/3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB
  -----END CERTIFICATE-----

TLSA 2 0 1 973A41276FFD01E027A2AAD49E34C37846D3E976FF6A620B6712E33832041AA6
TLSA 2 1 1 F11C3DD048F74EDB7C45192B83E5980D2F67EC84B4DDB9396E33FF5173ED698F
TLSA 2 0 2 42C5B22334CD08C727FDEC4ACA8DF6EC645AFA8DD7FC278D26A2C800C81D7CFF86FC107E6D7F28F1A8E4FAF0216FD4D2A9AF22D69714CA9099E457D1B2D5188A
TLSA 2 1 2 FB48C4F85AE0B07F8EF93D1915E32B161DADE3BD070A39DF508570FD64E7298703F90BFFA17FD636C29B8F4A69E8B7B14F0FD6F2525206F9F47331AF89EF79DB

Data:

  Version: 3 (0x2)

  Serial Number: 00

  Validity:

    Not Before: Sep  1 00:00:00 2009 GMT

    Not After: Dec 31 23:59:59 2037 GMT

  Subject:

    countryName =	US

    stateOrProvinceName =	Arizona

    localityName =	Scottsdale

    organizationName =	GoDaddy.com, Inc.

    commonName =	Go Daddy Root Certificate Authority - G2

  Issuer:

    countryName =	US

    stateOrProvinceName =	Arizona

    localityName =	Scottsdale

    organizationName =	GoDaddy.com, Inc.

    commonName =	Go Daddy Root Certificate Authority - G2

  Subject Public Key Info:

    Public Key Algorithm: rsaEncryption

    Public Key Bits: (2048 bit)

    Modulus:
      BF:71:62:08:F1:FA:59:34:F7:1B:C9:18:A3:F7:80:49
      ...lines removed for brevity...
      FC:CE:C4:1B:03:3C:09:EB:49:31:5C:69:46:B3:E0:47

    Exponent: 65537 (0x10001)

    Key:
      -----BEGIN RSA PUBLIC KEY-----
      MIIBCgKCAQEAv3FiCPH6WTT3G8kYo/eASVjpIoMTpsUgQwE7hPHmhUmfJ+r2hBtO
      oLTbcJjHMgGxBT4HTu70+k8vWTAi56sZVmvigAf88xZ1gDlRe+X5NbZ0TqmNghPk
      tj+pA4P6or6KFWp/3gvDthkUBcrqw6gElDtGfDIN8wBmIsiNaW02jBEYt9OyHGC0
      OPoCjM7T3UYH3go+6118yHz7sCtTpJJiaVElBWEaRIGMLKlDliPfrDqBmg4pxRyp
      6V0etp6eMAo5zvGIgPtLXcwy7IViQyU0AlYnAZG0O3AqP26x6JyIAX2f1PnbU21g
      nb8s51iruF9G/M7EGwM8CetJMVxpRrPgRwIDAQAB
      -----END RSA PUBLIC KEY-----

  X509v3 Extensions:

    X509v3 Basic Constraints: critical

      CA:TRUE

    X509v3 Key Usage: critical

      Certificate Sign, CRL Sign

    X509v3 Subject Key Identifier: 

      3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE

Digest: 45140b3247eb9cc8c5b4f0d7b53091f73292089e6e5a63e2749dd3aca9198eda

Signature: sha256WithRSAEncryption

  99:db:5d:79:d5:f9:97:59:67:03:61:f1:7e:3b:06:31
      ...lines removed for brevity...
  b4:99:84:65:ca:7a:88:e2:e2:44:be:5c:f7:ea:1c:f5

Fingerprints:

  all$308203C5308202ADA003020102020100300D06092A864886F70D0101
      ...lines removed for brevity...
  C57F7DD5080FE21CFE7E17B8AC5EF6D416B243090C4DF6A76BB4998465CA
  7A88E2E244BE5CF7EA1CF5

  all$pub$30820122300D06092A864886F70D01010105000382010F003082
      ...lines removed for brevity...
  624325340256270191B43B702A3F6EB1E89C88017D9FD4F9DB536D609DBF
  2CE758ABB85F46FCCEC41B033C09EB49315C6946B3E0470203010001

  sha256$45140b3247eb9cc8c5b4f0d7b53091f73292089e6e5a63e2749dd
  3aca9198eda

  sha256$pub$2a8f2d8af0eb123898f74c866ac3fa669054e23c17bc7a95b
  d0234192dc635d0

  sha512$c509cd5452659ae94c673a47b68e2c0aa8ad177804c8ae2949306
  e9232b70ab5b5334d1abe53a25ecaf0c609871b33849773b4edf277dd346
  069038f695d76fb

  sha512$pub$cb17d366514f38cd029146ff26bc2b054ee12f66cf976f405
  920db7f382f4d867996e616da60eac4cb0043edf95c06926a3f57d074d5a
  66e5372ef556bd75fd7

Certificate:
  -----BEGIN CERTIFICATE-----
  MIIDxTCCAq2gAwIBAgIBADANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx
      ...lines removed for brevity...
  LPAvTK33sefOT6jEm0pUBsV/fdUID+Ic/n4XuKxe9tQWskMJDE32p2u0mYRlynqI
  4uJEvlz36hz1
  -----END CERTIFICATE-----

TLSA 3 0 1 45140B3247EB9CC8C5B4F0D7B53091F73292089E6E5A63E2749DD3ACA9198EDA
TLSA 3 1 1 2A8F2D8AF0EB123898F74C866AC3FA669054E23C17BC7A95BD0234192DC635D0
TLSA 3 0 2 C509CD5452659AE94C673A47B68E2C0AA8AD177804C8AE2949306E9232B70AB5B5334D1ABE53A25ECAF0C609871B33849773B4EDF277DD346069038F695D76FB
TLSA 3 1 2 CB17D366514F38CD029146FF26BC2B054EE12F66CF976F405920DB7F382F4D867996E616DA60EAC4CB0043EDF95C06926A3F57D074D5A66E5372EF556BD75FD7

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