確定 Rocketseed 更改訊息的位置
Rocketseed 在商業電子郵件中加入品牌和簽名，因此在處理完成後必須檢查身份驗證。從實際的出站路由開始：員工的郵箱平台、使用的 Rocketseed 服務、任何後續安全閘道以及接收郵箱。直接從郵箱平台發送的成功測試可能會錯過客戶接收的路線。本指南涵蓋了路由邊界、提供者協助的 DKIM 激活和區域 SPF 審查。它並不聲稱任何客戶的網域或連接器已經過驗證。
建立其訊息透過 Rocketseed 傳遞的網域和應用程式的清單。包括共用信箱、委派寄件者和自動訊息（如果它們使用此路徑）。將 Rocketseed 雲端與 Rocketmailer 以及在外部投遞之前將郵件返回到其他服務的任何部署區分開來。請服務擁有者根據目前配置確認此清單。不要僅從簽署的外觀推斷最終的發送基礎設施。
在發布記錄之前與 Rocketseed 同意更改
火箭種子公司 配置DKIM指令 描述一個協調的過程：透過 Rocketseed 聯絡人請求簽名，接收TXT值，發布它，然後在 Rocketseed 驗證記錄後安排啟動。因此，發布記錄只是設定的一個階段，而不是簽名已經開始的證據。取得確切的DNS所有者及其值，並將約定的啟動時間保留在變更記錄中。
對於多域組織，詢問請求涵蓋哪些域以及不同的路由是否需要單獨設定。將答案與已部署的帳戶相關聯。本文不提供通用的 選擇器, 公鑰, 自訂 Return-Path 程式或自助激活按鈕。如果支援人員提供的說明與公共指南不同，請保留這些特定於帳戶的說明並在更改生產之前解決差異。
指定一位可以查看產生的外部訊息的管理員和一位可以暫停受影響的發送的企業主。根據支援的路由定義恢復，而不僅僅是刪除DNS記錄。停用品牌、繞過中繼或更改連接器可能會產生身份驗證以外的後果，應作為單獨批准的路由變更進行處理。
查看正確的區域SPF授權
火箭種子公司 SPF頁面 將其指令應用於 Rocketseed 雲端和 Rocketmailer。它列出了歐洲、美洲和非洲的區域性內容。透過 Rocketseed 確認實際服務區域，而不是從進行更改的人員的辦公地點中選擇值。特定於區域的說明是與提供者對話的證據，而不是向組織策略添加所有區域的權限。
將該頁面上的範例視為片段，以便在完整的SPF策略中進行審查。請勿複製“的頁面描述”PTR記錄”作為創建反向DNS的指令。SPF SPF以TXT形式發佈在 RFC 7208，協定評估SMTP 郵件來自 身份，單獨處理 HELO。在決定策略變更所屬的位置之前，確定最終出站路由實際使用的信封域。
導出該所有者的現有SPF策略。保留對其他活動寄件者的授權，檢查完整的查找成本並避免第二個SPF策略。 DNS 查詢機制和修改器在評估期間共用協定限制為 10。添加一個明顯較短的包含可能會帶來嵌套查找。如果策略已經接近限制，請停止並與郵件管理員一起設計支援的更改，而不是刪除不熟悉的服務。
發布已頒發的DKIM記錄而不打擾其他寄件人
記錄 Rocketseed 提供的完整擁有者、類型、值和 TTL。檢查DNS編輯器是否自動附加區域名稱。儲存後，驗證完整的公共所有者，而不是信任表單的顯示。重複的後綴可能會在錯誤的位置留下令人信服的記錄，而接收者使用的選擇器仍然不存在。
檢查提議所有者處的任何現有記錄。與其他服務或早期金鑰的衝突需要協調的答案。請勿覆蓋活動選擇器、發明替代選擇器或複製其他客戶的密鑰。只有公開的驗證資料才屬於DNS ；私人簽署金鑰和服務憑證不得出現在工作表或支援包中。
一旦DNS答案與發布的值匹配，請要求 Rocketseed 完成其記錄的驗證和啟動。捕獲回應以及應簽署新訊息的時間。保持舊基線可用，但不要僅僅因為提供者尚未達到計劃的啟動視窗而刪除新發布的金鑰。
品牌化後和最終網關後進行測試
透過普通品牌路由將無害的郵件傳送到受控的外部郵箱。對每個明顯不同的寄件者域和路由路徑重複此操作。測試不應包含真實的客戶資訊。保留訊息 ID 和 UTC 時間，以便郵件管理員和 Rocketseed 可以關聯相同投遞，而無需交換整個郵箱歷史記錄。
讀取接收者可信任的身份驗證結果。捕獲可見的 From 域、 Return-Path 、每個DKIM d= 簽章域和 s= 選擇器，以及最終的發送來源（如果可用）。 RFC 6376 定義簽章域和選擇器如何尋找驗證金鑰。如果稍後處理更改簽名內容，郵箱平台的簽名可能會失敗。在完整的路線之後檢查倖存的結果，而不是假設最早的簽名仍然有效。
申請 RFC 9989 到觀察到的身份： DMARC 需要與寄件人域一致的通過SPF或DKIM結果。不相關服務網域下的傳遞簽章本身並未提供下列內容 結盟。記錄哪個機構提供對齊路徑和有效的對齊模式。成功的收件匣放置、 TLS傳輸或品牌頁腳不能取代該證據。
一次診斷一個邊界
如果DKIM不存在，請先確認提供者啟動以及測試是否遍歷了預期的 Rocketseed 路徑。如果簽名存在但失敗，請將其選擇器與公共DNS進行比較，並在簽名後調查變更。當路線本身不確定時，避免重複請求新密鑰。新密鑰無法修復應用相關簽名後修改的訊息。
如果SPF通過但DMARC失敗，請將經過驗證的信封網域與可見的寄件者進行比較。當評估另一個網域時，向 From 網域新增授權可能不會起任何作用。如果兩種機制都失敗，請在一次變更多個控制項之前保留拒絕或接收結果。將DNS查找問題、未經批准的發送來源和內容簽章問題分開記錄在事件記錄中。
保留組織現有的DMARC策略，除非其所有者批准更廣泛的變更。 Rocketseed 的推出並不授權削弱對每個寄件者的保護。同樣，不要用白名單代替外部檢查：本地繞過可以使測試看起來成功，而客戶仍然收到未對齊的郵件。
Rocketseed 路線工作表
每個不同的網域和路由完成一份工作表：
- 企業主和批准的發送用途：____。
- 信箱平台、Rocketseed 服務與區域：____。
- 包括任何後續網關的完整路線：____。
- 預期來源和觀察到的信封域：____。
- 現有SPF所有者、完整的政策和查找審核：____。
- 發行的DKIM所有者、公開價值和 TTL：____。
- DNS觀察時間和 Rocketseed 啟動確認：____。
- 測試訊息 ID、UTC 時間和受控接收器：____。
- DKIM d= 和s=, SPF結果和對齊的DMARC機制：____。
- 恢復擁有者、未解決的異常和重新測試日期：____。
將缺少的啟動確認或接收結果視為未清項目。誠實地記錄失敗的測試而不是對待發布 一個記錄 作為閉包。
簽章路由故障的虛構範例
僅虛構的書面案例：RS-01 假設來自staff@example.org ，早期郵箱平台簽名失敗，品牌化後帶有d=example.org ，已發布的提供商頒發的公鑰，並且 Rocketseed 激活仍待處理。 SPF和更高版本的簽名未知，因此無法斷言完整的DMARC判決。路線所有者應確認計劃的激活，然後在所有處理後獲取新的外部樣本，而不是重新產生密鑰或繞過品牌。沒有檢查任何帳戶或訊息。
在驗證之前保持部署審查開放
更改品牌、連接器、發送網域或下游網關後重新測試。保留提供者的指示和接受者的證據以及批准的變更。即時租戶檢查、目前帳戶發布的記錄、即時DNS和標頭檢查、目視審查和 SME 人工批准仍然懸而未決。這是未發布的實施草案，而不是完整的身份驗證部署。
將傳遞的訊息與執行準備分開
RFC 9989 第 7.4 節要求有效的DKIM才能進行網域發布 p=reject 並對間接郵件互通性提出警告。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。