Is your business email actually encrypted?

"We use encryption" is the least informative sentence in the email industry. It is almost always true, and it almost never means what the person hearing it thinks it means. What owners picture is a sealed envelope that only the recipient can open. What they actually have is a series of armoured trucks, each carrying an unsealed letter between two buildings, where the letter sits on a desk in readable form at every stop.

That is not a scandal. For most business mail it is fine. But you cannot make a sensible decision about what to put in an email until you can name the three separate layers and say which ones you have.

Layer one: you to your own mail server

This is the connection between your phone, laptop or webmail browser tab and the server that holds your mailbox. It is the layer most people mean when they say email is encrypted, and it is the one most reliably in place: any reputable host requires TLS here and refuses plaintext logins outright.

It is also the layer with the clearest guarantee. TLS is designed to prevent eavesdropping, tampering and message forgery, and data sent over the channel after establishment is only visible to the endpoints [2]. On a coffee-shop network, this is what stops the person two tables over reading your mail or stealing your password.

The catch is that this layer ends at your own server's front door. Everything past that door is a separate question with a separate answer.

Layer two: server to server, and why it is optional by default

When your server passes the message to the recipient's server, the two machines negotiate encryption using the STARTTLS extension to SMTP [1]. The word to focus on is negotiate. The sending server asks whether the receiving server supports TLS, and if the answer is yes, they encrypt.

If the answer is no, the default behaviour across the internet is to send anyway, in the clear. This is not a bug or a lazy configuration; it is a deliberate design called opportunistic security, which means using encryption even when authentication is not available, and using authentication when possible, in order to remove barriers to widespread encryption [5]. Given the alternative was mail simply not being delivered, it was the right trade. RFC 7672 puts it bluntly: because the destination server is selected indirectly through DNS MX records and neither email addresses nor MX hostnames signal a requirement for secure transport, SMTP transport security is by necessity opportunistic [4].

The consequence is the part worth understanding. Opportunistic TLS is a high barrier against passive interception - someone quietly tapping a cable gets nothing. It is a much weaker barrier against an attacker who can actively interfere. RFC 3207 describes the attack directly: a man-in-the-middle can be launched by deleting the "250 STARTTLS" response from the server, which causes the client not to try to start a TLS session [1]. Another variant lets the server advertise STARTTLS but alters the client's request and the server's response [1]. RFC 8461 makes the same point about attackers who can delete parts of the SMTP session or redirect it entirely by overwriting a resolved MX record, and calls these downgrade or interception attacks [3].

Nothing breaks visibly when this happens. There is no warning in your sent folder. The mail goes through.

Making the second layer non-optional: MTA-STS and DANE

Two standards exist specifically to remove the "or send it in the clear" fallback, and they solve it in different ways.

MTA-STS lets a mail provider declare its ability to receive TLS-secured SMTP connections and specify whether sending servers should refuse to deliver to hosts that do not offer TLS with a trusted server certificate [3]. The policy is published through a combination of DNS and HTTPS, and it states what a conforming sender should do with messages when TLS cannot be successfully negotiated [3]. In effect it turns a suggestion into a commitment: a sending server that respects the policy will not quietly downgrade.

DANE takes a different route, using DNS TLSA records to signal TLS support and publish the means of authenticating the server. RFC 7672 describes the result as opportunistic DANE TLS, resistant to downgrade and man-in-the-middle attacks, enabling an incremental transition of the email backbone to authenticated TLS delivery [4]. Its trust anchor is DNSSEC rather than the certificate authority system, and it requires DNSSEC support on the client side plus a DNSSEC-published TLSA record on the server side [4].

You do not implement either of these yourself. They are your provider's job. What you can do is ask whether your domain has one of them, because that single question separates hosts who take transport seriously from hosts who use the word "encryption" in marketing copy.

Layer three: the message itself, which TLS never touches

Here is the layer that surprises people. TLS protects connections. It does not protect messages. When the armoured truck arrives, the letter comes out of the truck.

RFC 3207 states this outright: SMTP is not an end-to-end mechanism, so if a client and server pair decide to add TLS privacy, they are not securing the transport from the originating mail user agent to the recipient [1]. It goes further - because delivery of a single message may pass through more than two SMTP servers, adding TLS to one pair does not mean the entire SMTP chain has been made private [1]. And the STARTTLS extension is not suitable for authenticating the author of a message unless every hop in the delivery chain, including the submission to the first server, is authenticated [1].

Practically: your mail sits in readable form on your server, on the recipient's server, and on any relay in between. Anyone with administrative access to those machines, any backup of them, and any lawful order served on their operators reaches the content. Encryption of stored mail at rest helps against a stolen disk; it does not change who at the provider can read it in normal operation.

Only content encryption - encrypting the message body itself before it leaves your machine - closes that. And it is genuinely burdensome, which is the next section.

What TLS does not hide, even when it is working perfectly

Even a fully encrypted, policy-enforced connection leaks the shape of your correspondence. TLS protects the content of the channel, not the existence of it. Who is emailing whom, when, and how often, all remain visible to an observer on the path.

Size leaks too. TLS 1.3's own specification says TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis [2]. Appendix E.3 is more direct: TLS is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets, and provides no specific defence against them beyond that optional padding [2]. In email terms, an observer can tell that your firm sent a large attachment to a particular law office on a particular afternoon, even if the contents stay sealed.

The honest concession: most of you do not need layer three

For the overwhelming majority of small business mail - quotes, scheduling, invoices, back-and-forth with suppliers - opportunistic TLS plus a reputable host is genuinely adequate protection. The realistic threat to your business is not a state actor splicing a fibre link. It is a stolen password, a convincing phishing email, or a stale ex-employee account nobody disabled. Strong passwords, two-factor authentication and prompt account removal buy you far more real safety than any encryption upgrade.

And end-to-end message encryption has a cost that is rarely stated honestly: key management. Every correspondent needs keys. Keys expire, get lost with a replaced laptop, and do not work on the phone. Most small teams deploy it enthusiastically and abandon it within a month, at which point they have a false sense of protection plus one archive of messages nobody can open. Half-implemented encryption is worse than none, because it changes what people are willing to write down.

So when is it warranted? When the content is genuinely sensitive: health information, legal detail, banking and payment credentials, government identifiers, employee records. Canadian privacy law frames this proportionally rather than absolutely. PIPEDA's safeguards principle requires protection appropriate to the sensitivity of the information, and states that the nature of the safeguards will vary depending on the sensitivity of the information collected, its amount, distribution, format and storage method, and that more sensitive information should be safeguarded by a higher level of protection [6]. Technological measures such as passwords and encryption are listed alongside physical and organizational measures, not as a substitute for them [6].

Read plainly, that means a higher bar for the sensitive material and the ordinary bar for everything else. It also points at an option people forget: the honest alternative is frequently to not put that content in email at all. A phone call, an in-person handoff, or a link to a portal where the recipient authenticates before seeing anything are all easier to sustain than a key infrastructure, and they remove the permanent readable copy sitting in two mailboxes forever.

Do this this week

Send your provider three questions and require three separate answers. One: is TLS enforced, not merely offered, on connections between my devices and your servers? Two: do you publish an MTA-STS policy or DANE records for my domain, so mail to us cannot be silently downgraded? Three: is mail encrypted where it is stored, and who on your staff can read it?

Then do the non-technical half. Pick the two or three categories of information your business handles that you would not want printed in the local paper, and decide now which channel each one uses. Write it down in a sentence a new employee can follow. That decision protects you more than any protocol on this page.