使用 IIS SMTP - TLS 為多個域發送電子郵件?
我們正在銷售客戶在本地或不同雲環境中安裝的 Web 應用程序。預設電子郵件設置通過我們 15 年前創建的 Web 服務將電子郵件發送到我們的其中一台伺服器。我們中央伺服器上的 Web 服務在 IIS SMTP 拾取目錄中創建電子郵件以進行傳遞。我們一直警告我們的使用者,此 Web 服務僅用於測試和開發,但許多人在生產中使用它。
幾年前,我們開始遇到傳遞問題,因此我們建議所有使用該服務的客戶設置 SPF。這有很大幫助,但最近我們又開始遇到一些傳遞問題。我認為現在的主要問題是我們沒有使用 TLS,例如 Gmail 在來自我們伺服器的所有電子郵件旁邊都有一個問號。我已經開始考慮設置 TLS,但我不確定如何正確設置。如果我們只為一個域發送電子郵件,那會很容易,但我們正在為大約 30 個域發送電子郵件。
在教程中,我看到他們在配置 TLS 設置時指定了 FQDN。但是當有這麼多域通過我們的伺服器發送時,我們該怎麼做呢?我可以只為 mail.mycompany.com 設置一個證書,並將其用於所有域嗎?
是的,您的郵件伺服器應該有一個規範名稱,例如
mail.example.com
。理想情況下,您會在任何地方使用該名稱:
- 在
HELO
主機名和 SMTP 橫幅中- 在反向 DNS
PTR
記錄中(帶有匹配的A
)- 作為證書的通用名稱。
此域不必(技術上也不能)匹配伺服器用於發送電子郵件的每個域。任何人都不需要
HELO
主機名和信封發件人或標頭之間的這種匹配。From
這與 TLS 完全相同。不是問題!只需在您的 MTA 部分啟用 TLS,該部分用作其他 MTA的客戶端。
對於電子郵件,發送 MTA 不會檢查接收 MTA 證書的真實性,除非它被配置為尊重 DANE ( RFC 6698 )
TLSA
記錄;傳遞郵件通常被認為更重要。此外,接收 MTA 根本不檢查發送 MTA 的證書,即沒有與客戶端證書的**相互身份驗證。由於這兩個原因,自簽名證書就可以了,但是由於 Let’s Encrypt 為任何人提供免費且簡單的證書,因此也沒有理由不使用它們。此外,配置完整的 SPF + DKIM + DMARC 三位一體可以進一步提高傳遞率。