第5回・第6回で、送信ドメイン認証を整えました。でも、認証に合格しただけでは届くとは限りません。受信側は、送信元のIPや過去の実績、内容など、いくつもの観点でメールを疑っています。

第7回では、受信側がどこで疑うのか、送信側は何を整えれば届くのかを見ていきます。

迷惑メール対策の層

受信側のメールサーバーは、1通のメールをまとめて判定するのではなく、いくつもの層で順に疑います。

1. 接続時の検査：接続元のIPアドレスをDNSBL（ブロックリスト）やレピュテーションで照会し、逆引きやEHLO名、接続の頻度を確かめる。ここで断れば本文を受け取らずに済むため、大半の迷惑メールはこの層で落とす
2. 送信ドメイン認証：SPF・DKIM・DMARCでなりすましを確かめる（第5回・第6回）
3. 内容の検査：本文・URL・添付ファイルを調べる
4. レピュテーション：送信元のIPとドメインの過去の実績を加える
5. 判定：受信箱・迷惑メールフォルダー・拒否を決める

最後の層が利用者の報告で、「迷惑メール」ボタンの押下が苦情率として送信者の評判に返ります。

送信側から見ると、どの層で引っかかったかで、エラーの出方も対処も変わります。接続時に拒否されれば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の無償の公開ミラーは、非商用・少量の利用に限られます。公開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: <https://news.example.jp/unsub?u=8f3a2c>, <mailto:unsub@news.example.jp>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Gmailの大量送信者は「個人のGmailアカウント宛てに1日およそ5,000通以上」で、一度該当すると以後もずっと大量送信者として扱われます。送信者ガイドラインの全体は第6回、SESでの実装は第10回、設計は第12回の問3で扱います。

ポイント
広告と業務メールはサブドメインで分ける。広告の苦情で、業務メールまで届かなくなるのを防ぐ。

メールセキュリティゲートウェイ

受信側の対策を、専用の製品やサービスで強化することもあります。

ゲートウェイの後ろのMicrosoft 365からは、接続元がすべてゲートウェイのIPに見え、SPFが失敗したり、件名やURLの書き換えでDKIMの署名が壊れたりします。Microsoft 365では、コネクターの拡張フィルター（Enhanced Filtering for Connectors）で元の接続元を判定させるか、ゲートウェイのARC（第6回）を信頼する設定をします。

検査をMXの前に置くか、後ろに足すかで、見え方が変わるのです。

考えてみよう

1. 自社の送信サーバー（またはリレーの出口）のIPは、DNSBLに載っていませんか。逆引きと正引きは一致していますか。EHLOで何と名乗っていますか。
2. 社内のPostfixにDNSBLの照会を設定したところ、ある日からすべてのメールを拒否し始めました。何が起きた可能性があり、どう確かめますか。
3. 会員向けのお知らせメールを、業務メールと同じドメイン・同じサーバーから送っています。苦情が増えたとき、業務メールに何が起きますか。どう分けますか。

ヒント：この記事の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回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信（この記事）
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート
12. メールの設計演習