傳輸TLS和S/MIME解決不同的問題。 TLS保護相鄰系統之間的連接。 S/MIME可以對郵件內容進行簽署或加密，以便保護隨郵件一起傳遞。這是否是真正的端到端取決於金鑰的保存位置以及簽名或解密發生的位置，而不僅僅是電子郵件用戶端是否顯示安全性圖示。
選擇控制項之前繪製路徑
參考： RFC 3207 §1, RFC 8551 §1.
使用從 Alice 的用戶端到她的提交服務的訊息，然後是出站網關、收件人的MX服務以及 Bob 的郵箱和用戶端。每個網路躍點都可以有自己的TLS連線和策略。成功的域間SMTP TLS連線本身並沒有說明提交、內部中繼、郵箱存取或儲存加密。
在終止TLS每個伺服器上，普通訊息內容可用於處理，除非單獨加密。因此，過濾器、網關和受損端點仍然是機密邊界的一部分。 MTA-STS 和SMTP DANE 改善適用路線的運輸認證和執行；兩者都不會將逐跳TLS轉換為訊息加密。 RFC 8461第 2 節.
區分簽章和加密
參考： RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
S/MIME簽章內容根據憑證信任和驗證提供完整性和簽署者身分驗證證據。單獨簽名並不能隱藏該訊息。 S/MIME封裝內容對受保護的資料進行加密，收件者的金鑰可以對其進行解密；單獨的加密並不等同於經過驗證的作者簽名。正如RFC 8551 §3.4 所解釋的那樣，經過身份驗證的封裝內容還可以提供機密性和資料完整性，而無需證明來源。不要將這種保護與經過驗證的作者簽名等同起來。工作流程可以結合簽章和加密。 RFC 8551第 2 節和第 3 節.
金鑰和憑證身分需要生命週期管理。確認誰可以存取私鑰、收件者如何取得憑證、過期或遺失的金鑰如何影響對存檔郵件的存取以及授權的復原過程。這些是操作設計問題，而不是廣泛分發私鑰或假設網域身份驗證檢查取代憑證驗證的原因。
比較同一郵件的威脅
參考： RFC 8551 §3.1, RFC 8551 §6.
為了被動觀察正確加密的SMTP躍點， TLS會保護該躍點上傳送的位元組。對於在TLS終止後閱讀郵件的網關管理員來說，躍點加密不提供內容機密性障礙。如果用戶端S/MIME加密不持有解密金鑰，則可以保護加密主體免受該網關的攻擊。這個詞可能很重要，因為某些部署有意在網關處解密。
對於傳輸後的更改，有效的S/MIME簽章可以公開對簽章內容的變更；事實上，較早的TLS連線無法成功。對於擁有解密金鑰的受損接收方用戶端， TLS和S/MIME加密都不會阻止用戶端存取明文。對於可見的路由元資料和外部標頭，不承諾完全隱藏：覆蓋範圍取決於訊息包裝和實作。
私人審查證據包含描述這些邊界的明確路徑和威脅矩陣。它是一個設計模型，而不是加密互通性測試。當地的 TLSA 包中其他位置的憑證裝置不會建立S/MIME簽章或解密行為。
一起選擇控制和驗收證據
參考： RFC 8551 §4, RFC 8551 §6.
指定哪些躍點需要強制TLS 、哪些內容需要簽章或加密、允許解密的位置。在受控環境中測試代表性用戶端、附件、轉送和存檔存取。在聲明工作流程在特定路徑上保留簽名或機密性之前，保留正面驗證和負面更改內容的情況。
保持 網路釣魚 和業務流程聲明是分開的。經過身份驗證的寄件者或簽名的訊息仍然可能包含錯誤或欺詐性的付款請求，尤其是在帳戶洩露之後。對後續行動的獨立驗證仍然是必要的。本指南沒有對S/MIME訊息進行簽署、加密、傳送或解密；其證據是可檢查的控製到威脅矩陣，而客戶端互通性仍然是一項明確待驗收的任務。