Ordinary email is closer to a postcard than a sealed letter. It travels through servers you do not control, and whether the trip is protected depends on the other side. Microsoft Learn is plain about this for Exchange Online: it “always uses opportunistic TLS,” meaning it tries to encrypt the connection first, but “by default Exchange sends the message without encryption if the recipient’s organization doesn’t support TLS encryption.” Most large mail providers support it. A customer’s small business web host may not.
So the practical question is not “should we encrypt email.” It is “which method, for which messages, and how much friction can we live with.” That is a business decision more than a technical one: every option past the default costs somebody effort, and the option nobody uses protects nothing. Here they are, from invisible to genuinely annoying.
Level One: The Encryption Already Running Underneath
Transport Layer Security, or TLS, encrypts the connection between mail servers. It is already on, costs nothing, and users never see it. If you do nothing else, this is what you have.
Understand its limits. They are frequently misunderstood. Microsoft Learn states it directly: “TLS doesn’t encrypt the message, just the connection.” Forward a message that arrived over a protected connection to an organization that does not support TLS, and the documentation says “that message isn’t necessarily encrypted.” Once it lands, it sits in a mailbox as readable text, and anyone with access to that mailbox can read it.
There is a stricter version. Microsoft Learn describes forced TLS, where you configure a trusted channel with a specific partner organization, and that partner has to “authenticate to Exchange Online with a security certificate.” Good fit for constant traffic with one known partner, such as an outsourced billing company. Poor fit for one-off messages to strangers.
Hassle level: zero. What it protects: the message while it is moving, sometimes.
Level Two: The Encrypted Message You May Already Own
This is the sweet spot for most small and mid-sized businesses, and a surprising number already pay for it without knowing. Microsoft Learn describes Microsoft Purview Message Encryption as a service that “lets you send encrypted email to people inside or outside your organization, regardless of the destination email address,” naming Gmail, Yahoo Mail, and Outlook.com. It can fire automatically: “When a user sends a message that matches a rule, encryption is applied automatically.”
The recipient experience is where the grumbling starts. According to Microsoft Learn, recipients “can either get a one-time passcode, sign in with a Microsoft account, or sign in with a work or school account associated with Office 365,” and “They don’t need a Microsoft 365 subscription to view encrypted messages or send encrypted replies.” No software to install either, since “No special client side software is needed as long as the encrypted message (sent as an HTML attachment) can be opened in a browser.”
People will still complain. An extra click, a code pasted from another email, a browser window instead of their inbox. Expect it and warn them in advance. The part that matters most is key management: Microsoft Learn notes that “Microsoft securely manages and stores the keys, so you don’t have to.” That is why this option is realistic for a ten-person company and the next one usually is not.
One honest caveat. Microsoft Learn points out this method “doesn’t let you apply usage restrictions to messages,” so it cannot stop a recipient forwarding or printing what you sent. If you need that, the documentation describes Information Rights Management, which “helps prevent sensitive information from being printed, forwarded, or copied by unauthorized people,” while warning that “Some applications may not support IRM emails on all devices.”
Hassle level: low for you, mild for recipients. What it protects: the message itself, wherever it goes.
Level Three: Certificates, and the Reason Nobody Loves Them
S/MIME is the traditional end-to-end approach. Microsoft Learn calls it “a certificate-based encryption solution that allows you to both encrypt and digitally sign a message,” and notes it “addresses sender authentication with digital signatures.” The recipient can verify who sent it, not just read it.
Then comes the key management reality, and this is where small businesses quietly give up. Microsoft Learn is explicit: “To use S/MIME, you must have public keys on file for each recipient,” and “Recipients have to maintain their own private keys, which must remain secure.” Worse, “If a recipient’s private keys are compromised, the recipient needs to get a new private key and redistribute public keys to all potential senders.” Read that as a support workload.
One more tradeoff. Microsoft Learn notes that “S/MIME doesn’t allow encrypted messages to be scanned for malware, spam, or policies.” Strong privacy and strong inbound filtering pull against each other. Given how much risk arrives as convincing phishing mail, that is not a small thing to trade away.
Hassle level: high, and ongoing. What it protects: the message end to end, if both sides maintain their keys correctly.
When a Secure File Link Beats Encrypting the Message
Here is the option people skip. Often the sensitive thing is not the message, it is the attachment. The email says “here is the signed agreement.” The agreement is the secret. Encrypting the email is solving the wrong problem.
Put the file in your existing business file storage, share a link scoped to that one person, set an expiration, and send an ordinary email containing the link. You get access you can revoke later, which encrypted email cannot offer once the message is delivered. You get a record of who opened it. And the recipient experience is one they already know.
That last part cuts both ways. Training people that “click the link and sign in” is a normal way to receive sensitive documents is exactly the habit attackers exploit. If you go this route, be consistent about the platform you use, tell recipients what to expect, and never send a link asking them to authenticate somewhere unfamiliar. The same logic applies to the accounts protecting all of it, which is why choosing a strong authentication method matters more than any single email decision.
Matching the Method to What You Are Sending
Sort your outbound mail into a few buckets and stop overthinking it.
- Routine business correspondence. Scheduling, quotes, general questions. Default transport encryption is fine. Adding friction here just trains people to route around it.
- Sensitive content in the message body. Account details, personal information, anything you would not want forwarded. This is what message encryption exists for.
- Sensitive documents. Contracts, records, statements, spreadsheets. Usually better served by a scoped, expiring link than by encrypting the email carrying it.
- A steady stream to one known partner. Worth setting up a forced connection with that organization once and forgetting about it.
One last warning that saves support calls. Microsoft Learn advises against applying multiple email encryption technologies to the same message, because some clients “aren’t able to open messages with multiple email encryption technologies applied.” More layers is not automatically better.
The Bottom Line
The best encryption method is the one your staff will actually use on the messages that matter. For most businesses that means leaving default transport encryption alone, turning on the message encryption already bundled in your subscription for the slice of mail that needs it, using shared links for documents, and skipping certificate-based encryption unless a partner or requirement forces it. That is not a compromise. It is an accurate reading of where the risk is.
If you want someone to check what your subscription already includes, turn on the pieces you are paying for, and write the one-page rule your team can follow without calling for help, we do that for small and mid-sized businesses across Denton County. Contact us today.
Sources:
Comments are closed