使用子域委派的電子郵件 FROM 標頭身份驗證

我們公司擁有該域somecompany.com並使用外部電子郵件提供商emailemailprovider.com發送電子郵件。電子郵件提供商建議為他們委派一個子域以自動處理 SPF / DKIM / 等電子郵件身份驗證機制。所以我們在我們的 DNS 區域中添加了這個：

em.somecompany.com NS ns1.emailemailprovider.com
em.somecompany.com NS ns2.emailemailprovider.com

從那時起，我們就可以通過他們的 API 發送電子郵件，而不會落入收件人的垃圾郵件文件夾中，並將From標頭設置為任何地址，例如user@em.somecompany.com,user@somecompany.com或user@other.somecompany.com. 請注意，在所有 3 種情況下，Return-Path標題域仍然存在。em.somecompany.com

我知道如何user@em.somecompany.com通過我們的設置進行身份驗證，但我不明白為什麼其他 2 個 FROM 地址被收件人認為是有效的。

Return-Path我隱約理解header和header的區別From，但是如果公司的子域不是由同一個實體擁有和管理，這不會導致嚴重的身份驗證缺陷嗎？

您問題的關鍵在於您問題的這一部分：

SPF、DKIM等 電子郵件認證機制。

等實際上稱為 DMARC 。稍後再談。

防曬指數

正如您所提到的，SPF 僅驗證反彈地址，即返迴路徑。通過為所有發送的電子郵件保持相同的退回地址，電子郵件始終通過 SPF。您的電子郵件提供商使用此退回地址來執行退回處理。此外，他們現在可以管理您委派的此子域的 SPF 記錄。

DKIM

由於您通過 NS 記錄委派了子域，因此電子郵件提供商現在還可以在 zone 中創建 DKIM 選擇器記錄_domainkey.em.somecompany.com。因此，現在他們可以從DKIM 簽名中標籤中em.somecompany.com使用的域為您簽名消息。d=

DMARC

實際上有一種標準方法來驗證 FROM 地址域，它結合了 SPF 和 DKIM。它要求其中一種機制通過檢查並與FROM 地址中使用的域對齊。有兩種可能的對齊方式。任何一個

• Strict - 用於 SPF 或 DKIM 的域必須與 FROM 地址中的域完全相同，或者；
• 寬鬆- 用於 SPF 或 DKIM 的域必須共享 FROM 地址中使用的相同組織域。

SPF 和 DKIM 的這些對齊模式分別由aspf和adkim標籤控制。當這些標籤從 DMARC 策略記錄中省略時，它們預設為寬鬆模式。

必須為需要防止欺騙的每個域配置 DMARC 記錄。DNSTXT記錄至少應包含版本和策略標籤，例如“v=DMARC1;p=reject;”

DMARC的RFC 解釋了第 6.3 節中的所有標籤。

請記住，如果子域中沒有 DMARC 記錄，接收伺服器將在 FROM 地址中查找組織域的 DMARC 記錄。

_dmarc.em.somecompany.com 您可以檢查( record)處是否有特定於子域的 DMARC 記錄，TXT並根據那裡的配置設置您自己的記錄。

引用自：https://serverfault.com/questions/994314