「AWS Black Belt Tech Webinar 2014 – Amazon Simple Email Service」レポート
こんにちは、虎塚です。
昨夕実施されたAWS Black Belt Tech Webinarを聴講したので、レポートします。テーマは、Amazon Simple Email Service（Amazon SES）です。
講師は、アマゾンデータサービスジャパンの吉荒祐一さんです。吉荒さんは、過去に公共機関向けのシステムや防災系アプリケーションを担当されてきたそうです。
防災系のアプリケーションでは、何か起きた時にEmailを大量に送信する必要があります。その時、信頼性を担保しつつ迅速に送信するにはどうすればよいかが、悩みの種だったとのことです。あの頃にSESがあればラクにできただろうなぁという思いがあり、SESは好きなサービスだとのことです。
アジェンダ
- Amazon SESとは？
- Amazon SES利用開始までの流れ
- メール配信の信頼性を維持するために
- SPF
- DKIM
- バウンス処理
- EC2インスタンスからのメール送信
- まとめ
Amazon SESとは？
- 一言でいうと、スケーラブル・高信頼・低コストなEmail送信サービス
- 大きなIPプールでメール送信できる
- Mail Transfer Agent (MTA) を自分で立てて苦しむ必要がない
- 2014年10月現在、3リージョンで提供（us-east-1, us-west-2, eu-west-1）
- 用途例
- マーケティングメール、メルマガの配信
- 各種サービス、アプリからエンドユーザへの通知
From Jeff Barr, Chief Evangelist for the Amazon Web Services
「SESを使うということは、信頼を築き上げて行くことである。小さなリミットから始めて高品質のメールを送り続けることで、より厚い信頼を形作っていく」
「メトリクスを理解してね」
（上記の意味は、このwebinarが終わる頃には分かるはず、とのこと）
Amazon SESのコンセプト
- Eメールの様々な問題を理解する
- Bounce
- Complaint
- Suppression List
- プロアクティブに問題を解決する
- Verification
- Authentication
- Sending Limits
- Content Filtering
- Reputation
- 何が起きているかを把握する
- Notifications
- Usage Statistics
- Eメール配信プログラムを改善する
このサイクルをぐるぐると回すことがSESのコンセプト。
Amazon SESによるEmail送信 - HTTP REST API
- SendEmail API
- 送信側がFrom, To, Subject, Bodyだけ用意すればよい
- SendRawEmail API
- メッセージ全体を生成（MIME typeなども）して送信する
認証には、AWSアクセスキーとシークレットアクセスキーを使用する。
この方法は、アプリから直接Emailを送信する場合に便利。
Amazon SESによるEmail送信 - SMTPエンドポイント
生成済みのEmailメッセージを受け取って送信するエンドポイント。
- ポート: 25 / 465 (SMTP over SSL) / 587 (Message Submission)
- TLS必須
- 認証必須
- 専用のIAMユーザを作成して、クレデンシャルを使用する
この方法は、既存のSMTPサーバからリレーしたり、SMTPを前提にプログラムから直接利用したりする場合に便利。
SMTPエンドポイント用IAMユーザの作成
1
- Management Consoleでオレゴンリージョンを選択する
- Amazon SES Dashboardで、左メニューから［SMTP Settings］を選択する
- SMTPのサーバ名、ポート番号、TLS利用有無、認証方法が表示される
- ［Create My SMTP Credentials］ボタンを押すと、クレデンシャルが作成される
2
- 送信用ユーザの名前（IAMユーザ名）を入力する
- デフォルトで名前が入っているが変更できる
- 作成するユーザに適用するIAMポリシーが、デフォルトで提供される
- ses:SendRawEmail Actionがが許可される
IAMのManagement Consoleで、ユーザが作成されたことを確認する。ユーザを選択すると、User Pokiciesで先ほど適用したIAMポリシーを確認できる。
3
SMTP UsernameとSMTP Passwordが表示される。［Download Credentials］ボタンを押すと、ダウンロードできる。
この情報をクレデンシャルとして、SESにEmailメッセージを投げようとしているアプリケーション側（SMTPクライアント）に設定する。
SMTPエンドポイントを使う際の注意点
- EC2から外向きのSMTP（TCP 25番）は制限対象になっている
- Spamのリレーを防ぐため
- 誤ったSpam送信から利用者を守るため
- MTAとSESエンドポイントのリージョンが異なる場合は、SESのエンドポイントもこの制限の対象になる
- SMTPS（TCP 465番 / 587番）で、認証付きで外部サービスを利用するのは制限されない
この制限は、申請で解除できる。
配信メトリクスのモニタリング
Management ConsoleやAPIから、次の配信メトリクスをグラフでモニタリングできる。
- Deliveries
- 配信に成功した件数
- Bounces
- 跳ね返ってきた件数（先方のサイトやドメイン/メールサーバがない、メールボックスが満杯、ユーザが登録されていない等）
- Complaints
- 先方サイトから苦情が返ってきた件数
- Rejects
- 拒否された件数
Jeffが言っていた「信頼を築き上げる」とは、Bounces, Complaints, Rejectsを低く保つことを指す。
配信メトリクスの表示: rate
Deliveriesは、number（件数）で表示され、その他のBunces, Complaints, Rejectsはパーセントで表示される。
Management Consoleに、表示を切り替えるリンクがある。パーセント表示を件数表示に切り替えることができる。
送信クォータ
送信可能メール数とレートという2つのしきい値がある。送信設定は、送信クォータの範囲で設定できる。これらは、GeSendQuota APIか、Management Consoleで確認できる。
- SendingQuota
- 24時間で送信できるメール数
- 現時点で送信可能なメール数 = SendingQuota - 直近24時間に送信した数
- SendingRate
- 1秒間あたりに送信できるメール数
なお、送信クォータを超えるとスロットリングが起きて、エラーが返る。
- 456 Throttling failure: Maximum sending rate exceeded
- 456 Throttling failure: Daily message quota exceeded
送信クォータの増やす方法は2種類ある。1つは、実績に応じて自然に増加する。（Bouncesなどを含まない）良質なコンテントを送信クォータに近い量送信していると、自動的に増えていく。もう1つは、急に送信クォータを増やす必要がある場合、SES送信クォータの上限緩和フォームから申請することで増やすことができる。
送信クォータについての留意点は次のとおり。
- 24時間あたりの送信クォータは、送信要求の時点から24時間前までの送信数で判断する
- 日単位ではない。日付が変わってもリセットされない
- 送信クォータは受信者の数で計算される
- （例）50件の受信者を持つメールを1通発信すると、クォータ計算では50とカウントされる
送信クォータは、Amazon SES Dashboardから確認できる。
アクセスレベル
SESにはアクセスレベルという概念がある。アクセスレベルには、次の2種類がある。
- サンドボックス（初期状態）
- 登録された（Verify済みの）Emailアドレスにだけ送信できる
- 送信クォータは小さい: 200通/24時間, 1通/秒
- プロダクション
- 送信先に制限なし
- 送信クォータは実績によって決定。スタート時点: 10,000通/24時間, 5通/秒
アクセスレベルをサンドボックスからプロダクションに上げるには、SESのプロダクションアクセスの申請フォームから申請する。
Suppression List機能
ISPや世の中のホストサーバは、いかに良質なメールだけを送るかに腐心している。Supressino Listは、そのことを支援するSESの仕組みで、ハードバウンスしたEmailアドレスが登録されるリスト。回復しようのないバウンスが起きた時に、該当のEmailアドレスが登録されていく。
- 登録済みアドレスへ送信を試みた時、SESへのAPI Callは成功するが、SESから外部へは送信されずに、ハードバウンスとして処理される
- このリストはアカウントを越えて共有できる
- 登録されると2週間程度残る（手動削除できる）
Suppression Listは、バウンスを起こし続けることで送信元ドメインやSESのIPアドレスプールの評判が落ちないように、保護する役割を持つ。
コンテンツフィルタリング
多くのISPやユーザがコンテンツフィルタリングを実施しているように、Amazon SESもアプリケーションから送信リクエストを受け取ると、メッセージをスキャンする。
- メールメッセージを組み立てる（assemble）
- ISPがSpamとみなさないか、HeaderとBodyをスキャンする
- SESがSpamと見なした場合、SES内の評価（Reputation）が低下する
コンテンツフィルタリングは、ウィルスやマルウェアが含まれるメッセージを検出するとブロックし、これらが送信されることを未然に防止する役割がある。
料金
- 送信リクエスト料金
- 1,000通あたり0.10USD
- 添付ファイル料金
- 0.12USD/GB
- データ転送料金
- EC2のデータ転送料金と同じで、受信は無料
- 送信は複数Tier（詳細は料金表 - Amazon EC2 | アマゾン ウェブ サービスを参照）
リージョンを越えた送信では、送信元リージョンからのリージョン間転送料金が追加でかかることに注意する。2014年10月現在、Tokyoリージョンで0.09USD/GB。
無料利用枠
EC2から直接、またはElastic BeanstalkからSESを呼び出す場合、2,000件/日のメッセージを無料で送信できる。この無料枠は利用開始から1年が過ぎても有効期限が切れない。
ただし、データ転送料金はかかることに注意。
Amazon SES利用時の注意点
- コンテンツ・送信先リストの正しい運用が必須
- BounceやComplaintの処理をしないと、送信レートを下げられたり、送信停止措置を取られたりする可能性がある
- クォリティが低い（＝Spamと判定されるメールを定常的に配信している）と送信停止措置を取られる可能性がある
- 国内モバイルキャリアの迷惑メールフィルタと相性が悪いことに注意
- モバイルキャリアの迷惑メールフィルタに引っかかると、Bounceエラーが返る
- Suppression Listに送信先アドレスが登録される
- ホワイトリストに載ったドメインからもメールを送れなくなる（ユーザ側の設定にかかわらず送れなくなる）
Amazon SES利用開始までの流れ
利用開始までの流れ
- SMTPエンドポイント用IAMユーザを作成する
- 送信元Emailアドレス/ドメインを登録する
- Emailが送信できることを確認する
- バウンス処理の実装とテストをする
- アクセスレベルをプロダクションにする申請をする
- NotificationをモニタリングしながらEmailを送信する
単一のEmailアドレスを登録する場合と、ドメインを登録する場合がある。
1-a. 送信元Emailアドレスの登録
単一のEmailアドレスを登録する流れは、次のようになる。
- SES Dashboardの左メニューから［Email Addresses］を選び、［Verify a New Email Address］ボタンを押す
- メールアドレスを入力する
- Verification Emailが、入力したメールアドレス宛に送られる
- Verification Email内のリンクをクリックするとverifyされ、登録が完了する
この作業を日本語で説明する時、「メールアドレス登録」という言葉がよく使われるが、送信元が存在することを確認するのでVerifyと呼んでいる。
1-b. 送信元ドメインの登録
- SES Dashboardの左メニューから［Domains］を選び、［Verify a New Domain］ボタンを押す
- ドメインを入力する。この時、DKIMの設定もできる
- DNS登録用のTXTレコードが表示される
- 表示されたレコードをドメインのDNSレコードに登録してしばらく待つと、登録が完了する
Amazon Route 53を使っていると非常にラク。上記の最後の手順で［Use Route 53］ボタンが表示されるので、クリックするとRoute 53にTXTレコードが作成される。SESとRoute 53は裏で連携している。
1-c. メールアドレス/ドメイン登録の注意点
- 登録はリージョンごと
- ドメインを登録するとサブドメインからもEmail送信可能になる
- ドメイン、サブドメイン、Emailアドレスを個別に登録した場合、設定はEmailアドレス、より下位のサブドメイン、ドメインの順に優先される
- ドメイン名は大文字小文字を区別しない
- AWSアカウントあたり1000個（ドメイン、Emailアドレス）登録可能
2. Emailが送信できることを確認
Management ConsoleやCLI、SDKから確認する。
$ aws ses send-email --from alice@example.com --to bob@example.com --subject Hello --text SES
3. バウンス処理の実装とテスト
メールを送信したら必ず宛先に届くとは限らないので、バウンス処理を実装する。
送信元単位で処理を登録できる。ドメインを選択して、詳細情報でNotificationの設定をする。［Edit Configuration］のボタンをクリックする。
デフォルトでは、Bounce, ComplaintのNotificationがEmailで届く。Deliveryの通知は届かない。
SNSトピックを編集すると、SNSが対応するプロトコルに通知できる。（例: HTTP, HTTPS, SQS）
SESメールボックスシミュレータ
特定のメールアドレス。宛先としてEmailを送信すると、想定されたメッセージが返ってくる。テストに利用できる。
- success@simulator.amazonses.com
- 正常配信
- bounce@simulator.amazonses.com
- Delivery Status Notification: DNSの550（ユーザ非存在）メッセージ（RFC6533）
- ooto@simulator.amazonses.com
- 不在メッセージ（RFC5436）
- complaint@simulator.amazonses.com
- 送信先がメッセージをSpamと認識して、Abuse Reporting Formatを返す（RFC6650）
- suppressionlist@simulator.amazonses.com
- SESのSuppression Listに載ったアドレスへの送信をシミュレートする
これらのアドレスへはSandboxモードでも送信できる（登録されたEmailアドレス以外に送信できない閉鎖環境からでも、送信できる）。その時のEmail送信には、次のルールが適用される。
- メトリクスに表れない
- 24時間の送信クォータにカウントされない
- 秒あたりの送信レートの制約を受ける
- データ転送料の課金はされる
4.プロダクションアクセスの申請
アクセスレベルの変更は、SESのプロダクションアクセスの申請フォームから申請する。リージョンを選択し、準備が整っていることを申告するためにチェックリストにチェックをつける。利用目的を簡潔に記載する。
5. Notificationをモニタリング
- バウンスレート（ハードバウンス数 / Email送信数）は5%未満を推奨
- Complaint（Complaints数 / Email送信数）は0.1%未満を推奨
多くのISPが上記に近い数字をチェックしているといわれている。上記の割合を守ることで、メール送信時に送信元が信頼を得ていくことができる。
メール配信の信頼性を維持するために
SMTPにおける送信元認証のための技術
- 送信元IPアドレスに基づく認証
- Sender Policy Framework (SPF), Sender ID
- 各ドメインで送信元であるべきホストのIPやドメイン名をDNSで公開する。各DNSドメインにレコードを追加するだけで開始できるのが特徴
- 送信元による署名に基づく認証
- Domain Keys Identified Mail (DKIM)
- 送信元で各メールにデジタル署名をし、公開鍵をDNSで公開する。送信者あるいは送信元サーバで対応が必要
SPFの設定例（SESの場合）
「送信元サーバの逆引き結果が *.example.com である場合に、正当な送信者であると宣言する」場合の設定例。
- 一致しないときはソフトフェイルとするとき
- example.com. TXT "v=spf1 include:amazonses.com ~all"
- example.com. SPF "v=spf1 include:amazonses.com ~all"
- 一致しないときはハードフェイル（受信側MTAに受信拒否要求）とするとき
- example.com. TXT "v=spf1 include:amazonses.com -all"
- example.com. SPF "v=spf1 include:amazonses.com -all"
ソフトフェイルかハードフェイルかを~（チルダ）と-（ハイフン）で設定し分けていることに注意する。
また、TXTレコードとSPFレコードの両方に、同じ内容を設定することが推奨されているため、上記はそのような設定になっている（RFC4408によると、SPFかTXTどちらかが定義されていれば動作する、とされている）。
DKIM有効化時のメール送受信の流れ
MTAを自前で立てる場合
MTAとDNSに必要な設定をすることで導入できる。具体的には、MTAでキーペアを管理し、DNSサーバのTXTレコードで送信元ドメインに公開鍵を設定する。
これによって、次のような流れになる。署名をつけてEmailを送信すると、receiverのサーバが公開鍵を問い合わせる。senderから公開鍵が返答されて初めて、受信が行われる。
Amazon SESを利用する場合
SES側でキーペアを管理し、CNAMEレコードでユーザドメインに公開鍵を設定する。
これによって、次のような流れになる。まず、アプリケーションからEmailを送信する。次に、SESで署名付きEmailを送信する。それから、receiverが公開鍵を問い合わせる。この時、DNSサーバは公開鍵をダイレクトに返すのではなく、CNAMEレコードを返答する。それから、receiverは引いたアドレスに公開鍵を問い合わせる。最後に、DNSサーバがTXTレコードから公開鍵を引き、返答する。
キーペアをお客さまが管理しなくてよい点が特長といえる。
SESの簡単DKIM設定機能
- Emailアドレスまたはドメインを選択する
- DKIMタブで［Generate DKIM Settings］ボタンを押して、有効化する
- 表示されたCNAMEレコードをDNSに追加する
- Route 53を利用している場合は［Use Route 53］ボタンから2クリックで済む
- Route 53でない場合は、CNAMEのレコードセットをゾーンファイルに追加する
- 設定完了の通知を待つ
Bounce処理の実装
SMTPの正常時のシグナリング
左にsender.examplecom（MTA, MUA）、右にexample.jpがあるとすると、次のようなやり取りになる。
- HELO sender.example.com ->
- <- 250 OK
- MAIL FROM: user@example.com ->
- <- 250 OK
- RCPT TP: user1@example.jp ->
- <- 250 OK
- DATA ->
- <- 354 Start
- ヘッダ、本文...<CRLF>.<CRLF> ->
- <- 250 OK
- QUIT ->
- <- 250 OK
SMTPのステータスコード
- 200番台
- 正常応答、情報提供
- 300番台
- データ入力を促す (354)
- 400番台
- 一時的なエラー（サーバシャットダウン、メールボックスbusy, メールボックス溢れ）
- 500番台
- システムエラー（コマンド間違い）、転送エラー（メールアドレスなし、処理失敗通知）
配信エラーメール
SMTPセッション時のエラーは、送信元のMTAが作成する。エンベロープの発信者メールアドレスにエラーメールが返る。（Retturn-Path or Errors-Toヘッダ）
SMTPセッション時以外のエラーは、送信先のMTAが作成する。エンベロープの発信者メールアドレスにエラーメールが返る。
ユーザが存在しないような恒久的なエラー（ハードバウンス）が発生した時は、再度送信しないように送信側で対処する必要がある。
バルク配信とバウンス処理の例（SESの場合）
（※スライド資料を参照ください。）
- キューにメールが追加される
- SESにメッセージが送信される（オレンジ矢印）
- Bounce/Complaintが発生し、バウンスが記録される（グレー矢印）
- SNSのトピックを使って通知が返るので、通知をSQSに放り込む
- キューを見て、顧客情報に今後送信しないためのフラグを立てる
- 次回は、フラグが立っている顧客情報を除いて送信する
上記を繰り返して、クリーンなリストを作っていく。
SESの配信通知
送信失敗時だけでなく、成功時にも通知を受け取る設定ができる。SESが受信者の電子メールサーバへ正常にメッセージを配信するたびに、Amazon SNSの通知を受け取ることを選択できる（Emailによる通知は、Bounce/Complaintsのみ）。
Delivery, Bounce, ComplaintsのすべてをSNSトピックへの通知を介してトラッキングできる。
- 参考情報: Sendy - Send Newsletters 100x cheaper via Amazon SES
- Email作成、SESでの配信、レポート作成をワンストップで行うパッケージソフト
- PHPとMySQL環境で動作する
- Bounce/Complaint処理に対応
送信停止措置について
次のケースでは送信停止措置が適用されることがある。
- Bounce/Complainレートが高い状態が続く
- Spamフィルタのヒットレートが高い
送信停止措置では、まずSESから警告メールが管理者アドレスに届く。「probationary status」という表現を確認。猶予期間に入る。このような通知を受け取った場合は、次のように注意深く対応する。
Probationの通知があった場合の対処方法
メールを読み、送信停止理由とProbationの間に送信可能なEmail数を確認する。n件のEmailを送信し終えるまでの間に、問題を解決せよ（さもなくば送信停止措置をとる）、と書いてある。改善を適用するまでは、代替手段でメールを配信した方がよい。
問題の原因を取り除き、効果を確認した後、改善内容を返信すること。改善方法や改善結果のアピールに不安があれば、担当営業/ソリューションアーキテクトに相談する。ただし、個別のメールがSpamフィルタに引っかかるかどうかは、AWSに聞いても案内できないので、一般的なSpamフィルタソフトで確認する。
SES以外のメール送信選択肢
AWSからのメール配信の選択肢には、次の3つがある。
- EC2上にMTAを構築して配信する
- Amazon SESを利用する
- 外部Email配信サービスを利用する（※AWS特有の手順はないため省略）
EC2上にMTAを構築して配信
SESを使わず、EC2上に自分でMTAを構築する選択には、次のような利点と注意点がある。
- 利点
- 慣れたMTA製品や既存のノウハウを活用して構築・運用できる
- 携帯キャリア向けの送信ルール適用など、柔軟な制御ができる
- 注意点
- 構築・運用・障害対策・スケール調整は自分で行う必要がある
- Email送信のための制限解除やDNS逆引きなどの申請が必要な項目がある
2つの選択肢から適切な方法を選ぶ基準
EC2上でMTAを構築するか、SESを利用するかを選ぶ基準について。
- Bounce処理を実装予定か？
- →Yes: 次へすすむ
- →No: Bounce処理は自前MTAとSESどちらの方法をとるにしても重要です。実装しましょう
- 携帯キャリアのアドレスに送信予定があるか？
- →Yes: EC2上のMTA構築を検討する
- →No: 次へすすむ
- Bounceやコンテンツの問題が多いことで、AWSに送信レートを抑制されることを受け入れられるか？
- →Yes: SESの利用を考慮する
- →No: EC2上のMTA構築も検討する
どちらにしてもバウンス処理は実装する必要がある。また、携帯キャリアのアドレスへの送信が多い場合、EC2上にMTA構築は選択肢としてあり得る。
SMTPエンドポイントを使う際の注意点
前掲のEC2からEmailを送信する際の注意点とおさらい。
外向きのTCP 25番ポートは制限対象となっている。TCP 587番ポートから、認証付きで外部サービスを利用する場合は特に制限がない。この制限は、申請によって解除できる。
EC2でMTAを構築するまで
- MTAのホスト名とIPアドレスを用意する
- ホスト名を決めて、Elastic IPを取得し、ホストのAレコードをドメインに登録する
- 制限解除と逆引きDNSの登録を申請する
- メール関連のDNS設定をする
- SPFレコード、DKIM、MXレコード（受信もする場合のみ）
構成とDNSレコードの例
（※スライド資料を参照ください。）
EC2上でのMTA構築手順の詳細を次に示す。
1. MTAのホスト名とIPアドレスを用意する
- MTAのホスト名を決める
- 例: mta1.example.com, mta2.example.com
- Elastic IPをホスト名の数だけ取得する
- DNS Aレコードを登録する
- mta1.example.com IN A {取得したElastic IP 1}>
- mta2.example.com IN A {取得したElastic IP 2}
2. 制限解除と逆引きDNSの登録を申請する
専用の「Request to Remove Email Sending Limitations」というフォームから申請する。AWSのWebサイトで、「サービスの上限緩和の申請」から「Amazon EC2 Eメール」を選択すると表示される。（要ログイン）
申請フォームには、次の事項を記入する。
- メール送信の目的
- 申請対象のElastic IP Address
- 下記で入力するホスト名とDNS正引きの結果が一致している必要がある
- EIPの逆引き結果となるべきホスト名
申請時の注意点として、英語で記入する必要がある。また、DNSの正引き結果が申請内容と一致する場合に限り、逆引き設定をしてもらえるので、先に正引きの設定を済ませた上で申請する。
3. メール関連のDNS設定をする
SPFの設定例について。
「送信元サーバの逆引き結果が *.example.com である場合に、正当な送信者であると宣言する」場合の設定例。
- 一致しないときはソフトフェイルとするとき
- example.com. TXT "v=spf1 include:example.com ~all"
- example.com. SPF "v=spf1 include:example.com ~all"
- 一致しないときはハードフェイル（受信側MTAに受信拒否要求）とするとき
- example.com. TXT "v=spf1 include:example.com -all"
- example.com. SPF "v=spf1 include:example.com -all"
SESの場合の設定と同じく、SPFレコードとTXTレコードの両方に同じ内容を設定することが推奨される。
バルク配信とバウンス処理の例（EC2の場合）
（※スライド資料を参照ください。）
- Bounceを受けた情報を顧客情報に反映する
- Complaintを管理者に通知する
- 顧客情報からBounce記録のある宛先を除いて、送信先を抽出する
まとめ
- SESは、スケーラブル・高信頼・低コストなEmail送信サービス
- メール送信の作法にのっとらないと利用停止措置があり得る
- EC2からのEmail送信も可能
Jeff Barの言葉と、信頼関係を構築していくSESのコンセプトを理解できましたか？
最後に、メール配信の仕組みを作るにあたって必ず覚えておいて欲しい重要な点が2つ。
- 受信者に価値を届けてください
- あなたのメールが欲しい人にだけ送信してください
「Happy Sending!」
参考資料
- Amazon Simple Email Service Email Sending Best Practices (White Paper)
- Amazon SES Blog
- 携帯キャリア各社からのメール送信に関する注意事項
- メールシステムのおはなし #Mailerstudy
Q＆A
- Q: USのSESチームとのやりとりに、AWSサポートが入ってくれると有り難いのですが
- A: 日本特有の事情があることは理解しています。サポート入るかどうかはともかく、担当営業や担当SAにまずはご相談ください。何か問題が起きた時は、サポート窓口に連絡してください
- Q: SESブログを日本語化してSAブログに掲載して欲しいです
- A: 過去に通常のAWSブログに日本語化した記事を載せたことがあります。今後も継続できればと思います
- Q: プロダクションアクセスの申請は、日本語で申請しても英語で起票してもらえるようですが、日本語で送っていいんでしょうか？
- A: 可能ですが、迅速に対応するにはやはり英語で送った方がよいです
- Q: EC2に逆引きの事前設定をして欲しいです
- A: 正引きはまだ本番で使っているから設定できない等の場合、個別相談でお願いします
- Q: 携帯キャリアと相性が悪い問題については、今後も対応しないのですか？
- A: 携帯キャリア対応というよりも、SESがクォリティの高いメールを送り続ける仕組みの話になってくると認識してます。クォリティ維持の仕組みは、今後も作って行く必要があります
- Q: SESは逆引き対応されてる？
- A: Yes.
感想
講師の方がめずらしく関西弁で、しかも皆既月食の進行を気にしながらの優雅な（？）Webinarタイムでした。
SESのメトリクスやエラー応答の種類について、詳しく学ぶことができました。クォリティの高いメールを送り続けて行くことで、少しずつクォータが上がっていく仕組みは、なるほどという感じですね。それから、EC2からSESを使わずに直接メール送信するパターンについても説明されていて助かりました。
SESの話から少し逸れますが、参考資料として提示された携帯キャリアにメール送信する時の注意事項のまとめを、非常に面白く読みました。こういう事情があるのですね。
今後、自前MTAの運用から解き放たれてSESを活用する機会を増やせるように、復習しておきます。
それでは、また。
