## この記事でわかること - オープンリレー（第三者中継）とは何か、なぜ放置すると到達率が崩壊するのか - 自社メールサーバがオープンリレーかどうかを確認する2つの方法 - Postfix で中継を正しく制限し、認証必須にする設定のポイント ## オープンリレーとは何か、なぜ危険か ある日、自社のメールサーバから送った覚えのない海外宛てのメールが大量に滞留している。取引先へのメールが軒並み迷惑メール扱いになり、しまいには「届かない」と連絡が来る——。これはオープンリレー（第三者中継）の典型的な被害です。自社で構築したメールサーバや、古い設定のまま動き続けている社内サーバを運用している場合、この問題は他人事ではありません。GoogleやMicrosoftのメールサービスを使っていれば通常は起きませんが、自前構築では設定を一つ間違えるだけで発生します。 恐怖をあおるつもりはありません。確認方法も対策も確立しているので、順を追って自社の状態を把握していきましょう。 オープンリレー（open relay）とは、**自社とは無関係な第三者のメールを、認証も制限もなく外部へ中継してしまう状態**のメールサーバを指します。 メールサーバ（MTA）には、本来「メールを別のサーバへ中継（リレー）する」という正規の役割があります。RFC 5321 でも、リレーサーバは MX レコードで指定された中継地点として定義されています。問題は、**誰の・どこ宛てのメールを中継するか**を制限していないことです。 正常なサーバは「自社の利用者が出すメール」だけを中継します。一方オープンリレーは、外部から来た「外部宛て」のメールを、認証なしで素通りさせてしまいます。違いはこの一点に集約されます。 ![正規の中継とオープンリレーの違いを示す図](/blog/open-relay-check-guide/relay-vs-open-relay.svg) 放置すると、次のような実害が連鎖します。 - **スパムの踏み台にされる**: スパム業者が自社サーバ経由で大量のメールを送り、送信元が自社ドメイン・自社IPになります - **ブラックリスト（DNSBL）に登録される**: スパム送信元として各種ブロックリストに載ると、正規のメールまで弾かれます - **到達率が崩壊する**: ブラックリスト入りすると、取引先や顧客への正規メールが届かなくなります - **回復に時間がかかる**: 一度載ったブラックリストからの削除申請は、即座には通りません メールが届かなくなるリスクの全体像については、[メールセキュリティ｜中小企業・スタートアップ向けの最低限 3 層防御](/blog/email-security-smb)もあわせて確認してください。 ## 自社サーバがオープンリレーか確認する方法 確認方法は大きく2つあります。手軽なオンラインテストと、仕組みを理解したうえでの手動確認です。 ### オンラインのオープンリレーテスト 外部のチェックサービスに自社サーバのホスト名やIPアドレスを入力すると、第三者中継が通るかを自動でテストしてくれます。MXToolbox などの SMTP 診断ツールが代表的です。 注意点として、過去に使われていた `njabl` や `ordb`、`mail-abuse` などの古い relay-test サービスは現在いずれも終了しています。情報が古いまとめ記事の URL をそのまま叩いても動きません。現在も稼働しているサービスを使ってください。 ### telnet による手動確認の考え方 仕組みを理解するうえで有効なのが、SMTP 対話を手で打つ方法です。ただし**確認の前提を間違えると、安全なサーバを「オープンリレー」と誤判定します**。 重要なのは、**必ず外部のホストから、認証なしで接続してテストする**ことです。サーバ自身（localhost）から打つと、後述する `permit_mynetworks` の設定で中継が許可されてしまい、オープンリレーでなくても「通った」と見えてしまいます。 確認したいのは「外部のIPから、外部ドメイン宛てのメールが、認証なしで通るか」という一点です。外部のサーバからポート25へ接続し、おおむね次のようなやり取りを行います。 ``` HELO test.example MAIL FROM: RCPT TO: ``` ここで送信元（MAIL FROM）も宛先（RCPT TO）も自社と無関係なドメインなのに、`RCPT TO` に対して `250` などの受理応答が返ってきたら、オープンリレーの疑いが濃厚です。正しく設定されたサーバなら、ここで `554` や `550 Relay access denied` のような拒否応答が返ります。 逆に `RCPT TO` が拒否されれば、第三者中継は遮断できています。 ## Postfix での対策 代表的なMTAである Postfix を例に、中継を正しく制限する設定を見ていきます。鍵になるのは「誰を信頼するか」を定義する `mynetworks` と、中継可否を判定する `smtpd_relay_restrictions` です。 ![Postfix が中継可否を判定する流れを示す図](/blog/open-relay-check-guide/postfix-relay-guard.svg) ### mynetworks を広げすぎない `mynetworks`（マイネットワークス）は、認証なしで中継を許可する「信頼するネットワーク」を定義するパラメータです。社内LANのIP範囲などを指定します。 ここを `0.0.0.0/0`（全てのIP）のように広く設定すると、世界中のどこからでも中継できる状態、つまりオープンリレーになります。**必要最小限の範囲だけを指定する**のが鉄則です。安易に広いレンジを書かないでください。 ### smtpd_relay_restrictions で中継を制限する Postfix 2.10 以降では、中継の可否を `smtpd_relay_restrictions` で制御します。既定値は次のとおりです（Postfix 公式ドキュメント）。 ``` smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination ``` 意味は「信頼ネットワーク（`permit_mynetworks`）または認証済み利用者（`permit_sasl_authenticated`）なら中継を許可し、それ以外の外部宛て中継は拒否する」というものです。この既定値のおかげで、Postfix は初期状態でも全開放にはなりません。 ただし既定値の最後は `defer_unauth_destination`（一時エラーで保留）です。運用では、これを恒久拒否の `reject_unauth_destination` に変更しておくのが推奨されます。 ``` smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination ``` 設定を変更したら、必ず外部ホストからテストして、第三者中継が拒否されることを確認します。DNS やメール周りの変更は影響範囲が広いため、慎重に進めてください。Postfix での認証・署名まわりの構築は[Postfix で DMARC を自前構築する手順](/blog/postfix-dmarc-setup)も参考になります。 ### 認証必須（SMTP AUTH）と submission ポートの分離 中継を安全にする本質は、**外部からの送信には認証（SMTP AUTH）を必須にする**ことです。 ここで役立つのが、ポートの使い分けです。RFC 6409 では、利用者がメールを送り出す「メッセージ送信（submission）」を、サーバ間の中継とは別の専用ポート **587番** に分離しています。587番は認証を前提とした送信専用ポートで、サーバ間中継の25番とは役割が異なります。 つまり、 - **25番（サーバ間中継）**: 認証なし。中継先は `smtpd_relay_restrictions` で厳しく制限する - **587番（利用者の送信）**: SMTP AUTH 必須。認証された自社利用者だけが外部へ送れる このように送信経路を分けることで、「外部からの認証なし中継は拒否しつつ、自社利用者の送信はきちんと通す」という両立ができます。SMTP の応答コードの意味を確認したいときは[SMTP 応答コード（リプライコード）一覧と意味](/blog/smtp-reply-codes-reference)もあわせてどうぞ。 ## よくある質問 ### GoogleやMicrosoft 365を使っていてもオープンリレーの心配は必要ですか 通常は不要です。Google WorkspaceやMicrosoft 365などのクラウドメールは、提供側が中継制限と認証を適切に管理しています。オープンリレーが問題になるのは、主に自前で構築したメールサーバや、古い設定のまま運用している社内サーバです。 ### 一度ブラックリストに載ると元に戻せますか 原因（オープンリレー状態）を解消したうえで、各ブラックリストの削除申請を行えば、解除は可能です。ただし即時には反映されず、再発防止が確認されるまで時間がかかる場合があります。まずはオープンリレーを塞ぐことが先決です。 ### Postfixのデフォルト設定なら安全ですか Postfix 2.10 以降の既定値は全開放ではなく、一定の中継制限がかかっています。ただし `mynetworks` を広く設定していたり、既定値が `defer_unauth_destination`（一時保留）のままだったりすると不十分です。明示的に `reject_unauth_destination` を置き、外部からテストして確認してください。 ## まとめ - オープンリレーは「無関係な第三者の、外部宛てメールを認証なしで中継する」状態で、スパムの踏み台・ブラックリスト入り・到達率崩壊に直結する - 確認は、現存するオンラインテストか、外部ホストからの手動 SMTP 確認で行う。サーバ自身からのテストは誤判定するため避ける - Postfix では `mynetworks` を広げすぎず、`smtpd_relay_restrictions` に `reject_unauth_destination` を置き、外部送信は587番ポートで SMTP AUTH 必須にする 自社のドメインやメール設定がどのような状態にあるか、無料で診断できます。 オープンリレーやメール認証まわりが不安な方は、お気軽にご相談ください。 専門家がわかりやすくサポートいたします。 [無料でドメインを診断する](/diagnose)