こんにちは。ATOM事業部エンジニアの和田です。
直近でAmazon SESを利用した機能実装を行いました。
SESを利用するにあたり色々と考慮したことがありましたので、どのようなことを考えて対応したのかを書いていければと思います。
Amazon SESとは
Amazon SESとは、AWSが提供するメール配信サービスです。
メール配信サービスとして初期は最低限の機能で提供されていました。
他メール配信サービスでは提供されているバウンス管理の機能が存在しない等ありましたので、一部自力実装を行う必要のある部分もありましたが、
サプレッションリストの機能拡充等により単独でもミニマム構成を作成して運用したい場合にも使いやすくなってきています。
利用するにあたる考慮事項
迷惑メール扱いされないための対応
SESを利用する場合、ミニマム構築や検証の際はEメールアドレスによる認証を行い、実装を進めていくことになると思います。 ドメイン認証に切り替えた場合にDKIM鍵設定を忘れてしまうと、一部のメールサービスで迷惑メール扱いされてしまうことがありますので必ずDKIM鍵を設定しましょう。
DKIM鍵の設定については、清水さんが書かれたブログ記事があるので、こちらで詳細に確認いただけたらと思います。
バウンスレート管理
SESではバウンスレートがしきい値を超えると、メール送信が制限されることがあります。
このバウンスレート管理の問題については、以前から様々なブログ等で言及されていると思います。
バウンスレートの上昇により送信制限がかかる範囲は対象のアカウントで利用しているSES全体となるため、１つのアカウントで複数のSESの送信を行っている場合はそのアカウントで行っている全てのメール送信に対して影響が出てしまうことも。そのためバウンスレートは特に重要視されると思います。
アカウントレベルのサプレッションリストが実装される前は、バウンスが起きた送信先アドレスに対してメールを送信しないようメールアドレスと送信結果を利用者側で管理する必要がありました。
この処理が必要というところから、以前はAWSを使っていてもSES使わず別のメール配信サービスを使うことでミニマム実装していたこともあるのではないでしょうか？ (私は以前ありました
現在はアカウントレベルのサプレッションリストがデフォルトで有効になっているため、有効にしておけば90日間はバウンスが１度起きたアドレスに対してメールを再度送信してしまうことはありません。
管理としても、アプリケーション側で管理する必要がないため、ミニマム実装としては最適だと思います。
基本的にアカウントレベルのサプレッションリストは有効にしておき、90日越えたアドレスも管理したい等厳密に管理したい場合はSNSを利用しつつ、自力実装するほうが良いのかなと思っています。
開発環境での運用について
開発環境でSESを利用する場合、SESはサンドボックスで利用するのが理想かと思いますがサンドボックスから出しておくことも管理方法によっては視野にいれるかと思います。
サンドボックスから出して開発環境を運用する際は、こちらもバウンスレートの考慮をする必要があります。
バウンスレートの上昇を抑えるためにもメールの送信先に対して、必要に応じてIAMで制限をかける等の対策をすることをお勧めしたいなと思います。
まとめ
ということで、３点の特に考慮すべき点について書いてみました。
わりと当たり前のようなこともあるかもしれませんが、当たり前なことこそどこにも記載されていなかったりとかあるので改めて。
SO TechnologiesではAWSを活用しながら開発したいエンジニアを募集しています。
