At VerifyDMARC, we're committed to providing essential email security solutions for all. Today, we're thrilled to announce the launch of our new SMTP Transport Layer Security (TLS) Reporting feature, available to all customers, complementing our existing DMARC reporting and monitoring.
Before we dive into TLS Reporting, let's quickly explain what TLS is and how it's typically used in email systems. Transport Layer Security (TLS) is a cryptographic protocol that provides secure communication over the internet. In the context of email, TLS encrypts the connection between mail servers, protecting the contents of emails as they travel across the internet.
By default, most modern mail servers attempt to use TLS when communicating with other mail servers. However, if the TLS connection can't be established (due to misconfiguration, outdated software, or other issues), many servers will "downgrade" the connection and send the email without encryption. This behaviour, known as opportunistic TLS, ensures that emails are delivered even when a secure connection isn't possible, but it can also leave your communications vulnerable to eavesdropping or tampering.
This default behaviour highlights why TLS monitoring and reporting are so crucial. Without proper oversight, you might not know when your emails are being sent or received without the protection of TLS encryption. TLS Reporting provides visibility into these connection attempts, helping you identify and address issues that could be preventing secure communication.
While TLS doesn't encrypt the email itself (that's what end-to-end encryption does), it does protect the email during transmission, which is a critical component of overall email security. By ensuring TLS is consistently used and properly configured, you can significantly enhance the confidentiality and integrity of your organisation's email communications.
Transport Layer Security (TLS) is crucial for protecting email communications in transit. However, without proper monitoring, it's challenging to ensure TLS is working correctly across all your inbound email connections. That's where TLS Reporting comes in.
TLS Reporting is complimentary to DMARC. DMARC reports provide feedback on who is sending from your domain, TLS Reporting collects feedback from servers sending mail to your domain.
TLS Reporting provides valuable insights into how external mail servers experience connecting to your email infrastructure, helping you:
These reports, generated by sending mail servers attempting to connect to your domain, offer a unique "outside-in" view of your email security posture.
While TLS Reporting is beneficial for all organisations, it becomes particularly crucial if you've implemented or are considering implementing inbound DANE or MTA-STS. These protocols can significantly enhance email security by enforcing the use of TLS where available, but misconfiguration could result in missing inbound emails - a risk that could severely impact business operations. TLS Reporting provides the visibility needed to avoid such pitfalls.
We've made it easy to enable TLS Reporting for your domains:
This DNS record tells sending mail servers where to send their TLS reports about connections to your domain. Once enabled, external mail servers will begin generating reports about their TLS interactions with your mail servers, providing you with crucial insights into your inbound email security.
Once enabled, you'll see new TLS columns appear in your Dashboard and Domains tables, providing at-a-glance insights into your TLS configuration and statistics as they are reported.
Unlike DMARC reports, which are about emails sent from your domain, TLS reports provide information about emails sent to your domain. These reports are generated by external mail servers as they attempt to establish secure connections with your mail servers.
This means you're getting direct feedback on how your email infrastructure appears to the outside world.
For example, if an external server fails to establish a TLS connection with your mail server, you'll receive a report detailing this failure. This could alert you to misconfiguration issues, certificate problems, or potential security threats that you might not detect from inside your network.
Note: Unlike DMARC, many mail platforms (at this time) do not send success-only TLS reports. They send reports only when there are failed sessions. However, some major providers like Google do send success reports, which can give you a more complete picture of your TLS connections. This means you'll get comprehensive data from some senders, while others will only alert you to potential problems.
While TLS Reporting complements DANE and MTA-STS implementations, you don't need these protocols in place to benefit from it. TLS Reporting allows any organisation to collect aggregate statistics about their inbound TLS connections. When failures occur, you'll receive critical details about the nature of the issue, enabling swift resolution.
As email security continues to evolve, forward-thinking organisations are looking for ways to enhance their defences. By setting up TLS Reporting today, you're preparing your infrastructure for future adoption of advanced protocols like DANE or MTA-STS.
Ready to gain deeper insights into your email security? TLS Reporting is now available on all VerifyDMARC plans, with reported TLS connections counting towards your plan's message quota.
Sign up for our 30-day free trial to experience the benefits of TLS Reporting and our comprehensive DMARC management platform. Don't wait - take control of your email security today with VerifyDMARC.
We discuss inbound email security options for SMEs, considering MTA-STS over DANE due to its simplicity and lower risk. We outline a step-by-step approach to upgrade email security using TLS reporting and MTA-STS.
In response to a recent FBI, State Department, and NSA advisory, we highlight risks of weak DMARC security and offer actionable steps to protect your organisation, customers, and suppliers.
Ensuring the legitimacy and accuracy of DMARC reports is critical to avoid wasting resources or making poor security decisions based on faulty data.