範圍和特定於提供者的配置
StatusHub 有不同郵件提供者路由的文件。本指南遵循其電子郵件寄件者 - Postmark - 新文章；保留的舊Mailgun文章不得混入該設定中。發布前請確認您的 Hub 顯示符合的路由。遷移或較舊的租戶可能需要不同的記錄。
開啟集線器配置、通知設定、電子郵件寄件者。記錄的預設值是do-not-reply@statushub.io 。輸入預期的自訂寄件人，然後重新整理頁面以顯示其DNS說明。 Postmark路線需要 DKIM TXT記錄 和返迴路徑 CNAME。直接從控制面板複製名稱和值，而不是使用說明文章中的範例公鑰。
這 回程路徑 擁有者通常是 pm-bounces 子網域，但由實際請求的名稱控制。切勿僅因這是可見寄件者位址中的網域而將此CNAME放在網域頂端。 StatusHub 特別警告說，apex CNAME可能會與其他記錄發生衝突，並損害不相關的系統，包括傳入的郵件。保留信箱 MX記錄 與此返迴路徑委託分開。
發布這兩筆記錄後，請使用 StatusHub 中的重新檢查DNS記錄。經過完全驗證的自訂發送網域允許指定的寄件者地址。當自訂寄件者仍未經過驗證時，StatusHub 會在寄件者中將回退記錄為do-not-reply@statushub.io ，同時將自訂位址放在回覆中。這種差異在診斷過程中很有用：到達您團隊的回覆並不能證明客戶看到了您的品牌寄件者。
幫助文章討論了DKIM TXT值的轉義和非轉義分號。應用DNS編輯器所需的語法，然後檢查發布的值；不要將反斜線插入鍵中作為一攬子修復。新記錄可能很快就會得到驗證，但文章指出了提供者和 TTL 的差異。在將所有失敗歸因於傳播之前，診斷確切的所有者、類型和值。
重要的決定
確認活動郵件提供者路由以及回退是否已將自訂身分移至回覆。
驗證發布記錄和真實發送路徑
在編輯之前記錄變更所有者、發送產品、網域、批准的維護時段和先前的DNS答案。從指定帳戶或記錄的提供者工作流程取得目前記錄值。將提供者提供的值與您的組織控制的選擇分開，例如 DMARC 政策和報告接收者。現有郵箱MX 、不相關的驗證TXT記錄和活動DKIM選擇器不會因為新增新服務而成為清理候選者。
發布後查詢每個確切所有者和記錄類型的權威名稱伺服器。記錄查詢時間、回應伺服器和完整答案。將TXT字串作為一個邏輯值進行比較，其中DNS回應將它們拆分為字串。檢查CNAME目標以及起始別名。然後比較遞歸解析器答案以識別快取差異。成功的提供者驗證是配置的有用證據，但它並不能確定實際接收者收到的內容。
使用預期產品路線僅將授權測試傳送給受控收件人。保留原始訊息和可信任接收系統的 Authentication-Results。記錄可見的寄件者網域、 SMTP 郵件來自 或觀察到的Return-Path域，每個DKIM d= 和 s= 值， SPF 和DKIM結果，以及接收者的DMARC結果。僅當其經過驗證的網域與適用策略下的可見寄件人域一致時，透過SPF或DKIM檢查才支援DMARC 。回復和品牌顯示名稱不是 結盟 身份。 RFC 7208 、 RFC 6376和 RFC 9989 為這些區別提供協議基礎。
驗收工作表、恢復和證據限制
這是原始驗收工作表，而不是現場測試報告。將每個門標記為待處理，直到證據存在：帳戶範圍已確認；先前捕獲的DNS ；發布確切的新所有者/類型/值；提供者驗證完成；預定的行使路線；收到記錄的身份資訊；已確認一致的身份驗證；其他寄件者不受影響。為每個門分配一個人和證據文件。即使提供者儀表板為綠色，紅色門也會阻止推出。
如果測試失敗，首先區分遺失的發布、過時的快取資料、不活動的提供者配置、錯誤的出站路由和未對齊的身份驗證。修正所顯示的最小缺陷並再次測試。不要僅僅為了通過一項測試而削弱DMARC或刪除其他寄件者的記錄。如果變更損害了現有郵件，請使用核准的復原計畫和擷取的變更前配置，協調任何提供者端寄件者變更以及DNS 。當排隊的訊息或核准的重疊仍然需要舊密鑰時，請保留舊密鑰。
此稿件沒有可用的客戶租戶、更改前後的權威資訊或真實收到的訊息。保留的資源支援文件工作流程；他們不滿足委託的現場證據門。獨立檢查員審查和人類中小企業批准仍有待確定。請勿將本指南描述為經過現場驗證或將其發佈為已通過這些門檻。
將後備解釋為不同的身份結果
書面案例 SH-01 假定預期寄件者是status@example.com ，但郵戳路由域仍未驗證。因此，說明性通知使用記錄的預設值 From do-not-reply@statushub.io和 Reply-To status@example.com 。所有SPF / DKIM結果未知。到達自訂位址的回覆不會為example.com建立自訂的使用或對齊的身份驗證。中心所有者必須驗證活動提供者路由、更正精確產生的DKIM和Return-Path擁有者、重新檢查狀態並檢查受控通知。請勿將Return-Path CNAME移至根目錄或匯入舊的Mailgun指令。沒有發生任何事件、訂戶通知、 DNS查詢或設定變更。
保留執行邊界
RFC 9989第 7.4 節要求有效的DKIM ，而不僅僅是SPF來進行域發布 p=reject，並對間接郵件和郵件清單互通性發出警告。一次成功的直接訊息測試並不能證明每條合法路線都已準備好採取更強有力的政策。保留現有批准的保護，同時診斷實際差距；任何政策變化都需要自己的決定。