回答:
電子メールサーバーのIPアドレスを逆引きして、SMTP会話で使用している名前に解決できるようにできる限り努力します。生活が楽になります。
これをバックアップするための統計的証拠はありませんが、SMTP会話で使用されるホスト名と一致する逆ルックアップがないため、一部のリモートメーラーによってメッセージが拒否されることがあります。この問題に対処する必要があるのではなく、逆ルックアップの設定を正しく行う方が簡単です。過去数年間、私は一貫したフォワード/リバースルックアップを持つことを要件として扱ってきたので、それがないという問題に対処する必要はありません。
セットアップしていない場合は、正当なメールにフラグが付けられます。チェックの方法はスパムフィルタリングデバイス次第であり、明確な基準が定義されていないため、ヒットまたはミスです。しかし、ほとんどの場合、スパムスコアがあり、一致するフォワードルックアップとリバースルックアップがない場合は、電子メールが送信されます。そのこと自体は、多くの場合、電子メールブロックを取得しません（しかし、約束はありません）が、電子メールの他のわずかな懸念がそれを上回ってしまう可能性があります。
以前はメールサーバーの特定のPTRレコードを使用していなかったため、craigslist.orgと一部のビジネスパートナーから返送がありました。
また、MXエントリには特定のAレコードが必要です。一部の厳密なメールサーバーでは、*またはCNAMESは許可されません。
「バナー名」と言うと誤解を招きやすい。バナーはサーバー側の名前であり、何を拒否するかを決定する側です。:)私はあなたが送信側がHELO / EHLOコマンドで与える名前を意味すると思いますか？
ほとんどの場所では構文チェックを行い、明らかに悪いHELO / EHLOを拒否します。壊れたジャンクが多すぎるためです。ただし、正当なメールサーバーを実行している場合は、送信するHELOで自分のメールサーバーのパブリックホスト名を指定するだけです。チェックする人もいます。また、そのホスト名には、機能する逆引きDNSが必要です。TCP接続が多くのMTAによってすぐに拒否されないようにするため、実際には、指定された名前に対して逆引きDNSが機能する必要があります。
したがって、いずれにしても、一般的な到達可能性のために逆引きDNSを整理する以外に、HELOホスト名のDNSを機能させるのに構成上の困難はありません。
Evanが言ったように、最善の策は、PTRエントリをサーバーのIPアドレスに解決することです。
ただし、何らかの理由でこれが不可能な場合、PTRは、ホーム（非ビジネス）DSL回線ではなく、静的に割り当てられたIPアドレスを使用していることを示唆するはずです。アンチスパム戦略の一環として、多くの組織は、ボットネットアクティビティのIPアドレス範囲を監視し、IP範囲のブラックリストを維持するレピュテーションサービス（SORBSなど）を使用しています。ただし、疑わしいアクティビティの有無にかかわらず、通常はダイナミックユーザーリスト（DUL）をブラックリストに含めます。これらのDULを作成するには、PTRレコードと正規表現を使用します。特に、多くの大規模ISPの命名スキームに合わせて調整されています。
たとえば、PTR like cable-66-103-40-69.clarenville.dyn.personainc.netは自動的にブラックリストに登録される可能性が最も高くなります（「dyn」に一致するため、動的である必要があります）。IETFでの逆DNS命名に関する標準化の取り組みがいくつかあり、さまざまな成功を収めています。
http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations
トピックから少し外れて、ブラック/ホワイトリストの別の情報源はWHOIS SWIPレコードです。