【メール】【SPFレコード】逆引きレコードを設定していないとスパムメール扱いになるので注意
メールサーバーを構築した際に忘れがちになってしまいますが、メールサーバーの逆引きレコードを設定していないとスパムメール扱いされるので注意しましょう。
DNS SPFレコードとは何か？
目次
メールサーバーのドメイン名とグローバルIPの逆引きが異なるとなりすましと判断される
メールサーバーのドメイン名とグローバル IP の逆引きの結果が異なるとなりすましメールと判断されることがあります。
サーバーにアクセスする場合は、ドメイン名で検索をしても最終的に IP アドレスでアクセスする必要があります。
つまり、例えば ABC.com のサーバーにアクセスする場合は、最終的に ABC.com の IP アドレスの情報が必要になります。
メールサーバーでメールが不達になる場合は、以下のように「ドメイン名」と「IP アドレス」が一致していないことが原因の１つとして挙げられます。
- メールサーバーのドメイン名 ← ABC.com
- メールサーバーの IP アドレス ← 123.123.123.10
- 123.123.123.10 の逆引き結果 ← server01.network-company.com
よくある例ですが、「ABC.com」を正引きすると「グローバル IP」が返ってくる、ここまでは当たり前ですが、返ってきた「グローバル IP」を逆引きすると、なぜか ISP（インターネット・サービス・プロバイダ）のサーバーのホスト名（FQDN）が返ってきたり、何も返ってこなかったりします。
インターネット上ではスパムメールが飛び交っており、その為インターネット上のリソースが無駄に使われています。
スパムメールを送信する業者は身元を隠すために、わざと「ドメイン」と「グローバル IP」を一致させないように設定しています。
スパムメール送信業者は、メールヘッダーを改ざんして、元のメールアドレスを偽装し、メールが別の送信元から送られたように見せかけることができます。
スパムメール送信業者からすると、グローバル IP アドレスを特定されると ISP も特定され、アカウントを削除されたりブロックされてしまうことを防ぐために隠す必要があるわけです。
また訴えされることもあるため海外のサーバーを利用したりして偽装する必要があるわけです。
逆引きをしなくても環境によっては何となくメールが送信できてしまうので余計やっかい
ルール上、「逆引きを設定しないとメールは送信できません」と決まっているなら話は簡単ですが、現状、逆引きの設定をしなくても環境によっては何となくメールが送信できてしまうので余計やっかいです。
そのため、メール送信ができないと自身が管理しているメールサーバーとお客さん側のメールサーバーでどちらが悪いのか争いが発生することがあります。
しかしサーバー管理者が「ウチの設定は何も問題がない、実際他のお客様にはちゃんとメールを送信できている！」と言っていたのに、実際に調べたら、実は逆引きの設定をしていない、もしくは逆引きをすると ISP のサーバーの FQDN が返ってくるなどと後程判明すると若干恥ずかしいので、そういったケースもあるということを覚えておくと調査に役立つかもしれません。
逆引きチェックをするのはお客様のサーバー側のポリシーの問題になるのでメール送信者側ではどうにもできない
結局、逆引きチェックをするかしないかは、お客様のサーバー側のポリシーの問題になるのでメール送信者側ではどうにもできません。
「セキュリティが低くなるかもしれませんが、弊社のメールを受信するために御社のポリシーを変更してください」とは言えません。
一番現実的な解決策としては、「お客様の環境がセキュリティに厳しいことを想定して、その中でも確実にメールを送信できるように設定する」です。
セキュリティ意識が高い企業が導入しているスパムメール対策
なりすましメールやスパムメールの問題は、「偽装できる」ことにつきます。
そもそも偽装できなければ、「なりすましメール」は不可能になります。
■メールの仕組み
上図のメールの仕組みを見ると分かりますが、メールは「エンベロープ」と「メッセージ」に分かれており、メッセージの「To:」と「From:」は自由に書き替えることができます。
なりすましメールが不可能になっても、スパムメールを送ってくる業者はいるかもしれませんが、ISP（インターネット・サービス・プロバイダ）側でアカウントを停止したり、ドメインを削除すればメールは送信できなくなります。
また、業者を特定されてしまうため、損害賠償などが怖くてそもそもスパムメールは送れなくなります。
■現在のセキュリティ対策
- ドメインの逆引きチェック
- SPF (Sender Policy Framework) ← 送信ドメイン認証（エンベロープ MAIL FROM: をチェック）
- Sender ID ← 送信ドメイン認証（PRA でチェック）
- DKIM (ドメイン・キー・アイデンティファイド・メール) ← 送信ドメイン認証
- DMARC（Domain-based Message Authentication, Reporting, and Conformance） ← SPF および DKIM による認証を補完する仕組み
詐称メールやなりすましメールについては、メールヘッダーを確認することで分かります。
詳しくは以下の記事を参考にしてください。
【メール】メールヘッダーの解析方法【メールトラブル解析】
逆引きチェックをすると届いてほしいメールが届かなくなることもあるので要注意
メールアドレスのドメイン逆引きチェックは、「送信元のドメイン」と「グローバル IP の逆引きのドメイン」が一致しているかどうかを見ています。
- 送信元のドメイン
- グローバル IP の逆引きのドメイン
例えば「taro@tama-chan.com」からメールが配信されてきたとして、「tama-chan.com」ドメインの MX レコードを引くと「mx.tama-chan.com」が返ってきます。
「mx.tama-chan.com」のグローバル IP をチェックすると「123.123.123.10」が返ってきました。
念のため「123.123.123.10」の逆引きをチェックすると「mx.tama-chan.com」が返ってきました。
ここまでチェックすれば「なりすましメール」ではないことが分かります。
逆引きチェックをすると、ある程度のスパムメールは排除できますが、その一方、一般的な企業でもメールアドレスのドメインを正引きして IP アドレスを取得し、その IP アドレスを逆引きすると異なるドメインが返ってくることはよくあります。
つまり、逆引きチェックを厳しくしすぎると取引先企業とメールのやり取りができなくて機会損失につながることがあるので要注意です。
SPF（Sender Policy Framework）は送信ドメインを認証する仕組み
メール送信元をチェックする仕組みで、現在最も利用されている仕組みが SPF（Sender Policy Framwork）です。
DNS SPFレコードとは何か？
Sender Policy Framework プロジェクトホームページ
http://www.openspf.org/Project_Overview
SPF の設定は DNS サーバーに「SPF レコード（TXT レコード）」を追加するだけです。
■SPF（Sender Policy Framework）の仕組み
SPF の仕組みはそれほど複雑ではなく、あらかじめドメイン（例では tama-chan.com）を管理している DNS サーバ上にメールサーバ（例では mail.tama-chan.com）の IP アドレスを設定しておきます。
設定は「SPF レコード」と言い、実際は「TXT レコード」でリソースレコードが設定されています。
メール受信者はなりすましメールかどうかを確認するために SPF レコードをチェックして、DNS サーバーに問い合わせた IP アドレス（グローバル IP アドレス）と SPF レコードで登録されている IP アドレスと一致するか確認します。
メール受信者側は、エンベロープの「MAIL FROM:」コマンドの結果をもとに問い合わせます。
一致していれば、送信元のドメインが管理しているメールサーバーより送信されてきたことが認証できます。
SPF レコードの書き方
SPFレコードの書き方ですが、
- SPF RR
- TXT RR
の2つの書き方があります。
なぜ2つの書き方があるのかと言いますと、本来 SPF レコードを使用するのが標準ですが、SPF レコードに対応している新しいリゾルバが少ないため、「SPF RR」でも「TXT RR」でも利用できるようになっています。
優先度は「SPF RR」の方が優先度が高く、「SPF RR」と「TXT RR」の両方が存在しているなら「SPF RR」のレコードが読まれます。
SPFレコードに対応していないリゾルバの場合は「TXT RR」に従います。
- ドメイン：tama-chan.com
- メールサーバーホスト名：mail.tama-chan.com
- メールサーバー IP アドレス：123.123.123.123
|
tama-chan.com. IN TXT "v=spf1 ip4:123.123.123.123 -all" |
上記の SPF レコードは SMTP サーバーの IP アドレスが「123.123.123.123」がメールアドレスのドメイン「tama-chan.com」のメールを送信しますよということをレコードにしています。
メールサーバーは構築時に DNS のゾーンに MX レコードして登録される
メールサーバーを特定するためには、MX レコードを引いて送信先のメールサーバーのホスト名を確認します。
その後、返ってきたメールサーバーのホスト名に対してメールを配信します。
もちろん、返ってきたメールサーバーのIPアドレスが分からなければアクセスできません。
レピュテーション（Reputation, 評判）も重要
メールの到達率とかエラーメールなどからISPが判断することがあります。
RCPTの読み方
RCPT は「RECIPIENT（レシピエント、受信者、受領者）」の略です。
そのため、RCPT は「レシピエント」と読むのが正解のようです。
「逆引きチェックをすると届いてほしいメールが届かなくなることもあるので要注意」の記述は、すこし雑すぎるかもしれません。
Postfixで普通にDNSの逆引きチェックをする場合、reject_unknown_client を使います。
http://www.postfix-jp.info/trans-2.1/jhtml/postconf.5.html#reject_unknown_client
reject_unknown_client は、接続してきたIPアドレスを逆引きし、得られたホスト名をもう一度正引きしてみて元のIPアドレスにもどるかどうかを見ています。
例えば、送り元の エンベロープFromのメールアドレスが 「taro@tama-chan.com」であったとしても、
123.123.123.10 --> mailhost.example.jp --> 123.123.123.10
と元の接続元IPアドレスに戻ればOKなのです。
つまり、逆引きDNSサーバーでホスト名を詐称しても、ドメインを所有者が管理している正引きDNSサーバーで正しく引けなければホスト名を詐称していることを確認できるわけです。
メールサーバーは、他のドメインのメールを中継するので、別に mailhost.example.jp が、「taro@tama-chan.com」のメールを中継しても構わないのです。
もちろん、特別にポリシーサーバー等で、メール受信のポリシーを定め、そういうメールは弾くとしても受信する人の自由なので別にかまいませんが...。