注目の記事

Amazon SES でメール送信するときのベストプラクティスまとめ(2020年10月)

2020.10.05

はじめに

おはようございます、もきゅりんです。

皆さん、毎日メールしてますか?

色んな技術やツールが栄枯盛衰する中、メールは今も欠かせないツールとして深く我々の日常に組み込まれていますよね。

そんな日常に密接なメールだけに、検討する機会も多くなるのが AWS が提供するフルマネージドメールサービスの Amazon Simple Email Service 。

Amazon Simple Email Service(以下SES)のメール送信機能を使う上でどのようなことを考慮する必要があるのか、ベストプラクティスをまとめてみました。

参考元としては主に下記資料となります。

なお、本稿ではSESの受信機能について、および具体的な設定方法について基本的には扱いません。

はじめてSESを使う方は、概要を把握するのにあたり、下記ブログが参考になるかと思います。

AWS再入門ブログリレー Amazon SES編

内容としては、下記5つを要点としています。

  1. そもそも送信機能としてSESを使うかどうか
  2. メール送信方法をどうするか
  3. 本番利用開始の準備
  4. 認証方法はどうするか
  5. 運用管理はどうするか

まとめ

最初にまとめておきます。

  • 送信テストを行って評価する。宛先に合わせた調整が難しい場合、SES以外の検討をする。
  • 送信クォータを定期的に確認して必要なリクエストを行い、制限解除や制限引き上げをする。
  • メール送信の要件から適切な送信方法を選ぶ。
  • SPF, DKIM, (SPF,DKIMに基づいた)DMARC 準拠のすべてを対応する。
  • バウンス率、苦情率のアラームを設定する。レピュテーションダッシュボードを確認して継続的に改善する運用管理を行う。

1 そもそも送信機能としてSESを使うかどうか

まず最初に送信機能のSESを使うかどうか検討する必要があります。

下の図を再確認します。

choose_ses

この図では、SESを利用するか、 EC2でMTA構築してメールサーバ運用するか、の2択のフローチャートです。

SES以外の選択肢を検討する場合としては、例えば下記のようなケースがあります。

  • 慣れたMTA(Mail Transfer Agent)や既存のノウハウを活用してサーバー構築・運用がしたい

  • 携帯端末/ISP/サービス提供者側のメールサーバの SPAM 対策を含めたフィルタリングの細かい仕様が不明なため、宛先に合わせた送信ルールの適用や調整などを柔軟に設定したい

携帯端末(キャリアメール)の送信については若干古い記事ですが、下記ブログも参考になるかと思います。

[AWS]SESを利用したキャリアメール送信について考える

上記を含めた検討後、SESの利用で決定したとして次に進みます。

2 メール送信方法をどうするか

下記表が選択肢です。

API か SMTPエンドポイントか、さらに送信したい内容、メールフォーマットに応じて適切に選択しましょう。

送信手段 内容 特徴 ユースケース 認証方法
Amazon SES コンソール Amazon SESコンソールから送信 - 主にテスト検証 IAMユーザ、グループ、ロールでの権限付与
Amazon SES API SendEmail API, SendRawEmail API, SendTemplatedEmail (or SendBulkTemplatedEmail) の3つの方法 要件に応じて3種類を使い分ける/後述 アプリケーションから直接メール送信を行いたい IAMユーザ、グループ、ロールでの権限付与
SMTP インターフェイス 生成済みEmailメッセージを受け取って送信するSESのSMTPエンドポイント デフォルトEC2から外向きTCP 25番ポートは制限対象なので利用する場合は解除が必要 既存の送信用SMTPサーバからリレー、SMTPを前提としたプログラムから利用したい 別途IAMユーザのクレデンシャルが必要

Amazon SES API についての補足の説明です。

  • From, To, Subject, Body のみ指定すれば、残りはすべて AmazonSES が適切にフォーマットした Eメールメッセージで簡単にメール送信できるのが SendEmail API です。

  • 添付ファイルを使うなど、独自に細かく制御したフォーマットにカスタマイズしてメール送信をしたい場合は SendRawEmail API を利用します。

  • 基本となるテンプレートメールを作成して、テンプレート内の変数に対してパーソナライズされた値に置換した内容で Eメールメッセージを送信できるのが SendTemplatedEmail および SendBulkTemplatedEmail のAPIです。

詳細については、AmazonSESのEメール送信方法 を確認下さい。

SESのSMTPエンドポイントを使ったメール送信例は下記ブログも参考になります。デフォルトではEC2インスタンスの外向きのTCP 25番ポートは制限されているため、25番ポートでEメール送信をしたい場合は、制限の削除リクエストする必要があります。(587番ポート(Message Submission)、465番ポート(SMTP over SSL)の利用は制限ありません)

Amazon SESのSMTPエンドポイントを試してみた

3 本番利用開始の準備

SES サービスを本番環境にする

各リージョンにおけるSESアカウントの開始時点では、下記サンドボックス特有の送信制限があります。

  • 確認済みのEメールアドレスとドメイン、またはAmazonSESメールボックスシミュレーターにのみメールを送信
  • 確認済みのメールアドレスとドメインからのみメールを送信

任意の受信者に電子メールを送信するためには、アカウントをサンドボックスから削除するようにリクエストする必要があります。

下記参照下さい。

AmazonSESサンドボックスからの移動

ドメインのRoute 53での取得、SESでの承認、SESでのメール送信上限の緩和およびSandbox制限の解除をしてみた

先述の通り、EC2の25番ポートから送信を希望したい場合は、制限の削除リクエストする必要があります。

EC2 インスタンスからポート 25 の制限を削除するにはどうすればよいですか?

Amazon SES に検証済みのドメインがある

ベストプラクティスとして、単一の Eメールアドレスではなく、検証済みのドメインがあることを確認しましょう。

AmazonSESを使用したドメインの確認

デフォルトでは、 SES から送信するメッセージの MAIL FROM ドメインとして amazonses.com (またはそのサブドメイン) が使用されます。

一部のEメールサーバーは、 MAIL FROM アドレス *1が Eメールの送信者と一致しない場合にメッセージをブロックすることがあります。

下のイメージでは、SESでEメール認証した送信者アドレスを使ってメール送信したが、送信者のアドレス(自分のメールアドレス)とMAIL FROM アドレス(amazonses.com)とでドメインが異なるため、注意勧告が表示しています。

mail_alert

SESでは検証済みドメイン(およびサブドメイン)を、カスタム MAIL FROM ドメインに使って MAIL FROM ヘッダーの検証で使用することができるので、検証ドメインを使うことで、上記のように受信者に不信感を与えたり、サーバによって自動ブロックされないようにできます。

送信クォータを確認する

送信クォータを確認し、現在の送信割り当てがニーズに十分でなく、自動的に増加していない場合は、増加をリクエストします。

AmazonSES送信クォータの管理

アカウントがAmazonSESサンドボックスにある場合、24時間あたり200メッセージしか送信できず、最大送信速度は1秒あたり1メッセージです。アカウントをサンドボックスから削除するリクエストを送信するときに、同時にクォータを増やすようにリクエストすることもできます。

SES_Sandbox

専用IPを使うかどうか

SESのデフォルトとして、他のAmazonSESユーザーと共有されているIPアドレスからメールが送信します。したがって、他のSES利用者のメール送信方法によってIPレピュテーションが影響される(送信元のIPアドレスの評価によってメール配信を制限される)可能性があります。

専用IPは、大量のメール送信を行う、さらに送信パターンが定期的である程度決まっていて、 *2上記のような他利用者による配信成否の影響を受けたくない場合の選択肢として検討をします。

共有IPアドレスと専用IPアドレスの比較については、AmazonSESでの専用IPアドレスの使用 にも記載されています。

4 認証方法はどうするか

推奨

SESにおける送信ドメイン認証は、SPF, DKIM, DMARC を対応できますが、(DMARCは、SPFまたはDKIM、あるいはその両方で認証するのが前提) ベストプラクティスとしてはどれかではなく、全部対応しましょう

authentication

なお、DNSプロバイダーとして同一アカウントのRoute53を使用している場合、AmazonSESはドメイン確認時に自動的にDKIMに必要な3つのCNAMEレコード、TXTレコードを作成してくれます。

なぜ必要か?

メール受信者に対して、そのメールが発信元を偽装したような「なりすましメール」ではない、と立証するためです。

SPF や DKIM, DMARC のそれぞれの概要と仕組みについては下記を参考下さい。

送信ドメイン認証(SPF / DKIM / DMARC)の仕組みと、なりすましメール対策への活用法を徹底解説

[4-2 送信ドメイン認証: 迷惑メール相談センター]

具体的な設定については、下記を参照下さい。

Authenticating your email in Amazon SES

Route53 を使ってSPF, DKIM, DMARC を設定する

本稿では、Route53を利用している場合における設定を行ってみます。

別ドメインレジストラを使った場合は下記ブログも参照下さい。

Amazon Route 53 以外のドメインレジストラ (お名前.com) を使って Amazon SES の SPF, DKIM, DMARC を設定してみる

Route53を利用する場合、下記のような進め方になるかと思います。

  1. ドメインの確認 / 自動でDKIMの設定
  2. SPFを介したDMARCへの準拠のため、カスタムMAILFROMドメインを設定
  3. ドメインでのDMARCポリシーを設定
  4. 確認

1. ドメインの確認 / 自動でDKIMの設定

ドメインを入力すると、下記のように自動で作成されるレコードが表示されますので、 Use Route 53 を押下するとレコードが作成されます。

set_DKIM

2. SPFを介したDMARCへの準拠のため、カスタムMAILFROMドメインを設定

Domains タブのドメイン確認したドメインを押下すると、以下のようなイメージが表示されますので、Set MAIL FROM Domainを設定します。

set_mailfrom_domain

カスタム MAIL FROM ドメインについては、メール送信元のドメインではいけない、など要件がいくつかあるので、それらに気を付けてサブドメインを設定します。

Setting up a custom MAIL FROM domain

set_mail_from_domain

ドメインのDNS構成に追加する必要のあるMXおよびSPFレコードを含むウィンドウが表示されるので、Publish Records Using Route53 を押下して進めます。

Amazon SESがレコードが配置されていることを検出すると、カスタムMAILFROMドメインが正常に設定されたことを通知するEメー​​ルを受け取ります。

正常に設定されたため、ステータスが verified になっています。

mail_from_domain_verified

3. ドメインでのDMARCポリシーを設定

Complying with DMARC Using Amazon SES に従って Route 53 にTXTレコードを設定します。

dmarc_txt_record

4. 確認

テストメールで検証してみると (あくまでもGmailでの(Googleによる)判定結果でしかないですが) メッセージのソースから確認してみるとちゃんとSPF, DKIM, DMARCの判定結果はPASSとなっています。

all_ok_results

先のメールアドレス認証だけでメール送信されたメッセージソースはこのようになっています。

verified_mail_result

5 運用管理はどうするか

推奨

Bounces (バウンス) および Complaints (苦情) を監視するための Amazon SNS トピックをセットアップして、レピュテーションダッシュボードを確認してコンテンツ・送信先の管理運用を継続して行いましょう。

下記ドキュメントにバウンス率、Complaints率に対するアラームの設定方法は記載されています。

CloudWatchを使用したレピュテーションモニタリングアラームの作成

レピュテーションダッシュボードには、アカウントのステータスおよびバウンス率、苦情率、その他バウンスや苦情とは関係のないレピュテーション関連の問題が発生している場合は、ここに簡単なメッセージが表示されます。定期的に確認しましょう。

Reputation dashboard messages

Reputation Dashboard

なぜ必要か

Amazon SESは、アカウントのバウンス率または苦情率が高すぎる場合、アカウントを審査中にするか、アカウントのメール送信機能を一時停止する場合があります。

Email program success metrics には下記のような明確な数値が記載されています。

  • ハードバウンス率 *3を5%未満に保つようにしてください。

  • 苦情率を0.1%未満に保つようにしてください。

その他、メッセージの内容から不正なメールかどうかを識別するコンテンツフィルタリングに検出、ブロックされてしまわないようにメール内容にも注意するように記載があります。

どう対応するか

じゃあBounces (バウンス) や Complaints (苦情) を最小限に抑えるにはどうしたらよいの?という疑問が湧くと思います。

Amazon SES Sending review process FAQs には、残念ながらアカウントがレビュー対象の通知がきてしまったときや、バウンスや苦情をどのように抑えれば良いか、対処をどのようにすべきを記載してくれています。

例えば、 Q11. バウンスを最小限に抑えるにはどうすればよいですか? には、端的にまとめると下記のように書かれています。

  • バウンスされた Eメールアドレスをリストから削除する
  • メール送信する前に、実際に現在利用されているEメールなのかどうかを確認する仕組みを導入する

Q4. 苦情を最小限に抑えるにはどうすればよいですか? にはバウンスと同様のことが記載されていますが、受信者にとって不快であったり不信を生むようなメール内容・形式でないことに注意しましょう、といった記載事項がさらに増えています。

  • メールが適切な形式になっており、見た目の質も高いことを確認
  • メールがお客様からのものであることが明確になっており、他のメールと混同されないことを確認
  • ユーザーがメールの受信登録を解除するとき、わかりやすく簡単な方法で実行できるようする

詳細については、Amazon SES Sending review process FAQs にてご確認下さい。

イベント発行でさらに細かく送信をモニタリングして管理する

Configuration Set を使って送信、配信、オープン、クリック、バウンス、苦情、拒否、レンダリングの失敗、配信遅延など、さまざまな種類の E メール送信イベントを追跡し、 Amazon CloudWatch、Amazon Kinesis Data Firehose、または Amazon Simple Notification Service に発行するように Amazon SES にセットアップすることができます。

設定方法については下記ブログが参考になります。

Amazon SESで開封やクリックのトラッキングが可能になりました。

まとめ

再度まとめます。

  • 送信テストを行って評価する。宛先に合わせた調整が難しい場合、SES以外の検討をする。
  • 送信クォータを定期的に確認して必要なリクエストを行い、制限解除や制限引き上げをする。
  • メール送信の要件から適切な送信方法を選ぶ。
  • SPF, DKIM, (SPF,DKIMに基づいた)DMARC 準拠のすべてを対応する。
  • バウンス率、苦情率のアラームを設定する。レピュテーションダッシュボードを確認して継続的に改善する運用管理を行う。

最後に

SESを送信機能として使うことは決まった。で、何を、どのように考えて設定すればいいのだろうか、と悩まれるかと思います。

何を、どのように考えてどうすべきかについて、SESの多々ある機能や設定の中から限定して要点をまとめてみました。

どなたかのお役に立てば幸いです。

参考

脚注

  1. エンベロープ送信者、エンベロープ送信元、バウンスアドレス、またはリターンパスと呼ばれます。
  2. たとえば少なくとも月に1回、24時間以内に数百通の送信を行うなど
  3. バウンスには、ハードバウンスと ソフトバウンスの2種類があり、ハードバウンスは、電子メールアドレスが存在しない場合など、永続的な問題のために電子メールを配信できない場合に発生します。