Blog · Dmarc
How to Measure TLS Refusal in Email: Which Servers Refuse Encrypted Connections
Every time your mail server delivers a message to a receiving server, it negotiates a TLS connection. Sometimes that negotiation succeeds. Sometimes it fails silently and the message goes through in cleartext. Sometimes the receiving server refuses TLS entirely and your server either falls back or bounces.
Most senders have no idea this is happening.
The data is sitting in your DMARC aggregate reports. This guide shows you how to find it, read it, and use it to make better decisions about which domains you trust with sensitive mail.
Why TLS Refusal Data Matters for Email Senders
TLS encryption in email is not a binary on/off switch. It is a negotiation with multiple possible outcomes.
When a receiving server refuses TLS entirely, your message travels from your server to theirs in cleartext. Anyone sitting on the network between those two points can read the message content, modify it in transit, or capture metadata about who is talking to whom. This is not a theoretical risk. It is the default behavior for many mail servers that have not been configured for TLS.
The problem is that most organizations only discover TLS refusal has been happening when something goes wrong: a sensitive message gets intercepted, a compliance auditor asks about encryption, or a partner reports that emails from your domain arrived with suspicious headers.
By that point, you have been sending unencrypted mail without knowing it.
The solution is to start looking at TLS data in your DMARC reports today.
Where to Find TLS Failure Data in DMARC Aggregate Reports
DMARC aggregate reports arrive as XML files from your receiving partners. Most organizations route them to a folder and never open them. That is a mistake.
Within each report, under the <record> element for each sending domain, there is a <PolicyEvaluated> section. Inside that section, alongside the familiar SPF, DKIM, and disposition data, there is a <TLS> element.
That element tells you whether your server successfully negotiated TLS when delivering mail to that specific receiving server.
Here is a simplified example of what you might see in a DMARC report:
<PolicyEvaluated>
<dkim>pass</dkim>
<spf>pass</spf>
<disposition>none</disposition>
<TLS>TF</TLS>
</PolicyEvaluated>
The <TLS> tag is the signal you are looking for.
How to Read TLS Metrics: What Each Value Means
DMARC reports encode TLS results with single-letter codes. Here is what each one means in practice.
N = No TLS attempted. Your server did not attempt to negotiate TLS with this receiving server at all. The message was sent in cleartext by default. This is the most common value and the most concerning one.
SF = Some TLS failures. Your server attempted TLS but the negotiation failed on at least one attempt. This is usually temporary - a server restart, a cipher mismatch, a certificate problem that resolved itself. Track this over time to see if it becomes a pattern.
TF = Total TLS failure. Every single delivery attempt to this receiving server failed TLS negotiation. This almost always means the receiving server does not support TLS at all, or is configured to refuse it. Treat TF as a clear signal that your mail to this domain traveled in cleartext.
Most senders never look at these values. When they do, they are often surprised to find that a high-volume recipient - a major customer, a partner, a government agency - has been getting TF for months.
How to Test a Specific Mail Server for TLS Support
Once you have identified a domain with concerning TLS values in your DMARC report, the next step is to test that specific server directly.
The standard tool is OpenSSL. From a Linux or macOS terminal:
openssl s_client -connect mail.example.com:25 -starttls smtp
Replace mail.example.com with the receiving server from your DMARC report. The -starttls smtp flag tells OpenSSL to initiate the SMTP handshake before attempting TLS.
When the connection opens, look for these signals:
- Verify return code: 0 - the certificate verified successfully
- Protocol: TLSv1.2 or TLSv1.3 - modern encryption is in use
- Cipher suite - anything starting with ECDHE or CHACHA20 is strong
If the connection immediately closes without offering TLS, the server does not support STARTTLS at all.
If it offers only SSLv3 or TLSv1.0, the server is severely outdated and represents a real security gap.
If you see "no peer certificate available" after a successful handshake, the server is misconfigured - it is accepting TLS connections but not presenting a valid certificate.
What to Do When Important Domains Refuse TLS
When your DMARC report shows a domain you care about consistently refusing TLS, you have a few options.
For high-value recipients (banks, healthcare providers, government agencies): Open a support ticket or IT ticket with that organization. Tell them their mail server is refusing TLS and that you have messages going to them in cleartext. In regulated industries, this can matter for compliance. Many organizations are not aware they have this gap.
For domains that refuse TLS but are not critical: Document the risk. If you are sending sensitive content to a server that refuses TLS, you have a documented security gap. Your DMARC reports give you the evidence.
For your own sending infrastructure: Make sure your outbound mail server requires TLS for sensitive destinations where possible. Some mail systems support MTA-STS (RFC 8461), which lets you declare that TLS is required for specific domains and that your server should refuse to deliver mail if TLS cannot be negotiated.
MTA-STS is a policy layer on top of SMTP. When you publish an MTA-STS policy for your domain, you are telling receiving servers: "I require TLS for mail going to this domain." If a receiving server cannot complete the TLS handshake, your MTA-capable server will hold the message rather than sending it in cleartext.
How DMARCFlow Helps You Track TLS Refusal Over Time
Parsing TLS data from DMARC reports by hand is tedious. Each XML report can contain thousands of records. Finding the TLS values, aggregating them by receiving domain, and tracking changes over time is the kind of work that benefits from automation.
DMARCFlow reads the TLS section of every DMARC aggregate report that arrives and surfaces TLS refusal rates alongside your SPF and DKIM alignment data. When a domain that previously supported TLS suddenly starts refusing it, or when a new partner starts appearing with TF values, DMARCFlow flags it.
This means you do not have to wait for a compliance audit to discover that your mail to a major customer has been traveling in cleartext for six months.
You can see it in your daily report.
FAQ
Does TLS refusal mean my email was definitely read by someone?
No. TLS refusal means the connection was not encrypted. Whether anyone intercepted that unencrypted traffic depends on who had access to the network path between your server and theirs. On a private network the risk is low. Across the public internet, the risk is real and unmonitored.
Can I require TLS for every email I send?
In theory yes, but in practice many receiving servers do not support TLS. If you require TLS universally, messages to those servers will bounce. A practical approach is to require TLS for sensitive destinations using MTA-STS while allowing fallback to cleartext for domains that do not support encryption.
Does passing SPF and DKIM mean TLS also passed?
No. SPF and DKIM check authentication. TLS checks encryption. They are independent. Your email can pass DMARC authentication checks and still travel in cleartext if the receiving server refuses TLS.
How often should I check TLS data in my DMARC reports?
At least monthly, but weekly is better. TLS refusal patterns can emerge gradually as organizations update or misconfigure their mail servers. Regular monitoring catches these shifts before they become prolonged security gaps.
What is a reasonable TLS refusal rate for my domain?
Most domains see between 5% and 15% of their receiving servers refusing TLS in any given period. If you see rates above 30%, it is worth investigating whether a major partner or critical domain has changed its mail server configuration.
Bottom Line
TLS refusal in email is invisible unless you are looking for it. Your DMARC aggregate reports contain the data. Most organizations never open those reports, so they never see it.
The steps are straightforward: pull your last DMARC report, look for the TLS values in the PolicyEvaluated section, identify any receiving domains showing TF, test those servers manually to confirm, and decide whether to contact the domain owner or accept the risk.
If you want TLS refusal tracking automated alongside your DMARC monitoring, DMARCFlow parses the TLS section of every report and alerts you when new domains start refusing encryption or when established partners suddenly stop accepting it.