僅檢查網域解析是否會錯過已刪除的DNS監視器 DKIM選擇器 或破損的 SPF 依賴性。從真實郵件路徑使用的記錄開始。可用性監控應該報告查詢的內容、從何處查詢以及哪個預期屬性失敗，而不僅僅是DNS不健康。
建立明確的目標庫存
參考： RFC 6376 §3.1, RFC 7208 §4.4.
列出每個發送服務使用的作者網域、信封網域、活動選擇器和策略名稱。包括透過別名和SPF機制達到的依賴關係。監控接收安全性時新增傳輸策略名稱。普通的DNS查詢無法發現每個選擇器，因此需要從服務配置和代表性簽署訊息中取得活動集。
對於每個目標，記錄所有者、類型、預期形狀或批准值、責任所有者和變更視窗。避免假設每個值都必須永遠保持位元組相同：計劃的密鑰輪換會合法地更改資料。版本預期值並區分未經批准的變更和已批准的轉換。
分別探測權限和遞迴
參考： RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 4035 §5.5.
直接的權威查詢有助於確定該區域所服務的內容。遞歸查詢代表一個解析器的有效視圖，包括快取和驗證行為。保留兩者的查詢時間、伺服器位址、回應代碼、標誌、應答記錄和 TTL 上下文。在服務需要的地方使用多個相關的有利位置，而不是聲稱幾個探頭覆蓋了每個接收器。
區分NXDOMAIN 、沒有請求類型的現有名稱、 SERVFAIL 、逾時和成功但不正確的答案。一個 DNSSEC 即使權威伺服器傳回記錄，問題也可能導致驗證解析器失敗。權威答案標誌並不是答案經過密碼驗證的證據。
警惕隨後的決定
遺失的活動選擇器需要與一台監視器上的短暫逾時不同的回應。將相關的依賴項故障進行分組，這樣一個不可用的權限就不會建立數百個不相關的票證。使用連續觀測和獨立路徑來減少噪聲，同時保留首次故障時間和原始結果。閾值是本地操作選擇，而不是通用DNS協定要求。
不要因為探測失敗就自動替換記錄或停用強制執行。首先判斷monitor查詢的名稱和目前權限是否正確。將發現結果連同受影響的服務、最後良好的觀察以及確切變化或回應條件的證據一起發送給記錄所有者。
重現三個不同的觀察結果
本機裝置將傳回的預期選擇器標記 NOERROR 分類為存在，將NXDOMAIN回應分類為名稱缺失，將SERVFAIL回應分類為解析失敗。然後，它表明具有不同標記的 NOERROR 是內容不匹配而不是中斷。這些標記是合成的，不是 DKIM 鍵。
運行包含的腳本以重現分類。它消耗固定物件而不是發送資料包。若要驗證已部署的監視器，請查詢具有相同案例的隔離授權區域，並保留實際的線路回應、逾時測量和警報傳遞證據。那些現場測試不是在這裡進行的。
關閉監控環路
參考： RFC 2308 §5, RFC 6376 §6.
修復後，比較每個測試的權威端點，然後觀察遞歸恢復和授權時的代表性訊息。記錄返回後，否定答案可能會保留在快取中。不要僅僅因為稍後的查找成功就刪除該事件。
在寄件者加入、選擇器輪調、網域遷移和停用後查看清單。 DNS觀察確定了某個時間點的先決條件可用性。他們無法單獨證明有效的 DKIM簽名, DMARC 結盟、郵箱接受或收件匣放置。
保留歷史電報證據
以下描述了保留的 2026 年 11 月 7 日環回捕獲，已檢查但未作為本次審查的網路實驗重新運行。新的離線模型檢查單獨記錄。
保留的線路擷取將實際的 UDP 問題記錄到最小的環回權限。它保留擁有者、類型、端點、UTC 觀察時間、查詢和回應位元組、標誌、TTL 和 SOA 上下文。由此產生的分支是： NOERROR 和預期的TXT表示存在； NOERROR 在現有頂點沒有 AAAA 表示沒有請求的資料； NXDOMAIN代表absent.example .test 表示名稱缺失； SERVFAIL表示解析失敗；故意未回答的問題會導致客戶端逾時。伺服器編寫這些回應的腳本，但實際上會觀察到資料包和逾時。這測試的是決策樹，而不是商業監控行為或警報傳遞。