反向DNS 要求提供與 IP 位址相關聯的名稱。對於郵件寄件者來說，相關位址是SMTP連線上使用的公共來源。該地址的PTR記錄是有用的基礎設施證據，但它不是 SPF 授權，一個 DKIM簽名 或證明訊息合法性的證據。
識別真實地址和權限
參考： RFC 1035 §3.5, RFC 3596 §2.5.
從接收系統或受控外部SMTP觀察看到的 IP 開始。應用程式的私有位址、負載平衡器位址和提供者的出口位址可能不同。列出該服務可能使用的每個出站位址系列和池。
IPv4反向查詢使用 in-addr.arpa 下的反向八位元位元組。 IPv6在 ip6.arpa 下使用反轉的十六進位半位元組。這些反向區域的權限遵循 IP 分配和任何委派。它通常是託管或網路供應商，而不是寄件者可見網域的註冊商或DNS主機。在不相關的正向區域中發布類似 PTR 的名稱不會改變真正的反向答案。
協調兩個方向
參考： RFC 1912 §2.1, RFC 2181 §10.2.
向反向區域運營商詢問支援的更改流程和確切的公共 IP。選擇預期的基礎設施主機名稱並確保其轉送位址資料包含該 IP。 RFC 1912建議匹配反向和正向資料；它是操作指南，而不是通用的接收方驗收合約。
RFC 2181闡明DNS並不將地址限制為恰好一個PTR 。多個返回的名字必須保留為證據，而不是默默地丟棄。對於可預測的管理，穩定的記錄主機名稱通常更簡單，但接收器特定的要求需要其自己的當前文件。不要聲稱一種PTR模式可以保證交付給每個提供者。
重現反向查找
合成IPv4固定裝置：來源位址 192.0.2.25;反向所有者 25.2.0.192.in -addr.arpa。; PTR目標 smtp.example.com.;向該目標前進 A 192.0.2.25。預期的反向答案是主機名，預期的正向確認包括原始 IP。
在隔離的反向區域中，查詢 挖@AUTH -x 192.0.2.25 +norecurse 然後查詢 smtp.example.com. A 反對實驗室的前沿權威。保留每個方向使用的權限，因為它們不必是同一組織。刪除第二個固定裝置的PTR ：預期的證據是不存在或從實際回應中分類的錯誤，而不是新發明的主機名稱。
對於IPv6 ，使用查找工具的位址到反向轉換，而不是手動縮寫半位元組名稱。詢問 挖@AUTH -x 2001:db8::25 +norecurse，用配置的實驗室解析器取代 AUTH。生產檢查必須使用真實觀察到的來源位址；這些文件範圍並不描述即時寄件者。
區分基礎設施和身份驗證
參考： RFC 7208 §5.5, RFC 9989 §5.3.5.
PTR目標不需要僅僅因為郵件使用該網域而成為可見的寄件者網域。提供者可以使用自己的主機名稱來操作共享發送基礎架構。對於特定接收政策而言重要的事項必須與SPF和 DKIM 結盟.
不要添加令人沮喪的SPF 指針 機制只是為了使反向DNS與SPF相關。將PTR維護為基礎設施問題，並使用實際支援的寄件者授權配置SPF 。更改後，驗證正向和反向答案、 SMTP介紹和相關接收方回應。將任何交付結論限制在測試的路線和時間範圍內。
保持證據範圍明確
本機位址庫轉換確認192.0.2.25對應到 -addr.arpa 中的25.2.0.192.in ，並產生完整的IPv6半位元組名稱。此計算不會查詢反向區域或確定PTR存在。未執行傳遞或接收策略測試。