JAWS-UG京王線でメールサービスについて発表しました(SES, SendGrid, Mandrill, etc.)

JAWS-UG京王線でメールサービスについて発表しました(SES, SendGrid, Mandrill, etc.)

SendGridエバンジェリストの中井です。
JAWS-UG京王線第一回勉強会にコアメンバーとして参加し、メールサービスについて発表しました。
勉強会の様子については主催者のまてつさんが紹介してくださっているので、私は自分の発表内容の紹介をしたいと思います。

必ず必要になること

自分でMTAをたてようが、何らかのサービスを使おうが、メールを送る際には色々と気をつけなければならないことがあります。
その中でも以下の2つは特に重要です。

  • 送信ドメイン認証(SPF/DKIM)
  • バウンスメールの対処

送信ドメイン認証

メールサーバのセットアップや、DNSの設定をしたことがある方であればSPFを聞いたことが有るかもしれません。これは、送信元のドメインが正規のものである、なりすましでは無いことを証明するための技術です。

その仕組は、

  • 送信元ドメインのDNSに、送信に利用するホストのIPアドレスを予め登録しておく
  • 受信側のサーバは、メールを受け取る前に、そのレコードを参照して送信元のIPアドレスがきちんと登録されているかを確認する

というものです。
送信ドメイン認証のイメージ図
これにより送信元をなりすましている場合は受け取らない、という動作が可能になります。

DKIMはIPアドレスではなく電子署名を利用します。送信元ドメインのDNSに公開鍵を登録しておき、ヘッダに電子署名をつけることで、送信元の正当性を検証します。
ご自身が受け取ったメールのヘッダを見てみると、送信元はどんな設定になっているか確認することができます。

メールヘッダの例

メールヘッダの例(SPFもDKIMも正常に設定済み)

バウンスメールの対処

送信ドメイン認証は送信する前の準備段階で必要になることですが、バウンスメールの対処は日々の運用時に対応すべき内容です。

多くの場合メールがバウンスするのは、

  • メールアドレスに誤りがある
  • 既に存在しないメールアドレスである

といった場合ですが、そのアドレスに対しては以降は送信しないという対処が必要になります。

迷惑メール業者がどのように送信しているか想像してみてください、購入した宛先リストや何らかの方法を利用して入手した宛先に対し大量に送信します。そういった場合、存在しないアドレスを多く含んでいるため、バウンスが多数発生します。
もしバウンスメールの対処をきちんと行っていないとどうなるでしょうか?受信する側から見ると悪質な送信者と同じような振る舞いに見えてしまいます。最悪の場合ブラックリストに入れられてしまい以降メールを送り届けることが不可能になることもあります。
そのためバウンスメールの対処が必要になるのです。

AWSから送信する場合どんな方法があるか

今回の発表では自分でメールサーバをたてる場合は置いておいて、メール配信サービスに注目し、どんなサービスがあるか、どんな差があるか、をご説明しました。

SES, SendGrid, Mandrill

AWSのメール配信サービスであるSimple Email Service(SES)および、その他の代表的なメール配信サービスとしてSendGridとMandrillを紹介しました。
それぞれの特徴はスライドを確認していただくとして、簡単に違いをまとめると以下のようになります。
【SES】
メールの送信までのセットアップは容易であるが、バウンスメールの対処や開封/クリックトラッキングを実現するためには作りこみが必要になる
【SendGrid, Mandrill】
トラッキングも含め、メール周りでよく必要となる機能が予め用意されている

選択のポイント

今回比較するにあたってそれぞれのサービスで実際にメールを送信してみましたが、いずれのサービスもセットアップが容易であっという間にメールが送信できるようになりました(当然送信ドメイン認証までの設定もやりました)。
あとはそこからどれくらい楽をしたいか、どこまでの機能を必要としているかといったところが選択のポイントになると思います。
例えば、行動分析をしてメールマーケティングを積極的に進めていきたいのでSendGridを選択するという場合や、分析は不要でとにかく安く大量に送りたいのでSESを選択するといった場合もあるでしょう。
用途、要件を事前にしっかりと整理し、それを満たすのに最適なサービスを選択しましょう。
しかし既にその機能が用意されていたとしても先に述べた対策については考えておく必要があります。メンテナンスにかけられるコスト、利用者の理解度、そのあたりから総合的に判断してご自身の環境にあった方法をお選びください。
もちろん今回取り上げたサービスはいずれもクラウドなので、送信量が増えていってもスケールしていくので安心です。

HAPPY SENDING!!

参考