Transport Layer Security (TLS) protects the connection carrying an email. Message encryption protects the contents beyond a single connection. For confidential business correspondence, choose the design by deciding who may read the message: the mail operators along its route, an approved delivery service, or only the people holding the required decryption keys.
Start with the places where the contents must stay unreadable. TLS belongs in the transport design whichever additional protection is chosen. Recipient access and key ownership determine what happens after that connection ends.
Follow a confidential quotation through the mail route
Consider a hypothetical manufacturer sending a confidential quotation to an authorized buyer at a distributor. Assume the message passes from the manufacturer's mailbox platform through an outbound filtering gateway, then to the distributor's mail platform and the buyer's inbox.
The route: sender's mailbox platform → filtering gateway → recipient's mail platform → recipient's email application.
Each connection can use TLS. The SMTP STARTTLS specification protects communication between mail systems, rather than providing end-to-end message confidentiality. When a system terminates that connection, it can process the message it received unless the contents have another layer of encryption. The filtering gateway may therefore inspect the quotation before passing it onward over a new encrypted connection. The receiving platform can make it available to the buyer according to that platform's permissions.
Microsoft's explanation of email transport security makes this boundary explicit: TLS encrypts the connection between systems. It does not apply continuing access restrictions to the delivered message. Protecting those network hops is valuable, but the manufacturer must also decide whether it trusts the systems processing the quotation.
Delivery policy matters too. Microsoft documents that Exchange Online normally attempts TLS but can send without it when an external recipient does not support it, unless configured to require a secure connection. That is a Microsoft example, not a universal description of mail services. If this quotation must never travel over an unencrypted hop, specify the required route and what should happen when secure delivery is unavailable. Do not leave fallback behavior implicit.
The UK National Cyber Security Centre's email transport guidance recommends TLS support and describes requiring authenticated TLS connections with regular correspondents. Confirm the actual mail operators' supported settings and failure handling.
Decide whether access must follow the message
Suppose the manufacturer trusts both companies' mail operators, but wants the quotation available only through an approved recipient-access process. A service that encrypts the message and checks the reader's identity can address that requirement beyond the transport connection. Depending on the product and policy, the reader may open it in a supported mail application or a protected web portal.
For example, Microsoft Purview Message Encryption combines encryption with identity and authorization policies. Microsoft distinguishes an encrypt-only option from an option that restricts forwarding, and documents different recipient experiences. These are product-specific choices: encryption alone should not be interpreted as a promise that copying, forwarding, downloading, or later access is restricted.
A portal also remains part of the trust decision. Establish which service holds the keys, how it authenticates the buyer, and whether the quotation or its attachments become ordinary downloaded files. A legitimate reader can still disclose information they can see; access controls do not remove the need for an approved recipient and appropriate handling.
Now change the requirement: the quotation must remain unreadable to the mail intermediaries themselves. That calls for a design in which encryption and decryption occur at the approved endpoints and those intermediaries do not hold the necessary keys. Secure/Multipurpose Internet Mail Extensions (S/MIME) is one approach to evaluate with both organizations. It requires compatible clients and a workable certificate and key-management process.
The Internet Engineering Task Force's RFC 9787 guidance on end-to-end email security, published in August 2025, discusses S/MIME and OpenPGP-based protection, along with usability and interoperability problems. For deployment, agree how recipient keys, device access, recovery, replies, and attachments will work.
Place inspection where the contents are available
Content inspection needs access to the content it is expected to evaluate. If the sender encrypts the quotation before the gateway receives it and the gateway has no decryption key, that gateway cannot inspect the protected quotation as plaintext. Place the required inspection before encryption or after authorized decryption, and assign responsibility for it.
Network Box USA's Managed Cloud Email Security (MCES) supports SMTP, SMTPS, and STARTTLS mail environments and provides message filtering, email-policy enforcement, reporting, and managed operational support. SMTP is the server-to-server mail protocol; SMTPS and STARTTLS are ways to protect mail connections with TLS. MCES service design includes validating mail flow and policy behavior, so the teams can establish where filtering and confidentiality controls meet.
Agree the actual route, encryption stage, inspection access, and delivery-failure process. Confirm any recipient portal, S/MIME key management, rights-management integration, or required-TLS policy separately; protocol support does not establish those capabilities. The customer retains responsibility for approving recipients and information handling, while the relevant mail, encryption, and endpoint operators maintain their agreed parts.
Our protected-attachment inspection guide addresses the related situation where a file arrives unreadable to scanning. Our email DLP example answers the earlier business question: whether the transfer should be permitted at all.
Replace “encrypted email” with a usable requirement
For the hypothetical manufacturer, assume the approved requirement is to trust the designated mail and delivery operators, protect every transport hop, and require the intended buyer to authenticate before viewing the quotation. Its service brief could read:
Deliver the quotation through an approved recipient-authenticated service. Protect the required mail connections with TLS and use the agreed failure process if secure delivery cannot be completed. Identify which operators can access plaintext, where inspection occurs, and whether downloaded attachments retain protection. Include replies in the design.
That brief selects a service-managed access model for this example. If keeping content unreadable to mail intermediaries is mandatory instead, the brief must require endpoint-held encryption and account for the resulting inspection and key-management changes.
Before using real quotations, walk a harmless sample through the buyer's actual application, attachment handling, and reply path. Have the operators demonstrate the required failure and access behavior. To discuss how managed email filtering fits your confidential correspondence, contact our team with the mail route, intended readers, and the confidentiality requirement. Use a description rather than submitting sensitive documents through the form.