お久しぶりです、たつたつです。気づけば前回の投稿から半年以上も経ってい
お久しぶりです、たつたつです。
気づけば前回の投稿から半年以上も経っていました。いや～、月日が経つのって本当に早いですね。
前回はのんびり旅行ブログを投稿したのですが、今回はちょっとだけ技術者っぽいことを書いてみようと思います。
というのも、最近業務で「Amazon SES」を触る機会がありまして。
せっかくなので、タイトルにもある通り、そのあたりの話をゆる～くまとめてみようかなと！
AWSとは
まずはAmazon SESの話に入る前に、その親玉であるAWS（Amazon Web Services）についてちょっとだけ触れておきます。
AWSは、Amazonが提供しているクラウドプラットフォームで、ざっくり言うと、インターネット経由でサーバやデータベース、ストレージなどを借りられる仕組みです。
このAWSには用途に応じてさまざまなサービスが揃っていて、SESもそのひとつ。
他にもいろんなサービスがあり、他のサービスについては一緒に苦労した仲間たちが、そのうちブログを書いてくれる……はず！
Amazon SESとは
さて、今回業務で触れたのが、Amazon SES（Simple Email Service）。
これはAWSが提供しているメール送信サービスで、主にアプリなどから自動でメールを送るときに使われます。
今回はこのSESを使用して、アプリからメールを送信するための設計を業務で行ったので、その体験を紹介していきます。
1. 設定セットの設計
まずは、「設定セット」の設計から。
この設定セットとは、SESでメールを送るときに「どう送るか？」を決めるルール集のようなもので、後述する「ID」に適用できます。
画面だとこんな感じ
設定セットを設定する画面の一部
今回設定した内容はこちら
・TLSプロトコルを使用して、メール送信中の盗み見を防止する設定
・メール送信の試行時間を5分以内に設定
他にもいろんな設定ができますが、今回はこのあたりだけ。
その他設定について気になる方は「Amazon SES 設定セット」で調べてみてください！
2. IDの設計
次に「ID」の設計です。
SESでは、メール送信（主に送信元）に使用するドメインやメールアドレスを「ID」として設定します。
このIDに対して、「認証してね〜」「通知してね〜」といった設定を行います。
画面だとこんな感じ
IDを設定する画面の一部
今回の設定内容はこちら
・ドメインをIDとして設定
・カスタム MAIL FROM ドメイン(サブドメイン)の設定
・設定セットの紐づけ
・DKIM認証のEasy DKIMを設定
※DKIM認証とは？については後程！
・フィードバック通知(バウンスや苦情が発生した場合に、AWSのSNSを用いて通知する)設定
※バウンス：送信したメールが何らかの理由で受信者に届かず差し戻されること
※苦情：送信したメールが受信者により迷惑メールとして報告されること
3. サンドボックス環境の解除
ここまでで、IDの設定や認証、通知の設定はバッチリ…
と思いきや、まだメールは自由に送れません。
というのも、SESは初期状態だと「サンドボックス環境」という制限付きモードで動作します。
この状態では、以下のような制限があります。
・送信先はIDが検証済みのメールアドレスまたはドメインのみ
・送信数に制限あり
など…
画面だとこんな感じ
サンドボックス環境の場合の画面
つまり、「ちょっとだけ試してみてね」というお試しモードです。
そのため、本番運用を想定している場合は、この環境では運用が難しいため、「本稼働アクセスのリクエスト」を行う必要があります。
申請フォームに「こういう用途で使います！」などを記入して、AWS側の審査を待つ流れです。
今回はまだ申請はしていませんが、申請する前提で設計を進めています。
4. ドメインの認証
さて、メール送信の準備が整ってきたところで、送信元ドメインの信頼性を高めるための認証準備に進みます。
SESでは、IDとして登録したドメインを使ってメールを送る際に、DKIM認証 / SPF認証 / DMARC認証の3つを行うことで、メールの信頼性が向上します。
これらの認証を行うには、SESから発行されるDNSレコードを、ドメインを管理しているDNSへ登録する必要があります。
しかし、今回使用するドメインは管理者がお客様だったため、私たちはDNSへの登録ができません。
そのため、以下のような内容を含めた説明資料を作成して、登録依頼を行う予定です。
・なぜこのレコードが必要なのか
・登録するレコードの概要
・登録スケジュール
ちなみに、ドメインの認証の仕組みについては少しハマったので、次で簡単に説明します…。
※メールアドレスをIDとして設定した場合は、そのメールアドレスへ認証メールが送信され、そのメールから承認することで認証が完了します。
はまりポイントその1：認証まわりで混乱した話
SESの設計を進める中で、いちばん時間を使ったのが認証まわりでした。
ここでは、各認証の仕組みについて簡単に説明します。
DKIM認証
まず、DKIM（Domain Keys Identified Mail）認証は、公開鍵と秘密鍵（電子署名）を用いてメールの正当性を確認する仕組みです。
いわゆる、改ざん防止を目的とした仕組みですね。
SESでは「Easy DKIM」という便利な機能があり、これを使うとSES側でメールに電子署名を自動的に付けてくれます。
※「Easy DKIM」以外にも2種類のDKIM設定機能があるので、気になる方は「Amazon SES DKIM認証」で調べてみてください！
ただし、電子署名が本物かどうかを証明するには、SESから発行されるCNAMEレコードを登録する必要があります。
※CNAMEレコード：「この名前は、別の名前のことですよ〜」と教えてくれる役割
仕組みはこんな感じ
DKIM認証の例
①IDとして設定したドメインを管理しているDNSに、CNAMEレコードを登録
②SESがメール送信時に秘密鍵と公開鍵を生成し、秘密鍵は電子署名としてメールに添付、公開鍵はAmazonが管理するDNSに登録
③受信側のサーバが①で登録したCNAMEレコードを参照して、Amazonが管理するDNSから公開鍵を確認
④電子署名と公開鍵がペアになっていれば「改ざんされてない！」と認証成功
ちなみにこのCNAMEレコードはID設定時に一意の値が付与され、CNAMEレコードがDNSに登録されることでIDが「検証済み」になります。
SPF認証
次にSPF（Sender Policy Framework）認証は、「このドメインからメールを送っていいのはこのサーバですよ！」と宣言する仕組みです。
いわゆる、なりすましや迷惑メール防止を目的とした仕組みですね。
IDとして設定したドメインを管理しているDNSに、SESの送信サーバを許可すると定義したTXTレコードを事前に追加することで、
SESから送信されたメールが正当なものとして認証されます。
この許可はSESのリージョン単位で行われます。
※リージョン：AWSの物理的な拠点（東京リージョン、大阪リージョンなど）
SPF認証の例
ここでちょっとした疑問が出てきますよね？
「例えばIDとしてunalus.comを設定して、SESの東京リージョンの送信サーバを許可するTXTレコードをunalus.comを管理しているDNSに登録した場合、第三者が東京リージョンでunalus.comをIDとして設定したら、unalus.comを送信元としてメール送信(なりすまし)できちゃうのでは？」と。
実はそれ、理論上は正しいです。
でも、SESでは「IDが検証済みでないとメール送信できない」という仕組みがあるので、
DNSにCNAMEレコードを登録できる人（=ドメインの所有者）でないと、そもそも送信で着ないようになっているんですね。安心！
※既に他のメール送信が許可されているTXTレコードが存在する場合は、SESの送信サーバの許可を追加する形でレコードを更新が必要です。
※サブドメインを設定していない場合は、デフォルトでAmazon側で管理しているドメインが使用されるため、ユーザ側でレコードの登録は不要です。
DMARC認証
最後にDMARC（Domain-based Message Authentication, Reporting & Conformance）認証は、DKIM認証やSPF認証に失敗した場合に、
受信側のサーバがどう対応すべきかを定義する仕組みです。
「認証に失敗したら破棄してね」や「迷惑メールとして扱ってね」といったポリシーを設定できます。
この設定はTXTレコードに定義して事前にDNSへ登録します。
DMARC認証の例
はまりポイントその2：苦情通知の落とし穴
認証まわりがひと段落…と思いきや、落とし穴がありました。
それは、フィードバック通知で苦情が発生した場合の通知の仕組みについてです。
SES側の設定はシンプルで、SNSトピックというリソースと紐づけるだけで、苦情が発生したときに通知が飛ぶようになります。
「これで安心！」と思っていたのですが、実は裏側の仕組みに注意が必要でした。
というのも、受信者が「迷惑メールです！」と報告した場合、
その情報がSESに届くには、IDとして設定したドメインを管理しているDNSが契約しているプロバイダが、「FBL（フィードバックループ）」に対応している必要があります。
※FBL：受信者が「迷惑メールです！」と報告したときに、その情報を送信者側に通知する仕組み
FBLに対応していないと、SESに「苦情が来たよ〜」という通知が届かないんです。
最初はこの仕組みを知らず、「SESで設定したし通知来るでしょ！」と思っていたので、危なかったです。
このブログを読んでくださった方は、苦情通知はFBL対応のDNSが前提であることを覚えておくと、通知が来ないときに「あ、FBL未対応かも！」と気づけるかもしれませんね！
ちなみに、FBLは日本ではまだあまり普及しておらず、大手プロバイダのみ対応しているとのことです。
まとめ
というわけで、今回はAmazon SESの設計を実際にやってみたことなどを、ゆる〜くまとめてみました。
特に認証まわりは、仕組みを理解していないと後々痛い目を見る可能性もあるので、がんばって調べて理解しました。
また、苦情通知のように、深くまで仕組みを知らないと見落としがちなポイントもあり、
「設定できた＝安心」ではないことも学びになりました。
今回は実体験をもとに機能の説明をしているため、ここに登場していない機能もまだまだあります。
今後の業務では、SESの機能を実際にテストして、アプリからメール送信ができるかを確認していく予定です。
うまく動作するといいなぁ〜（フラグじゃないことを祈る）
ここまで読んでいただき、ありがとうございました！
あ、そうそう。アイキャッチ画像のかき氷、内容とはまったく関係ありません。
最近行ってきたアンカードレっていうかき氷屋さんの桃ぜんかいが美味しすぎて、つい載せてしまいました笑
ちなみにこのお店、めっちゃ並びます。8月に行ったときは最低3時間待ちでした……。
真夏は予約必須です！（お金はかかりますが😖）
ぜひ来年、行ってみてはいかがでしょうか(*^-^*)