圍繞記錄的批准流程和日期進行規劃
點擊官方 電子郵件傳送網域指南，於 2026 年 10 月 6 日編輯，介紹了在 ClickDimensions Marketing Automation 中配置域。它宣布，從 2027 年 1 月 25 日開始，電子郵件只能從狀態為「已批准」的網域發送。截至 2026 年 11 月 9 日審查本指南時，這是未來宣布的限制，而不是證據表明新的強制措施已經在租戶中發生。在計劃變更之前，請確認適用的版本、帳戶和目前提供者的通知。
該指南表示，必須涵蓋寄件者電子郵件地址中使用的每個網域，包括不同品牌或地區使用的網域。清點電子郵件發送記錄中的實際寄件者地址以及行銷活動自動化中的發送電子郵件操作。不要假設組織的主域涵蓋每個配置的寄件者。帳戶準備情況取決於實際的網域清單和批准狀態，本稿均未檢查這兩者。
將DNS驗證與已批准狀態區分開來
記錄的順序包括等待DNS驗證、等待批准和已批准。驗證DNS記錄後，網域仍會經歷 Click 的變更管理流程。該指南描述了每週的更換窗口，可能需要長達 7 天的時間，並表示 DKIM 預計在等待批准階段後 1 至 7 天發布。這些是提供者的調度聲明，而不是立即啟動的承諾或獨立驗證的服務水準承諾。
儘早規劃DNS工作，為審批流程和任何更正留出空間。綠色DNS檢查不應輸入為“已批准”，除非網域的實際狀態如此說明。記錄負責提供者問題的聯絡郵箱，並確保授權人員對其進行監控。本文不會開啟支援票證、提交網域以供批准或聲明已預訂任何變更視窗。
輸入具有正確範圍的域和子域字段
導覽至 ClickDimensions 設定和電子郵件發送網域。該指南描述了發送網域、 DKIM子網域、可選電子郵件 CNAME 和聯絡電子郵件。子域字段採用標籤而不是完整的完全限定名稱。 DKIM子域必須是 Click 所獨有的，不得為其他服務或目的而保留，並且使用不帶前導或尾隨標點符號的有效標籤。 DKIM和電子郵件CNAME子網域不能使用相同的標籤。也要檢查現有的網路內容和社交CNAME依賴關係，而不是在不檢查所有權的情況下選擇方便的標籤。
可選的電子郵件CNAME用於電子郵件連結；它不能與DKIM子網域互換。保持連結品牌， 回程路徑 配置和簽名證據單獨記錄在驗收記錄中。使用帳戶為目標網域產生的值。請勿複製其他品牌的標籤或目標，因為它已經具有「已批准」狀態。批准屬於配置的身份及其記錄，而不屬於可重複使用的DNS範本。
保存後，指南描述了可能的組織域 SPF 改變，兩個新的 MX記錄 和五個新 TXT記錄。記錄整個發行集和每個所有者的目的。這些並不是替換組織根部普通入站MX記錄的說明。在進行任何變更之前，請與DNS管理員一起檢查產生的確切擁有者名稱和路由依賴關係。
保留提供者的DNS格式說明
該指南警告其齒輪的複製貼上格式。 _domainkey條目，包括電子郵件用戶端引入的換行符、空格和引號。它還表示其三個DKIM TXT值分別為 225、225 和 4 個字符，並且應在不串聯的情況下創建。將這些指令應用於實際發布的記錄，而不是將它們合併到單一發明的鍵值或假設每個TXT記錄都具有相同的格式。
DNS編輯器的表示與DNS傳回的邏輯資料不同。 RFC 6376 ，第3.6.2.2節 定義DKIM金鑰儲存的TXT資源記錄。保留提供者發布的記錄邊界並透過授權流程檢查實際發布的資料。儲存的輸入框的螢幕截圖不足以證明公共所有者和值是正確的。
該指南的「驗證」按鈕可檢查記錄是否存在並包含內容。該範圍比完整的接收訊息測試要窄。將實際驗證結果、後續審批狀態和最終簽署證據分開保存。如果 一個記錄 如果錯誤，請與DNS所有者更正特定的不匹配項，而不是重複提交批准或替換不相關的記錄。
將輕鬆對齊視為產品先決條件
官方 DMARC實施指南，編輯於 2025 年 5 月 16 日，表示 Click 的子網域設計不支援嚴格的 adkim 或嚴格的 aspf。它需要明確地或透過相應的預設值來寬鬆地設定兩者的值。將其保留為記錄的產品約束；不要將其軟化為可選的性能建議，或者說該帳戶可以使用嚴格模式而無需額外的證據。
這並不授權悄悄削弱組織現有的域策略。確定策略擁有者、其他郵件流和預期的安全要求。如果當前政策與記錄的產品設計相衝突，請在設計決策獲得批准或當前提供者澄清之前阻止實施。不 DMARC 此處的策略已更改，且本指南未聲明不受支援的替代配置。
RFC 9989 ，第 4.4 節 定義協定的 結盟 規則。對嚴格對齊的通用協定支援並不意味著每個服務都實現相容的路由。相反，提供者的限制並不意味著在任何地方都不可能嚴格對齊。在記錄接受決定時，將這兩個聲明分開。不要僅僅因為發送平台受到組織的信任而將不相關的傳遞簽名視為對齊。
一起查看SPF和實際郵件身份
帳戶產生的SPF說明需要在完整的合法寄件者清單中進行審查。 RFC 7208 ，第 2.4、3.2 和 4.6.4 節 定義 郵件來自、多個SPF策略行為並評估依賴 DNS 的術語限制。不要用單一服務範例取代正在運行的組織策略，也不要添加競爭性的第二個範例 SPF記錄。查看核准路線使用的實際返迴路徑標識。
經過單獨授權設定後，無害的接受訊息應建立作者網域、返迴路徑域、簽章域和 選擇器，具有可信賴的接收器結果。 RFC 6376 ，第 3.5 節 定義簽名字段。提供者級預設簽章或成功的DNS驗證本身並不能證明客戶域路由一致。身份驗證也不能保證收件匣的放置或活動的參與。
虛構診斷與空白接受工作表
虛構的經銷商 Birchline Tools 完成了第二個品牌的DNS驗證，並在網域仍在等待批准期間安排了一項活動。競選團隊將這種中間狀態視為等同於生產準備狀態。審查發現了兩個缺少的決策：完成提供者變更視窗並確認品牌的DMARC對齊設定滿足記錄的產品要求。
建議的更正是保留已完成的DNS證據，同時保持發布開放，直到實際的域狀態和策略決策得到解決。不得繞過審核、私自更改寄件者地址或擅自削弱政策。這個虛構的場景不包含真實的租戶結果、計劃的活動或執行的測試。
- 帳戶版本和所有實際發送網域：______
- 產生的DKIM子網域、可選連結網域和記錄集：______
- 現有依賴項和權威DNS批准：______
- 所需的寬鬆 adkim/aspf 相容性決定：______
- DNS驗證結果，等待批准並獲得批准的證據：______
- 受監控的聯絡人和提供者變更視窗計劃：______
- 電子郵件傳送和行銷活動自動化來自網域檢查：______
- 可信任訊息級身分和對齊結果：______
- 未解決的條件、回滾擁有者和發布決定：______
原始實施證據、人類主題審查、當前適用性、生產路線、視覺可及性和所有者發布仍然開放。未提交網域名稱、編輯DNS 、更改策略或發送電子郵件。該目錄更廣泛的實施要求仍然取決於授權帳戶和訊息證據。