使用帳戶配置作為起點
Sendloop 提供了用於寄件人域身份驗證的帳戶工作流程，而其公共身份驗證精靈也提到了專用的 DKIM 和 結盟 設定.這些頁面確定身份驗證可用，但它們沒有為特定帳戶建立確切的記錄集、簽名身份或信封控制。本指南將引導您完成記錄的帳戶工作流程和受控驗證計畫。專用DKIM安排或客製化信封要求仍然是提供者確認項目。 Sendloop 驗證精靈、 DKIM和網域對齊設置.
首先確定帳戶、批准網域以及使用每個帳戶的活動或自動化。記錄該帳戶是否有專門的送貨安排以及誰可以確認。請勿從定價標籤、舊的入職電子郵件或第三方發送 IP 清單推斷專用基礎設施。為組織分配一名 Sendloop 管理員、一名DNS所有者和一名審查者 DMARC 政策。
在進行變更之前，請先匯出相關擁有者的目前DNS條目。保留一名代表從現有批准的路線收到的訊息（如果有）。現有工作的清單可以防止新的身分驗證項目意外停用另一個寄件者。目標是經過身份驗證和對齊的 Sendloop 路由，而不是網域電子郵件配置的大規模替換。
打開發件人域控制面板
提供者的指南將引導您完成“設定”>“寄件者網域驗證”>“驗證寄件者網域”，然後“新增網域”。產生的網域控制面板提供帳戶相關值和檢查DNS記錄操作。在編輯DNS之前捕獲該輸出。如果目前介面不同，請使用目前提供者說明或支持，而不是猜測等效按鈕。 Sendloop 指南，使用電子郵件授權精靈並檢查您的身分驗證設定.
記錄每個完整所有者、 DNS類型、值和 TTL 及其用途。將顯示的記錄集附加到變更單上。如果面板顯示缺失記錄，請確定該記錄是否不存在、由錯誤的擁有者發布或以不同的值顯示。已為另一個 Sendloop 帳戶配置的網域可能需要提供者協調而不是替換。
公共指南有一個 SPF 範例和現有記錄修正案未列出相同的內容。它還描述了準備文本文件。不要將任何一個細節變成自動生產配方。 DNS必須包含目前適用的政策；儲存在工作站上的文字檔案不會發布。在實施之前解決帳戶面板和公共頁面之間的任何差異。 Sendloop 指南，設定SPF記錄.
在不擴大不相關權限的情況下審查SPF
確定真正的 Sendloop 訊息使用哪個信封域。這是要調查SPF的身份，而不是假設可見的 From 領域必須是評估所有者。如果存在授權的自訂信封排列，請擷取其已發佈的設定和範圍。如果不存在，請記錄觀察到的提供者信封身分並單獨評估DKIM對齊情況。
在任何所有者發生變更時，保留單一SPF策略並保留其他活動寄件者所需的授權。新增術語之前檢查嵌套DNS查找。 SPF的十個術語限制適用於在評估期間導致DNS查找的機制和修飾符，而不是記錄中可見的單字數。現有的許可機制也值得審查，但刪除它們是一個單獨的依賴決策。 RFC 7208 ，第 4.5 節和 4.6.4 節.
請勿複製廣泛的樣本政策來取代現有記錄。這樣做可能會授權不需要的主機、更改故障限定符或刪除另一個提供者。當所需的授權無法安全地滿足時，請停止並要求郵件所有者選擇支援的設計。不要透過發布另一個SPF策略或刪除不熟悉的服務來解決問題。
僅發布已發布的公共DKIM資料
使用為此帳戶提供的所有者和公共值。公共指南顯示了DKIM TXT設置，但其演示密鑰不是客戶的密鑰。如果專家小組或支援人員提供了不同的支持記錄表格，請保留該指示，而不是在沒有證據的情況下轉換它。 Sendloop 指南，設定DKIM記錄.
只有公共驗證金鑰屬於DNS 。 DKIM使用私鑰來建立加密簽章；它不會將私鑰嵌入傳出訊息中。公共指南的非正式解釋不應被解釋為共享簽名秘密的請求。訊息攜帶簽名，驗證者使用其簽名域標識的公鑰和 選擇器. RFC 6376 ，第 3.5 和 6.1 節.
檢查提議的所有者是否有屬於另一條路線的活動密鑰。碰撞需要協調；僅僅為了清除紅色狀態而覆蓋工作選擇器是不安全的。發布後驗證完全限定名稱，包括DNS編輯器新增的網域後綴。保留時間戳記和查詢結果，以便以後的報表可以將過時的快取與不正確的擁有者或金鑰區分開來。
將連結品牌保留在聯盟結論之外
提供者的指南描述了一個可選的 CNAME 用於別名訊息連結。其目的是連結品牌，而不是SPF或DKIM一致的證據。僅當相關追蹤變更獲得批准並且帳戶提供準確目標時才實施。 Sendloop 指南，可選：設定CNAME記錄.
在聲明提議的所有者之前，請檢查現有網站或追蹤使用情況。請勿將根網站或即時應用程式主機名稱指向追蹤目標。在受控活動中保留無害的測試鏈接，以便審核者可以驗證其目的地及其顯示的主機名稱。驗證和連結功能是單獨的驗收檢查；有效的品牌連結不會建立有效的簽名。
發布後返回帳戶的DNS檢查。將每個顯示的結果與獨立的公共查找進行比較。誠實地記錄未決狀態。如果帳戶顯示已驗證，但外部測試仍然失敗，請保持變更開啟狀態並使用訊息證據來定位剩餘邊界。
收集收到的訊息身份記錄
不使用客戶數據，透過實際行銷活動工作流程傳送到受控外部郵箱。對於實質上不同的寄件者域或交付配置重複此操作。保留原始訊息和可信任接收者結果，以及訊息 ID 和 UTC 時間戳記。記錄所有DKIM簽名，而不是在第一個通過的簽名處停止。
證據記錄應包含可見的寄件者域、經過驗證的信封身分、 Return-Path、 DKIM d= 和 s= 值、 SPF和DKIM結果以及接收者的DMARC結果。建立與 From 域一致的傳遞機制。寬鬆和嚴格的對齊強加了不同的領域比較；記錄使用的模式。 RFC 9989 ，識別符對齊解釋.
如果唯一傳遞的簽章使用不相關的提供者網域，請要求支援的客戶網域簽章選項及其啟動條件。公共嚮導的專用 DKIM 聯繫說明並不能證明該選項已啟用、免費、在每個計劃上可用或自動配置。取得確切帳戶的答案。不要將追蹤別名表示為替代信封網域。
使用失敗來選擇下一次檢查
對於一個失蹤的 DKIM簽名，確認帳戶，選擇從身分和提供者啟動。對於簽章失敗，請在調查簽章內容的下游變更之前比較觀察到的選擇器和公鑰。使用不同寄件者地址的測試可能會成功，但受影響的活動仍然失敗，因此在診斷期間保持工作流程不變。
對於SPF失敗，請確定評估的網域和最終發送來源。對於SPF通過但DMARC失敗的情況，請檢查對齊情況，而不是添加更多SPF包含內容。如果提供者無法記錄所需的身份選項，請封鎖該要求，並與企業主一起評估其他支援的途徑。不要僅僅為了使一個提供者的測試停止失敗而降低整個域的策略。
準備一個支援包，其中包含帳戶標識、受影響的網域、發布的公共記錄、觀察到的DNS答案、訊息 ID、時間和相關接收者結果。排除密碼、API 金鑰、收件者清單和不相關的訊息內容。簡潔的可重現故障比多個不相關的DNS編輯螢幕截圖更有用。
工作表回收和驗收
使用 Sendloop 驗證工作表（使用此處所述的欄位建立單獨的審核記錄）來追蹤記錄差異審核、專用功能確認和最終身分比較。即使普通對齊的DKIM工作，丟失的信封功能答案可能仍然無法明確解決。根據業務需求定義接受度，而不是用假設來填補每個空白。
如果變更失敗，暫停受影響的發送並透過記錄的變更計畫恢復先前核准的配置。協調DKIM更改與提供者啟動；在服務仍使用公鑰進行簽署的情況下刪除公鑰會導致新的失敗。停用 Sendloop 時，請確認所有活動和自動化已停止，並在刪除信任或追蹤記錄之前檢查共享SPF依賴關係。
SPF差異的虛構範例
僅虛構的書面案例：SLP-01 假定來自offers@workshop.example 。公共範例包含兩個提供程序，而其現有策略指令指定了一個；目前帳戶授權、信封身分和DKIM / SPF結果未知。 DNS擁有者保留變更並要求帳戶擁有者取得特定於路由的確認。文字檔案和品牌連結不建立身份驗證。澄清後，團隊將審查一項政策並收集受控的活動資訊。未執行任何帳戶、 DNS或發送測試。
紀錄片報導和剩餘的門
該草案涵蓋了公眾帳戶工作流程和安全驗證。它不會建立通用的專用 DKIM 或自訂Return-Path設置，也不聲明已檢查即時對齊的 Sendloop 訊息。這些與帳戶相關的詳細資訊、即時DNS和標頭證據、獨立審查、目視審查和 SME 人工批准仍然懸而未決。保留原來的完整實施範圍，直到所需的帳戶證據彌補差距。
將傳遞的訊息與執行準備分開
RFC 9989 第 7.4 節要求有效的DKIM才能進行網域發布 p=reject 並對間接郵件互通性提出警告。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。