DMARC 遷移指南
在遷移 DMARC 平台時，了解現有 DMARC 平台所應用的當前配置至關重要。精心規劃的遷移可確保您的電子郵件在加強身份驗證和報告的同時繼續順暢流動。本指南將引導您完成更換 DMARC 提供商（以及相關的 DNS 級別配置）的每個階段。
概述
本指南涵蓋以下內容：
- 規劃和清單
- 評估和準備
- 並行配置
- DNS 更新排序
- 測試和監控
- 切換執行
- 遷移後審查
遵循此流程可確保與最佳實踐保持一致，並允許您利用自動化技巧來確保零停機時間、維持可投遞性並最大化報告和執行。
1. 規劃和清單
第一階段確保您完全了解當前配置的每個相關領域。
域名和記錄清單
列出所有涉及的域名。對於每個域名，收集以下當前 DNS 記錄：
| DNS 記錄 | 預期記錄類型 | 如何識別 |
|---|---|---|
| DMARC | TXT 或 CNAME | 主機名中包含 _dmarc |
| SPF | TXT | 值部分以 v=spf1 開頭 |
| DKIM | TXT 或 CNAME | 主機名中包含 _domainkey |
| BIMI | TXT | 值部分以 v=BIMI1 開頭 |
| MTA-STS | TXT | 主機名中包含 _mta-sts |
| TLS-RPT | TXT | 主機名中包含 _tls-rpt |
記錄現有的 DMARC 執行（p=none/quarantine/reject）和報告地址（rua/ruf）。完整的初始清單至關重要 - 在進行更改之前，「首先創建現有保護服務配置的清單」。
對於大型環境，使用腳本或 DNS 導出工具來自動收集此數據。
識別發送源
- 列出所有電子郵件發送者（本地伺服器、雲服務、營銷平台等）及其當前的 SPF includes 或每個域名的 DKIM 密鑰
- 檢查任何子域名或第三方委託
- 使用現有的 DMARC 報告或出站電子郵件日誌驗證您的清單
審查當前報告流程
- 記錄 DMARC 聚合/失敗報告和 TLS-RPT 報告的發送位置（電子郵件地址）
- 計劃通過將這些轉移到新的 DMARC Manager 平台來維持可見性
- DMARC 記錄可以列出多個報告 URI（用逗號分隔）以同時將數據發送到新舊系統
建立基準性能
在更改之前，記錄當前的電子郵件指標（退信率、垃圾郵件投訴、可投遞性）和 DMARC 合規水平。這使您能夠驗證遷移後的改進並確保沒有倒退。
2. 評估和準備
評估和準備階段確保您在必要時準備好回滾。對於較小的環境，可能不需要以下所有內容，請根據實際情況判斷。
備份現有 DNS 記錄
- 導出或保存您的區域文件
- 保留所有當前記錄的副本，包括 DMARC、SPF、DKIM 選擇器、MTA-STS、TLS-RPT 等
記錄新的目標 DNS 條目
打開 DMARC Manager 並捕獲每個域名的新目標配置。確保您有每個域名所需的新 DMARC manager 記錄（如果在舊平台中涵蓋）：
- DMARC
- SPF
- DKIM
- MTA-STS
- TLS-RPT
- BIMI
示例：DMARC 配置說明的示例位置。其他配置可以通過切換到相關的默認配置選項卡輕鬆找到。
利益相關者角色
分配責任。定義誰更新 DNS、誰配置新的 DMARC Manager、誰監控報告以及如果出現故障誰處理回滾。例如，IT 運營可能處理 DNS 更改，而安全團隊審查報告。明確的角色和溝通渠道至關重要。
風險評估和調度
- 識別風險（例如，臨時配置錯誤導致拒絕）並計劃緩解措施
- 考慮在低流量窗口期間或按域名組分階段遷移
- 對於大量域名，分批遷移（例如，每次 100 個域名）以限制影響
準備新環境
- 讓您的團隊熟悉新平台的界面/API
- 收集所有必需的信息（新的 DKIM 公鑰、SPF include 值、報告地址、MTA-STS 端點）
- 確保您有新 DMARC Manager 記錄的 DNS 訪問權限
- 記下任何必需的 CNAME 或 TXT DNS 條目
降低 DNS TTL
- 在更改前幾天，將關鍵記錄（DMARC、SPF、DKIM、MTA-STS、TLS-RPT）的 TTL 降低到較低值（例如，300-3600 秒）
- 這可以最小化轉換期間的傳播延遲
- 記得在穩定後恢復較高的 TTL
角色委派和文檔
- 記錄每個計劃的更改並準備逐步指南
- 對於每個域名（或域名模板），記下確切的 DNS 編輯和序列
- 準備好審計的更改日誌，以便能夠證明合規性並顯示何時更改了什麼
3. 並行配置
在舊的 DMARC 平台保持活動狀態時，並行配置新的 DMARC Manager，以便兩個系統同時接收或驗證電子郵件。這個「雙寫」階段避免了停機時間或盲點，並應用於所有相關的 DNS 條目。
將域名添加到新的 DMARC Manager
- 在 DMARC Manager 中添加所有新域名
- 根據需要驗證 DNS 所有權（例如，通過 DNS TXT 或電子郵件）
DMARC 配置
- 將新添加域名的初始 DMARC 策略設置為當前發布的策略
- 在 DMARC Manager 中添加舊 DMARC 平台的報告地址
- 在域名界面的「編輯設置」下配置：
- 在聚合報告部分添加 RUA 地址
- 在失敗報告部分添加 RUF 地址
SPF 配置
- 在 DMARC Manager 中將每個域名的 SPF TXT 記錄更新為當前發布的 SPF 記錄
- 確保所有 includes 都出現在 DMARC Manager 中
- 驗證 'all' 標籤設置為相同的策略（通常是
~all） - 暫時不要刪除舊 DMARC 平台中的 SPF includes
DKIM 配置
- 將 DKIM 密鑰添加到新 DMARC Manager 的 DKIM 密鑰管理中
- 暫時不要刪除舊的 DKIM 記錄
BIMI 配置
- 將證書文件複製到 DMARC manager
- 將圖像文件複製到 DMARC manager（使用完全相同的 SVG）
- 暫時不要刪除舊的 BIMI 記錄
MTA-STS 配置
如果使用 MTA-STS，確保新 DMARC Manager 的 MTA-STS 策略反映舊策略。
4. 記錄更新排序
適當的 DNS 更改排序可以最小化風險。按照以下順序進行：
- 降低 TTL（在準備階段完成）
- 用新的 SPF 替換現有的 SPF：
- 遵循 DMARC Manager 的說明
- 驗證語法和查詢限制
- 等待 DNS 傳播（幾分鐘到一小時）
- 發布新的 DKIM 密鑰管理條目：
- 添加新的 DKIM 管理 NS 記錄
- 保留舊的 DKIM 記錄以備回滾
- 替換現有的 DMARC 記錄：
- 使用 DMARC Manager 記錄
- 驗證語法（每個域名一個 TXT/CNAME DMARC）
- 替換現有的 BIMI 記錄：
- 刪除舊的 BIMI 記錄
- 添加新的 BIMI NS 記錄
- 更新 MTA-STS DNS 記錄
- 更新 TLS-RPT DNS TXT
- 驗證暫停（24-48 小時）
- 可選的執行調整
驗證步驟
在每個步驟中，驗證電子郵件身份驗證：
- SPF：使用工具或測試電子郵件驗證身份驗證
- DKIM：發送測試消息並驗證標頭
- DMARC：確認提供商之間的報告分割
5. 測試和監控
DMARC 報告
- 確認兩個服務都收到報告
- 比較示例報告
- 驗證合法的電子郵件源
身份驗證測試
- 從每個源發送測試電子郵件
- 驗證 SPF=pass 和 DKIM=pass
- 調查任何失敗
MTA-STS 驗證
- 使用在線 MTA-STS 驗證器
- 測試外部域名電子郵件
- 檢查 Google Workspace 管理控制台（如果適用）
TLS-RPT 審查
- 幾天後審查報告
- 解決任何問題
- 確認新提供商收到報告
可投遞性監控
- 觀察退信率
- 監控垃圾郵件報告
- 追踪用戶投訴
6. 切換執行
一旦驗證完成，執行最終切換：
- 刪除舊的 DKIM 密鑰（48-72 小時後）
- 清理 SPF includes
- 完成 DMARC 記錄：
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100 - 更新 MTA-STS 配置
- 刪除舊的 TLS-RPT URI
- 停用舊提供商
注意：在維護窗口期間執行刪除操作，並準備好備份計劃。
7. 遷移後審查
驗證清單
- [ ] 所有域名都向 DMARC Manager 報告
- [ ] 只剩下 DMARC Manager 記錄
- [ ] 使用
dig或 DNS 管理界面驗證
性能審查
- 監控電子郵件退信率
- 檢查 DMARC 合規性
- 比較遷移前後的指標
文檔
- 編制審計日誌
- 記錄 DNS 更改
- 記錄轉換日期
- 保存確認消息
策略改進
- 計劃執行增強
- 朝向
p=reject移動 - 定期 SPF 審查
結論
通過仔細清點、準備和並行執行系統，您可以確保在轉換期間零停機時間。多目標報告保持不間斷的可投遞性和可見性。最後，清理舊記錄和加強策略完成了遷移，讓您在 DMARC Manager 下擁有更強大的電子郵件身份驗證和全面監控。