スパム対策の実践に関して、典型的な逆引きDNSチェックは正確に何を探しますか？
私の理解では、一般的な逆DNSルックアップは、着信接続のSMTPホスト名（EHLO/HELOコマンドで提供）を比較し、接続元のソースIPのPTRレコードと一致することを確認します。あれは正しいですか？
最近、メールプロバイダーが、着信接続で使用されるホスト名を送信ドメインの[〜＃〜] mx [〜＃〜]エントリと一致させることを要求するのが一般的であると聞きました。送信組織がアウトバウンドに対して完全に異なるMTAを持っている可能性があるため、これは私には意味がありません。
それはそれがすることではありません。 HELO/EHLOのホスト名は実際には関係ありません。これがPTRルックアップと一致したとしても、なりすましの可能性があるため、何も証明されません（HELOに嘘をついた場合は、おそらくPTRにも嘘をつくことになります。それは二重に役に立たないチェックになります。）.
内容doesクライアントアドレスでPTRルックアップを実行します。次に、A（またはAAAA）がPTRレコードで返された名前を検索します。これが一致する場合は、DNSゾーンの所有者がIPの所有者でもあることがわかります。
このステータスに基づいて動作するのは、残りの構成次第です。ブランケットをOKにするだけではほとんど十分ではありませんが、一致するものがない場合は、メールを拒否できることを示す良い指標です。
あなたが正しい。あなたが述べた正確な理由のためにそれは意味がありません。 MXレコードは、電子メールの送信元ではなく、電子メールの送信先を定義します。あらゆる種類のMXレコードチェックを使用して受信メールを検証している人は、私に関する限り、それを間違って行っています。
SPFレコードは、電子メールの送信元を定義します。
メールシステムを受信して、あなたが提案していることを確認することはめったにないと私は主張します。
フォワードDNSとリバースDNSで一致を要求する人は実際にはそうではありません。これは通常、送信元IPアドレスに定義された逆PTRがleastにあることを確認する場合です。たとえば、AT＆T IPアドレスには、デフォルトで定義された逆PTRレコードはありません。
さらに、DNSルックアップは、ホームDSLやブロードバンドプロバイダーによってプロビジョニングされたものなど、動的IPブロックから送信されたメールを識別するために使用されます。
次の逆ルックアップ結果が与えられます。
69.180.133.54
108-80-118-218.lightspeed.sndgca.sbcglobal.net
kiwi.testa.com
- 最初のものは、定義されたレコードがないために、より頻繁にブロックされます。
- 2つ目は、ブロードバンドプロバイダーによって割り当てられた動的アドレスに関連付けられているため、より頻繁にブロックされます。
- 3つ目は、順方向と逆方向のレコードが一貫しているため、ほとんどの場合に機能します（ただし、メールドメイン名とは関係がないという意味ではありません）。