トップ > Amazon SES > Amazon SES Mail Manager の宛先ドメインごとでSMTPリレーの転送先を振り分ける

Amazon SES Mail Manager の宛先ドメインごとでSMTPリレーの転送先を振り分ける

Amazon SES Amazon SES Mail Manager
記事タイトルとURLをコピーする

こんにちは、近藤（りょう）です！

Amazon SES Mail Manager（以下、Mail Manager）を利用して、宛先ドメインに応じてメールの転送先を振り分ける構成を検証しました。

今回実現するルーティングは、以下のとおりです。

  • ドメインAAA宛（例：@aaa.example.com）のメールは、メールサーバーAへ転送
  • ドメインBBB宛（例：@bbb.example.com）のメールは、メールサーバーBへ転送

Mail Manager の Rule set を使うことで振り分けられますが、ルールの評価やログの確認方法など、実際に検証して初めて分かった点もありましたので設定手順と検証結果に加えて、構成を検討する時に押さえておきたいポイントもご紹介します。

本記事では、そのうち SMTP 認証を必要としない OPEN タイプの Ingress endpoint を利用した検証をしています。

docs.aws.amazon.com

検証構成

検証用のメールサーバーとして、Mailpit をインストールした Windows Server の EC2 インスタンスを2台用意しました。

MailManager検証構成-認証なし

メールクライアントの EC2 インスタンスから、Interface VPC endpoint 経由で Mail Manager の OPEN Ingress endpoint へメールを送信します。Ingress endpoint までの通信は VPC 内のプライベートネットワークで完結します。

Mail Manager は Rule set の条件に従い、ドメインAAA宛のメールをメールサーバーAへ、ドメインBBB宛のメールをメールサーバーBへ転送します。

なお、Mail Manager の SMTP relay に指定できる転送先は、パブリックに到達可能な SMTP エンドポイントに限られますので、今回の検証では Mailpit をインストールした各 EC2 インスタンスに Elastic IP アドレスを割り当てています。

SMTP relay - Amazon Simple Email Service

All SMTP endpoints you configure with Amazon SES SMTP relay must be public as private SMTP endpoints are not supported.

使用した主なリソース

リソース 用途
VPC、Public subnet 検証環境のネットワーク
EC2 Linux（Amazon Linux 2023） swaks を利用したメールクライアント
EC2 Windows × 2、Mailpit SMTPリレー先メールサーバー（メールサーバーA、メールサーバーB）
Interface VPC endpoint Ingress endpoint へプライベート接続するためのエンドポイント
Mail Manager Ingress endpoint メールを受け付けるSMTPエンドポイント
Mail Manager Traffic policy 送信元IPアドレスによるアクセス制御
Mail Manager Rule set 宛先ドメインによる転送先の振り分け
Mail Manager SMTP relay × 2 転送先SMTPサーバーの定義
Route 53 SES ドメイン認証用の DNS レコード管理
CloudWatch Logs Ingress endpoint と Rule set のログ確認


（補足）Mailpit とは？

Mailpit は、メールの送信確認テストに必要な機能を簡単に用意できます。

・単一のバイナリで起動できる
・ドメインごとのメールボックス設定が不要
・Web UI で受信したメールを確認できる
・SMTP サーバーとして受信したメールを外部へ配送しない

今回は Windows Server の EC2 インスタンスへインストールし、SMTP ポートと Mailpit の Web UI をインターネットへ公開します。

Mailpit の導入方法は、以下の公式ドキュメントもご参照ください。


（補足）swaks とは？

swaks は、コマンドラインから SMTP サーバーへテストメールを送信できるツールです。宛先・送信元・認証情報・TLS の有無などをオプションで指定でき、SMTP の疎通確認に便利です。

swaks の導入方法は、以下の公式ドキュメントもご参照ください。


Amazon Linux 2023 の標準リポジトリでは swaks をインストールできないので、今回は配布元から取得しました。

■ 参考コマンド

curl -o /tmp/swaks \
  https://jetmore.org/john/code/swaks/files/swaks-20240103.0/swaks
chmod +x /tmp/swaks
sudo mv /tmp/swaks /usr/local/bin/

Mail Manager の設定

  • 前提
    • 既に、VPCとEC2は設定は完了していること
    • SMTP relay は、インバウンド (非認証) の設定を行うため、宛先を SES の Verified identity に登録をしていること（構成を検討する際の注意点参照のこと）

Mail Manager は、以下の設定します。

  1. Traffic policy
  2. SMTP relay
  3. Rule set
  4. Ingress endpoint
  5. ログ配信

1. Traffic policy

Traffic policy では、Ingress endpoint へ接続できる送信元を制御します。

■ 例

項目 設定値
Traffic policy name kensho-relay-policy
Default action Deny
Action Allow
Condition type IP address
Evaluate Sender IP
Operator CIDR matches
Values メールクライアントのプライベートIPアドレス／VPC CIDR

今回は VPC エンドポイント経由で接続するため、Traffic policy にはメールクライアントのプライベートIPアドレス、または VPC CIDR（例：10.0.0.0/16）を指定します。

本番環境では、許可範囲が必要以上に広くならないよう、メール送信元となるサブネットやサーバーのCIDRに絞ることを検討します。

■ イメージ

Traffic policy

2. SMTP relay

転送先となる SMTP relay を2つ作成します。

■ 例

項目 メールサーバーA メールサーバーB
Relay name relay-aaa relay-bbb
Server name EC2 Windows ①の Elastic IP アドレス EC2 Windows ②の Elastic IP アドレス
Server port 25 25
Authentication No authentication No authentication

■ イメージ

SMTP relay

3. Rule set

Rule set の作成

項目 設定値
Rule set name kensho-relay-rules

作成した Rule set には、宛先ドメインごとに2つのルールを設定します。

Rule 1：ドメインAAA宛のメールをメールサーバーAへ転送

項目 設定値
Rule name relay-to-aaa
Condition Recipient address ENDS_WITH @aaa.example.com
Exception（Unless） なし
Action Relay：relay-aaa

Rule 2：ドメインAAA宛以外のメールをメールサーバーBへ転送

項目 設定値
Rule name relay-to-bbb
Condition なし
Exception（Unless） Recipient address ENDS_WITH @aaa.example.com
Action Relay：relay-bbb

Rule 1 を先、Rule 2 を後に配置します。

Rule set

■ 補足: Rule 2 に Exception を設定する理由

条件を設定していない Rule 2 は、すべてのメールにマッチします。Rule 1 の Relay アクションが実行された後も後続ルールの評価は続くため、Exception を設定しない場合、ドメインAAA宛のメールは両方の SMTP relay へ転送されます。

そのため、Rule 2 に @aaa.example.com を除外する Exception を設定し、重複転送を防止します。

振り分け対象のドメインが明確な場合は、キャッチオールにせず、Rule 2 に @bbb.example.com の Condition を設定する方法もあります。意図しない宛先への転送を避けたい場合は、対象ドメインを明示する構成が分かりやすいです。

4. Ingress endpoint

項目 設定値
Ingress endpoint name kensho-relay-ingress-open
Type OPEN
Network type Private
VPC endpoint OPEN タイプ用の Interface VPC endpoint（サービス名: com.amazonaws.＜リージョン＞.mail-manager-smtp.open）
Rule set 3. Rule set 作成した Rule set
Traffic policy 1. Traffic policy で作成した Traffic policy
Transport Layer Security (TLS) policy Optional

VPC エンドポイント経由の OPEN タイプでは SMTP 認証を必要とせず、ポート25および587を利用できます。Interface VPC endpoint のセキュリティグループや Traffic policy で接続元を制限できます。

Ingress endpoint

5. ログ配信

Ingress endpoint と Rule set で、CloudWatch Logs へのログ配信を有効化します。

対象リソース Log type 主な確認内容
Ingress endpoint TRAFFIC_POLICY_DEBUG_LOGS Traffic policy の評価、送信元IPアドレス、TLS情報
Ingress endpoint APPLICATION_LOGS 受信メッセージ、宛先、メッセージサイズ
Rule set APPLICATION_LOGS マッチしたルール、実行したアクション、実行結果

ログ配信先は CloudWatch Logs のほか、Amazon S3 と Amazon Data Firehose も選択できます。

docs.aws.amazon.com

動作確認

メール送信

メール送信イメージ

ドメインAAAとドメインBBBへ、それぞれメールを送信します。

# ドメインAAA宛
swaks \
  --to test@aaa.example.com \
  --from noreply@aaa.example.com \
  --server <Interface VPC endpointのDNS名> \
  --port 25 \
  --helo localhost \

# ドメインBBB宛
swaks \
  --to test@bbb.example.com \
  --from noreply@aaa.example.com \
  --server <Interface VPC endpointのDNS名> \
  --port 25 \
  --helo localhost \

検証結果

テスト内容 期待する動作 結果
ドメインAAA宛 メールサーバーAのみに転送される 成功
ドメインBBB宛 メールサーバーBのみに転送される 成功
ドメインAAA宛の重複転送 メールサーバーBには転送されない 成功

Mailpit の Web UI から、メールが想定した転送先のみに届いていることを確認できました。

aaa

重複転送なし

Rule set の後続ルールも評価される

今回、最も注意が必要だったのは Rule set の評価です。

当初は、以下の2つのルールを設定していました。

Rule 1：Recipient address ENDS_WITH @aaa.example.com → relay-aaa
Rule 2：条件なし                                  → relay-bbb

Rule 1 にマッチした時点で処理が終わると想定していましたが、ドメインAAA宛のメールがメールサーバーAとメールサーバーBの両方へ転送されました。

Mail Manager のルールは指定した順序で実行されますが、先行ルールのアクションが成功しただけでは後続ルールの評価は停止しません。また、条件を設定していないルールはすべてのメールにマッチします。

そのため、後続の Rule 2 に以下の Exception を追加しました。

Exception：Recipient address ENDS_WITH @aaa.example.com

設定後、ドメインAAA宛のメールはメールサーバーAのみに転送されました。

複数ルールを作成する場合は、個々のルールだけではなく、同じメールが後続ルールの条件にも一致しないかを確認する必要があります。

CloudWatch Logs でメールフローを確認する

Mail Manager のログでは、メールの受け付けから Rule set のアクション実行までを確認できます。

1. Traffic policy の評価

TRAFFIC_POLICY_DEBUG_LOGS は宛先ごとに生成され、Traffic policy の評価結果を確認できます。

TRAFFIC_POLICY_DEBUG_LOGS

traffic_policy_verdict が REJECT の場合も、Traffic policy のデバッグログは出力されます。Ingress endpoint の Application logs は、Ingress endpoint が受け付けたメールに対してのみ生成されます。

2. Ingress endpoint での受信

Ingress endpoint の APPLICATION_LOGS はメッセージごとに生成されます。

Ingress endpoint の APPLICATION_LOGS

ここで発行される message_id を利用して、Rule set のログまで同じメールを追跡できます。

3. Rule set のアクション実行結果

Rule set の APPLICATION_LOGS は、メッセージおよび実行したアクションごとに生成されます。

Rule set の APPLICATION_LOGS

action_status では、SUCCESS、FAILURE、IN_PROGRESS のいずれかを確認できます。

CloudWatch Logs Insights では、以下のように message_id を指定すると、対象メールに対して実行されたアクションを追跡できます。

fields @timestamp, message_id, rule_name, recipients_matched,
       action_metadata.action_name, action_metadata.action_status,
       action_metadata.action_failure
| filter message_id = '<message-id>'
| sort @timestamp asc

CloudWatch Logs Insights

リレー先を停止した場合の動作

Mailpit を停止した状態でメールを送信し、その後 Mailpit を起動して復旧させました。

初回の配送時は Rule set のログに IN_PROGRESS が記録され、復旧後に同じ message_id で SUCCESS が記録されました。

一時的に転送先へ接続できない場合、即座にメールが失われるのではなく、Mail Manager が再試行することを確認できましたが、この結果は今回の検証時点における一例のため、再試行間隔や回数を保証するものではありません。

構成を検討する際の注意点

SMTP relay の転送先はパブリックエンドポイントのみ

Mail Manager の SMTP relay に指定できるのは、パブリックに到達可能な SMTP エンドポイントです。プライベートIPアドレスのみを持つ VPC 内やオンプレミスの SMTP サーバーは、直接指定できません。

オンプレミスのメールサーバーへ転送する場合も、Mail Manager から到達できるパブリックな SMTP エンドポイントを用意する必要があります。

SMTP relay - Amazon Simple Email Service

All SMTP endpoints you configure with Amazon SES SMTP relay must be public as private SMTP endpoints are not supported.

SMTP relay インバウンド（非認証）の場合、宛先は SES の Verified identity が必要

SMTP relay には、ドキュメント上でインバウンド（非認証）とアウトバウンド（認証）の2パターンの手順が記載されています。

コンソールに選択項目があるわけではなく、実体はシークレットARNを設定するかどうかの違いです。シークレットARNを空欄のまま作成するとインバウンド（非認証）、シークレットを設定するとアウトバウンド（認証）になります。

インバウンド（非認証）の場合、メールの宛先メールアドレスまたはドメインを SES の Verified identity として事前に検証する必要があります。

SMTP relay - Amazon Simple Email Service
※「Creating an SMTP relay in the SES console」の Inbound タブ内参照のこと

Inbound

未検証の宛先へ転送した場合、Rule set のログで action_status: FAILURE となり、action_failure から原因を確認できます。

■ 出力例
"action_failure": "Email address is not verified. The following identities failed the check in region ＜リージョン名＞: ＜Eメールアドレス＞. Ensure that the domains of your intended recipient destinations are SES verified domain identities"

Verified identity error

また、アウトバウンド（認証）の SMTP relay では宛先の検証は不要とのことです（2026年9月時点、AWS Support 回答）。

アウトバウンド（認証）については、本記事では未検証のため、利用を検討される場合は実機での確認お願いします。

ルール数とRelayアクション数のクォータ

2026年9月時点で、Mail Manager には以下のクォータがあります。

項目 デフォルトクォータ 引き上げ
Rule set あたりのルール数 40 不可
Rule あたりのCondition数 10 不可
Rule あたりのAction数 10 不可
Rule set あたりのRelayまたはSendアクション数 10 不可
SMTP relay 数 40 不可

宛先ドメインごとに Relay アクションを作成する場合、特に Rule set あたりの Relay／Send アクション数が設計上の上限になります。

docs.aws.amazon.com

Ingress endpoint あたりの送信レート

2026年9月時点で AWS Support へ確認したところ、Ingress endpoint あたりの送信レートは 300 TPS との回答でした。上限を超えた場合は SMTP の 421 一時エラーが返され、Mail Manager 内部には受け付けられません。

送信元が Postfix などの MTA であれば、通常は4xx応答に対する再送機能を備えていますが、アプリケーションから直接 SMTP 接続している場合は、4xx 応答時にエクスポネンシャルバックオフを利用して再送できるか確認が必要です。

また、1つの VPC endpoint を複数の Ingress endpoint へ関連付けることはできません。もし、AUTH や OPEN の Ingress endpoint を併設する場合は、それぞれに VPC endpoint を作成します。

SMTP relay の再試行の仕様

AWS の公開ドキュメントでは、SMTP relay の再試行間隔や最大再試行期間の詳細を確認できませんでした。

今回（2026年9月時点）、AWS Support へ確認した内容では、再試行は約6時間との回答でした。ただし、公開仕様ではなく、今後変更される可能性があります。本番利用時は AWS Support へ最新仕様を確認することをおすすめします。

また、Rule set の Application logs にはアクションの FAILURE や IN_PROGRESS が記録されます。配送失敗を見逃さないよう、CloudWatch Logs のメトリクスフィルターやアラームを利用して RELAY アクションの失敗を監視する構成を検討します。

まとめ

Mail Manager の Rule set を利用して、宛先ドメインごとにメールの転送先を振り分ける構成を検証しました。

  • 条件なしのルールはすべてのメールにマッチする
  • 先行ルールの Relay アクションが成功しても、後続ルールの評価は続く
  • 重複転送を防ぐには、Condition または Exception を利用してルールの対象を排他的にする
  • message_id をキーに Ingress endpoint と Rule set のログを確認できる
  • OPEN タイプでも、VPC endpoint を関連付けることでプライベート接続にできる
  • SMTP relay の転送先は、パブリックに到達可能なエンドポイントである必要がある
  • SMTP relay の宛先は、インバウンド（非認証）の場合 SES の Verified identity として検証する必要がある
  • 再試行の詳細は公開仕様ではないため、監視設計とあわせて最新情報を確認する

設定手順だけを見るとシンプルですが、複数ルールに同じメールがマッチする点や、リレー先で障害が発生した場合のリトライ設計は、別途送信元で考慮する必要があります。

本記事が、Mail Manager を利用したSMTPリレーメールルーティングを検討する時の参考になれば幸いです。

参考リンク

近藤 諒都

（記事一覧）

クロスインダストリー第2本部インフラ技術課

夜行性ではありません。朝活派です。

趣味：お酒、旅行、バスケ、掃除、家庭用パン作り（ピザも）など

2026 Japan AWS Top Engineers
2025 - 2026 Japan AWS All Certifications Engineers