Amazon SESによるメール送信環境の構築と実践
Amazon SES を利用してメール送信する際に必要となるスパム対策の基礎知識と、環境構築や利用申請の方法については具体的にステップ・バイ・ステップで説明します。SESのメール送信では、SESの利用方法や応用例をご紹介します。
SES とは
Amazon SES(Simple Email Service)は Amazonが提供するフルマネージド型のメール配信サービスで以下の特徴があります。
- 初期費用無し、低価格
- 配送機能のみ提供 *1
- Email配送API
- Amazon SES クエリ(HTTPS)
- AWS コマンドラインインターフェイス
- AWS Tools for Windows PowerShell
- AWS Software Development Kit(SDK)
- Android、Browser、iOS、Java、.NET、Node.js、PHP、Python、Ruby、および Go
- 高可用性・高信頼性・スケーラブル
- 稼働時間とメール到達性に最適化
- Amazonで証明された配送実績
SESの全体像については、「AWS Black Belt Tech Webinar 2014 – Amazon Simple Email Service」レポート にまとめられていますのご覧ください。
スパム対策の基礎知識
メールの送信者偽称を防ぐ送信ドメイン認証技術
メールを受信するサーバーではスパムメールを受信しないための対策を行っています。その結果、普通のメールを送る場合でも、送信ドメイン認証を導入していないメールサーバーからメール送信するとスパムメール扱いを受けてしまいメールが相手に届きません。メールの送信者偽称を防ぐ送信ドメイン認証技術として、SPF と DKIMがあります。
送信元IPアドレスをチェックする SPF
SPF(Sedber Policy Framework)はメール送信元のIPアドレスを基準に送信者を認証します。ドメインのメールを送信するサーバのIPアドレスをリストして管理して、リストにないIPアドレスからのメールを破棄します。DNSにTXT/SPFレコードを追加してSESからのメール送信を許可する設定をします。
送信ドメインを電子署名で認証する DKIM
DKIM(Domainkeys indentification)は電子署名を使って送信ドメインを認証します。送信側で電子署名を施し、受信側で電子署名の照合を行うことで、偽者を見破り破棄することができます。DNSにCNAMEレコード(公開鍵)を追加して、SESからのメール送信を受信側で電子署名の照合を行い、不一致のメールは破棄します。
SPFとDKIMの具体的な設定方法や内容については後述します。また、これらの詳細について知りたい場合は、Amazon SESでSPFとDKIMを用いて高信頼なメールを送る を参照してください。
バウンスと苦情の管理
メールを安定して送信するには、スパムメールの送信者として扱いを受けないように、常にバウンス率や苦情率を低く保ち続ける運用が必要となります。
バウンス(Bounce)とは、配信したメール・配信しようとしたメールがなんらかのエラーによって 送信者に差し戻されたメールのことです。SESではバウンス率が一定の水準を超えるとそのアカウントのメール配信が停止されますので、バウンスは常に注意が必要です。その理由は、スパム事業者は不特定多数のメールアドレスに対して大量のメールを送り付けますが、スパムメールが到達した後に受信者がドメイン拒否の設定などによって到達しなくなることで、バウンス率が上昇することがあるからです。「バウンス」に関しては Amazon SES のバウンスに関するよくある質問 にまとめられていますので御覧ください。
過去 14 日以内にハードバウンスの原因となった受信メールアドレスを保持する仕組みがあり、これをサプレッションリストと呼びます。サプレッションリストに登録されているアドレスにメールを送信しようとした場合、SES の呼び出しは成功しますが、このメールを送信せず、送信量上限やバウンス率にカウントするので注意が必要です。Management Console の Suppression List Removal からサプレッションリスト登録されたメールアドレスを削除することができます。詳細はAmazon SES サプレッションリストからの E メールアドレスの削除 をご参考にしてください。
苦情(Complaint)とは、メールの受信者がメッセージがスパムと報告すると ISP はこのことを苦情として記録します。このような苦情が多すぎる場合は、送信者がスパムを送信していると ISP が判断する可能性が高くなります。SESでは苦情率が一定の水準を超えるとそのアカウントのメール配信が停止されますので、苦情についても常に注意が必要です。SES では、苦情を申し立てたことを送信者に知らせるため、フィードバックループを採用している ISP からの苦情は自動的に送信者に転送されます。「苦情」に関しては Amazon SES の苦情に関するよくある質問 にまとめられていますので御覧ください。
下記のAWSの公式ドキュメントでは、「基本的にバウンス率は 5% 以下に維持してください。」「基本的に苦情率は 0.1% 未満に維持してください。」と記載されています。バウンスや苦情については、Management Console の Your Amazon SES Metrics から参照できます。
Amazon Simple Email Service E メール送信のベストプラクティス(PDF)
なお、上記以外にメールコンテンツの質が低い(Low Content Quality)が原因でそのアカウントのメール配信が停止されることもあります。上記のAWSの公式ドキュメントの「質の高いコンテンツを作る」に記載があります。
メール送信要件の確認
SESはスケールの大小にかかわらず、メール送信にかかる手間やコストは最も小さいといえますが、導入するシステムの要件を満たしているか事前に確認して下さい。特に日本の携帯キャリアのアドレスにメール送信が必要な場合はSESはあまり適しません。そのような場合は、以下の2つの方法を検討してください。
- 自前でEC2インスタンスにメールサーバーを構築
日本の携帯キャリアのアドレスにメール送信したい場合や、Bounceやコンテンツに問題が多いことで、AWSに送信レートを抑制されることが懸念される場合は、この方法をご検討ください。
この場合、構築・運用・障害対策・スケール調整は自分で行う必要があります。また、忘れてはならないのが各種申請です。200通/日以上を送信するには、EC2インスタンスに対して「EC2メール送信制限解除の申請」と、大抵の場合には、「DNS逆引き申請」を行います。これらの申請をしないと、AWSのメール配信制限により送れない可能性がありますのでご注意ください。
自前でEC2インスタンスにメールサーバーを構築する場合は、Amazon EC2 Eメール送信ベストプラクティス が参考になるでしょう。
- メール送信サービスを利用
日本の携帯キャリアのアドレスにメール送信したい場合や、メール配信の管理(配信者リスト、配信スケジュール、配信実績)が必要な場合など、コストよりも短期間で確実に配信できることを優先したい、メール配信のサポートを受けたい場合はメール送信サービス(SendGrid等)という選択肢があります。SESでは、メール配信の管理をサービスで提供していませんので、必要な場合はそのような機能を実装しなければなりません。
日本の通信キャリアのデコメール送信は、国内携帯キャリア対応のデコメールを送る で方法をご紹介しています。日本の携帯キャリアのアドレスにメール送信は、「バウンス」や「苦情」が問題にならないようにクライアント側で配慮済みの場合は送信できなくはないですが、やはり、限定的といえるでしょう。
構築手順
SESのリージョンの選択
現在、以下の3つのリージョンでのみサービス提供しています。
- 米国東部(バージニア北部)
- EU(アイルランド)
- 北米西部(オレゴン)
今回は、「米国東部(バージニア北部)」を利用したいと思います。
送信元の確認
送信元メールアドレス もしくは ドメインが正しいことを検証します。
今回は、送信者認証、つまり送信元メールアドレスを検証します。ここで指定する送信元メールアドレスは受信可能なメールアドレスを指定しなければなりません。Velification Sender の Email Addresses をクリックすると、検証済みの送信メールアドレスが一覧表示されます。(初めての場合はアドレスは表示されません)
[Verify a New Email Address]ボタンを押すと、登録用のダイアログが表示されますので、送信メールアドレスを入力して、[Verify This Email Address]ボタンを押します。
登録した送信メールアドレスに検証要求メールが届くので、承認するためリンクをクリックすると、
認証すると、「検証に成功しました」というメッセージがブラウザに表示されます。
Management Console に戻り、Verlification Sender の [Email Addresses] をクリックすると、登録した送信メールアドレスの Status が pending verification (resend) から verified に変わります。
自メール送信確認
この時点ではToに登録したメールアドレス以外設定できない、サンドボックスと呼ばれる試用状態です。 登録したメールアドレスを選択して、[Send a Test Email]ボタンを押すと、Send Test Mail ダイアログボックスが表示されます。 Toに登録したメールアドレスを入力、Subject、Bodyも適宜入力して、[Send a Test Email]ボタンを押します。
メールが登録したメールアドレス宛に届くことが確認できます。メール送信するとDashboardのメトリックスDeliveriesの統計情報が 0 -> 1 に反映される
送信制限の解除申請
SESのDashboardから[Request a Sending Limit Increase]ボタンを押すとサポートウインドが表示され、この画面から「送信制限の解除申請」を行います。(Support Center の画面が English になっている場合は、日本語が良い場合は変更してください。)
以下の質問に対して必須項目の入力と「サービス制限の増加」をチェックして送信します。スピーディーに申請が受理され、メール送信の上限を上げてもらうためには、具体的かつ管理方法を明確に書いてください。
Create Case
項目 | 設定 |
名前 | ー |
アカウント | ー |
CC | 必要に応じて記入してください。 |
内容* | サービス制限の増加(変更なし) |
制限タイプ* | SES送信制限(変更なし) リージョンは「北米東部(バージニア北部)」を選択 |
メールの種類 | 用途によって選択する。 |
ウェブサイトの URL | 外部から参照できるウェブサイトURLを指定してください。存在するなら出来る限り記載してください。 |
私は AWS サービス利用規約と AUP に準拠してメールを送信します | 規約に従っていただけるかご確認ください。確認して「はい」を選択してください。 |
私は明確にリクエストされた受信者にのみメールを送信します | 受信を希望していない人に送らないことの確認です。 確認して「はい」を選択してください。 |
バウンスや苦情を処理するプロセスがあります | バウンス(Bounce)や苦情(Complaint)に配慮したメール送信がなされているかの確認です。確認して「はい」を選択してください。 |
申請理由の説明* | 例.お客様宛にニューズレータを定期配信します。メールの受信者のアドレスはシステムで管理されており、送信できないメールアドレスは登録されておりません。 |
お問い合わせ言語* | お好きな言語を指定してください。( 一般に「日本語」指定します。) |
連絡方法 | Web 一択です。 |
申請が受理されると通知メールが届き、SESが正式に利用できるようになります。「サンドボックス(試用状態)」から「プロダクション(本番状態)」となり、受信者メールアドレス(To)自由に指定してメール送信が出来るようになります。
他メール送信確認
送信者メールアドレス以外にメールが送られるか確認しましょう。登録したメールアドレスを選択して、[Send a Test Email]ボタンを押すと、Send Test Mail ダイアログボックスが表示されます。 Toに登録したメールアドレス以外を入力、Subject、Bodyも適宜入力して、[Send a Test Email]ボタンを押します。
メールが登録したメールアドレス宛に届くことが確認できます。
SPFの設定
訂正(2021/07):現在のAmazon SESの実装では、AmazonのDNSにSPFレコードが設定されているので、自前でDNS設定を行う必要はありませんでした。(SPF and Amazon SESより)
登録したメールアドレスのドメインのDNSに下記のSPFレコードとTXTレコードを登録します。 *2
SPFレコードの追加
SPFレコードが新規の場合
"v=spf1 include:amazonses.com ~all"
SPFレコードがすでにある場合
既存の設定に "include:amazonses.com ~all" を追加してください。
"v=spf1 a:example.com include:amazonses.com ~all"
TXTレコードの追加
TXTレコードが新規の場合
"v=spf1 include:amazonses.com ~all"
TXTレコードがすでにある場合
既存の設定の最後に改行して、以下の行を追加します。Amazon SES:同一ドメイン名で複数のアカウント利用に対応する(Domain verification record setの複数登録) をご参考にしてください。
"v=spf1 include:amazonses.com ~all"
DKIMの設定
CNAMEレコードの追加
[Email Addresss]を選択して、[Generate DKIM Settings]ボタンを押すと、登録する情報が表示されます。
上記のDKIMを登録したメールアドレスのドメインのDNSに表示された値をCNAMEレコードとして追加します。
- SPFレコードの追加
- Route 53 の場合のみ[Route 53]ボタンを押すと自動的に登録されます。(とても便利です)
- Route 53 以外の場合登録したメールアドレスのドメインのDNSに表示された値をCNAMEレコードとして登録します。
DKIMの有効化
CNAMEレコードを追加してSESに反映されると、DKIM: waiting on DKIM verification... から DKIM: disabled (enable) に変わります。DKIMを有効化するには、この enable リンクをクリック、ダイアログの[Yes, enable DKIM]ボタンを押すと有効化されます。有効化されるとDKIM: enable (disable) に表示が変わります。
他メール送信確認(SPF、DKIMヘッダの確認)
「他メール送信確認」の手順に従い、再びメール送信確認して、ヘッダを確認します。DKIMは登録したドメインが追加されていることが確認できす。
メール送信
AWSCliによるメール送信
まずは、動作確認を兼ねて、AWSCliを利用してメール送信する方法をご紹介します。
aws --region us-east-1 ses send-email \ --to [email protected] --from [email protected] \ --subject "ses sendmail test" \ --text "ses mail body" { "MessageId": "0000014f1589c210-312ba117-af2e-4386-984c-3c3e7c5e909d-000000" }
AWS SDK for Java によるメール送信
その他に、AWS SDK for Java を利用したメール送信は、AWS SDK for Javaを使う#Amazon SES をご参考にしてください。基本的に他の言語のSDKでも同じような手順でメール送信できます。
メールクライアントからSMTP送信
AWS SDKやAWSCliを使わずにメールクライアントからSMTP送信も対応しています。詳しくはAmazon SESでメールクライアントからSMTP送信を行う を参考にしてください。
EC2からSESをリレーしてメール送信
EC2からSESをリレーしてメール送信するためのPostfix設定方法を紹介しています。
【AWS】簡単!berkshelfとchefを使ってPostfixからSESでメールを送ってみた
既存システムをAWSへ移行するにあたって、アプリケーションの改修を行わず、サーバーからメールを手軽に送りたいという需要は多いのではないでしょうか。
Postfixを使ってSESを利用するメリットは、sendmailやmailコマンドを使ってメールを送ることができる点です。またPHPのmail()関数は、デフォルトでローカルのメールサーバー経由でメール送信をするので、その点でもお手軽です。これ以外に、メール送信に失敗した場合にはキューに保存され再送してくれる点も使い勝手がいいのではないでしょうか。
最後に
Amazon SES は、スケーラブル・高信頼・低コストなEmail送信サービスですが、大量のメール送信が可能なので、つい大規模向けと考えがちですが、簡単な設定で素早く・ランニングコストの少ないメール配信環境を構築できるので、小規模でも十分コストメリットがあります。
メールは身近なサービスですが、メールが正しく送信するには多くのノウハウや考慮すべきことがたくさんあります。SESの設定を通じてノウハウを学び、SESの利用申請を通じて考慮すべきことを知ることが出来るでしょう。安定してメール送信するには、高品質なメールを送り続けることでメール配信の信頼を築き上げることが必要です。
ほとんどコストが掛からないので、頭で考えるよりも実際に手を動かしていただけると、SESの頭文字のS(Simple)が、利用者にとってシンプル(簡単)に導入できるサービスであることを体験していただけるのではないかと思います。
脚注
- 2015/09/29以降は、メールを受信できるようになりました。詳しくはこちらを御覧ください。[新機能]Amazon SES でメール受信が出来るようになりました! ↩
- 執筆時点(2015/08)では、互換性のために両方記述したほうが良いと考えています。RFC 7208が導入されるまでは、SPFタイプ(code 99)とTXT(Type 16)の両方で記述するべきものでしたが、一部の大手事業者はSPFとしてTXTレコードのみを参照しており、SPFタイプが普及しなかった経緯がありました。その後、2014年4月にRFC 7208が勧告され、Section 3.1.の通り、SPFレコードはDNS Resource Recordsにて、TXT(Type 16)のみで記述しなくてはならなくなりました。 ↩