Ultimate Guide to Simple Mail Transfer Protocol (SMTP) TLS Reporting

Transport Layer Security (TLS) is a cryptographic protocol that encrypts data in transit, protecting email content from interception or tampering. On the other hand, Simple Mail Transfer Protocol (SMTP) is the standard system used to send emails from one server to another. So, when SMTP uses TLS, emails are delivered over an encrypted connection rather than in plain text. To make it efficient, SMTP TLS reporting adds visibility to the entire process.

This article discusses how these protocols work together to bolster email security and how reporting plays its role in this exercise.

What Is SMTP TLS Reporting

SMTP TLS reporting is a mechanism that helps domain owners monitor how email encryption is working during mail delivery. When emails are sent using SMTP and TLS, receiving mail servers generate reports showing whether the TLS connection was successfully established or if any problems occurred. These reports are shared in a structured format and give visibility into encrypted and unencrypted email delivery attempts.

So, if you regularly use a TLS-RPT Record Checker, you can identify issues like policy mismatching or TLS negotiation failures. Fixing these issues early on ensures emails are consistently protected in transit. 

How SMTP Works with Transport Layer Security?

In SMTP email communication, TLS encryption is opportunistic by default. This means the sending mail server tries to establish an encrypted connection, but if TLS cannot be negotiated, the email is still delivered in plain text. This behavior exists because SMTP was designed nearly four decades ago, long before encryption was part of email protocols. TLS support was added later through the STARTTLS command.

STARTTLS is used only when both the sending and receiving servers support TLS. If either side does not support it, the SMTP session continues without encryption.

To fix this risk, MTA-STS was introduced under RFC 8461. When MTA-STS is enforced, the sending Mail Transfer Agent (MTA) will only deliver an email if a secure TLS connection is successfully established. If encryption is unavailable or fails, the message is blocked rather than sent in plain text. This shifts SMTP from a “try and hope” approach to a security-first model, where encrypted delivery is the default rather than an optional fallback.

What is a Mail Transfer Agent (MTA)

A Mail Transfer Agent (MTA) is a core email service responsible for sending, receiving, and relaying messages between mail servers using SMTP. An MTA receives emails either from a Mail User Agent (MUA) or from another MTA and then routes them to the recipient’s mail server over SMTP.

During this server-to-server exchange, the MTA handles critical delivery tasks such as MX record resolution, connection setup, and encryption negotiation. This is also where SMTP TLS is applied, allowing the MTA to establish secure connections, enforce authentication policies, and determine whether an email can be delivered safely or must be deferred or rejected.

What is a Mail Delivery Agent (MDA)

MDA receives messages from MUA or from the MTA to sort and deliver the email to the recipient’s mailbox. Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can serve as MDAs when they append new email messages to a local user’s mailbox.

Difference Between MTA and MDA

MTA is responsible for moving emails between mail servers using SMTP. It handles server-to-server communication, routing messages based on DNS and MX records, and applying security controls such as SMTP TLS, authentication checks, and delivery policies. The MTA decides whether an email can be securely transferred to the recipient’s mail server.

MDA, in contrast, operates after the message has been accepted by the receiving server. Its role is to deliver the email to the recipient’s mailbox. The MDA does not participate in SMTP routing or TLS negotiation and does not communicate with external servers. It simply places the message into the correct inbox based on local delivery rules.

SMTP Encrypted Channels

The original SMTP protocol was designed to support only unauthenticated and unencrypted communication between mail servers. As a result, emails sent over SMTP could be transmitted in plain text, making them vulnerable to interception and manipulation. This design limitation exposes email traffic to risks such as man-in-the-middle attacks, spoofing, and unauthorized message alteration.

To address these security gaps, multiple mechanisms were later introduced to enable encrypted channels between SMTP Mail Transfer Agents.

Risks of Unencrypted SMTP Connections

When SMTP connections are not encrypted, email content can be intercepted or modified as it travels between mail servers. Attackers can exploit these weaknesses to perform man-in-the-middle attacks, capture sensitive information, or downgrade secure connections without detection. Unencrypted SMTP traffic also makes it easier for spoofed or tampered messages to pass through the mail flow, increasing the risk of phishing, impersonation, and data exposure.

STARTTLS

STARTTLS is a command issued by an email client. It indicates that the client wants to upgrade the existing, insecure connection to a secure connection using the SSL/TLS cryptographic protocol. The STARTTLS command name is used by SMTP and IMAP protocols, whereas the POP3 protocol uses STLS.

Common STARTTLS Configuration Issues

STARTTLS failures are often caused by the following configuration or compatibility issues between sending and receiving mail servers:

• Invalid or Expired TLS Certificates

STARTTLS negotiation can fail if the receiving mail server presents an expired, self-signed, or otherwise invalid TLS certificate. Sending MTAs may reject the connection or refuse to upgrade to TLS when certificate validation checks fail.

• Certificate Hostname Mismatch

A mismatch between the certificate’s hostname and the MX hostname of the receiving server is a common cause of STARTTLS failures. When the presented certificate does not match the expected domain, the sending server may treat the connection as untrusted.

• Unsupported TLS Versions or Cipher Suites

If the receiving server only supports outdated TLS versions or weak cipher suites, modern MTAs may be unable to establish a secure connection. This incompatibility can prevent STARTTLS from being successfully negotiated.

• Network Interference During TLS Handshake

Firewalls, load balancers, or proxy devices may interrupt or modify the STARTTLS handshake. Such interference can cause TLS negotiation to fail silently, leading to connection timeouts or fallback to unencrypted SMTP delivery if enforcement is not enabled.

DNS-Based Authentication of Named Entities (DANE)

DNS-Based Authentication of Named Entities (DANE) allows domain owners to specify which TLS certificate should be used when connecting to their mail servers. This information is published in DNS using TLSA records and is protected by DNSSEC. With DANE, sending MTAs can verify that the receiving server presents the expected certificate during TLS negotiation, reducing the risk of certificate spoofing and downgrade attacks.

MTA Strict Transport Security (MTA-STS)

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive TLS-secured SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

Why SMTP TLS Reporting is Important

Domain owners need visibility into email delivery problems, especially when TLS encryption fails for emails sent from domains using MTA-STS. Without this visibility, encryption issues can remain hidden and weaken email security. SMTP TLS reporting solves this problem by providing clear insights into how SMTP TLS connections are negotiated and by showing when and why secure email connections fail.

From a security standpoint: 

• TLS reporting helps detect unencrypted email transmissions and reduce the risk of interception or man-in-the-middle attacks. 
• It also supports compliance by helping organizations show that email data is protected while in transit, which is required by many data protection regulations. 
• In addition, TLS reporting improves email deliverability by highlighting TLS or email misconfigurations, certificate problems, and policy errors that can prevent secure email delivery.

SMTP TLS Reporting Policy

A domain publishes a policy in DNS to indicate that it wants to receive SMTP TLS reports. SMTP TLS Reporting (TLS-RPT) policies are distributed via DNS as TXT records, similar to DMARC policies, under the name _smtp._tls within the policy domain’s DNS zone.

For example, for the policy domain ‘easydmarc.com,’ the TLS-RPT record can be retrieved from: _smtp._tls.easydmarc.com.

A typical TLS-RPT policy looks like this:

v=TLSRPTv1; rua=mailto:[email protected]

• v: Specifies the TLS-RPT version and MUST be set to TLSRPTv1.
• rua: Defines the URI to which aggregate reports of TLS policy validation results should be sent.

Note: When the mailto scheme is used, reports are delivered to the specified email address. Sending MTAs must attempt to deliver TLS reports even if TLS-related failures occur, and should not include these report-delivery sessions in subsequent reports. As a result, TLS reports may be delivered without encryption.

Reports sent via SMTP must include a valid DKIM signature from the reporting domain. Reports without a valid DKIM signature must be ignored by the recipient. The DKIM signature must not use the l= tag to limit body length, as this could allow attackers to append misleading data without invalidating the signature. The DKIM TXT record should include the service type declaration s=tlsrpt; if it is missing, the receiving system may choose to ignore the report.

SMTP TLS Reporting Schema

The report is composed as a plaintext file encoded in the Internet JSON (I-JSON) format.

Aggregate reports contain the following fields:

Report metadata:

• The organization responsible for the report
• Contact information for one or more responsible parties for the contents of the report
• A unique identifier for the report
• The reporting date range for the report

Policy, consisting of:

1 . One of the following policy types:

• the MTA-STS Policy applied (as a string)
• the DANE TLSA record applied (as a string, with each RR entry of the RRset listed and separated by a semicolon)
• the literal string “no-policy-found”, if neither a DANE nor MTA-STS Policy could be found

2. The domain for which the policy is applied

3. The MX host

4. Aggregate counts, comprising result type, Sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review further information on a failure type.

Report Summary

The report summary has two elements:

Success Count (total-successful-session-count)

This field contains an aggregate count of successful connections for the reporting system. A successful session means the sending and receiving servers were able to use SMTP TLS correctly and deliver the email without any encryption or policy issues. A high success count usually indicates that TLS settings and security policies are working as expected.

Failure Count (total-failure-session-count) 

This field contains an aggregate count of failed connections. Failures can happen due to certificate problems, policy mismatches, unsupported TLS versions, or temporary network issues. An increasing failure count is a sign that something may be misconfigured and should be reviewed to avoid delivery problems or unencrypted email transmission.

Result Types

Here is the breakdown of the types of results you expect:

Negotiation Failures

• “starttls-not-supported”: This indicates that the recipient MX did not support STARTTLS.
• “certificate-host-mismatch”: This indicates that the certificate presented did not adhere to the constraints specified in the MTA-STS or DANE policy.
• “certificate-expired”: This indicates that the certificate has expired.
• “certificate-not-trusted”: This label covers multiple certificate-related failures.
• “validation-failure”: This indicates a general failure for a reason not matching a category above.

Policy Failures

Here are the two types of policy failures:

DANE-Specific Policy Failures

• “tlsa-invalid”: This indicates a validation error in the TLSA record associated with a DANE policy.
• “dnssec-invalid”: This indicates that no valid records were returned from the recursive resolver.
• “dane-required”: This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report.

MTA-STS-specific Policy Failures

• “sts-policy-fetch-error”: This indicates a failure to retrieve an MTA-STS policy, for example, because the policy host is unreachable.
• “sts-policy-invalid”: This indicates a validation error for the overall MTA-STS Policy.
• “sts-webpki-invalid”: This indicates that the MTA-STS Policy could not be authenticated using PKIX validation.

JSON Report Schema

Here is the example:

{
"organization-name": organization-name,
"date-range": {
"start-datetime": date-time,
"end-datetime": date-time
},
"contact-info": email-address,
"report-id": report-id,
"policies": [{
"policy": {
"policy-type": policy-type,
"policy-string": policy-string,
"policy-domain": domain,
"mx-host": mx-host-pattern
},
"summary": {
"total-successful-session-count": total-successful-session-count,
"total-failure-session-count": total-failure-session-count
},
"failure-details": [
{
"result-type": result-type,
"sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo,
"receiving-ip": receiving-ip,
"failed-session-count": failed-session-count,
"additional-information": additional-info-uri,
"failure-reason-code": failure-reason-code
}
]
}
]
}

• “organization-name”: The name of the organization responsible for the report. It is provided as a string.
• “date-time”: The date-time indicates the start and end times for the report range.
• “email-address”: The contact information for the party responsible for the report.
• “report-id”: A unique identifier for the report.
• “policy-type”: The type of policy that was applied by the sending domain.
• “policy-string”: An encoding of the applied policy as a JSON array of strings.
• “domain”: The Policy Domain against which the MTA-STS or DANE policy is defined.
• “mx-host-pattern”: In the case where “policy-type” is “sts”, it’s the pattern of MX hostnames from the applied policy.
• “ip-address”: The IP address of the Sending MTA that attempted the STARTTLS connection.
• “receiving-mx-hostname”: The hostname of the receiving MTA MX record with which the Sending MTA attempted to negotiate a STARTTLS connection.
• “receiving-mx-helo” (optional): The HELLO (HELO) or Extended HELLO (EHLO) string from the banner announced during the reported session.
• “receiving-ip”: The destination IP address that was used when creating the outbound session.
• “total-successful-session-count”: The aggregate count of successfully negotiated TLS-enabled connections to the receiving site.
• “total-failure-session-count”: The aggregate count of failures to negotiate a TLS-enabled connection to the receiving site.
• “failed-session-count”: The number of (attempted) sessions that match the relevant “result-type” for this section.
• “additional-info-uri” (optional): A URI that points to additional information around the relevant “result-type”. For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session.
• “failure-reason-code”: A text field to include a TLS-related error code or error message.

SMTP TLS Reporting provides visibility into misconfigurations or attempts to intercept or tamper with mail between hosts that support STARTTLS.

Strengthening Email Security with SMTP TLS Reporting

SMTP TLS reporting plays a critical role in improving email security by providing visibility into how encrypted connections behave during email delivery. It helps domain owners detect TLS failures, identify misconfigurations, and ensure that SMTP TLS policies such as MTA-STS and DANE are working as intended. Without this insight, encryption issues can remain hidden, impacting both security and deliverability.

With EasyDMARC, managing SMTP TLS reporting becomes straightforward. The platform helps you collect, analyze, and act on TLS reports without manual effort. Start your 14-day free trial with EasyDMARC to monitor SMTP TLS performance, fix encryption issues early, and strengthen secure email delivery across your domains.

Frequently Asked Questions