はじめに
Amazon Simple Email Service（以下 SES）の送信ドメインを、「複数のリージョンで使いたい」「別の AWS アカウントからも使いたい」というご要望をいただくことがあります。今回の調査も、「AWS アカウントやリージョンが異なる複数のシステムから、同じドメインでユーザーに通知メールを送りたい」というご相談がきっかけでした。SES の ID と DKIM（DomainKeys Identified Mail）の署名設定は、アカウントとリージョンごとにあります。そのまま広げると、DNS レコードも設定も環境の数だけ増えていきます。
2026年の検証では、リージョンをまたぐ（クロスリージョン）場合、Deterministic Easy DKIM（以下 DEED）を使うと DNS に CNAME を足さずに済みました。アカウントをまたぐ（クロスアカウント）場合は、ドメインを持つ側が送信を許可する「送信承認」と、送信側でも同じドメインを検証する「個別検証」のどちらでも送れます。両方をまたぐ構成でも送れましたが、送信承認のポリシーなどは使うリージョンごとに用意する必要があります。
なお、本記事で紹介する別アカウントからの送信は、送信承認・個別検証とも東京リージョンでのみ確認しており、仕様は2026年10月時点の公式ドキュメントを基準にしています。
対象読者
- SES でドメインの ID を作成し、Easy DKIM で検証した経験がある方
- IAM ポリシーを JSON で読み書きでき、ARN でリソースを指定できる方
- 共通の送信ドメインを複数の AWS アカウント・リージョンで使う構成を設計するインフラエンジニア
本記事で取り扱わないこと
- SES のドメイン認証の手順と、DKIM・SPF・DMARC の基本
- SMTP インターフェースでの送信（本記事は SES API v2 を使います）
- 2つのリージョンへ送信を自動で振り分ける Global endpoints
- AWS Organizations や SCP（サービスコントロールポリシー）による統制
- カスタム MAIL FROM ドメインの設定
まず押さえたい仕組み：SES の ID はアカウント×リージョンごとにある
SES で送信元として検証したドメインやメールアドレス（ID）は、AWS アカウントとリージョンの組み合わせごとに存在するリソースです。米国西部（オレゴン）で検証済みのドメインでも、アジアパシフィック（東京）からはそのまま使えません（Regions and Amazon SES）。
アカウントを縦に、リージョンを横に並べたマス目で考えてみます。同じドメインでもマスが違えば別の ID で、DKIM の署名設定も、送信の許可（後述する送信承認）も ID ごとに持ちます。一方今回の要件では、どのマスから送っても送信元アドレスのドメイン（@ より後ろ。例：mail.example.com）は同じである必要があります。そのため、DKIM 用の CNAME レコードは、マス目の外にあるドメインの DNS（今回は Route 53 のホストゾーン）にまとめて登録します。
リージョンを増やすだけなら、DEED で CNAME の追加を省ける
通常の Easy DKIM の場合
Easy DKIM では、ID を作ると DKIM 用の CNAME レコードが3件発行されます。公式ドキュメントでは、送信に使うリージョンごとに ID を作り、それぞれで発行された CNAME をすべて DNS に追加するよう案内されています。リージョンが3つなら、CNAME は合計9件です。
面倒を減らす DEED の仕組み
この手間を減らすのが DEED です。Easy DKIM で検証済みの ID を「親」に指定して別リージョンに ID（レプリカ）を作ると、親の DKIM の署名設定がレプリカへ複製されます。DKIM のトークンも親と同じになるので、親のために登録した CNAME をレプリカもそのまま使えます。その後に親で行った DKIM 鍵のローテーションや鍵長の変更も、レプリカに自動で反映されます（DEED の公式ドキュメント）。
注意点として、親にできるのは Easy DKIM の ID だけで、自前の鍵を使う BYODKIM（Bring Your Own DKIM）の ID も、DEED で作ったレプリカも親にはできません。また、レプリカを作る操作には、ses:ReplicateEmailIdentityDKIMSigningKey の権限も必要です。
実際にAWSコンソールでレプリカを作ってみる
検証では、アカウントA のオレゴン（us-west-2）に親 ID を置き、東京（ap-northeast-1）にレプリカをコンソールで作りました。
- 東京リージョンの SES コンソールで「ID の作成」を開き、ID タイプに「ドメイン」を選んで、親と同じドメイン名（例：
mail.example.com）を入力する - 「DKIM の詳細設定」を開き、「Deterministic Easy DKIM」を選ぶ
- 「親リージョン」で、親 ID のあるリージョンを選ぶ。今回は「米国西部（オレゴン）」を選んだ
- 「DKIM 署名」が有効になっていることを確かめて、ID を作成する
コンソールでは、このレプリカを「グローバル ID」と呼んでいます。
結果：DNS を触らず検証済みに
作成直後のレプリカは「検証保留中」と表示されましたが、Route 53 には何も追加しないまま「検証済み」「DKIM 有効」に変わりました。ホストゾーンの DKIM 用 CNAME は、親を作ったときの3件のままです。東京から送ったテストメールも、受信側で DKIM=PASS（署名ドメイン d=mail.example.com）でした。
別アカウントから送るなら、送信承認か個別検証を ID の置き場所で選択
アカウントB の認証情報で SES API を呼び出し、ドメインを持たない B から同じドメインでメールを送る方法は2つあります。どちらでも送れますが、ID と DKIM の署名設定をどこに置くかが違います。ID をアカウントA に集めたいなら送信承認、アカウントごとに持ちたいなら個別検証が向いています。以下でそれぞれ紹介します。
方法1：送信承認（ドメインを持つ側が送信を許可する）
アカウントA には、自分の ID に「アカウントB はこのドメインで送ってよい」というポリシーを付けます。アカウントB は、送信時にその ID を ARN で指定します。この仕組みを送信承認（Sending authorization）と呼び、B は自分でドメインを検証しないまま「代理送信者」として送れます（公式ドキュメント）。
ポリシーは、アカウントA の東京リージョンの SES コンソールで ID の詳細を開き、「承認」タブから付けます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccountBToSend",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "ses:SendEmail",
"Resource": "arn:aws:ses:ap-northeast-1:123456789012:identity/mail.example.com",
"Condition": {
"StringEquals": { "ses:FromAddress": "noreply@mail.example.com" }
}
}
]
}
ポリシー設定例
内容としては、Principal は送信を許可する相手（アカウントB）、Resource はアカウントA の東京の ID （前検証にて DEED で作ったレプリカ）です。今回はさらに、Condition で使わせる送信元アドレスを1つに絞っています。アカウントB 側でも、送信を実行する IAM ユーザーやロールに、A の ID の ARN を対象とした ses:SendEmail の権限が必要です（IAM のクロスアカウントの評価）。これにより、ID・DKIM の署名設定・送信の許可（ポリシー）をアカウントA に集約できます。
送信承認での送信を実際にやってみる
方法1 の代理送信では、DEED で作った東京のレプリカを送信元の ID に指定して検証しました。
アカウントB では、オレゴンで開いた CloudShell（標準の AWS CLI v2）から、東京を指定して次のように送りました（値は置き換え、メール本文の指定は簡略化しています）。
# 送信先の SES リージョンは --region で明示する（CloudShell を開いたリージョンが既定になるため）
aws sesv2 send-email \
--region ap-northeast-1 \
--from-email-address "noreply@mail.example.com" \
--from-email-address-identity-arn "arn:aws:ses:ap-northeast-1:123456789012:identity/mail.example.com" \
--destination "ToAddresses=recipient@example.com" \
--content "Simple={Subject={Data=送信テスト,Charset=UTF-8},Body={Text={Data=アカウントBからの代理送信テストです,Charset=UTF-8}}}"
検証メール送信コマンド例
メールは受信側に届き、DKIM=PASS（d=mail.example.com）でした。コマンドが返す MessageId は SES が受け付けた印にすぎないので、到達は受信側で確かめました。この時点で、アカウントB にこのドメインの ID は作成されていません。
方法2：個別検証（送信側でも同じドメインを検証する）
アカウントB の東京リージョンでも同じドメインで ID を作ると、アカウントA とは別のトークンを持つ CNAME が3件発行されました。同じドメインでも、アカウントが違えば DKIM の鍵は別々です。この CNAME を A のホストゾーンに追加すると、B の ID も検証済みになりました。この方法は通常のドメイン登録と同じ流れなので、もちろん B 自身の ID から送ったメールも、受信側で DKIM=PASS でした。
手間になるのは DNS の運用です。ホストゾーンと同じアカウントで ID を作る場合は、コンソールが DKIM 用のレコードを Route 53 に自動で登録できます（公式ドキュメント）。しかし、アカウントB のコンソールからは A のホストゾーンに登録できないため、A 側の担当者に CNAME を追加してもらう調整が発生します。比較的初期コストは高いですが、クロスアカウントでの権限管理などの運用複雑化を抑制できます。
方法1と方法2の比較
| 観点 | 方法1：送信承認 | 方法2：個別検証 |
|---|---|---|
| ID と DKIM の署名設定 | アカウントA だけが持つ。B に対象ドメインの ID は不要 | A と B がそれぞれ持つ |
| DKIM 用の CNAME | A の3件だけ | B 用の3件を A のホストゾーンに追加 |
| 送信の実装 | B は送信のたびに A の ID の ARN を指定する | B は自分の ID で通常どおり送る |
| 依存関係 | A の ID・ポリシーと、B 側の IAM 権限の両方に依存する | A のポリシーには依存しない。DNS の変更は A との調整が残る |
| 本番アクセス（サンドボックス解除） | 未検証の宛先に送るには、A と B の両方が、送信するリージョンで解除済みである必要がある | B が送信するリージョンで解除が必要 |
注意すべき5つのポイント
ここまでの検証で分かった設計・実装時の注意点をまとめます。
①②はリージョン方向（DEED）、③〜⑤はアカウント方向（送信承認）の注意点です。
① 送信承認のポリシーはリージョンごとに設定が必要
DEED が複製するのは DKIM の署名設定です。送信承認のポリシー・カスタム MAIL FROM・通知の設定は複製されないため、使うリージョンごとに設定します（リージョンの説明、ID 複製の説明）。オレゴンと東京の両方から代理送信させるなら、両方の ID にポリシーを付けます。
② 親 ID の削除は全レプリカの削除後にしかできない点
レプリカは親の DKIM の署名設定に依存するため、レプリカをすべて削除するまで親 ID は削除できません（公式ドキュメント）。親を置くリージョンは、最後まで残す前提で選びます。
③ 本番アクセスは、両方のアカウントで申請が必要
検証済みの宛先にしか送れないサンドボックス環境の解除（本番アクセス）は、リージョンごとに申請します。代理送信で未検証の宛先に送るには、アカウントA と B の両方が、送信するリージョンで解除されている必要があります（公式ドキュメント）。
④ 送信枠・料金・バウンスの記録は送信する側に計上される点
送信承認で送ったメールは、アカウントB の送信クォータを消費し、料金も B に請求されます。バウンスや苦情も B のアカウントに記録され、SES 上での B の評価に影響し得ます。一方、DKIM 署名を制御できるのは ID を持つ A だけです（公式ドキュメント）。
⑤ 送信承認の場合、設定セットは送信側で毎回指定が必要
代理送信に使わせる ID には、デフォルトの設定セット（送信イベントの通知先などをまとめた SES の設定）を割り当てられません。バウンスや苦情をイベントとして受け取るなら、アカウントB 側で設定セットを用意し、送信のたびに指定します（公式ドキュメント）。
まとめ
アカウント×リージョンのマス目でいえば、マスをまたいで共有できたものは2つです。DEED で複製した DKIM の署名設定と、送信承認で別アカウントに使わせた ID です。送信承認のポリシー、本番アクセス、通知の設定は、マスごとに用意します。
方法は、まずドメインの ID を誰が持つかを決め、そのアカウントの中でリージョン展開に DEED を使うかを考える順番で選ぶのがおすすめです。ID の持ち主が決まらないと、DEED の親をどこに置くかも決められないためです。
今回私が悩んだのは、送信承認と個別検証のどちらの構成をお客様に提案するかでした。送信承認なら ID と DKIM の署名設定をアカウントA に集約できますが、B の送信は A の ID とポリシーに依存します。今回はアカウントごとにお客様側の管理担当者が異なり、運用時の複雑さも考えて、個別検証を採用しました。DNS の調整は残りますが、各アカウントが自分の ID を持つため、アカウントをまたぐ権限の管理が不要なことを重視しました。
この経験から、設計の段階でアカウント×リージョンの構成表を作っておくことをおすすめします。マスごとに ID の持ち主と管理担当者、DNS の担当、送信承認のポリシー、本番アクセスを書き出しておくと、どちらの方法が運用に合うかを判断する材料になります。そして選んだ方法は検証環境で試し、受信側で DKIM の結果まで確かめてから本番に広げることで安全に複数環境へのメール送信設定の展開を実施できます。
参考文献
- Amazon SES で Deterministic Easy DKIM (DEED) を使用する
- 地域と Amazon SES
- Amazon SESの送信承認の概要
- Amazon SESの送信承認時のID所有者のE メールの送信
- 送信ポリシーの例
- Amazon SES でグローバルエンドポイントを使用する
- 本稼働アクセスのリクエスト (Amazon SES サンドボックスからの移行)
投稿者プロフィール
-
2021年入社。BS事業部所属。
入社当初から一貫してAWSを用いた開発案件に携わっており、現在はサーバレス構成を基本としたプロジェクトに従事しています。
クラウドは進歩の早い技術領域ですので、最新技術のキャッチアップを日々積極的に行っています。
