DKIM 簽名不匹配比根本不簽名 DKIM 更糟糕嗎？
如果我使用在 DNS 中沒有相應公鑰的私鑰簽署郵件，這是否比根本不簽署郵件更糟糕（為了可傳遞性）？
我知道將取決於接收郵件伺服器，它可以執行牠喜歡的任何規則，但我希望有關於此的一般指導。
我問的原因是我將控制一些郵件的簽名，但我不能確定負責更新 DNS 記錄的人是否/何時會完成他們的工作。如果我只是設置我的結束，簽名，如果他們很久沒有解決添加 DNS 記錄，這是一個大問題嗎？
根據 RFC 6376：
6.3 . 解釋結果/應用當地政策
描述身份評估者可以執行的操作超出了本規範的範圍，但是帶有經過驗證的 SDID 的郵件為身份評估者提供了未經身份驗證的電子郵件沒有的機會。具體來說，經過身份驗證的電子郵件會創建一個可預測的標識符，通過該標識符可以可靠地管理其他決策，例如信任和聲譽。相反，未經身份驗證的電子郵件缺乏可用於分配信任和聲譽的可靠標識符。將未經身份驗證的電子郵件視為缺乏信任和沒有正面聲譽是合理的。
通常，使用 DKIM 驗證輸出的模組不應僅根據缺少任何簽名或無法驗證的簽名來確定消息的可接受性；這種拒絕將導致嚴重的互操作性問題。如果 MTA 確實希望在 SMTP 會話期間拒絕此類消息（例如，在與根據事先協議同意僅發送簽名消息的對等方通信時），並且簽名失去或未驗證，則處理 MTA 應該使用 550/5.7.x 回复程式碼。
如果驗證程序集成在 MTA 中並且無法獲取公鑰，可能是因為密鑰伺服器不可用，則可以使用 451/4.7.5 回复程式碼生成臨時失敗消息，例如：
451 4.7.5 無法驗證簽名 - 密鑰伺服器不可用
諸如無法訪問密鑰伺服器或其他外部服務的臨時故障是應該使用 4xx SMTP 回复程式碼的唯一條件。特別是，密碼簽名驗證失敗不得引發 4xx SMTP 回复。
驗證簽名後，必須將該資訊傳達給身份評估者（例如明確的允許/白名單和信譽系統）和/或最終使用者。如果 SDID 與 From: 標頭欄位中的地址不同，郵件系統應該努力確保實際的 SDID 對讀者來說是清楚的。
雖然驗證失敗的症狀很明顯——簽名無法驗證——但確定確切原因可能會更加困難。如果找不到選擇器，是因為選擇器已被刪除，還是在傳輸過程中值以某種方式更改？如果缺少簽名行，是因為它從未存在過，還是因為過分熱心的過濾器將其刪除？出於診斷目的，驗證失敗的確切原因應該提供並且可能記錄在系統日誌中。
因此，它可能因接收伺服器配置而異，但可能大多數都不會標記為垃圾郵件，特別是如果存在有效的 SPF 和 DMARC 記錄以及有效發件人的其他指標（IP 地址信譽、域信譽等）。