ここでは、ドメイン会社を使い、Amazon SES 側に送信ドメインを登録し、DNS レコードを確認するところまでをまとめます。
この作業を行うことで、独自ドメインからのメール送信に必要な認証(SPF・DKIM)の準備ができます。
認証(SPF・DKIM)とは
SPF
ざっくり言うと、SPF(Sender Policy Framework)は「このドメインからメールを送っていいサーバーの一覧表」です。
この一覧表は、ドメインの DNS に TXT レコードとして登録します。
人間の世界でたとえると
- ドメイン:会社名(例:example.com)
- メールサーバー:各営業所
- SPF レコード:
「この名刺(ドメイン名)を使って営業していいのは A支店とB支店だけです」と書かれた社内ルール
受信側のメールサーバーは、この「社内ルール(SPF)」を見て、
- 本当にこのサーバーは example.com を名乗ってメールを送っていい人なのか?
- それとも勝手に example.com のフリをしているだけなのか?
をチェックします。
どう動いているのか(ざっくりステップ)
- 送信者:user@example.com からメールを送る
- 受信側サーバーは、example.com の DNS から SPF レコード(TXT レコード)を読み取る
- 例:v=spf1 include:amazonses.com ~all
- メールを送ってきたサーバーの IP アドレスや、送信サービス(Amazon SES など)が
SPF レコードのルールに含まれているかチェックする - ルールに合っていれば「SPF 認証成功」、合っていなければ「失敗」と判断される
SPF でできること・できないこと
できること
- なりすましメールのうち、
「全く関係ないサーバーから@example.comを名乗って送ってきているメール」を見つけて弾きやすくなる - 「このドメインはちゃんと送信元サーバーを管理している」と受信側にアピールできる
できないこと
- メールの本文や件名が途中で書き換えられていないか、までは分からない
- 転送(フォワード)されると SPF が失敗するケースがある
(一度別のサーバーを経由してしまうため)
なので、**SPF は「送信元サーバーのチェック担当」**くらいの役割だと思っておくと分かりやすいです。Amazon SES では、ドメインの DNS に
- include:amazonses.com
~all(もしくは-all)
といった TXT レコードを追加することで、「このドメインから Amazon SES が送信してもOKですよ」という宣言をしています。
DKIM
DKIM(DomainKeys Identified Mail)は、メールに電子的な「ハンコ(署名)」を付ける仕組みです。
受信側はそのハンコを確認することで、
- 本当にそのドメインが署名したメールなのか
- 途中で本文や件名が書き換えられていないか
をチェックできます。
人間の世界でたとえると
- メール本文:契約書
- DKIM 署名:会社の実印+印鑑証明書
- DNS に登録する公開鍵:印鑑証明書を誰でも確認できる場所に貼り出しているイメージ
誰かが契約書(メール)を書き換えたり、他人が勝手に会社名を名乗ってハンコを使おうとしても、
受信側は「印鑑証明書(公開鍵)」を見て、おかしいものは見抜けるようになっています。
どう動いているのか(ざっくりステップ)
- 送信前に、送信側(Amazon SES)が
- 件名
- 本文の一部
- 送信元アドレスなどのヘッダー情報
をまとめて「電子署名」を付ける
- この署名を検証するための「公開鍵」を、ドメインの DNS に DKIM 用 CNAME / TXT レコードとして公開する
- 受信側サーバーは、DNS から公開鍵を取得し、メールに付いた署名を検証する
- 署名が正しければ
- 「このメールは確かにこのドメインから送られた」
- 「途中で中身が書き換えられていない」
と判断できる
DKIM で何がうれしいのか
- メール本文や件名が途中で改ざんされていないことを確認できる
- 単なる SPF よりも「信頼できるメール」として扱われやすくなる
- DMARC というルールと組み合わせることで、なりすましメール対策をさらに強化できる
Amazon SES の Easy DKIM では、
- SES が秘密鍵を管理して署名を自動で付けてくれる
- ドメイン側は、SES が提示する 3つの CNAME レコード(xxxxx._domainkey)を DNS に登録するだけ
という形なので、「DKIM 用のハンコを置く場所(DNS)」だけ正しく用意してあげればOKです。
SPF と DKIMのざっくり比較イメージ
- SPF:
「このドメインを名乗っていいサーバーはどこか?」をチェックする仕組み
→ 送信元サーバーの本人確認 - DKIM:
「このメールは本当にこのドメインが署名したものか?途中で書き換えられていないか?」をチェックする仕組み
→ メールの中身と署名のチェック
どちらか片方だけでもある程度の効果はありますが、
SPF と DKIM の両方をきちんと設定しておくと、メールの到達率・信頼性がぐっと上がる、というイメージで書いておくと、社長クラスにも説明しやすくなります。
送信ドメインを登録する
SES コンソールを開く
- AWS マネジメントコンソールにログインします。
- 画面上部の検索バーに 「SES」 または 「Simple Email Service」 と入力し、表示された Amazon SES をクリックします。
- 右上のリージョンが、メールを送信したいリージョン(例:東京リージョン)になっていることを確認します。

カスタム MAIL FROM ドメイン、SPFの設定
ID に送信ドメインを追加する
- 左メニューの 「設定」セクション内にある[ID] をクリックします。
- 右上の [ID を作成] ボタンをクリックします。
- 「ID の種類」は 「ドメイン」 を選択します。
- 「ドメイン」 の入力欄に、メールの From に使いたい 送信ドメイン(あなたの独自ドメイン名)を入力します。
- ここでは @ より前の部分(info や no-reply など)はまだ決めなくて構いません。
- ドメイン単位で登録しておけば、そのドメイン配下の任意のアドレスをあとから使えます。
ドメインを入力すると、次の3つのオプションが表示されます。
- 「デフォルト設定セットの割り当て」
配信ルールを細かく分けたい場合に利用するオプション。
基本的なドメイン登録だけを行う場合は、チェック不要。 - 「テナントに割り当てる」
マルチテナント構成向けの機能で、1つの SES アカウントから複数テナントにメールを送るケースで使用する。
通常のシングルドメイン運用では、チェック不要。 - 「カスタム MAIL FROM ドメインの使用」
SPF/DMARC を整えて迷惑メール判定を避けたい場合に利用する項目。
独自ドメインで正しく認証を行う構成とするため、この項目のみチェックを入れて設定を続行する。

DKIM(ドメイン認証)の設定
DKIM(Easy DKIM)を有効にする
- 同じ画面の下部にある DKIM 設定(DomainKeys Identified Mail) のセクションを開きます。
- Easy DKIM が選択されていることを確認します。
- キー長は特に理由がなければ、デフォルトの RSA 2048-bit のままで問題ありません。
Easy DKIM を有効にすると、後で CNAME レコードが複数個 自動生成されます。
これをドメイン会社のDNSに登録することで、送信メールに DKIM 署名が付き、なりすまし対策・迷惑メール対策として有効になります。

DNS レコードの Route53 への発行
「DNS レコードの Route53 への発行」については、
メール送信に利用するドメインを AWS の Route 53 で管理している場合のみチェックを入れます。
それ以外の DNS サービスでドメインを管理している場合は、チェックを外してください。
DNSレコードを確認する
画面下部の 「IDの作成」 をクリックして送信ドメインの ID を作成します。
DKIM 用 CNAME レコードを確認する
「DomainKeys Identified Mail (DKIM)」の [DNS レコードの発行] には、DKIM 署名用の CNAME レコードが複数表示される。
- タイプ:すべて CNAME
- 名前:xxxx._domainkey.送信ドメイン のような長いホスト名
- 値:xxxx.dkim.amazonses.com 形式のホスト名
これらのレコードを、そのまま DNS(ドメイン会社のコントロールパネルなど)に登録すると、
送信メールに DKIM 署名が付き、受信側で「改ざんされていない正当なメール」として認証される。

カスタム MAIL FROM ドメイン用 MX / TXT レコードを確認する
「カスタム MAIL FROM ドメイン」の [DNS レコードの発行] では、
MAIL FROM 用サブドメインに設定する MX / TXT レコードが表示される。
- MX レコード
- タイプ:MX
- 名前:spf.送信ドメイン
- 値:10 feedback-smtp.ap-northeast-1.amazonses.com
- TXT レコード(SPF 用)
- タイプ:
TXT - 名前:spf.送信ドメイン
- 値:”v=spf1 include:amazonses.com ~all”
- タイプ:
この 2 つを DNS に登録することで、
MAIL FROM ドメインが SES のサーバーを正しく指し示し、SPF 認証も通るようになる。

DMARC 用 TXT レコードを確認する
「Domain-based Message Authentication, Reporting, and Conformance (DMARC)」の
[DNS レコードの発行] では、DMARC 用の TXT レコードが 1 件提示される。
- タイプ:
TXT - 名前:_dmarc.送信ドメイン
- 値:”v=DMARC1; p=none;”

このレコードを DNS に登録すると、
SPF / DKIM の結果をもとに、受信サーバーがどのようにメールを扱うかを指示できる。
初期値の p=none は「隔離・破棄は行わず、レポートのみを行う」という監視モードの設定になっている。
この画面に表示されている「名前(Name)」と「値(Value)」を、ドメイン会社の DNS 画面でそのまま登録していくのが次のステップです。
ドメイン設定時の注意点
カスタム MAIL FROM ドメインや DKIM(ドメイン認証)のレコードを DNS に登録するときは、DNS サービスごとの「名前(ホスト名)の扱い方」によって、値が変形してしまうことがあります。ここを間違えると、AWS 側ではいつまで経っても「検証保留中」のままになってしまいます。
「amazonses.com」のあとに自分のドメインが付いてしまうケース
whatsmydns などで確認したときに、
- 期待している値
xxxx.dkim.amazonses.com - 実際に登録されている値
xxxx.dkim.amazonses.com.example.com
のように、amazonses.com のあとに自分のドメイン(example.com)がくっついて見える場合があります。
これは、多くの DNS では「ピリオド(.)で終わらない名前は、自ドメイン配下として扱う」というルールがあるためです。
- 入力した値:xxxx.dkim.amazonses.com
- DNS の解釈:xxxx.dkim.amazonses.com.example.com
この状態だと、AWS SES が探しているホスト名と一致しないため、DKIM やカスタム MAIL FROM の検証が失敗し、ステータスが保留中のまま変わりません。
末尾にピリオド「.」を付ける意味
DNS 上での完全修飾ドメイン名(FQDN)は、本来
- xxxx.dkim.amazonses.com.
のように、末尾にピリオドが付いた形が正式な書き方です。
このピリオドには「ここでドメイン名が終わり」という意味があり、DNS サーバーはそれ以上ドメインを付け足しません。
そのため、DNS パネルで CNAME や MX の「値(Value)」を入力するときに
- xxxx.dkim.amazonses.com.
- feedback-smtp.ap-northeast-1.amazonses.com.
のように 最後にピリオドを付けておくと、自分のドメイン名が勝手に追加される事故を防げます。
こんな表示になったら要注意
- ドメイン会社の管理画面では問題なく見える
- しかし whatsmydns などで見ると
…amazonses.com.自分のドメインになっている - SES のステータスが 24〜48 時間以上たっても「保留中」のまま
このような場合は、CNAME / MX レコードの「値」が相対パス扱いになっている可能性が高いので、
- DNS パネルで該当レコードを編集
- 値の末尾にピリオド「.」を付ける
- 保存したあと、再度 whatsmydns で値を確認する
という手順で修正します。
が終わらないことがあるので、レコード登録時はいちどしっかりチェックしておきましょう。
最後に
ここまでの内容を一言でいうと、「メールをきちんと名乗って送れるようにするための下準備」です。
DNS の設定や DKIM・カスタム MAIL FROM という言葉は難しく聞こえますが、実際にやっていることは、
- どのドメインから送るメールなのか
- そのメールは本物かどうか
を受信側に伝える名刺づくりのような作業です。
この名刺づくりが終わると、AWS の画面で「保留中」だった表示が「成功」に変わります。ここまでできていれば、あとは通常どおり業務メールを送っても、迷惑メールに入るリスクをぐっと下げられます。
今はテスト段階で、1 日に送れる通数が少ない「サンドボックス」という制限もかかっています。将来、ステップメールやキャンペーンなどで「もっとたくさん送りたい」となったら、次のステップとしてこのサンドボックス解除を申請することも検討するとよいでしょう。そのときに大事なのは、
- どんな内容のメールを
- 誰に
- どのくらいの頻度で送るつもりなのか
をざっくり決めておくことです。そこまで決まっていれば、技術担当者は具体的な設定や申請文を整えていけます。
DNS や英語のエラーをすべて理解する必要はありません。このセクションで書いたように、**「ドメイン名が二重になっていないか」「必要なら末尾にピリオドを付ける」**というポイントだけ頭の片すみに置いておけば、何かトラブルが起きたときも、「まずここを疑えばいい」と判断できるようになります。

