「うちから送ったメールが、取引先で迷惑メールフォルダーに入ってしまうそうです」
「DNSBLの設定を入れたら、ある日からすべてのメールを拒否し始めました」
第5回・第6回で、送信ドメイン認証を整えました。でも、認証に合格しただけでは届くとは限りません。受信側は、送信元のIPや過去の実績、内容など、いくつもの観点でメールを疑っています。
第7回では、受信側がどこで疑うのか、送信側は何を整えれば届くのかを見ていきます。
迷惑メール対策の層
受信側のメールサーバーは、1通のメールをまとめて判定するのではなく、いくつもの層で順に疑います。
- 接続時の検査：接続元のIPアドレスをDNSBL（ブロックリスト）やレピュテーションで照会し、逆引きやEHLO名、接続の頻度を確かめる。ここで断れば本文を受け取らずに済むため、大半の迷惑メールはこの層で落とす
- 送信ドメイン認証：SPF・DKIM・DMARCでなりすましを確かめる（第5回・第6回）
- 内容の検査：本文・URL・添付ファイルを調べる
- レピュテーション：送信元のIPとドメインの過去の実績を加える
- 判定：受信箱・迷惑メールフォルダー・拒否を決める
最後の層が利用者の報告で、「迷惑メール」ボタンの押下が苦情率として送信者の評判に返ります。
送信側から見ると、どの層で引っかかったかで、エラーの出方も対処も変わります。接続時に拒否されれば5xxのエラーが返りますが、迷惑メールフォルダーに入った場合は、送信側には何も返りません。
DNSBLの仕組み
DNSBL（DNS-based Blocklist、RFC 5782）は、登録されたIPアドレスをDNSのレコードとして公開する仕組みです。
# 接続元 203.0.113.45 を照会する：オクテットを逆順にしてリストのゾーンの下を引く（例）
$ dig +short 45.113.0.203.zen.spamhaus.org A
127.0.0.4 ← A レコードが返る＝登録あり（値で種類が分かる）
$ dig +short 46.113.0.203.zen.spamhaus.org A
← 何も返らない（NXDOMAIN）＝登録なし
$ dig +short 45.113.0.203.zen.spamhaus.org TXT # 理由・解除手続きの URL
PS> Resolve-DnsName 45.113.0.203.zen.spamhaus.org -Type A -DnsOnly- 受信サーバーは、接続のたびにDNSを1回引くだけで照会できる。IPの照会を、DNSの名前解決に置き換えている
- Aレコードが返れば登録あり、NXDOMAINなら登録なし。返る値（127.0.0.x）でリストの種類や理由を表し、TXTに説明や解除の窓口が入っていることが多い
- ドメインを載せるドメインのブロックリスト（Spamhaus DBL等）は、本文中のURLや送信元ドメインの照会に使う
- 自社の送信IPが載っていないかは、各リストのWebの照会ページで確かめる。公開DNSリゾルバー経由のdigでは、正しい結果にならないことがある（次で説明）
代表的なDNSBLと使い方の注意
| リスト | 載るもの | 主な使い方 |
|---|---|---|
| Spamhaus ZEN（zen.spamhaus.org） | SBL・XBL・PBL・CSS をまとめたもの | 接続時の拒否に最もよく使われる |
| SBL・CSS | スパムの送信元や、その運営者が使う IP | 接続時の拒否 |
| XBL | ボット・マルウェアに感染した端末の IP | 接続時の拒否 |
| PBL | 直接インターネットへメールを送るべきでない IP（家庭向け回線等） | 25番の受信にだけ使う。認証付きのサブミッション（587）には使わない |
| DBL | ドメイン | 本文中の URL・送信元ドメインの照会（IP には使わない） |
| その他（SpamCop 等） | 利用者の報告や観測に基づく IP | 拒否ではなく採点（スコア）の材料にする例が多い |
冒頭の「ある日からすべてのメールを拒否し始めた」は、ここに原因があることが多いです。
Spamhausの無償の公開ミラーは、非商用・少量の利用に限られます。公開DNSリゾルバー（8.8.8.8等）経由の問い合わせには127.255.255.254を返します。これを「登録あり」と扱うと、全メールを拒否する事故になります。
対策は次のとおりです。
- 自前のキャッシュDNSで引くか、無償のDQSに切り替える
- Postfixでは
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]のように、返る値を絞る
ポイント
DNSBLは「Aレコードが返ったら拒否」ではなく、「決まった値が返ったら拒否」と設定する。
レピュテーション（IPとドメイン）
受信側は、接続元のIPアドレスと送信ドメインのそれぞれについて、過去にどんなメールを送ってきたかという実績（レピュテーション）を蓄えています。
- 材料：迷惑メールとして報告された割合（苦情率）、存在しない宛先への送信の多さ、スパムトラップ（公開していない罠のアドレス）への着信、認証の結果など
- IPとドメインの違い：IPの評判はIPアドレスを変えれば白紙に戻るが、ドメインの評判はDKIMの署名やFromのドメインに付いて回る。そのため近年はドメインの評判が重視される
- 共有IPでは、同じIPの他の利用者の影響も受ける
自社の状況は、Gmail宛てはGoogle Postmaster Tools（迷惑メール率、認証、要件への適合状況）、Outlook.com宛てはMicrosoft SNDS（IPごとの苦情等）で確かめます。
逆引き（PTR）と正引きの一致（FCrDNS）
$ dig -x 203.0.113.25 +short # 送信 IP の逆引き
mail.example.jp.
$ dig mail.example.jp A +short # その名前の正引き
203.0.113.25 ← 元の IP に戻れば一致（FCrDNS）
PS> Resolve-DnsName 203.0.113.25 -Type PTR -DnsOnly
PS> Resolve-DnsName mail.example.jp -Type A -DnsOnly- 送信IPの逆引き（PTR）で得た名前を正引き（A／AAAA）して、元のIPに戻ることをFCrDNS（Forward-Confirmed reverse DNS）と呼ぶ。Gmailはすべての送信者にこの一致を求め、Yahooも送信IPに意味のある逆引きを求めている
- 逆引きの名前は
mail.example.jpのような汎用的でない名前にする。203-0-113-25.dynamic.isp.exampleのような回線の既定名は、家庭向け回線とみなされやすい - PTRを設定できるのは、IPアドレスの割り当て元（ISP・クラウド）。EC2はElastic IPに逆引きを設定でき、先に正引きを登録しておく（連載「DNS入門」第6回）
- IPv6で送る場合も同じ。IPv6だけ逆引きが無いのは見落としやすい
- 受信側のPostfixでは、
reject_unknown_reverse_client_hostname（PTRの有無だけ）やreject_unknown_client_hostname（正引きの一致まで）で検査できる。後者は正規のメールも落としやすい
名前とIPが互いを指し合って、はじめて身元の手がかりになります。
EHLO名
# 送信側（Postfix）：EHLO で名乗る名前。既定は $myhostname
smtp_helo_name = mail.example.jp
# 受信側（Postfix）：EHLO 名を検査する例
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname- EHLOでは自分のFQDN（または
[203.0.113.25]のようなアドレスリテラル）を名乗る（RFC 5321）。逆引きの名前とそろえると疑われにくい - よくある誤り：
localhost、社内だけの名前（mail.corp.local）、括弧の無いIPアドレス、クラウドの内部名（ip-10-0-1-5.ec2.internal） - 受信側は、EHLO名がFQDNか、DNSで引けるかを検査する。SPFもEHLO名を検査の対象にする
- 複合機やvCenterなどの機器は、自分のホスト名をそのまま名乗ることが多い。社内のリレーサーバーを経由すれば、外に名乗るのはリレーサーバーの名前になる（第8回）
OP25B（25番ポートの遮断）
OP25B（Outbound Port 25 Blocking）は、ISPが利用者の回線から、インターネット上の任意のメールサーバーの25番ポートへの接続を遮断する対策です。
- ボットに感染したパソコンが直接スパムを送るのを防ぐため、日本では2000年代半ばから主要なISPが導入した。そのため利用者のメールソフトは、587番に SMTP AUTHを付けて送る方式（第4回）が標準になった
- クラウドも同様：Amazon EC2は外向きの25番を既定で制限し（申請で解除）、Azureは契約の種類によって遮断し、Google CloudはVPCの外への25番を遮断している。いずれも認証付きのリレーを587番で使うことを勧めている
機器やPCから外部へ25番で送って「つながらない」ときは、まず経路上の遮断を疑います。
グレイリスティング
グレイリスティング（RFC 6647）は、初めて見る「送信元のIP・送信者・宛先」の組から来たメールを、いったん4xxの一時エラーで断る方法です。
- 正規のMTAは規格どおり数分後に再送するので2回目で受け取り、再送しない使い捨てのスパム送信プログラムだけが落ちる
- 単純で効果が高い一方、初回のメールが数分〜数十分遅れる、再送のたびに別のIPから送る大規模なメールサービスが何度も断られる、といった副作用がある。そのため大手のIPは除外リストに入れて運用する
- 送信側のログに
status=deferredと「Greylisted」「try again later」などが出ていても、再送で届いていれば正常 - Postfixでは、postgreyなどのポリシーサービスやpostscreenを使う
「メールが数分遅れて届く」という問い合わせの原因が、相手側のグレイリスティングであることもあります。
大量送信の作法
会員へのお知らせやメールマガジンなど、大量に送る場合は、さらに気を配る点があります。
| 項目 | 内容 | 目安・出典 |
|---|---|---|
| ワンクリック登録解除 | List-Unsubscribe と List-Unsubscribe-Post を付け、両方を DKIM の署名に含める | RFC 8058。Gmail・Yahoo の大量送信者の要件。2日以内に処理 |
| 苦情率 | 迷惑メールとして報告された割合 | 0.1%未満を目標、0.3%以上は要件違反（Gmail・Yahoo） |
| 送信量の立ち上げ（ウォームアップ） | 新しい IP・ドメインは少量から日ごとに増やす | 反応の良い宛先から始める。急増は一時エラーや迷惑メール判定を招く |
| バウンスの処理 | 恒久エラー（5xx）の宛先には次から送らない。一時エラーが続く宛先も止める | 無効な宛先への送信は評判を下げる。SES はバウンス率5%で審査 |
| 送信ドメインの分離 | 業務・通知・広告でサブドメイン（news.example.jp 等）や IP を分ける | 広告の評判の悪化が業務メールに波及しない |
List-Unsubscribe: <https://news.example.jp/unsub?u=8f3a2c>, <mailto:unsub@news.example.jp>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickGmailの大量送信者は「個人のGmailアカウント宛てに1日およそ5,000通以上」で、一度該当すると以後もずっと大量送信者として扱われます。送信者ガイドラインの全体は第6回、SESでの実装は第10回、設計は第12回の問3で扱います。
ポイント
広告と業務メールはサブドメインで分ける。広告の苦情で、業務メールまで届かなくなるのを防ぐ。
メールセキュリティゲートウェイ
受信側の対策を、専用の製品やサービスで強化することもあります。
| 方式 | 置き方 | 例 | 注意点 |
|---|---|---|---|
| ゲートウェイ型 | MX をゲートウェイに向け、検査したメールをメールボックスへ渡す | Cisco Secure Email Gateway（旧 ESA）、各社のクラウド型 | 後段からは接続元がゲートウェイに見え、SPF・DMARC の判定がずれる |
| メールサービスの内蔵 | メールボックスのサービスの受信経路で検査する | Microsoft 365 の標準の保護（旧 EOP）、Microsoft Defender for Office 365 | Defender は URL の検査（Safe Links）、添付の検査（Safe Attachments）等を加える |
| API 連携型 | 配送後のメールボックスを API で検査し、あとから隔離する | Cisco Secure Email Threat Defense 等 | MX を変えずに足せる。配送後の対処になる |
ゲートウェイの後ろのMicrosoft 365からは、接続元がすべてゲートウェイのIPに見え、SPFが失敗したり、件名やURLの書き換えでDKIMの署名が壊れたりします。Microsoft 365では、コネクターの拡張フィルター（Enhanced Filtering for Connectors）で元の接続元を判定させるか、ゲートウェイのARC（第6回）を信頼する設定をします。
検査をMXの前に置くか、後ろに足すかで、見え方が変わるのです。
考えてみよう
- 自社の送信サーバー（またはリレーの出口）のIPは、DNSBLに載っていませんか。逆引きと正引きは一致していますか。EHLOで何と名乗っていますか。
- 社内のPostfixにDNSBLの照会を設定したところ、ある日からすべてのメールを拒否し始めました。何が起きた可能性があり、どう確かめますか。
- 会員向けのお知らせメールを、業務メールと同じドメイン・同じサーバーから送っています。苦情が増えたとき、業務メールに何が起きますか。どう分けますか。
ヒント：この記事のdigによるDNSBLの照会、127.255.255.254、FCrDNS、大量送信の作法の「送信ドメインの分離」が答えにつながります。
まとめ
- 受信側は接続時・認証・内容・評判・報告の層で順に疑う。どの層で落ちたかで、エラーの出方が変わる
- DNSBLはDNSを1回引くだけの照会。公開DNSリゾルバー経由の127.255.255.254に注意し、返る値を絞る
- 評判はIPとドメインの両方に付き、近年はドメイン重視。Postmaster Tools・SNDSで確かめる
- 送信IPは逆引きと正引きを一致（FCrDNS）させ、EHLOではFQDNを名乗る
- 外向きの25番はISPもクラウドも遮断。587番＋SMTP AUTHが通り道
- グレイリスティングのdeferredは、再送で届けば正常
- 大量送信はワンクリック登録解除・苦情率・ウォームアップ・バウンス処理・ドメインの分離
次回は、こうした対策を受け持つMTAを、Postfixを例に安全に運用する方法を見ていきます。
連載「メール入門」全12回
- メールが届くまで
- SMTPのやり取り
- メッセージの構造
- ポートと暗号化・認証
- 送信ドメイン認証 前編
- 送信ドメイン認証 後編
- 迷惑メール対策と配信（この記事）
- MTAの運用
- コマンドで調べる
- クラウドと現代のメール
- メールのトラブルシュート
- メールの設計演習
コメント