SendGridとAmazon SESを比較してみる #AWS

これはSendGrid Advent Calendar 2016の14日めの記事です。
昨日は@kikutaro_さんのSalesforceからSendGridを利用してメール送信する！でした。

SendGridエバンジェリストの@nakansukeです。今日はタイトルの通りSendGridとAmazon SESの比較をしてみたいと思います。比較と言っても価格等の公開情報や、送信前の制限解除などすぐに見つかる情報は置いておいて、サービス選定時におさえておいたほうがよい内容に絞って取り上げます。

細かな情報について、SESはBlack Beltのスライドを見るのが一番早いと思います。
SendGridは、ブログ、FAQ、ドキュメントあたりをご確認ください。

SendGridエバだからといってSESをディスろうとかそういう意図は全くありませんが、もし誤っている部分があったらコメント等いただけるとありがたいです。

では順番にいきます。

Suppression List

Suppression Listとは、もう送ってはいけないアドレスを掲載されたリストのことです。

SES

送信したメールがバウンスが発生した場合、そのアドレスはSuppression Listに掲載され、再度そのアドレスに対して送信を試みるとSESはリクエストを受け取りますが、SESからそのアドレスに対して再送せず破棄します。このとき、バウンスイベントが発生します。

また、Suppression Listはリージョンごとに用意されており、リージョン内のユーザで共有されています。
リストに掲載されたアドレスは2週間程度残りますが、手動で削除可能です。

SendGrid

SESと同様バウンスが発生した場合は、そのアドレスがSuppression Listに掲載され、再送を受け付けたときにリクエストを受理し、メールを破棄します。SESと異なりDrop(破棄)イベントが発生します。
Suppression Listはアカウント別に用意されており全て独立しています。リストからの削除は手動もしくはAPIで可能です。

また、SendGridではバウンスの他にも再度送ってはならない宛先のリストということで、Spam Reportリストや、Unsubscribedリストも管理可能です。これらも再度リクエストがあった際は自動的にDropします。

ポイント

（ハード）バウンスはメールアドレスが存在しないなど、恒久的なエラーの場合に発生するものなので、一度バウンスすると他のユーザからも送信不可能にするSESの仕組みは非常に合理的といえます。ただし、日本で使用する場合に問題になるのが携帯キャリアへ送信する場合です。

例えば、ドメイン指定拒否をしている人に対して、許可されたドメイン以外から送信すると、バウンスが発生します（挙動はキャリアによって異なります）。そうすると当然Suppression Listに掲載されてしまうので、許可されたドメインから送信していた人もSuppression Listに引っかかってしまい、送信ができなくなってしまいます。リストから削除しても、また他のドメインから送信されてしまうと、また巻添いを食らってしまいます。これがSESが携帯キャリアへの配信と相性が悪いと言われる所以だと考えています。

仕組み上相性が悪いということですね。

また、List掲載アドレスへの再送時の挙動もバウンス、Dropで異なります。SendGridもSESもバウンスや苦情が発生しまくるとアカウントを停止される危険性があります。SendGridはDropされるので気にしなくても問題ありませんが、SESの場合は送信側のDB等から削除するなど、再送を回避するための仕組みを用意する必要があります。

RFC規約違反のアドレス

携帯キャリアへの送信の話がでたのでついでにRFC規約違反の話に触れたいと思います。
細かい決まりはWikipediaを確認していただくとして、よく問題になるのが、
ローカルパートが、

ドットで始まる、もしくはドットで終わるもの
連続するドットを含むもの
( ) < >などの記号を含むもの

です。home.......(>_<)..... @example.comみたいなやつですね。（あぁ撲滅したい。。。

SES

どうも実験した限りだと、
1,2に該当するものは、Toに..abc.....def.@example.comのようなアドレスを指定してもリクエストは受付けてくれます。が、自動的に"..abc.....def."@example.comのようにないぶで変換されRFCに違反しない形に変更し送信してくれるようです。
3に該当する、(>_<)@example.comのようなアドレスはリクエストが受付けられませんでした。ダブルクォートでくくると大丈夫でした。

SendGrid

1,2はこちらにある通り受付けられますが、SESのようにダブルクォートでくくられることはなく、そのまま送られます。

現在のSendGridの仕様では、RFCに違反していないダブルクォートでくくったアドレスがInvalidになるので、3を使用したメールを送ることはできません。

大量送信の方法

SESもSendGridも送信用のエンドポイントとして、SMTPとWebAPIを用意していますが、特にSMTPの場合プロトコルの特性上連続して送信する際のオーバーヘッドが大きいので、大量のメールを送信したい場合に非常に時間がかかってしまいます。そういうときのためにSendGridは1リクエストで大量に送信するための仕組みを用意しています。

X-SMTPAPI (SMTPもしくはAPIv2でメール送信する場合に利用)

要はJSONをリクエストにくっつけて送る、ということなのですが、以下のように複数の宛先をセットすることが可能です。

{
  "to" : [
    "alice@test.com",
    "bob@test.com"
  ]
}

この場合、toに全てのアドレスをセットして送信されるのではなく、1件1件に分けてそれぞれ送信してくれます。なので、例えば、1万人に対しての送信するのに、1万リクエストしていたところ、1リクエストで済むようになります。
Toの数に上限はありますので、詳しくはこちらの記事をご確認ください。

Personalization (APIv3でメール送信する場合に利用)

仕組みはX-SMTPAPIとほぼ同じです。詳細はドキュメントを。

送信元IPアドレス

9日めの記事で固定IPアドレスと共有IPアドレスに関して説明しましたが、それぞれ以下のような形で提供しているので、特性を事前に理解しておいたほうが安全です。

SES

基本は共有IPアドレスを利用。追加オプションで固定IPアドレスを利用することが可能。固定IPアドレスを使用したい場合は、平均して1日あたり175,000通を送信しているくらいのボリュームが要求されるようです。

SendGrid

Free, Bronzeプランでは共有IPアドレス、Silverプラン以上では固定IPアドレスになります。Bronzeプランで固定IPアドレスを使用したり、Silverプランで共有IPアドレスを使うといったことはできません。

マーケティング用途

単純な通知であれば不要かもしれませんが、開封やクリックをトラッキングしたいというケースは多いと思います。その点について比較します。

SES

デフォルトでは用意されていないので、例えば開封をトラッキングしたければ、本文にトラッキング用の画像を埋め込んでそれをカウントするということが必要になります。クリックをトラッキングしたい場合や、購読/配信停止管理をしたい場合も自前で用意する必要があります。

SendGrid

開封、クリック、購読/配信停止管理は全てデフォルトで提供しています。それらの統計情報もチェック可能なので、例えばメルマガをどーんと送って、どれだけ開封されたか、クリックされたかというのを確認するのが簡単です。

まとめ

いかがだったでしょうか。
個人的にはいずれも世界をリードしているサービスですし、送信に関する能力は大差ないと思います。
ただSESは少々玄人向けというか、メール配信に関するノウハウがある程度ない場合にはハードルが高いかもしれません。当然その部分はコストの差として現れてくるので、そのあたりを考慮に入れつつ自分たちに適したサービスを選択すると良いと思います。

明日は@shibayanがサブユーザについてアツく語ってくれるそうです。ではでは。