客製化 郵件來自 網域可讓服務驗證與您的可見寄件者網域相關的信封身分。有用的結果是一個有效且一致的郵件路徑，而不僅僅是提供者控制台中的綠色DNS指示器。驗證產生的DNS設定、實際SMTP身份、 SPF 結果和 DMARC 結盟 作為單獨的步驟。
慎重選擇域名
清點可見寄件者地址中使用的作者網域以及提供者支援的自訂信封設計。跳出子網域可能在操作上很方便，但嚴格的SPF對齊需要與作者域完全匹配。在寬鬆的協調下，組織域關係根據 RFC 9989 §4.10.2 可以允許子域對齊。不要從品牌名稱或回覆欄位推斷一致性。 RFC 9989 §3.2.4, RFC 9989 §4.4.
使用您的服務提供的目前帳戶特定的DNS值。提供者可能需要額外的退回郵件處理記錄以及SPF ；這些要求是特定於服務的。本指南故意不提供通用MX主機名稱、包括目標或按一下序列。確認網域是專用的或變更不會與現有郵件流衝突。
在不失去政策完整性的情況下發布
在確切的SPF身份域中，維護一個 SPF記錄 而不是在現有策略旁邊新增第二個v=spf1記錄。當網域有多個合法寄件者時，請驗證完整的組合要求。家長保單不會自動承保孩子。檢查嵌套相依性和代表性評估路徑是否存在引起 DNS 查詢的術語限制。 RFC 7208 §4.5, RFC 7208 §4.6.4.
在切換之前記錄舊的DNS值和安全回滾計劃。驗證權威出版物和相關遞歸答案，然後在服務中啟用或確認自訂信封。僅經過驗證的DNS記錄並不能證明郵件已開始使用它。
證明收到的郵件上的關係
說明性範例，假設適用的DMARC策略：訊息使用receipts@example.com和 MAIL FROM return.bounce.example.com 。如果該信封網域經過 SPF 授權並共用適用的 組織域 example.com ，它可以在寬鬆模式下對齊。它不會在嚴格模式下對齊，因為完整域名不同。如果提供者默默地回退到bounce.provider.example.net ，則原始SPF可能會通過，同時SPF對齊會遺失。
透過每個實質上不同的路由發送測試訊息，包括支援的故障轉移。記錄實際的 MAIL FROM、連接 IP、可信任接收者SPF結果、對齊的SPF結果和 DKIM 簽章域。即使信封未對齊， DMARC也可以透過對齊的DKIM ；誠實地報告，而不是聲稱自訂郵件來自有效。 RFC 9989 §4.4.
驗證操作端
測試提供者支援的退回處理並檢查預期的應用程式是否收到傳遞狀態資訊。當您的系統使用空反向路徑發起訊息時， SPF會使用其定義的 postmaster-plus-HELO 身分結構，因此將其作為單獨的情況進行測試。不要將循環產生的反彈測試發送到生產中。 RFC 7208 §2.4, RFC 7208 §10.1.3.
僅當發送、身份驗證、對齊和退回處理有證據時才完成更改。在 Runbook 中保留提供者後備行為和所有權，並在路由或帳戶變更後重複測試。
使用具體的決策記錄
使用兩個假設的接受行：正常路由發出return.bounce.example.com和SPF通過；回退會發出不相關的提供者網域和SPF通行證。使用 From= example.com ，第一個只能在限定的寬鬆關係下對齊，而第二個則不能。如果DKIM提供整體DMARC通行證，仍將自訂 MAIL FROM 後備標記為不符合請求的身份。獨立保留退回處理證據。未執行提供者配置或測試郵件。