範圍和先決條件
先前的 ZeptoMail 網域驗證 URL 現在提供Zoho CPaaS 文檔，更新於 2026 年 10 月 22 日。下面的網域設定遵循目前頁面及其交易電子郵件範圍。確認租戶中的產品標籤和帳戶路徑，而不是假設歷史螢幕截圖仍然匹配。此頁面明確排除促銷批量電子郵件；行銷活動屬於支援的行銷服務。
配置記錄的路由
- 步驟 1. 在網域中，選擇新增網域並輸入確切的網域。關聯適當的一個或多個代理人。記錄哪個應用程式使用每個代理，以便測試覆蓋生產路線。
- 步驟2.選擇未驗證的網域並取得生成的 DKIM TXT和 CNAME 主機/值對。使用 DNS 提供者 選擇器 或其他以了解預期的主機格式。
- 步驟 3. 在權威DNS服務上發布兩筆產生的記錄。 DKIM記錄攜帶公鑰； CNAME建立退回郵件或 Return-Path 子域。請勿隨意替換 MX記錄 或猜測的 SPF 包括。
- 步驟 4. 返回產品並選擇驗證。其目前文件建議使用DKIM加上返迴路徑CNAME ，並指出單獨的 SPF記錄 此驗證流程不需要。現有的不相關的SPF政策必須保持不變。
- 步驟 5. 如果驗證待決，請比較活動的 名稱伺服器 以及準確的記錄。記錄的更新視窗為 24-48 小時；使用其驗證工具包中的 Check DKIM和 Check CNAME進行調查，而不是重複重新產生金鑰。
- 步驟 6. 透過指定的代理人發送代表性交易通知。記錄由產生的Return-Path所選擇的DKIM和SPF身分。
- 步驟7. 啟動後保留記錄。該服務會不斷檢查它們，如果所需的記錄在帳戶規定的截止日期之後仍然遺失，則可以暫停發送。
產品特定風險
新的DKIM選擇器必須在使用前進行驗證。該頁面描述了在驗證現有金鑰後添加最多兩個新金鑰；使用帳戶的輪調流程，而不是立即刪除舊的DNS金鑰。如果DNS更改後域被暫停，請恢復遺失的生成條目並重新驗證。保持退回郵件路徑正常運作：僅DKIM通行證並不能證明退回郵件處理已保留。
證明接收端的路由
使用核准的外部郵箱並保存完整的原始訊息及其時間戳記和訊息識別碼。本指南中沒有聲稱進行現場租戶測試。以下是實施期間需要完成的驗收工作表，而不是 一個記錄 觀察到的結果。
- 證據欄位：Visible From；記錄內容：實際地址和網域名稱；接受問題：這是預期的寄件者身分嗎？
- 證據領域：信封；記錄內容： Return-Path和接收者報告的SPF域；驗收問題： SPF實際驗證了哪個域？
- 證據領域： SPF ；記錄內容：可信賴接收者結果和評估的身份；驗收問題：它通過了嗎？該身份是否一致？
- 證據領域： DKIM ；記錄內容：每個d=域，s=選擇器和接收器結果；驗收問題：至少有一個通過的簽章是否對齊？
- 證據領域： DMARC;記錄內容：接收結果和適用的政策；驗收問題：是否存在對齊的通過路徑？
- 證據欄位：路線；記錄內容：產品、帳戶、訊息類型；驗收問題：測試是否使用生產路徑？
DMARC需要至少一條對齊的、通過的SPF或DKIM路徑。僅傳遞來自不相關服務域的簽章是不夠的。嚴格的 結盟 需要精確的域相等；寬鬆的對齊使用適用的組織域關係。在宣布成功之前檢查域的實際對齊設定。子網域不是自動嚴格匹配。 SPF使用SMTP身份，而不是顯示名稱或回覆。諮詢 對齊術語表 記錄決定時。
使用 Authentication-Results 來自您信任的接收系統，而不是任意發送者提供的標頭。捕獲所有簽名，而不是在第一次失敗時停止。對於轉寄的郵件，將直接測試與轉送的副本進行比較：轉送可能會變更SPF評估或變更簽署的內容。不要透過將貨運代理的地址添加到您的提供者授權中來診斷這些影響。
在不擴大訪問範圍的情況下診斷故障
首先將權威DNS與準確配置的記錄名稱進行比較，然後檢查遞歸可見性和服務驗證。錯誤的名稱、截斷的金鑰或衝突的CNAME無法透過等待快取來修復。擁有者僅保留一個SPF策略，並在合併另一個寄件者之前檢查評估的包含和重新導向中的 10 個 DNS 尋找術語限制。 DKIM選擇器屬於單獨的簽章配置；不要覆寫其他應用程式的記錄來強制驗證結果。
如果驗證通過但傳送效果不佳，請分別檢查收件者回應、信譽、內容和傳送權限。 DMARC通行證不承諾接受或收件匣放置。如果兩條路徑都不一致，請停止擴充並修正實際的發送器配置。不要削弱整個域的DMARC策略來隱藏單一產品故障。
移交和恢復
與指定所有者一起保存已批准的DNS差異、公共查找結果、服務狀態和經過編輯的接收訊息工作表。將憑證和私鑰保留在票據之外。發生故障時，暫停受影響的發送作業或使用服務擁有者控制下的先前測試的路由。僅恢復屬於此整合的已更改記錄；保留飛行訊息所需的公鑰。回滾、金鑰輪替、網域移轉或出站中繼變更後重新測試。僅當產品擁有者和郵件管理員可以解釋觀察到的身份鏈時才關閉變更。
確認提供者邊界
目前頁面將共享記錄功能限制為 Postmaster 和 Engineer 角色，並列出了 100 個網域帳戶的上限。其可選的一鍵式DNS流程是單獨的授權選擇，不需要手動設定。閱讀實際的警告期限，而不是發明一個普遍的寬限期。在新增記錄的附加金鑰之前，需要驗證現有金鑰。
完成一個虛構的診斷案例
僅虛構的書面案例：ZP-01 假設alerts@shop.example已在一個代理上傳遞d=shop.example ，但第二個應用程式使用其域關聯未確認的代理。沒有第二次申請信封或簽名結果。應用程式擁有者必須驗證該關聯並僅發送經過批准的事務測試。第一個代理商的結果並不能證明第二條路線或行銷資格。在這種情況下，沒有執行任何租用戶、 DNS 、伺服器命令或訊息。
將傳遞的訊息與執行準備分開
RFC 9989第 7.4 節要求發布p=reject域具有有效的DKIM ，並警告間接郵件互通性。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。