メールリレー

仕組み・詳細解説

SMTPリレーの通信フロー

メールリレーの内部では、通常のSMTP配送と同じコマンドのやり取りが行われます。違うのは「受け取ったメールの宛先ドメインが自分のものではない」場合に、それを拒否せず次のホップへ転送する点です。典型的な流れは次の通りです。

1. 送信側クライアント（MUA/業務システム）がリレーサーバーにSMTP接続
2. HELO/EHLO → MAIL FROM → RCPT TO のやり取り
3. リレーサーバーが送信元IP・認証情報・宛先ドメインをチェック
   - 許可条件を満たせば → 次のMTA（最終宛先 or 別のリレー）へ再送信
   - 満たさなければ → 550 5.7.1 Relay access denied で拒否
4. 許可された場合、リレーサーバーはメールキューに一時保存し
   配送先MXへ非同期に再送信（メールキューで管理）

リレーの種類

「メールリレー」とひとくくりに言っても、構成上の役割によっていくつかのパターンに分かれます。

リレー許可の判定ロジック

Postfixのsmtpd_relay_restrictions（および旧来のsmtpd_recipient_restrictions）は、上から順にルールを評価し、最初にマッチした結果を採用します。主な判定材料は次の3つです。

• 送信元ネットワーク: mynetworksに含まれるIPからの接続は無条件で許可（permit_mynetworks）
• 認証状態: SASL認証済みユーザーは許可（permit_sasl_authenticated）
• 宛先ドメイン: 自ドメイン（mydestination）またはrelay_domainsに含まれる宛先のみ許可

これらいずれにも該当しない場合、最終行のreject_unauth_destinationによって拒否されます。この「最後は必ず拒否で締める」構成が、オープンリレー化を防ぐ最重要ポイントです。

具体例・ユースケース

業務システムからの通知メール送信

基幹システムやWebアプリケーションが「注文完了メール」「パスワードリセットメール」を送る際、アプリケーションサーバーから直接インターネットへ送信するのではなく、社内のリレーサーバー（またはAmazon SES等）にリレーさせる構成が一般的です。アプリケーション側はlocalhost:25や社内リレーホストにSMTP送信するだけでよく、SPF/DKIM署名やレート制御、送信ログの一元管理をリレーサーバー側にまとめられます。

クラウド配信サービス（ESP）経由のリレー

自前のPostfixサーバーから、Amazon SESやSendGrid、Mailgunといったメール配信サービス（ESP: Email Service Provider）をスマートホストとして利用するケースです。IPレピュテーションの管理やDKIM鍵のローテーションをESP側に任せられるため、自社でIPウォームアップを行うより到達率（Deliverability）が安定しやすいというメリットがあります。

拠点間・グループ会社間の集約リレー

複数拠点や複数システムを持つ組織で、各拠点のメールサーバーが個別に外部送信すると送信ドメイン認証（SPF/DKIM）の設定がばらつき、なりすまし判定を受けやすくなります。本社に集約リレーサーバーを置き、全拠点のメールを一度そこに集めてから外部へ送信することで、SPFレコードやDKIM署名ポリシーを一元管理できます。

障害時のバックアップMXによる一時中継

主系メールサーバーがメンテナンスや障害でダウンしている間、MXレコードで優先度の低いバックアップサーバーを指定しておくと、送信側MTAはそちらにメールを配送します。バックアップサーバーは受信したメールを自身のキューに保持し、主系復旧後にリレー（再送信）します。

メリット・デメリット（注意点）

メリット

• 送信経路の一元管理: SPF/DKIM/DMARCの設定やログ監視を一箇所に集約できる
• 到達率の向上: ESPのIPレピュテーションを活用でき、自前サーバーより到達率が安定しやすい
• 負荷分散・可用性: バックアップMXや複数リレーホストによる冗長構成が組める
• ポリシー適用の一貫性: スパムフィルタやウイルスチェックをゲートウェイ1箇所に集約できる

デメリット・注意点

• 単一障害点になり得る: リレーサーバーが停止すると、経由するすべてのメールが送信不可になる
• 設定ミスがオープンリレー化に直結: 制限ルールの記述順序や条件を誤ると、意図せず誰でも中継できる状態になる
• 遅延の要因になる: 中継ホップが増えるほど配送に時間がかかり、キュー滞留（メールキューの肥大化）が起きやすい
• 認証情報の管理負荷: SASLパスワードやESPのAPIキーなど、複数の認証情報を安全に管理する必要がある
• DMARC・ARCへの配慮が必要: 中継時にヘッダーやFromが書き換わると送信ドメイン認証が失敗しやすくなる

混同されやすい用語・類似技術との違い

オープンリレーの危険性

オープンリレーとは、送信元や宛先を一切チェックせず、誰でも自由に中継できてしまう誤設定状態を指します。1990年代後半〜2000年代前半にはデフォルト設定のままオープンリレーになっているサーバーが多く社会問題化しましたが、現在の主要MTA（Postfix/Exim/Sendmail）はいずれもデフォルトでリレー制限が有効になっています。それでも「動作確認のために制限を緩めたまま放置」「クラウド移行時の設定ミス」でオープンリレー化する事故は今も後を絶ちません。

具体的なリスク

• スパム送信の踏み台化: 攻撃者が自社サーバーを経由して大量のスパム・フィッシングメールを送信する。数時間〜数日でキューに数万通が滞留するケースもある
• RBL（ブラックリスト）登録: Spamhaus等の主要RBLに送信元IPが登録され、Gmail・Outlook・yahoo.co.jp等の主要プロバイダー宛てのメールが軒並み拒否・迷惑メール判定される
• リソース枯渇: 大量中継によるCPU・帯域・ディスクI/Oの消費でサーバー全体の性能が低下し、正規業務メールの遅延にもつながる
• ブランド・信用の毀損: 取引先に「なりすましメール」「不審な添付ファイル付きメール」が届き、自社の信用問題に発展する
• 法的責任: 意図せずとも管理不備によるスパム加担とみなされ、プロバイダー間の申し合わせに基づくアクセス遮断や契約解除に至ることもある

オープンリレー化を招く典型的な設定ミス

• mynetworksに広すぎるCIDR（例: 0.0.0.0/0）を誤って指定してしまう
• 制限ルールの並び順を誤り、permit_mynetworksより前に無条件のpermitが入ってしまう
• 検証用に一時的にsmtpd_recipient_restrictionsを空にしたまま、本番反映を忘れる
• クラウドのセキュリティグループ／ファイアウォールで25番ポートを全世界に開放してしまう

自社メールサーバー運用への応用

Postfixでのリレー制限

Postfixではsmtpd_relay_restrictions（新しめのバージョンでは推奨。旧バージョンではsmtpd_recipient_restrictionsと統合されている場合もある）でリレー可否を制御します。

# main.cf - オープンリレー防止
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination

# 許可するネットワーク（社内LAN・監視サーバー等）
mynetworks = 127.0.0.0/8, [::1]/128, 192.168.1.0/24

# 中継を受け付ける宛先ドメイン（自ドメイン以外を中継したい場合のみ明示）
relay_domains = $mydestination

この設定の要点は、リストの最後に必ずreject_unauth_destinationを置くことです。上位の条件（社内ネットワークからの接続、SASL認証済み）のいずれにも当てはまらない接続は無条件で拒否されるため、想定外の第三者中継を防げます。

SMTP認証（SASL）によるリレー許可

社外の営業担当者やリモートワーカーが、社外ネットワークから社内SMTPサーバー経由でメール送信したいケースでは、IP制限だけでは対応できません。SASL認証を有効にし、認証済みユーザーのみリレーを許可します。サブミッションポート（587番）と組み合わせるのが定石です。

# main.cf
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination

# master.cf - submissionポート（587）を有効化
submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

認証バックエンドにはDovecotのSASLライブラリを流用するのが一般的です。DovecotはIMAP/POP3サーバーとして稼働させつつ、Postfixの認証プロキシとしても兼用できるため、ユーザーDB（パスワード）を二重管理せずに済みます。STARTTLSまたは直接TLS（465番）を必須にし、認証情報を平文でやり取りしないことも忘れずに設定してください。

Smart Host（外部リレーサービス）の利用

自社IPからの直接送信ではなく、Amazon SESやSendGridなどのESPをスマートホストとして経由させる構成です。到達率の観点から中小規模の組織では第一候補になることが多い方式です。

# main.cf - Amazon SES経由の例
relayhost = [email-smtp.us-east-1.amazonaws.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_security_level = encrypt

# /etc/postfix/sasl_passwd
[email-smtp.us-east-1.amazonaws.com]:587 SES_SMTPユーザー名:SES_SMTPパスワード

sasl_passwd作成後はpostmap /etc/postfix/sasl_passwdでハッシュDB化し、パーミッションを600に絞ることを忘れないでください。ESP側の送信ドメイン認証（SPF・DKIM）設定も併せて行わないと、リレー自体は成功してもなりすまし判定で迷惑メールフォルダ行きになります。

DNS側の設定（MXレコードとSPF）

リレー構成を組む場合、DNS側にも正しい設定が必要です。バックアップMXを使う場合の例と、リレー元サーバーを送信許可するSPFレコードの例を示します。

; MXレコード例（主系優先度10、バックアップ優先度20）
example.com.    IN MX  10 mail1.example.com.
example.com.    IN MX  20 mail2-backup.example.com.

; SPFレコード例（自社サーバーとESPの両方を送信元として許可）
example.com.    IN TXT "v=spf1 mx ip4:203.0.113.10 include:amazonses.com ~all"

スマートホスト経由で送信する場合、Fromに使うドメインのSPFレコードにinclude:でESPのSPFドメインを追加しておかないと、リレー先から送られたメールが「なりすまし」としてSPF fail判定されてしまう点に注意してください。

オープンリレーチェック

設定変更後は、必ず外部ネットワークまたは外部ホストから自サーバーへ疑似的な中継リクエストを送り、拒否されることを確認します。社内ネットワークからのテストはpermit_mynetworksに該当してしまい正しく検証できないため、必ず社外の環境（VPS、モバイル回線など）から実施してください。

# 外部ホストから自サーバーのオープンリレーテスト
telnet mail.example.com 25
EHLO test.com
MAIL FROM: <test@external.com>
RCPT TO: <recipient@external.com>

# 拒否されれば正常（例: 454 4.7.1 Relay access denied）
# 受理されRCPT TOが250 OKになった場合はオープンリレー状態＝要修正

手動telnet確認に加え、MxToolboxなどの無料オンラインツールで定期的にスキャンしておくと、設定変更時のヒューマンエラーを早期に発見できます。また、Postfixの場合はpostconf -n | grep relayで現在有効な制限設定を一覧確認できるため、変更後のレビューに組み込んでおくとよいでしょう。

実務ポイント

• 制限ルールは「許可を先、拒否は最後」を徹底: permit_mynetworks→permit_sasl_authenticated→reject_unauth_destinationの順序を崩さない
• リレーログを継続的に監視: /var/log/mail.log（Postfix）でstatus=sentやrelay=の急増を検知し、想定外の大量送信を早期発見する
• 送信レート制限を設定: smtp_destination_rate_delayやanvilプラグインで、1接続あたりの送信数・頻度を制限し、万一の踏み台化時の被害を最小化する
• キュー状況を定期確認: メールキューに大量の未配送メールが滞留していないか（mailqコマンド）を監視し、異常な滞留があれば即座に調査する
• 認証情報のローテーション: SASLパスワードやESPのSMTP認証情報は定期的に変更し、退職者・システム変更時には速やかに失効させる
• 変更前後で必ずリレーテスト: main.cf変更後はPostfixをreloadし、外部からのオープンリレーチェックを都度実施する運用をルール化する

関連ブログ記事

• Docker Mailserver完全ガイド

Q. メールリレーとは？

SMTPサーバーが自ドメイン宛てではないメールを受け取り、別のサーバーへ転送する仕組みです。スマートホスト経由の送信や、社内リレーサーバーへの集約が代表的な利用形態です。

Q. スマートホストとメールリレーは同じものですか？

スマートホストはメールリレーの実装パターンの1つで、アウトバウンド送信を委任する先のサーバーを指す設定用語です。メールリレーはより広い概念で、インバウンドの中継やバックアップMXなども含みます。

Q. オープンリレーの危険性は？

誰でも自由に中継できてしまう状態のため、スパム送信の踏み台にされIPがRBL（ブラックリスト）に登録されます。正規メールも送信できなくなり、信用問題にも発展するため、認証とアクセス制限が必須です。

Q. メールリレーとメール転送（フォワーディング）はどう違いますか？

メール転送はメールボックス単位で「受信済みのメールを別アドレスへ再送する」機能です。メールリレーはMTA（サーバー）レベルで配達前のメールを別サーバーへ中継する動作を指し、発生するレイヤーが異なります。

Q. 自社サーバーがオープンリレーになっていないか、どう確認すればよいですか？

社外の環境からtelnetで自サーバーの25番ポートに接続し、外部ドメイン宛てのRCPT TOが拒否されるかを確認します。MxToolboxなどの無料オンラインツールでも診断可能です。

Q. Postfixでリレーを許可する条件はどこで設定しますか？

main.cfのsmtpd_relay_restrictions（旧: smtpd_recipient_restrictions）で設定します。許可条件を先に、最後に必ずreject_unauth_destinationを置くのが基本形です。