SMTP掃描程式可能會報告伺服器的橫幅不匹配 反向DNS。這項發現值得解釋，而不是自動得出伺服器是 欺騙 郵件。確定測試了哪個位址、掃描器期望的名稱以及它是否觀察到入站服務或用於真實訊息的出站路由。
說出正在比較的身份的名稱
伺服器的初始SMTP問候語標識客戶端存取的服務。客戶的 EHLO 參數標識該SMTP會話的連線客戶端。 PTR記錄將 IP 位址對應到反向 DNS 名稱。轉發DNS將名稱對應到位址。這些是單獨的觀察結果，可能涉及不同的機器或管理所有者。 RFC 5321第4.1.1.1和 4.2 節.
入站網關的問候語不一定描述用於出站傳送的主機。負載平衡、網路位址轉換和單獨的發送池使這種比較變得複雜。在要求DNS管理員進行名稱匹配之前，請記錄準確的測試地址和角色。否則，外觀修復可能會針對與原始交付投訴無關的系統。
檢查協議實際需要什麼
RFC 5321描述了問候語和EHLO中的首選網域標識，並且它允許在指定情況下使用地址文字。它也表示接收者不得僅僅因為EHLO參數的驗證與客戶端 IP 位址不符而拒絕訊息。這並不能消除接收者的其他安全或營運策略決策，也不能保證每個提供者都會接受。
不要將提供者記錄的DNS期望轉變為通用協定規則。某些接收服務對發送方套用明確的正向和反向 DNS 要求。應根據該提供者目前的第一方指南和實際連接 IP 來調查特定於提供者的拒絕。本文並未斷言所有接收者都實施相同的PTR檢查。
建立比較記錄
擷取 UTC 時間、連線 IP、面向收件者的MX或服務角色、原始問候語、 EHLO值、 PTR答案以及PTR名稱的正向尋找。保持遺漏的答案、多個名稱和解析器錯誤清晰可見。如果出站地址由託管提供者提供，請確定誰控制其PTR委託；編輯不相關的區域可能不會更改反向DNS 。
將真實被拒絕的交易與接受的受控交易（如果可用）進行比較。完整的拒絕文字比一般的掃描器警告更重要。如果郵件已經正常流動且掃描器沒有提供適用的規則，請將發現結果歸類為身分識別衛生問題，而不是聲稱已證明投遞中斷。
繪製假設的拆分郵件架構
假設掃描器連接到inbound.example並記錄其伺服器問候語。然而，真正的出站事務透過send.example與EHLO send.example離開。它的連接位址有一個指向send.example PTR和一個傳回該位址的正向查找。掃描器的入站橫幅和出站客戶端名稱描述不同的系統，因此它們的差異本身並不能證明有缺陷。
帶有d=brand.example簽名將是另一個獨立的身份。其有效性需要實際 DKIM 確認; PTR協定無法提供該結果。同樣地， DMARC 需要自己一致的認證證據。這些是假設值，不是查詢的DNS 、捕獲的SMTP或執行的加密驗證。
對於實際拒絕，請收集真實連線 IP 和相關提供者要求的一筆記錄。如果提供者投訴指定反向DNS ，請與地址空間擁有者解決預期的PTR 。不要僅僅因為它是掃描器顯示的第一個名稱而編輯入站橫幅。
在正確的所有權下進行修復
如果存在真正的配置不一致，請與各自的所有者協調服務身分以及轉送和反向DNS 。保留舊值、TTL 和受影響的發送池。變更批准後，再次查詢實際地址，重複原來失敗的受控交易。
保持 SPF、 DKIM和DMARC檢查是分開的。匹配的PTR名稱不會確定其通過結果或 結盟 與可見的 From 域。僅關閉經過驗證的命名或交付缺陷，並保留未解決的提供者策略問題，而不是提供裝飾性橫幅匹配作為全面身份驗證。
將名稱與正確的角色進行比較
- 伺服器問候語：標識實際測試的入站端點。
- 客戶端EHLO和連線 IP：識別有問題的出站事務。
- PTR和轉發答案：保留時間戳記和地址空間所有者。
- 提供者拒絕：取得其準確的診斷和當前的要求。
- 關閉：驗證受影響的命名或交付問題，而無需向PTR索取DKIM或DMARC 。