仕事がら、Webアプリからメールを送信する機能を付ける機会はよくある。今回は、特定のドメインにメールを送信した場合に、メールが受信できない現象に遭遇したので、その対処方法を備忘録（正確には対処出来ないので対処方法ではない）
とりあえず、最近はスパム除けの機能が各メールサーバーに実装されており原因を探すのに大変です。
この記事の最後にありますが、世の中なんともならないこともあるんだと痛感しました。問題はスパムを配信し続ける業者より、いい加減なセキュリティポリシーでメールを受信させないプロバイダーなのかもしれません。
話を元に戻して最近は、このくらいの事項をチェックすれば大体原因が見えてきます。
- SPF
DNSの設定が必要なので、権限が無い人は手が出せませんが、メールが届かない訳ではなく、迷惑メールとして扱われる場合がほとんどです。SPFが対応できているか確認するには、Gmailの宛先に送信して、Gmailに届いたメールのプロパティを表示して［SPF=PASS］になっていれば、SPF対応ということになります。
- DNS逆引き
メールサーバーを運営しているプロバイダーのポリシーに依存する可能性が高いですが、逆引きが出来ない場合に受信を拒否するサーバーも世の中にはあります。そんなんでメールの運用ができるのか思いますが、実際に、逆引きができないと受信されないメールサーバーはあります。
Gmailや自分自身などメールが受信できる宛先にメールを送信して、メールヘッダーを表示してみて
“Recieved : from メールサーバー名 ([123.123.123.123])”
“Recieved : from メールサーバー名 (unknown [123.123.123.123])”
とかであればDNSに逆引き設定されていないことになります。逆引き設定がされている場合には
“Recieved : from メールサーバー名 (メールサーバー名 [123.123.123.123])”
のように、DNS名が表示されます
- SMTP認証
可能性が低いですが、利用するメールサーバーに認証が付いている場合も考えられます。
- 中継（リレー）
これも可能性が低いですが、不正防止用にIPアドレスなどで中継が許可されていない場合も考えられます。
過去の経験で、大抵はクリアできてきましたが今回は、このどれにも当てはまらず解決までに嵌りました。
解決したのは、次の方法です。
まずは、SMTPログを出力させておいて、送信できないメールアドレスのメールサーバを突き止めます。
例えばこんな感じ。554を戻しているサーバーを見つけます。
XXX.XXX.XXX.XXX 554 smtp001.secure.sample.jp
PowerShellやTELNETで（私の場合な付き合いの古いTELNETを使いました）で554を返すサーバーに接続します。
サーバーから次のような応答がありました。
554 Your access to this mail system has been rejected due to the sending MTA’s p oor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.
平たく言うと、「あなたからの接続は拒絶します」です。運営しているプロバイダーさんに問い合わせをしてみると、以下のような回答でした。
○ホストの評価が低い（怪しい挙動のホスト）ため、プロバイダ（○○ホスティング）が参照しているブラックリストに登録されている具体的な登録理由はそのリストの配布業者しかわからない。
○プロバイダ（○○ホスティング）側では、そのブラックリストの編集はできないし、セキュリティ上、申し訳ないがどこのリストを参照しているかは教えられない。
○一般論での回答ですが、そういったリストは時間とともにホストの評価が戻る場合と除外申請が必要がある場合がある。
○以下のSPAM認定リストの検索サイトでみる情報によると、メジャーなブラックリストにはまだ登録されていないようです。
送信元のIPアドレスが、スパム認定されているみたいという話です。除外申請を出そうにも、教えてくれないということなので、諦めるしかありません。
ホストの評価が低い（怪しい挙動のホスト）とされているサーバーは、つい最近AWSで契約したEC2のサーバーなのに… もう笑うしかありません。
