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

Amazon SES

コンニチハ、千葉です。

AWSを利用していて、メール送信機能が必要な場合、SESを検討するかと思います。ただし、SESを利用する時はキャリアとの相性がよくないという記事を目にするので、実際のところどうなの?とういアンサーです。

キャリアへメールがそもそも送れないの?

そんなことはありません。私の環境から、自分の携帯にメールを送ってみましたが問題なく届きました。 では相性が悪いというところはどこになるのでしょか?

SESからキャリアメールへ送信するときの検討ポイント

SESを利用する場合、バウンス率と苦情率を管理し、低く保ち続けることを利用者側に求められます。そのため、存在していないメールアドレスがある場合は、送信対象から外すなど、継続的に監視し対策していく必要があります。

ここでポイントなのですが、携帯端末や通信キャリア側メールサーバでは、スパム対策を含めたフィルタリングの仕様は非公開となります。そのため、受信側メールアカウントが存在しないのか、フィルタでバウンスが発生しているのか区別が難しく原因調査も非常に難しくなります。バウンス率と苦情率を低く保つための対策がとりずらい、というところになります。

AWSでのメール送信の方式

SESとEC2を利用する方法がありますが、いくつか種類があります。どのような違いがあるのか整理してみました。

SES(共有IP)

SESをデフォルトで利用する場合は、AWS側で持っているIPを共有してメール送信する形になります。

  • IPのレピュテーション:AWS側でIPアドレスをプールしており、AWSにてIPの評価を高く保つようにしています。ただし、IPアドレスは共有されるので他の利用者の利用方法に影響される可能性があります。
  • バウンス率、苦情率:率が高くなるとAWSから連絡が来て、理由と改善策を提示する必要があります。依頼を無視し、改善されない場合は、停止措置の可能性もあります。逆にちゃんとしたがって改善していくことで、スパム扱いされる可能性が減ります。

SES(Dedicated IP)

Dedicated IPを取得し、専用IPでメール送信できます。また、複数IPを取得しプールとして利用することもできます。

  • IPのレピュテーション:ユーザー専用のIPのため、ユーザー側で管理する必要があります。現在は45日かけて自動でウォームアップされるようになっています。
  • バウンス率、苦情率:率が高くなるとAWSから連絡が来て、理由と改善策を提示する必要があります。依頼を無視し、改善されない場合は、停止措置の可能性もあります。逆にちゃんとしたがって改善していくことで、スパム扱いされる可能性が減ります。
  • メリット:同じIPアドレスから大量のメール送信を行う場合、キャリア側でブロックされる可能性があります。Dedicated IPを利用することで専有できるため他の利用者の影響を受けなくなります。また、1IPでは足りない場合はIPアドレスを複数取得し利用できます。
  • デメリット:SESの共有IPと比較した場合ですが、IPレピュテーションの管理をユーザー側で行う必要がります。

EC2 + EIP + MTA

EC2を起動し、ミドルをインストールし自分で構築し、自分で管理します。

  • IPのレピュテーション:完全にユーザーで管理する必要があります。
  • バウンス率、苦情率:完全にユーザーで管理する必要があります。
  • 冗長化を行ったり、脆弱性管理、OS管理が追加で必要になります。

対策

では、SESを利用しキャリアへメール送信したい場合、どういう対策が必要そうかを検討してみます。

  • キャリア独自のスパムフィルタがあり、同じIPアドレスから大量に送った場合はスパムとして登録されるリスクがあります。こちらはSESでも、Dedicated IPを利用することでEC2 + EIPを利用したあ場合と同じ状況にすることが可能です。
  • SESを利用する場合はバウンス、苦情をどれだけ低くできるか、低く保つ必要があります。停止措置もありえるので気をつける必要があります。逆にウォッチし改善できるため クリーンなメール送信を行うことができます。
  • キャリアではRFCに従っていないメールアドレスが現在定義可能なため、SESで送信できない可能性があります。またフィルタも非公開な仕様となります。どういうメールアドレスへ送信するかによって変わるのでテストを行い評価が必要になります。
  • SESを利用できなかった場合の代替として、EC2 + EIP + MTAを事前に用意し切り替えるようにしておくことを考えます。
  • SendGridなどの別サービスを検討します

最後に

対象としているユーザーのスコープや、システムの規模にもよるので、一度SESを検討するのもいいのかなと思います。移行の場合は検証できるのであれば、検証できるのが吉かなと。

参考

AWS Cloud Roadshow 2017 福岡