## この記事でわかること

- Amazon SES の Easy DKIM と BYODKIM、どちらを選ぶべきかの判定基準
- SES のリージョン（us-east-1 / ap-northeast-1 等）ごとに違う SPF include の値
- Sandbox 環境を解除して本番送信に移るときに DMARC 対応で詰まらないための準備

## なぜ SES は「設定したのに届かない」が起きやすいのか

Amazon SES（Simple Email Service）は AWS の汎用メール送信基盤で、トランザクションメール用途で広く使われています。一方、Cloudflare Email Routing や SendGrid のような「全部入り」サービスではないため、**ドメイン認証は利用者側で正しく設計する必要**があります。

具体的には次の 3 点でつまずくケースが多いです。

1. **Easy DKIM を有効化しただけで終わってしまう**（SPF と DMARC が未対応）
2. **リージョンを跨いで送信しているのに SPF include が片方しか入っていない**
3. **Sandbox を解除した直後に大量送信して、Gmail 側で迷惑判定**される

最新の管理画面操作は[Amazon SES 公式ドキュメント](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html)をご確認ください。本記事は UI に依存しない**設計の方針**に絞ります。

![Easy DKIM と BYODKIM の判定フロー](/blog/amazon-ses-email-auth/dkim-decision-flow.svg)

## Easy DKIM と BYODKIM の選び方

SES は DKIM 鍵の管理方式を 2 つ用意しています。

| 方式 | 鍵の生成と保管 | DNS に書く内容 | 推奨ケース |
| --- | --- | --- | --- |
| Easy DKIM | AWS 側で生成・自動ローテート | CNAME 3 本（`<token>._domainkey`） | 通常はこれで十分。鍵管理を AWS に任せられる |
| BYODKIM (Bring Your Own DKIM) | 利用者が秘密鍵を生成し SES に登録 | 公開鍵を TXT で 1 本 | 既存の DKIM 鍵を流用したい / 監査要件で鍵を自社管理したい |

ほとんどの企業は **Easy DKIM** で問題ありません。BYODKIM を選ぶのは、すでに別環境で同じセレクタを運用していて移行できないとか、DKIM の秘密鍵を社内 KMS で管理しなければならない監査要件がある場合に限られます。鍵は 1024bit / 2048bit が選べますが、現代では 2048bit が推奨です（[DKIM 鍵ローテーション](/blog/dkim-key-rotation)も参照）。

## リージョン別 SPF include の落とし穴

SES のメール送信は MTA がリージョン単位で異なるため、**SPF の include もリージョンごとに違います**。代表的な値は次のとおりです。

| リージョン | 推奨 SPF include |
| --- | --- |
| us-east-1（バージニア北部） | `amazonses.com` |
| us-west-2（オレゴン） | `amazonses.com` |
| ap-northeast-1（東京） | `amazonses.com` |
| eu-west-1（アイルランド） | `amazonses.com` |

SES の場合、リージョンを問わず `include:amazonses.com` で全リージョンの送信元 IP がカバーされる設計になっています。**リージョンを跨いで複数 SES アカウントから送る場合でも include は 1 個で済む**のが SES の利点です。ただし、独自の専用 IP プール（Dedicated IP）を借りている場合は専用 IP を直接 SPF に書く運用に切り替える企業もあります。

複数の送信サービスと併用すると、SPF lookup 上限 10 個（RFC 7208）にすぐ達します。詳細は[SPF レコードのフラット化と上限対策](/blog/spf-flattening)をご参照ください。

![リージョン別 SPF include 一覧](/blog/amazon-ses-email-auth/region-spf-table.svg)

## Sandbox 解除と DMARC 必須性

新規 SES アカウントは Sandbox モードで作成され、**検証済みのアドレス宛にしか送れません**。本番運用には「Sending limit increase」リクエストで Sandbox を解除する必要があります。AWS のレビューでは過去の到達率や送信内容も確認されるため、解除申請の前に次を整えておきます。

- **DMARC レコードを `p=none` で公開**しておく（`v=DMARC1; p=none; rua=mailto:...`）
- **rua のレポート受信メールアドレス**を実在のものにする
- 1 日数千通以上送る予定なら、初日からフルスロットルではなくウォームアップ（段階的に送信量を増やす）を計画する

Gmail / Yahoo の送信者要件では 5,000 通/日を超えると DMARC が必須です。SES は到達率が低い専用 IP を引いてしまうリスクもあるため、最初から DMARC レポートで状況を可視化する運用が安全です。DMARC 段階強化の進め方は[DMARC 設定ガイド](/blog/dmarc-setup-guide)を参照してください。

### IAM 権限と SMTP 認証情報

SES の送信は 2 つのインターフェースから行えます。

- **AWS SDK / API**: `ses:SendEmail` の IAM 権限を付与した IAM ロールを使う。Lambda / ECS 等の AWS 内部処理に向く
- **SMTP インターフェース**: `aws ses create-smtp-credentials` で発行した SMTP 認証情報を WordPress プラグイン等で利用する

どちらでも**送信元アドレスが SES で verified**かつ DKIM が DNS で公開済みであることが前提です。SDK 利用時は IAM ロールで権限最小化し、長期 SMTP パスワードを残さない構成が推奨です。

設定後の検証は[DKIM の仕組みと検証手順](/blog/dkim-verification)を参照。`dig` か[無料ドメイン診断](/diagnose)でまとめて確認できます。

### まとめ

- 通常は Easy DKIM。鍵を自社管理する監査要件があれば BYODKIM
- SES の SPF include はリージョン横断で `amazonses.com` 1 個で OK
- Sandbox 解除前に DMARC `p=none` を公開し、rua アドレスを実在にする
- IAM 権限は最小化、SMTP 認証情報の長期保管は避ける
- 5,000 通/日を超える予定なら DMARC 必須要件を見越したウォームアップ
- 最新の管理画面操作は必ず[Amazon SES 公式ドキュメント](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html)で確認

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。