こんにちは。
システム開発をしていると、動的にメール送信をすることがあると思います。
エラー発生時にシステム関係者に通知、問合せフォーム送信時に自動返信、etc…
システムごとに構築することが多いと思いますが、とあるプロジェクトにて汎用的に使えるAPIとして構築したい場面がありました。
マイクロサービスとして提供することで、少ない影響範囲で検証・デプロイできるメリットがあります。
今回はメール送信するまでの検証を行っていきます。
1. 前提
本記事はAWSのRoute53にて独自ドメインを取得している前提で進めます。
最終的にはAWS外で取得したドメインにも対応させることが必須となりますが、Route53の設定だけな気がしているので、一旦はAWSだけで完結する形で構築していきます。
2. IDの作成
メール送信するうえで、SESを使います。正式名称は「Simple Email Service」で、名前の通りメール送信といえばこれ!って感じです。
AWSマネジメントコンソールでSESの設定をしてきます。
まず、「ID」を作成します。

3. IDの詳細設定
- タイプ:ドメイン
- ドメイン:Route53で取得したドメイン
- カスタム MAIL FROM ドメインの使用:チェック
- これをチェックしないと、DMARCとクリアできない
- MAIL FROMドメイン:no-reply
- よく自動返信メールのfromは「no-reply@~~」ってなってますね。
- MX 障害時の動作:デフォルトの MAIL FROM ドメインを使用
- DNS レコードの Route53 への発行:有効化

4. ドメインの検証
こちらはセキュリティ系ですね。SPFだけでなくDKIMのクリアもしておかないとスパムになる可能性が高そうなので、しっかりやっておきます。
- DKIMの設定:Easy DKIM
- DKIM署名キーの長さ:RSA_2048_BIT
- DNSレコードのRoute53への移行:有効化
- DKIM署名:有効化

5. 作成後の確認
IDを作成したら、ステータスとRoute53にレコードがあるか確認します。
作成直後は「検証保留中」となってますが、、、

少し待つと「検証済み」になります🙌(初めてだったので内心ホッとしましたw)

Route53では、DKIMでCNAMEレコードが3つ、DNSでMXレコードが1つ、TXTレコードが1つできるようです。


マスクするのが大変なので、Route53のキャプチャは割愛します😅
同じレコードがあることを一応確認しておいてください。
6. DMARCの対応
なりすまし対策強化のDMARCも対応します。
DKIMまで対応していれば十分な気もしますが、DMARCまで対応しておけばひとまず安心といってもいいのではないのでしょうか?(あまり詳しくないので、間違っていたらごめんなさい)
自分が新卒入社した会社のシステムでSPFしか対応しておらず、Gmailには送れなくなるという事態が起きたことがあります。
作った当初はSPFだけでよかったみたいですが、時代は変わっていくものですね!
やることは、DMARCの右上のRoute53への発行ボタンを押すだけです。ほんとクラウドってすごい!!

Route53でもできていることを確認できました。

7. テスト送信
設定が完了したのでテスト送信をしてみようと思いましたが、マネコンからはToの指定ができないようなので、CCで動作確認してみます。
- Eメール形式:フォーマット済み
- From-address:no-reply
- シナリオ:配信の成功
- 今回はとりあえずこれにしたけど、機能によって使い分けた方がいいのかなぁ??
- 件名、本文:適当に入れましょう
- 設定セット:my-first-configure-set
- これ以外の選択肢がなかった。別で設定したら増えるだろうが、今回はそのまま使用
- Reply-to:fromとは違う任意のメアド
- Return-path:fromとは違う任意のメアド
- Cc、Bcc:受信できる任意のメアド


いざ、送信!!

Opps!!
自分のメアド(今回とは別のドメイン)に送信しようとしたのですが、ダメみたいでしたw
じゃあCLIから・・
aws ses send-email \
--from "no-reply@(今回設定したドメイン)" \
--destination "ToAddresses=(自分のメアド)" \
--message "Subject={Data=テスト送信},Body={Text={Data=無事に届いたかな??}}" \
--region "ap-northeast-1" \
--profile isub
お!きたー!!🎉🎉🎉

dkim=pass, spf=pass, dmarc=pass だった。完璧やね⭐
8. サンドボックスモードから本稼働モードへ移行
SESは最初はサンドボックスモードの状態で、実際のサービスで使うには本稼働モードに移行する必要があるようです。
今回使用したAWSアカウントは既に本稼働モードに移行されていたので今回は割愛しますが、公式ドキュメントに沿って申請すればよさそうです。
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/request-production-access.html
9. まとめ
今回はAWS SESでIDの作成とテストメール送信までやってみました。
メール周りは難しいイメージでしたが、やってみるとそんなに沼らずに進められました!
次回はこの仕組みをAPI Gateway + Lambdaと連携してAPIにしちゃいます。
10. 参考
https://zenn.dev/carenet/articles/6c2ffbc773276b
投稿者プロフィール

-
学んだことをアウトプットしていきます!
好きなこと:音楽鑑賞🎵 / ドライブ🚗 / サウナ🧖