如何為 Zimbra 伺服器設定 DKIM、SPF 和 DMARC 記錄

DKIM、SPF 和 DMARC 分別解決出站電子郵件驗證的三個不同部分，可靠的 Zimbra 部署需要它們協同工作。 SPF 會告知收件者哪些系統可以使用您的信封網域傳送郵件。 DKIM 會新增與網域關聯的加密簽章。 DMARC 會檢查通過的 SPF 或 DKIM 驗證是否與郵件「寄件者」標頭中顯示的網域一致，然後發布對應的處理和報告策略。

這裡需要注意一個現行標準細節：截至 2026 年 10 月，有效的 DMARC 協議規範是RFC 9989，該規範於 2026 年 5 月發布。它取代了較早的 RFC 7489，並更改了一些部署細節，包括將舊pct標籤標記為歷史版本並引入t測試標籤。如果您要複製先前 Zimbra 指南或 DNS 教程中的舊版 DMARC 範例，這一點尤其重要。

更改 DNS 之前需要準備什麼？

您需要擁有 Zimbra MTA 的管理 shell 存取權限、發送網域的權威公共 DNS 區域存取權限，以及使用該網域合法發送郵件的所有系統的完整清單。此清單可能包括您的 Zimbra 伺服器、中繼或智慧主機、行銷平台、工單系統、雲端應用程式以及任何災難復原郵件服務。

一個常見的誤解是，僅發布 Zimbra 主機的記錄就足夠了。實際上，只有當 Zimbra 確實是唯一授權的寄件者時，這樣做才足夠。 SPF 會根據 SMTP 身分進行評估，而一旦啟用 DMARC 強制執行，它可能會暴露被遺忘的第三方寄件者。建議：在發布限制性 SPF 或 DMARC 策略之前，先清點所有出站來源。

在設定 Zimbra 電子郵件驗證之前，終端機顯示了 zmhostname、zmprov gad 以及 mail.example.com 的 DNS A 記錄查找資訊。 — 在建置 SPF、DKIM 或 DMARC 記錄之前，請確認 Zimbra 主機名稱、託管郵件網域和公用 DNS 對應。

步驟 1：在 Zimbra 中產生 DKIM 金鑰

Zimbra 包含zmdkimkeyutil用於網域級 DKIM 簽章的公用程式。 Zimbra 官方文件指出，該實用程式應在 MTA 伺服器上執行。若要為尚未新增 DKIM 資料的網域新增 DKIM 數據，請切換至 Zimbra 帳戶並執行下列命令：

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

該命令會將 DKIM 資料儲存在 Zimbra 的 LDAP 網域項目中，並列印您需要發佈的選擇器和公用 TXT 記錄。 Zimbra 的DKIM 簽章文件也介紹-q如何查詢、-u更新和-r刪除現有的 DKIM 資料。

對於較新的 Zimbra 安裝，輸出結果中的選擇器值可能與您在網路上看到的範例略有不同。選擇器不應是固定的單字（例如 `/`default或 `/` zimbra）；請使用您的伺服器實際輸出的選擇器。操作：從命令輸出複製完整的公鑰記錄，而不是手動重建。

Zimbra 終端運行 zmdkimkeyutil -a -d example.com 並顯示 DKIM 選擇器以及公共 DNS TXT 數據 — 在 MTA 上運行 Zimbra 的 DKIM 實用程序，並使用它為您的網域實際返回的選擇器和公鑰。

步驟 2：發布 DKIM TXT 記錄

DKIM 驗證器會根據選擇器和建置的名稱在 DNS 中尋找公鑰。此機制在RFC 6376._domainkey中定義。在實際的 DNS 提供者看來，記錄通常如下所示：

場地	例子
類型	TXT
姓名	YOUR_SELECTOR._domainkey
價值	v=DKIM1; k=rsa; p=您的公鑰

您需要輸入完整域名YOUR_SELECTOR._domainkey還是僅輸入域名，YOUR_SELECTOR._domainkey.example.com取決於您的 DNS 控制面板。某些服務商會自動新增區域名稱。操作：在儲存之前，請在您的服務商中預覽最終的完整域名，以免意外建立域名...example.com.example.com。

DNS TXT 記錄表單顯示了 _domainkey 下的 DKIM 選擇器和 DKIM1 RSA 公鑰值。 — 發布 DKIM 選擇器，`_domainkey`並將 Zimbra 生成的完整公鑰貼到此處。

步驟 3：為傳送網域建立一個 SPF TXT 記錄

SPF 記錄以 DNS TXT 記錄的形式發佈在您要描述其寄件授權的網域上。 RFC 7208要求使用 TXT 記錄來設定 SPF，並指出在相同擁有者名稱下存在多個 SPF 記錄會導致永久性錯誤。換句話說，不要v=spf1因為新增了另一個郵件服務就建立第二個 TXT 記錄。

如果您的 Zimbra 伺服器直接使用一個穩定的公共 IPv4 位址傳送郵件，一個簡單的範例是：

v=spf1 ip4:203.0.113.10 -all

如果您的網域名稱 MX 記錄中引用的所有主機都是合法的出站寄件人，則可以使用預設設定mx；如果第三方服務發布了包含網域的 SPF 記錄，則可能需要其他include:機制。具體的記錄取決於部署情況，因此沒有一個通用的 Zimbra SPF 字串。

另一個常見的錯誤是假設嚴格模式~all總是比不嚴格模式更安全-all。真正的問題在於你的授權寄件者清單是否完整。當授權寄件者清單完整時，嚴格模式是合理的。建議：在一個 SPF 記錄中授權所有合法寄件人，在生產環境中進行驗證，然後根據驗證結果-all選擇最終的限定符。all

保持 SPF 協定的簡潔性。 RFC 7208 將評估期間觸發 DNS 查詢的機制和修飾符的數量限制為 10 個；超過此限制可能會導致錯誤permerror。操作：在新增其他供應商之前，先統計包含的 DNS 擴充機制的數量。

DNS TXT 記錄表單顯示了根網域的 SPF 策略，IP 位址為 203.0.113.10，並附有 -all 參數。 — 一個簡單的直接傳送設定可以在單一 SPF TXT 記錄中授權 Zimbra 公用 IP；僅當您的環境需要時才新增其他合法寄件者。

步驟 4：首先以監控模式發佈 DMARC

DMARC政策發佈於[此處] _dmarc.example.com。謹慎起見，以下是初步記錄：

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none請接收方在您收集資料期間不要根據 DMARC 策略變更處理方式。該地址請求匯總報告；當前的匯總報告格式由RFC 9990rua規定。請使用能夠處理 DMARC 報告的郵箱或報告服務，而不是無人值守的個人郵箱。

不要盲目複製舊文章中的部署範例pct=10，pct=25或類似的部署範例。 RFC 9989 已被列為pct歷史版本，因為實際運作經驗顯示其應用並不一致。當前標準t=y在需要時使用測試行為。建議：首先查看p=none並分析報告；不要依賴百分比抽樣作為安全機制。

DNS 表單建立了一個名為 _dmarc 的 TXT 記錄，其 v=DMARC1，p=none，以及聚合報告郵箱。 — 首先建立 DMARC 監控記錄，`_dmarc`以便在請求隔離或拒絕之前查看真實的發送來源。

步驟 5：驗證公用 DNS 中的所有三個記錄

DNS 提供者發布記錄後，可以從權威伺服器外部或能夠存取公共 DNS 的解析器查詢這些記錄。例如：

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

對於 SPF，請確認該擁有者名稱下僅v=spf1存在一個以特定名稱開頭的 TXT 回應。對於 DKIM，請確認選擇器與 Zimbra 目前儲存的值完全相符。對於 DMARC，請確認預期名稱下存在一個可用的 DMARC 政策記錄。

DNS 傳播取決於您的服務提供者、TTL（生存時間）和解析器快取。即使更改立即顯示在權威名稱伺服器上，也可能已快取到其他地方。建議：在將舊答案歸咎於 Zimbra 之前，至少使用一個獨立的公共解析器進行測試。

使用 dig 指令查詢 example.com 的 SPF、DKIM 選擇器和 DMARC TXT 記錄。 — 使用獨立的 DNS 查詢來驗證公共記錄是否與您打算發布的政策相符。

步驟 6：發送真實訊息並檢查身份驗證是否正確

從 Zimbra 網域傳送郵件，並檢查完整的郵件頭到其他服務商的郵件匣。成功發送郵件通常應顯示 DKIM 簽章和/或 SPF 驗證通過，且 DMARC 驗證也通過，因為至少有一個已驗證的身份與可見的寄件者網域一致。

這裡又出現了一個誤解：DMARC 並沒有要求同時通過 SPF 和 DKIM 驗證。它只需要透過對齊的 SPF 身份驗證或透過對齊的 DKIM 身份驗證。 RFC 9989 將寬鬆對齊定義為 SPF 和 DKIM 驗證的預設設置aspf，adkim但您也可以使用 `--strict-align-items` 參數請求嚴格對齊s。操作：檢查Authentication-Results並確定究竟是哪種機制提供了對齊的 DMARC 驗證。

原始郵件檢視顯示了 example.com 的身份驗證結果，其中 spf=pass、dkim=pass 和 dmarc=pass。 — 真正的外部投遞測試不僅應該顯示 SPF 或 DKIM 通過，還應該顯示可見的寄件者域的 DMARC 通過。

步驟 7：只有在報告無誤後，才從監控轉為執法。

一旦您的 DMARC 資料顯示合法寄件者已正確認證並匹配，您就可以將策略變更為p=quarantine或最終變更為p=reject。在目前標準中none，、quarantine和reject表示域所有者對未經認證使用的評估，但接收方仍保留本地處理權。

不要將p=rejectDMARC 視為提高郵件送達率的手段。 DMARC 主要是一種身分驗證和網域濫用控制措施；它並不能自動使郵件可信，也不能保證郵件進入收件匣。行動：應將 DMARC 的實施視為一項基於身分驗證覆蓋範圍的安全決策，而不是為了追求更高的收件匣送達率。

步驟 8：輪換 DKIM 金鑰，但不要立即刪除舊的 DNS 記錄

Zimbra 文件中寫道：要更新網域的 DKIM 數據，請執行以下操作：

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

此指令會建立更新後的 DKIM 資料並產生新的 DNS 項目。 Zimbra 特別建議將先前的 TXT 記錄保留在 DNS 中一段時間，以便在郵件傳輸或排隊期間仍能驗證使用先前金鑰簽署的郵件。操作步驟：先發布新的選擇器，驗證其有效性，然後暫時保留先前的選擇器，之後再刪除。

Zimbra 終端機運行 zmdkimkeyutil -u -d example.com，其中包含一個新的選擇器和一個指示舊選擇器應暫時保留的表格。 — 在 DKIM 輪調期間，發布新金鑰並暫時保留先前的選擇器，以便較早簽署的郵件仍然可以進行驗證。

快速參考：每筆記錄證明了什麼

控制	它檢查什麼	您可以在此處進行配置	主要失敗在於避免
防曬係數	發送主機是否已取得 SMTP 身分授權	公共 DNS TXT 記錄	多個 SPF 記錄或缺少第三方寄件人
DKIM	訊息是否包含簽名域的有效簽名	Zimbra金鑰產生及公網DNS TXT金鑰	選擇器錯誤或公鑰被截斷
DMARC	SPF 或 DKIM 驗證是否通過，以及是否與寄件者網域一致。	公共 DNS TXT 記錄位於`_dmarc`	在合法寄件者達成協議之前強制執行