自訂追蹤網域會變更收件者在追蹤追蹤的電子郵件連結時遇到的主機。它可以使旅程更容易被識別，但它也會產生對DNS 、憑證、重定向和追蹤服務的依賴。購買或配置該主機名稱本身並不能建立郵件身份驗證或保證更好的遞送聲譽。
區分四種身份
記錄可見的From域， DKIM 簽名域名， 信封寄件人 和追蹤主機名。連結主機不會自動成為 SPF 身份或DKIM d= 域。傳遞簽名根據相關規則對簽名訊息進行驗證；它並不是對每個連結目的地的認可。 RFC 6376.
清點誰控制追蹤主機名稱及其指向的位置。包括服務帳戶、相關區域、證書所有者和退役計劃。將提供者變更視為依賴項遷移：舊電子郵件可能仍包含使用先前主機的連結。
遵循所選提供者的實際設計
Amazon SES透過配置集記錄自訂開啟和點擊跟踪，並具有單獨的網域和 HTTPS 配置。它的指導將DNS和 CDN 安排與選擇訊息使用的配置集區分開來。請勿將範例目標複製到其他帳戶或區域。 SES 自訂追蹤網域.
本文不配置SES帳戶。一般操作課程是驗證最終產生的訊息，而不僅僅是綠色DNS檢查。如果在傳送時未選擇預期配置，則範本可以保留在預設追蹤主機上。
檢查整個連結路徑
使用一次性非敏感測試鏈接，記錄第一個主機、每個重定向、HTTPS 行為和最終目的地。驗證目標是否是預期的應用程序，並且憑證是否與所聯繫的主機相符。避免在一般診斷中遵循即時重置、登入或付款授權連結。
查看追蹤服務接收和保留哪些識別符。更願意透過核准的設計從不必要的分析中排除敏感的帳戶存取連結。不要將記錄的點擊視為人類決定的證據；事件建立了一個請求，而參與者和意圖需要更多證據。 Mailchimp解釋非人類連結活動.
區分配置選擇和可及性
假設假設的最終訊息仍然包含預設提供者追蹤主機，儘管品牌主機名稱可以正確解析。在變更其憑證之前，請檢查所選訊息的配置集。在 SES 中，所選集決定是否使用其自訂追蹤網域。健康的未使用主機名稱無法更改該訊息中的連結。
現在考慮一條不同的訊息，它使用預期的品牌主機，但在重定向完成之前因證書不匹配而停止。這需要進行 Web 路徑調查，而不是再次進行DKIM變更。使用授權的一次性連結記錄所聯絡的主機、失敗步驟和預期目的地。這是兩個不同的教學案例，不是即時DNS / TLS測驗或測量的可及性改進。這兩種結果都不能確定收件匣的放置位置。
維護舊連結並安全退出
在刪除追蹤服務之前，請尋找哪些先前發送的訊息仍依賴該服務，並建立核准的保留期限。確認替換不會將使用者重新導向到不相關的內容。當不再需要時，透過受控更改刪除過時的DNS委派，而不是無限期地留下無主依賴項。
發布決定應列出已測試的路線、已知的排除情況、持續的所有者和剩餘的不確定性。只有當組織可以操作背後的網路路徑時，品牌連結才能成為良好接收者體驗的一部分。
將訊息選擇與網路路徑修復分開
如果最終訊息使用錯誤的追蹤主機，請在變更DNS之前檢查設定選擇。如果它使用預期主機但稍後失敗，請檢查特定憑證、重新導向或應用程式回應。關閉有關受控最終消息及其預期路線的每個問題。