反向查找傳回 IP 位址的聲明主機名稱。遠期確認 反向DNS 然後檢查該主機名稱是否解析回原始位址。第二步驟捕捉常見的不一致情況，但配對並不能證明寄件者值得信賴或有權使用郵件的寄件者網域。
定義比較
參考： RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.
以觀察到的SMTP來源位址作為起始值。查詢其PTR記錄。對於每個傳回的主機名，查詢適當的轉送位址類型：A 表示IPv4來源，AAAA 表示IPv6來源。使用IPv6的 IP 解析器來比較位址值，因此同等的文字形式會被同等對待。
對於本指南的診斷，確認表示至少一個傳回的主機名稱的轉送位址集包含原始 IP。保留每個主機的結果以及摘要。這是一個明確定義的診斷規則，而不是承諾每個接收者都實施相同的選擇策略或檢查每個PTR結果。
保持失敗的明顯性
參考： RFC 1035 §4.1.1, RFC 2181 §10.2.
沒有PTR答案、主機名稱沒有符合位址、 DNS逾時和驗證失敗是不同的結果。超時不能證明記錄不存在。 IPv4 A 匹配不會建立對IPv6來源的確認。保留回應代碼和時間，而不是將所有結果折疊成單一紅色徽章。
不要停在為主機名稱回傳的第一個位址處。一台主機可以有多個位址，原始位址可能位於位址集中的較晚位置。儀表板也不應該默默地丟棄多個PTR名稱。需要底層結果來準確解釋配對的內容。
計算綜合測試集
情況 A 開始於 192.0.2.25。 PTR回報 smtp.example.com;那個名字的A組是 192.0.2.24, 192.0.2.25。預期結果得到確認，因為原始地址是該集合的成員。不需要與整個集合相等。
情況 B 使用相同的PTR ，但 A 集僅包含 192.0.2.24。預期結果不符。情況 C 的正向查找逾時。預期的結果是未解決，而不是不匹配。情況 D 開始於 2001:db8::25 目標的 AAAA 答案是 2001:0db8:0000:0000:0000:0000:0000:0025。將兩者標準化為IPv6位址後，預期結果得到確認。
使用夾具解析器或隔離區域重現這些情況。對於每種情況，儲存來源 IP、 PTR回應、轉發回應、查詢類型和計算的成員資格結果。一個簡單的實作會解析每個位址並評估來源是否在傳回的集合中，同時在該成員資格步驟之前處理DNS錯誤。這些預期結果並未顯示任何生產接收器已經過測試。
修復車主一側不匹配的情況
參考： RFC 1035 §3.5, RFC 8767 §4.
如果PTR錯誤，請與反向區域操作員合作。如果轉址錯誤，請與主機名稱的權威DNS業者合作。如果兩者在權威上都是正確的，但在解析器上卻不正確，請調查快取或不同的觀點。同時保留兩個方向的證據，這樣連續的變化就不會被誤診為持續的不一致。
最後，測試實際的SMTP路由並保留任何接收方回應。前向確認是DNS資料的一致性屬性。攻擊者可以操作匹配的正向和反向記錄，而合法的提供者仍然可以擁有損壞的配置。將這一發現與身份驗證和濫用控制一起使用，而不是代替身份驗證和濫用控制。
保持證據範圍明確
可以僅透過地址成員資格和標準化來檢查四種綜合案例：已確認、不匹配、未解決和已確認。本機計算不執行PTR或前向查找、執行接收器或測量信譽。