Amazon SES カスタム MAIL FROM 設定のポイントと DNS トラブルシューティング徹底解説

はじめに

メール配信の認証強化やブランドイメージ向上のために、Amazon SES (Simple Email Service) で独自ドメインを使ったカスタム MAIL FROM 設定を行うケースが増えています。ところが、いざDNSやサブドメインを設定しようとすると「MXはCNAMEと共存できない」「Aレコードが必要」など、思わぬトラブルに見舞われることも少なくありません。

本記事では、実際に さくらのレンタルサーバー や Route 53 以外のDNSサービス でカスタム MAIL FROM を設定する際に起きやすい問題と、その解決プロセスをまとめてご紹介します。複数のサブドメイン（mail.example.jp など）を運用している場合の混乱や、DNSの反映が遅れて「Pending」から抜け出せないときのポイントについても、具体例を交えて解説していきます。

1. カスタム MAIL FROM とは？

Amazon SES から送信されるメールの**エンベロープ送信元（MAIL FROMアドレス）**を独自ドメインに設定できる機能が「カスタム MAIL FROM」です。これを設定すると、受信者のメールヘッダ上で「Return-Path:」が自社ドメインとなり、バウンス処理などをAmazon SESが代行しつつ、ブランドイメージを高めることができます。

メリット
- ドメインのブランド強化
- バウンス通知メールのReturn-Pathが独自ドメインになる
- SPFなど送信認証の一貫性向上
必要なもの
- カスタム MAIL FROM 用のサブドメイン（例：mail.example.com）
- そのサブドメインに対して Amazon SES指定のMXレコード を設定
- SPF (TXTレコード) に include:amazonses.com を含む
- Amazon SES コンソールからドメイン検証

2. サブドメインを分ける理由

受信用・送信用（カスタム MAIL FROM用）を同じサブドメインで混在させると、MXやSPFの設定が衝突し、トラブルの原因になります。

例：
- 受信用：mail.example.jp → Google Workspace / 自社メールサーバー
- 送信用 (カスタム MAIL FROM)：ses.example.jp → feedback-smtp.us-west-2.amazonses.com

こうすることで、配送先の衝突を防ぎつつ、DNS設定もシンプルになります。

3. よくあるトラブルと対処法

(1) 「CNAMEと他のレコードは共存できません」

原因：同じホスト名にCNAMEを設定しつつ、TXTやMXなど他のレコードを追加しようとするとエラーになる。DNSの仕様で「CNAMEは単独で存在し、他のレコードと共存できない」と決められています。
対策：カスタム MAIL FROM 用にMXやTXTが必要なら、CNAMEを削除するか、別のサブドメインを使う。

(2) 「MX先はAレコードしかダメ」と言われる

原因：さくらのレンタルサーバーなど一部のDNSサービスでは、MXの先にCNAMEを指定できないとチェックする仕組みがある。Amazon SES側のfeedback-smtp.us-west-2.amazonses.comがCNAME扱いになっている場合、エラーになることがある。
対策：
- Route 53 や他のCNAMEが許容されるDNSサービスに切り替える
- 末尾に.を付けて完全修飾ドメイン名を記述してみる（解決する場合あり）
- カスタム MAIL FROM を断念し、デフォルトのamazonses.com経由に戻す

(3) 「同じサブドメインに複数のMXがあるが、意図と違うメールサーバーに届く」

原因：優先度 (Priority) が同じ複数のMXを登録してしまうと、配送がランダムに行われる恐れがある。受信用とSES用が同居すると混乱が大きい。
対策：
- カスタム MAIL FROM 専用サブドメインを用意し、既存の受信用MXと完全に切り分ける
- 冗長化のために同一サービスのMXを複数登録するのはOKだが、異なるサービスを同列に混在するのはNG

4. DNSの反映が「Pending」のまま進まない

(1) 正しいDNSレコードが設定されているか

Amazon SESのコンソールで示される feedback-smtp.◯◯.amazonses.com をミスなく登録。
さくらDNSの場合、サブドメイン欄に「@」やフルドメインを誤って入力していないか再確認。
- 例：サブドメインに「mail」とだけ入力すればmail.example.jpになるところを、うっかり「mail.example.jp」と書いて重複エントリになっていないか。

(2) SPF (TXT) が合っていない

v=spf1 include:amazonses.com ~all を書いているか？
他の送信サービスと併用するなら、include:_spf.google.com などを併記し、最終的に ~all や -all で閉じる。

(3) DNSのキャッシュや伝搬

通常は数分～数時間で反映されるが、最大72時間かかる場合もある。
権威DNSサーバーに直接問い合わせ(dig mail.example.jp MX @ns1.dns.ne.jp)することで、本当に設定が反映されているかチェック可能。

(4) SESコンソールでカスタム MAIL FROM を有効化しているか

ドメイン検証 (Domain Verification) とは別に「MAIL FROM の設定」を行い、正しく保存されているか確認。

5. 設定手順のまとめ

サブドメインを分ける
- 受信用: mail.example.jp
- SES(送信用): ses.example.jp (例)
SESコンソールでカスタム MAIL FROM を設定
- Identity(ドメイン) → 「Edit MAIL FROM」 → サブドメイン指定
- 表示されるMX・SPF情報をコピー
DNSでMX/TXTを登録
- ses.example.jp. IN MX 10 feedback-smtp.us-west-2.amazonses.com.
- ses.example.jp. IN TXT "v=spf1 include:amazonses.com ~all"
ステータスが「Verified」になるのを待つ
- Pendingのままなら設定ミスを疑う → ログや権威DNSへの問い合わせで再確認

6. 実際のトラブルシュート事例

事例1: SakuraのDNSで「subdomainにmail.example.jpを作ったつもりが、実は@(Apex)を上書きしていた」
- → nslookupするとmail.example.jpが返らずexample.jpの設定が出る
- → 正しくホスト欄に「mail」と入力して再保存することで解決。
事例2: SESコンソールで「mail.example.co.jp」はVerifiedと表示されないのに、DNSを確認するとfeedback-smtp...は設定済み
- → 実はCNAMEが残っていた / 受信用MXが同居していた / SPFが誤っていたなど原因はいろいろ
- → 不要レコードを削除し、SPFやTXTを修正後、数時間で Verified。
事例3: 「mailサブドメインにスクリプトやログがあるが、実際には運用していない」
- → 過去の残骸かもしれない。ログの最終更新日やCRONジョブをチェックし、不要なら削除しても問題なし。

おわりに

Amazon SES のカスタム MAIL FROM は、送信ドメイン認証やブランドイメージ向上にとても便利ですが、DNSの微妙な制限（CNAME共存不可、MXのCNAME不可など）にハマりがちです。
「サブドメインを分けて、MXを正しく設定する」 これが最大のポイントと言えるでしょう。もし設定に行き詰まったら、まずは 権威DNSサーバーへの問い合わせ や SESコンソールでのステータス を確認し、ほんの小さなスペルミスなどがないか洗い出してみてください。

本記事のトラブルシュート事例と対策が、皆様のDNS設定やSES運用の一助となれば幸いです。