AWSクラウドでメールを送信する(AmazonSES)
AWSクラウドでのシステム構築で、メール送信する要件があった場合に、オンプレミスでの開発経験からして、EC2上にメールサーバを立てるのを普通に考えると思いますが、これがなかなか悩みどころなのです。
まず、AWSクラウドでは内部のEC2インスタンスからのSMTP通信はリスクがあると考えられています。
メール送信のための通信である、SMTPポート25番はブラックリストに登録されています。
基本的に、EC2インスタンスからのメール送信は、悪意あるユーザーによるしわざとみなされています。
つまり、これが、セキュリティを考えた場合の基本的なスタンスなのです。
そのようなAWSの方針なのですが、それでもEC2インスタンス上のメールサーバ機能によって、メール送信を行うと決めた場合には、AWSに対する送信制限解除申請が必要になります。
☞ 「AWS EC2インスタンスからメール送信する場合の送信制限解除申請」
(契約したばかりのAWSアカウントでの解除申請で、お断りのメールをAWSから受け取ったことがありました。
サポートとやり取りした結果で聞いた理由では、この申請はある程度運用したアカウントで、料金を支払った実績がないと
許可されないことがあるとのことでした)
そして、EC2インスタンス上で Postfix などのメール送信サーバを構築する段階でも、実装の難しさがあります。
AWSからは、セキュリティ的に問題のない実装を義務ずけられていますので、送信者ドメイン認証(SPF、DKIM、DMARC)の実装が必要です。
ところがこれが難しいのです。SPF、DKIM、DMARCといった機能を有効化して、設定を行い、さらにDNSであるRoute53にもレコードを登録する必要があります。
私は、色々設定を試しましたが、DKIM、DMARCといった機能を標準的メールソフトへ実装する情報がインターネット上に少なくてつまずきました。
色々試しましたが、正常動作にまで至りませんでした。
( DKIM、DMARC 自体最近の実装なので、今のWebアプリ環境での実装がためされていないのでは。本当にできたのかなという感じのサイトばかりです)
また、設定がうまくいったとしても、AWSはリスクのない安全なメール運用を求めています。
メール運用監視が必要であったりとか、クレームがあった場合の迷惑メール対策が必要です。
それには稼働した後にも、エラーやメール不達で戻ってくるバウンスメールに対しても、適切な対応が必要になってきます。
このエラーの通知について、監視して認識できるようにして、適切な対策を取っていない場合に、スパムメールの送信元と評価されたり、エラーによるメール配信の遅延で機会損失となったり、社会的信用を失ったりすることが発生してしまうのです。
AmazonSESには、このようなメール運用の負荷を支援する監視の仕組みや必要な対策が取れる機能が備わっているのがミソです。
問題のないメール運用を行うには、「AmazonSESを運用するのがベスト!!」というのが私の意見です。
ということで、今回はEC2インスタンスでのメール送信サーバ運用を行わないで、AWSサービスのSESを使う場合の手順です。
その他の投稿もご確認下さい
今回はメール送信のAWSサービスである、AmazonSESの内容だったのですが、
①次回はAmazonSESの送信設定(最終的には、Wordpressサイトからメール送信する場合のプラグインの設定が必要です)
②次々回はメール受信のほうのサービス「AmazonWorkMail」をセットアップします。
SESでメールの送信はできるのですが、AWSのメールサービスの仕組みではいわゆるメール受信サーバ機能(smtp OR imap)は提供されていないのです。
AWS受信メールサービスでは、 AmazonWorkMail があるのですが、こちらが(バージニア、アイルランド、オレゴン)しか扱っていません。
そのため、投稿では(オレゴン)を指定してメール受信サービスのセットアップを行っています。
③また、さらにSESのメンテナンスも投稿しています。運用稼働後に色々と問題に見回りました。その顛末も記載しています。
Amazon SES(Amazon Simple Email Service) セットアップ
SESは発信専用のメール送信サービスです。 2020.07 に SESが東京リージョンに対応しました!
AWS マネジメントコンソールのメニュー表示では、ずいぶんと端にあります。
SESのコンソールが表示された。東京リージョンにして、「Domains」をクリック。
ドメインの指定
新規にドメインを登録するために、上部「Verify a New Domain」ボタンをクリック
「Domain:」欄に新規登録するドメイン名を入力
「Generate DKIM Setting」にもチェックを入れる
「Verify This Domain」ボタンをクリック
※ Route 53を使用している場合には、「Use Route53」→「Create Record Sets」で自動設定されます。
Route53へのDNS登録
登録したドメインが認証待ち状態になります。
DNSサーバ(Route3)に登録され、しばらく経過すると、「verified」になり、ドメインおよびDKIMの検証が完了します。
Route53を確認すると、自動でDNS登録がされている。
ドメイン認証確認
画面を更新すると
しばらく経過すると、「verified」になり、ドメインおよびDKIMの検証が完了します。
2022.03.31 久しぶりに、SESの画面を確認したら、だいぶ変わっていた。また、時間あるときに新画面で確認したい!!
ただ、設定した結果の画面内容は以前と変わらないようなので、この最終結果になるように設定すれば良いと思う。
メールアドレスの登録
「Email Addresses」をクリック
「Verify a New Email Address」をクリック
「Email Address:」欄に登録するメールアドレスを入力し、「Verify This Email Address」ボタンをクリック
「Verification Email Sent」ダイアログが表示されるので、「Close」ボタンをクリック
入力したメールアドレス名が表示されます。まだこの時点では、Statusが「pending verification」
メールアドレスの検証
しばらく経つと、登録したメールアドレスにメールが送信されます。その中のリンクをクリックします。
「Amazon SES の特徴」が表示されるが、
再表示すると
検証は完了(verified)
メールの送信テスト
「Send a Test Email」をクリック
送信したメールが受信できたことを確認
※ この時点では登録したメールアドレスのみ
に送信できる
SES Metric に
送信結果が記録されている
Amazon SES の制限解除
SESですが、初期状態だと以下の制限が掛かっています。
- 事前に登録したメルアド以外には送信できない
- 1日当たり200通までしか送信できない
- 1秒当たり1通までしか送信できない
制限を解除するためには、以下の申請が必要になります。
2022.03.31 久しぶりに、SESの画面を確認したら、だいぶ変わっていた。また、時間あるときに新画面で確認したい!!
ただ、ちなみに、制限解除はAWSマネージメントコンソールの上部右メニューのEアドレス→「 Service Quotas」で設定できるようになっていた。
これはAWSのドキュメントにも記載されていませんでした。
「Request a Sending Limit Increase」をクリック
※ 2021.05.01 左の②のクリックで以前のように画面遷移しなかった。以下の操作を追加した。
AWSコンソールのヘッダー部分にあるサポート
→ サポートセンターを選択
AWS Support Center画面でCreate Caseを押下
解除申請するページに遷移した。
解除申請
Limit type:SES送信制限 → 固定値です
メールの種類 -opyopnal:システム通知 → 送信するメールの種類を記入します
ウェブサイトのURL -opyopnal:今回設定なし → 任意入力項目です
あなたのメールを明確にリクエストした受信者のみに送信する方法を説明してください -opyopnal
: AWSサーバの監視とエラー通知。サービス利用者からの問い合わせ対応の用途のみ使用します。
→ 実際の使用用途を説明します。迷惑メールの送信でないことを明確に記述することが重要。
バウンスや苦情の通知を受け取った場合に従うプロセスを説明して下さい -opyopnal
: SNS通知を設定し、バウンスが発生した場合は即座に解消に努めます。
→ バウンスメールの対応方法が分かっていて、適切に対応できることが書かれていれば合格だと思います。
Requests / Request 1 の設定
- リージョン:東京リージョン → SES作成時のリージョン
- Limit:希望する1日あたりの送信クエリ → 1日あたりに送信するメールの最大数を記載します。
- New limit value:10000 → あまり大きな数値を申請すると通らないこともあるそう。5000~10000が妥当な線らしい。
Case description/Use case description
- 詳しくシステムのことを記載します。任意項目。
Contact option
- 「Preferred contact language」で日本語を選択し、「Submit」をクリックします。
解除申請を実施すると、アマゾンサポートから、申請を受けた旨、メールで通知がある。
送信制限の引き上げ申請が承認された旨、メールが送られてくる。
SES HOME から「Sending Statistics 」を選択して、送信制限が引き上げられているのを確認する。
1 日あたり 50,000 メッセージとなった
1秒間最大5通が、14通になった
2022.03.31 制限解除をAWSマネージメントコンソールの上部右メニューのEアドレス→「 Service Quotas」で設定すればメールの確認は不要であった。
1日たったら、値が上がっていた。
送信者認証の確認
SPF
Amazon SES の場合には、DNS に SPF 設定は不要
Amazon の DNS に SPF レコードが設定されているので、自前で DNS 設定を行う必要はありません。デフォルトのままで SPF 認証が通ります。
DKIM
Route53を使っている場合には、SES設定のドメイン情報の登録時に(今回は mikolabo.net )Route53のDNSレコードに
自動的にDKIMのためのCNAMEレコードが登録される。以下でステータスを確認する。
DKIM が enable になっており、
CNAMEレコードも確認できる。
DMARCへの準拠
DMARCは、SPF およびDKIM を使用してメールスプーフィングを検出するメール認証プロトコルです。
DMARC に準拠するため、メッセージは SPF または DKIM のいずれか、または両方で認証される必要があります。
SPF によるDMARC への準拠 次の両方の条件を満たすことが求められている。
- Eメールが SPF チェックに合格する必要があります。
- メールヘッダーに含まれる From アドレスのドメインは、送信側メールサーバーが受信側メールサーバーに指定する MAIL FROM ドメインと合致する必要があります。
ドメインの DMARC ポリシーが SPF で strict アラインメントを指定している場合、From ドメインと MAIL FROM ドメインが完全に一致する必要があります。
ドメインの DMARC ポリシーが SPF で relaxed アラインメントを指定している場合、From ヘッダーに指定されたドメインのサブドメインを MAIL FROM ドメインにすることができます。
上記、2番目のDMARCポリシーを満たすために、カスタムのMAIL FROM ドメインの設定が必要!
※ Amazon SES から送信するメッセージには、MAIL FROM ドメインとして amazonses.com のサブドメインが使用されます。
デフォルトの MAIL FROM ドメインが E メールを送信したアプリケーション (この場合は Amazon SES) と一致するため、
Sender Policy Framework (SPF) 認証はこれらのメッセージを正常に検証します。
他の投稿も確認して下さい
今回はメール送信のAWSサービスである、AmazonSESの内容だったのですが、
①次回はAmazonSESの送信設定(最終的には、Wordpressサイトからメール送信する場合のプラグインの設定が必要です)
②次々回はメール受信のほうのサービス「AmazonWorkMail」をセットアップします。
SESでメールの送信はできるのですが、AWSのメールサービスの仕組みではいわゆるメール受信サーバ機能(smtp OR imap)は提供されていないのです。
AWS受信メールサービスでは、 AmazonWorkMail があるのですが、こちらが(バージニア、アイルランド、オレゴン)しか扱っていません。
そのため、投稿では(オレゴン)を指定してメール受信サービスのセットアップを行っています。
③また、さらにSESのメンテナンスも投稿しています。運用稼働後に色々と問題に見回りました。その顛末も記載しています。
追伸:その後のメール運用ではまった。
ドメインのAWSアカウント間移動をAWSサポートにやってもらったのですが、SES環境も考慮しなければならない配慮に欠けていました。
移動後、メール送信テストはしていたのですが、テストメール送信できていたのは錯覚だったみたいです。
(2022.3.30追記)
結局、以下の対応が必要でした。
①SMTPクレデンシャルを作成し直した。 (SESのSMTPエンドポイントが違って設定していた)
②SESアカウントをサンドボックスから移動した。(長らく砂場にいた)
③SES送信クオーターの増加をリクエストした。 (長らく砂場にいた)
④Wordpressの問い合わせからメール送信できるように、プラグイン「WP Mail SMTP」を設定した。
(設定必要であることを忘れていた。 次回、AmazonSESの送信設定 で投稿します。)
⑤Workmailに新しいユーザを追加した。(なぜかユーザが無効化されていた。元アカウントと矛盾していたか?)
⑥WorkmailのWebアプリケーション接続するためのURIが旧アカウントのものから更新されていなかったので更新した。
(ずっと気が付かなかった)
AWSアカウントを3つSES設定したのですが、結局、手順が多すぎて抜けていました。