我有一個透過 Mailchimp 和 Google 發送電子郵件的網域。我已經為它們設定了 DKIM，並添加了 DMARC 記錄（用於測試 atm）。我收集 DMARC 失敗的報告，其中絕大多數報告都是 SPF 失敗的。
根據我的理解，SPF 是可以發送電子郵件的 IP/主機的白名單，DKIM 是寄件者必須用來簽署電子郵件的金鑰。對我來說，DKIM 似乎更適合欺騙保護。
在我搜尋的所有地方，我都只看到 SPF 對於電子郵件保護至關重要，但在我的情況下我不明白為什麼。由於設定了 DKIM，只有 Mailchimp 和 Google 可以發送電子郵件，而 DMARC 將使收件者拒絕來自其他任何地方的電子郵件。限制 IP 位址似乎並沒有為這種組合帶來任何好處。
在這種情況下可以使用 +all 來停用 SPF 嗎？如果我這樣做，在什麼情況下我會受到較少的保護？
答案1
SPF、DKIM 和 DMARC 協同工作，以提高您的網域的信任度以及將電子郵件傳送到收件匣。但是，要記住的重要一點是，收件者電子郵件系統可以自由地以他們想要的任何方式處理您的電子郵件。因此，不能保證這些機制中的任何一項或多項都正確實施。
SPF 和 DKIM 本身最重要的一點是，它無法確保from標頭經過身份驗證。這是收件者在其郵件用戶端中看到的電子郵件地址。因此，它們不能有效地確定最終用戶所看到的內容是否為真。
return-path對於 SPF，它僅檢查SMTP 訊息中標頭（也稱為信封寄件者）中指定的網域。這不是最終用戶看到的地址。
對於DKIM，它只關心標頭d=中參數中指定的域dkim-signature。同樣，最終用戶看不到這一點。
DMARC 修復了此問題。 DMARC 要求在任一 SPF 上「對齊」正確或者DKIM。
- 為了使 SPF 處於「對齊」狀態，標
from頭中的域必須與標頭中的域相符return-path。當透過第三方大量郵件提供者發送電子郵件時，這種情況很少發生，因為return-path提供者會追蹤退回郵件和投訴，並且通常是由第三方管理的電子郵件地址。這就是您在 DMARC 報告中看到 SPF 失敗的原因。 d=對於 DKIM，標頭欄位中指定的網域dkim-signature必須與標頭中的網域相符from。這可以透過確保第三方寄件者（即 Mailchimp）正確配置 DKIM 簽章並且您已將適當的 DNS 記錄新增至您的網域來實現。
此「對齊」檢查可確保最終使用者在其電子郵件用戶端中看到的內容經過 SPF 或 DKIM 的身份驗證。如果傳遞的 SPF 記錄或 DKIM 記錄與標頭（最終使用者看到的內容）一致from，則郵件將通過 DMARC。否則，DMARC 將會失敗。
請注意，這些協議僅檢查電子郵件地址的「網域」部分。標誌後面的部分@。這些都不會檢查使用者名稱部分的有效性。標誌之前的部分@。
因此，您可以看到 SPF 和 DKIM 對於 DMARC 的完整功能都是必要的。所有這三個都是正常郵件流所必需的。而且，並非所有收件者電子郵件系統都以相同的方式或正確地實施這些標準。
對於系統管理員來說，一個巨大的挫折感是，大量寄件者在發送電子郵件時仍未正確配置這 3 個標準。而且，遺憾的是，上述基本原則很少在任何地方得到正確解釋。
答案2
是的，因為並非所有伺服器都會在接收時檢查 DKIM/DMARC，但目前 SPF 檢查更加整合/部署。
On-Prem Exchange 的伺服器就是一個例子。可以使用反垃圾郵件規則集檢查 SPF 記錄，並在更高版本中使用邊緣傳輸角色，但 DKIM/DMARC 需要第三方整合才能啟用它。
在這種情況下刪除您的 SPF 記錄可能會讓您面臨這種情況下的組織可能會收到欺騙性電子郵件。
答案3
雖然只有授權伺服器可以使用 DKIM 進行簽名，但 DKIM 標準中沒有任何內容可以通知接收伺服器來自您的網域的郵件必須使用 DKIM 進行簽名。從郵件標準的角度來看，接收伺服器無法區分授權的發送伺服器和未經授權的發送伺服器。
最終出現的問題是，對於不使用 DMARC 測試的接收伺服器，您的網域將很有可能被列入黑名單，因為垃圾郵件發送者發現欺騙是微不足道的。