Webアプリのログイン認証メールにAmazon SESを導入する方法

Amazon SES は、正式には Amazon Simple Email Service というサービスで、自社のメールアドレスやドメインを使ってメールを送受信できる AWS のメール基盤 です。

このようないわゆる、トランザクションメールにもマーケティングメールにも使えるほか、受信したメールを元に自動返信、配信停止処理、サポートチケット生成などを行う用途にも使えます。

当社では、DjangoでWebアプリ開発を複数行っていますが、その際のログイン認証メールやリマインドメールの送信に使っています。メールスタンドサービスは他にもいくつかありますが、どれも月額3,000円程度かかりますし、管理画面が英語でどうせ分かりづらいのであれば、Amazon SESを使ったほうが圧倒的に安いので、Amazon SESを扱えるようになっていたほうが良いだろう、という判断です。

この記事では、AWSアカウントの作成から、DjangoでAmazon SESを使ってサインアップメールやリマインドメールを送れる状態にするまでを、順番に説明します。

Amazon SESを使う大きなメリット

SES の大きな利点は、メール送信基盤を自前で持たなくてよいことです。AWS 公式でも、大規模なメールソリューションを自前で構築するのはサーバ管理、ネットワーク設定、IP レピュテーションなどの面で複雑かつ高コストになりがちで、SES はそれを簡素化すると説明しています。

もう1つは、AWS の他サービスと組み合わせやすいことです。たとえば SES で発生した bounce や complaint を SNS で通知したり、アプリ側の監視や運用フローに接続しやすいです。送信後の状態監視まで含めて設計できるのが、単なるSMTPサーバより強い点です。

さらに、SMTP と API の両方が使えるのも実務では便利です。既存アプリには SMTP でつなぎ、新しい機能や高機能制御には API を使う、といった段階的な運用ができます。

まず全体像

最初に AWS アカウントを作成し、その後 Amazon SES を使うリージョンを決めます。次に、送信元メールアドレスまたは送信元ドメインを SES で検証し、必要なら sandbox を解除し、最後に SMTP 認証情報を作成します。SMTP 認証情報は AWS の通常ログイン情報とは別物で、しかもリージョンごとに別です。

AWSアカウントを作る

AWS のサインアップ画面を開き、まず root user 用のメールアドレスと AWS アカウント名を入力します。確認コードが届くので、それを入力して検証します。そのあと root user のパスワードを設定し、利用規約に同意し、支払い方法を登録し、最後に電話認証を行います。AWS では、有効な支払い方法の登録が完了しないとサインアップを進められません。

ビジネス用途なら、root user 用メールアドレスは個人の私用アドレスより、会社で管理できる安全な共有アドレスや配布リストを使うのが推奨です。AWS は、そのメールアドレスが root 認証情報のリセットにも使われるため、アクセス管理を厳重にするよう案内しています。

AWS アカウント作成直後は、最初のサインイン主体として root user が作られます。root user はアカウント全体への完全な権限を持つため、AWS は日常運用で root user を使わないことを強く推奨しています。

作成直後にやっておくべきこと

AWSアカウントを作ったら、最初に root user でサインインして MFA を有効化し、その後は日常作業用の管理者ユーザーを作るのが安全です。AWS は、root user を日常利用せず、IAM Identity Center などで管理者アクセスを持つ別ユーザーを作る運用を推奨しています。

ここは SES の利用だけなら必須の技術要件ではありませんが、実務ではほぼ必須です。請求設定やアカウント閉鎖対応のような root 専用作業だけ root user を使い、普段の SES 設定や閲覧は管理者ユーザーで行うのが安全です。

SESを使うリージョンを決める

次に Amazon SES をどのリージョンで使うかを決めます。ここはかなり重要です。SMTP 認証情報は AWS リージョンごとに固有で、複数リージョンで送信したいならリージョンごとに SMTP 認証情報が必要です。SMTP エンドポイントもリージョンごとに異なります。

日本向けの Django アプリなら、運用を単純化するためにまずは東京リージョン ap-northeast-1 で統一するのがわかりやすいです。東京リージョンの SMTP エンドポイントは email-smtp.ap-northeast-1.amazonaws.com です。

Amazon SESを開く

AWS コンソールにログインしたら、サービス検索で SES と検索して Amazon SES を開きます。まだ SES で identity を1つも作っていない場合は、ホーム画面から Get started を押すとセットアップウィザードが表示されます。

このウィザードは、最初の送信元 identity の作成や production access 申請の導線として使えます。すでに identity を作成済みの場合は、同じ画面構成ではなく Get set up 側の導線が表示されます。

送信元メールアドレスを登録する

ここでやるのが、「このメールアドレス、またはこのドメインは自分のものです」と SES に証明する作業です。SES では、送信時の From、Source、Sender、Return-Path に使う identity を事前に検証しておく必要があります。

やり方は2つあります。最短で試すなら、メールアドレス単体を検証します。本番運用を考えるなら、ドメイン単位で検証するほうが一般的です。AWS では、ドメイン identity を検証すると、そのドメイン配下のメールアドレスやサブドメインから送信でき、個別アドレスの都度検証が不要になるケースが多いと説明しています。

まずは最短で試したい場合

SES コンソールで Identities から Create identity を押し、Email address を選び、たとえば noreply@yourdomain.com を入力します。すると、そのメールアドレス宛に検証メールが届くので、メール内のリンクを開けば検証が完了します。AWS の案内では、この確認リンクは送信後 24 時間で期限切れになります。

この方法は、とにかく早く Django から1通送りたいときに向いています。ただし、その1アドレスしか使えません。たとえば後から support@yourdomain.com や info@yourdomain.com を使いたくなったら、それぞれ追加検証が必要になる場合があります。

本番向けにきちんとやる場合

Create identity で Domain を選び、ドメイン名を入力して作成します。すると、SES から DNS に追加すべきレコードが提示されるので、それをドメイン管理画面に追加します。AWS は、ドメイン検証を先に済ませることを production access 申請前のベストプラクティスとして案内しています。

実運用ではこちらがおすすめです。サインアップメール、パスワードリセット、請求通知、リマインドメールなどで送信元を分けたくなることが多いため、最初からドメイン検証にしておくと後が楽です。これは私の実務上のおすすめで、AWS の要件というより運用上の判断です。

まだsandboxなら、本番送信の申請をする

新しい SES アカウントは各リージョンごとに sandbox 状態から始まります。sandbox 中は、検証済みメールアドレスや検証済みドメイン宛、または SES mailbox simulator にしか送れません。さらに、24時間あたり最大 200 通、毎秒最大 1 通という制限があります。

つまり、一般ユーザーへのサインアップメールやリマインドメールを本番で送りたいなら、production access の申請が必要です。SES コンソールの Account dashboard に進み、上部の sandbox 警告から View Get set up page → Request production access に進みます。申請フォームでは、主なメール種別を Transactional か Marketing から選び、WebサイトURL、連絡先メールアドレス、連絡言語などを入力し、オプトイン送信とバウンス/苦情対応の確認に同意して送信します。AWS は初回応答を通常 24 時間以内に返すと案内しています。

Djangoのサインアップメールやリマインドメールは、基本的には Transactional で申請するのが自然です。これは AWS の仕様ではなく、メールの性質に照らした実務上の分類です。

SES_SMTP_USERNAME と SES_SMTP_PASSWORD を作る

ここが Django 側の SMTP 接続で使う本命です。SES コンソールで左メニューの SMTP settings を開き、右上の Create SMTP Credentials を押します。すると IAM 側の画面に移り、SMTP 用ユーザー名を決めて Create user を押せます。次の画面で Show を押すと SMTP パスワードが表示されます。さらに .csv をダウンロードできます。

このとき表示される値がそのまま Django で使う認証情報です。
SES_SMTP_USERNAME は表示された SMTP user name、SES_SMTP_PASSWORD はそのとき表示された SMTP password です。なお AWS は、このダイアログを閉じると認証情報を再表示・再保存できないと案内しています。つまり、この場で必ず控える必要があります。

なお、SMTP 認証情報は AWS の通常ログインパスワードでも、通常の access key / secret key でもありません。別物です。既存の IAM access key から変換生成する方法もありますが、通常は SES コンソールの Create SMTP Credentials を使うのが最も簡単です。

SES_FROM_EMAIL を決める

SES_FROM_EMAIL は AWS が自動で発行してくれる値ではありません。SES で検証済みの identity の範囲内で、自分が送信元として使いたいメールアドレスを決め、その文字列を環境変数に入れます。たとえば noreply@yourdomain.com や support@yourdomain.com です。

最も無難なのは noreply@あなたのドメイン です。サインアップ確認、パスワード再設定、予約通知、リマインドなどの自動送信と相性がよく、ユーザーにも送信元の意図が伝わりやすいです。これは運用上のおすすめです。

ここまでで最終的に手に入る値

ここまで完了すると、Django に入れる値は次のようになります。

SES_SMTP_USERNAME=AWSコンソールで発行されたSMTPユーザー名
SES_SMTP_PASSWORD=AWSコンソールで発行されたSMTPパスワード
SES_FROM_EMAIL=noreply@yourdomain.com

このうち、前の2つは SMTP settings から作成して取得し、最後の1つは SES で検証済みの送信元メールアドレスを自分で決めて設定します。SMTP 認証情報はリージョン固有なので、東京リージョンで作ったなら東京リージョン用の SMTP endpoint を使います。

Django側の設定例

Django で SMTP として SES を使うなら、典型的には次のようになります。東京リージョンを使う前提の例です。東京の SMTP endpoint は email-smtp.ap-northeast-1.amazonaws.com です。SES の SMTP 接続では TLS を使う必要があります。

import osEMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "email-smtp.ap-northeast-1.amazonaws.com"
EMAIL_PORT = 587
EMAIL_HOST_USER = os.getenv("SES_SMTP_USERNAME")
EMAIL_HOST_PASSWORD = os.getenv("SES_SMTP_PASSWORD")
EMAIL_USE_TLS = TrueDEFAULT_FROM_EMAIL = os.getenv("SES_FROM_EMAIL")
SERVER_EMAIL = os.getenv("SES_FROM_EMAIL")

587 + STARTTLS は一般的な組み合わせです。AWS は SMTP エンドポイントとの接続で TLS が必要で、クライアントはリージョンに対応した SMTP endpoint とポート番号を使う必要があると説明しています。

途中でつまずきやすいポイント

最も多い勘違いは、「AWS に登録したメールアドレスやパスワードをそのまま SMTP ログインに使える」と思ってしまうことです。これは違います。SMTP ログイン用のユーザー名とパスワードは、SES の Create SMTP Credentials で別途作成します。

次に多いのは、SES_FROM_EMAIL を未検証のメールアドレスにしてしまうことです。SES では送信元に使う identity を事前に検証しておく必要があります。ここが未検証だと、SMTP 認証が通っていても送信時に失敗します。

もう1つは、sandbox のまま一般ユーザー宛に送ろうとして失敗することです。sandbox 中は検証済み宛先にしか送れないため、サインアップメールの本番運用前に production access を確認しておく必要があります。

エトカンパニーへの開発支援の依頼について

エトカンパニーでは、Webアプリや業務システムの受託開発と、社内開発チームを伴走支援するハンズオン型のアドバイザリー支援の両方に対応しています。

「構想はあるが、設計から実装までまとめて任せたい」という場合は、要件整理から設計、開発、改善まで一貫してご支援できます。
一方で、「自社にエンジニアはいるものの、手が足りない」「実装方針の整理やレビュー、難所だけ外部の力を借りたい」といった場合には、リソース補完や技術支援の形でも柔軟に伴走可能です。

つまり、エトカンパニーは、丸ごと開発を任せたい企業にも、自社開発を前に進めるために外部の知見と実働を足したい企業にも対応できる体制を持っています。単に言われたものを作るだけではなく、事業の目的や運用体制まで踏まえたうえで、

「今どこまでを社内で持ち、どこからを外部に任せるべきか」

「短期で立ち上げるべきか、将来の拡張を見据えて設計すべきか」

といった判断も含めてご相談いただけます。

新規サービスの立ち上げ、既存システムの改善、社内開発体制の補強まで、必要な形で入り込めるのがエトカンパニーの強みです。ぜひ、お気軽にご相談ください！