DMARC 和加密解決不同的電子郵件風險。 DMARC可協助接收系統評估網域是否正在透過一致的、經過驗證的路徑使用。加密可保護傳輸躍點之間的訊息數據，或採用不同的設計，保護訊息端點之間的訊息資料。兩個控制項都不會自動為另一個控制項提供支援。
這種區別很重要，因為相同的訊息可以得到很好的驗證，並且仍然可以在沒有您想要的傳輸保證的情況下傳輸。訊息也可以透過加密連線傳輸，同時聲明沒有一致身份驗證的寄件者網域。
從保護問題開始
在選擇控制項之前詢問必須保護什麼：
- 保護問題：通過的認證域是否與From中的域一致？相關機轉： DMARC與 SPF 或者 DKIM;它沒有確定什麼：機密性、寄件者意圖或安全內容
- 保護問題：訊息是否由 d= 域的DKIM私鑰持有者簽署？相關機制： DKIM ；它沒有建立什麼：人類身分、保密性或收件匣放置
- 保護問題：此SMTP傳遞躍點是否需要使用可接受的TLS ？相關機制： MTA-STS 或其他運輸政策；它沒有建立什麼：端到端機密性或來自域 結盟
- 保護問題：接收者可以解密傳送給該接收者的內容嗎？相關機制：訊息層級加密；它不建立什麼： DMARC對齊，除非單獨配置
此矩陣描述的是控制邊界，而不是產品排名。完整的架構可以使用多種機制，因為威脅是不可互換的。
遵循一條合成訊息路徑
考慮透過直接SMTP傳送從billing@shop.example.com發送到accounts@buyer.example.org虛構發票。發送服務使用bounce.mailer.example.net的信封網域並使用d=shop.example.com.假設適用的DMARC策略並已完成身份檢查。在這個綜合場景中，發送 MTA 從https://mta-sts.buyer.example.org/.well-known/mta-sts.txt.發現並擷取接收網域buyer.example.org的有效強制模式MTA-STS策略。它檢查所選目標mx1.buyer.example.org是否與策略匹配，然後連接並協商TLS ，在傳輸訊息之前驗證MX憑證。
在下面 RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 和 RFC 8461 §5，假設的控制將支持這些陳述：
- DKIM可以提供對齊的傳遞路徑，因為簽章經過驗證且其 d= 網域與本範例中的 From 網域相符。
- DMARC可以在訊息層級透過對齊的DKIM路徑傳遞。
- 接收SMTP躍點根據接收方域的已發布傳輸策略使用TLS ，前提是該策略有效、目前且正確應用。
- 這些事實都不能證明發票是真實的，寄件者的帳戶沒有受到損害，或者郵件的每個先前和後來的副本都保持加密狀態。
現在僅將簽章網域變更為d=mailer.example.net. DKIM仍然可以通過，但該不相關的網域將與shop.example.com不一致。受 TLS 保護的傳送躍點不會修復該對齊失敗。
將DKIM簽章和加密分開
在下面 RFC 6376 §3.7， DKIM對選定的訊息資料套用加密簽章。驗證者使用為 選擇器 d=域。簽名提供有關簽名內容和簽名域的證據。它並不隱藏該訊息。
加密有不同的目的。在下面 RFC 3207 §6, SMTP TLS保護系統之間協商連接上的數據，而不是完整的端對端訊息路徑。 MTA-STS允許接收域發布策略，合規寄件者可以在驗證到其MX主機的TLS傳送時使用該策略。 TLS報表可以提供有關傳輸失敗的總計回饋 RFC 8460 §4.1, RFC 8460 §4.2 和 RFC 8460 §4.3。這些控制不會將SMTP郵件轉變為端對端加密物件。
訊息級加密是另一層，如S/MIME所示 RFC 8551 §1 和 RFC 8551 §3.3。它可以保護內容，以便只有具有合適金鑰的預期端點才能讀取它，但金鑰分發和憑證處理，例如 RFC 8551 §4 事情。接收者能力、復原和存檔存取也需要明確的操作設計。 DMARC仍然是對可見域和一致身份驗證的單獨評估。
定義每個信任決策
有用的設計記錄為每個控制項命名了四件事：
- 控制： DMARC ；身分或資產：From 中的網域；信任錨： DNS策略加上一致的SPF或DKIM結果；要保留的證據：受信任的接收者結果和適用的政策
- 控制： DKIM ；身分或資產：簽章網域和選擇器；信任錨： DNS公鑰；保留證據：簽章、驗證結果和金鑰記錄
- 控制： MTA-STS ；身分或資產：接收域和MX傳輸；信任錨： DNS發現加HTTPS策略；保留證據：保單ID、取得的保單和投遞結果
- 控制：訊息加密；身分或資產：接收者或端點金鑰；信任錨：選擇金鑰和憑證信任模型；要保留的證據：加密狀態、收件者對映和金鑰生命週期
不要將這些轉化為單一的綠色徽章。每個答案都有較窄的意思和不同的故障模式。
將控制措施映射到威脅
DMARC可以使參與的接收者更容易識別和處理對受保護域的未經授權的使用。它不能防止合法帳戶被濫用、檢查付款請求是否真實或加密儲存的郵件。
TLS可以減少受保護躍點上被動攔截的風險。它不驗證寄件者域。與錯誤或不受信任的目標協商TLS系統無法獲得與策略強制、經過驗證的連線相同的保證。
訊息加密可以保護傳輸會話之外的內容，具體取決於其設計。它本身不會創建DMARC一致性、授權業務交易或消除端點洩漏。
建立證據但不要誇大其詞
對於身份，捕獲代表收到的訊息並記錄寄件者、信封身份、每個DKIM d= 網域、原始身份驗證結果、對齊和DMARC處置。對於傳輸，保留MTA-STS策略、 MX範圍和TLS報告證據。對於訊息加密，記錄誰持有金鑰、收件者如何註冊、金鑰遺失時會發生什麼以及哪些系統可以存取明文。
實驗室測試應標記為測試。它並不能證明每條生產路線的行為都是一樣的。驗證影響控制目標的小容量服務、轉送路由、備份MX主機以及行動或存檔存取。
分配單獨的所有者和恢復路線
郵件操作通常擁有身份驗證和SMTP傳輸。安全架構可能擁有策略、威脅覆蓋範圍和加密標準。應用程式團隊擁有產生業務郵件的發送路由。法律和記錄團隊可能會影響內容保留和金鑰恢復要求。
為每個控制項提供一個升級觸發器。對齊回歸涉及寄件者所有權和郵件操作。 TLS策略失敗將歸咎於傳輸和DNS所有者。遺失的訊息加密金鑰將進入金鑰管理復原過程。一個通用的「電子郵件安全」佇列隱藏了需要做出的決定。
明確購買決定
在批准一個專案之前，為所需的結果寫一句話。 「減少對我們的寄件者網域的未經授權的使用」指向DMARC和一致的身份驗證。 「需要可接受的TLS才能交付到我們的域」指向傳輸策略。 「保持訊息內容在核准的端點之外不可讀」需要訊息加密設計。
這些結果可以共存。重要的決定是為缺失的保護提供資金，而不是假設熟悉的電子郵件安全縮寫詞同時涵蓋身分、機密性和商業合法性。
將結論保留在證據範圍內
對於發票固定裝置，請在不同的證據欄位中保留成功的DKIM對齊和經過驗證的SMTP躍點。如果僅 d= 變更為不相關的提供者網域，而SPF保持未對齊，則TLS仍不會建立對齊的身分。這裡描述的策略取得、 TLS協商和簽名驗證是假定的教學輸入，而不是執行的網路或訊息測試。