メールを送信する話

こんにちは、IT基盤部の中村です。主に社内システムのインフラを担当しています。現在の業務内容とは少しずれてしまいますが、最近までメール系のインフラには深く携わっていたこともあり、今回はメールシステムについてお話します。

今どきSMTPなどレガシーな話かもしれませんね。しかしながら良くも悪くも枯れたSMTPはインターネット基盤の根底に位置する息の長い技術でもあります。きっとみんなまだ使ってるはずなのに、あまりノウハウが出回っていないのが辛いと感じているそこの担当者の方、よろしければ少しの間お付き合いください。

サービスでのメールの利用用途

我々がサービスとしてメールを取り扱うとき、その主だった利用用途は下記の2つです。

メールマガジンなどの情報発信
入会・ユーザ登録時などのユーザ存在確認

メールマガジンはユーザーに情報を新たに届けたり、あらたに弊社の別のサービスに触れて頂く機会を提供するために送信されています。こちらは単位時間あたりの送信量も送信時間もコントロールが可能ですし、宛先不明メールなどの送信不能メールを予めクリーニングを実施した上で送信できます。

逆に入会系のメールは、とあるゲームやサービスがリリースした直後に爆発的に急増します。こちらは時間帯のコントロールができない上に、流量についてもある程度の予測をしたところでそれを上回ってくる事が多く、さらにユーザ登録時のメールアドレス間違いなどで一定数の宛先不明メールも発生します。

これらのメールを確実に（できるだけ）早く先方に届けることがシステム上の命題となります。

特に「入会・ユーザ登録」は大事な顧客獲得のチャンスでもあり、インフラの問題でメールが届かないなんてことは可能な限り避けなければなりません。

今回は、世界に向けて発信したサービスの導入時に発生した、ユーザ登録のメールを相手に届けるにあたって検討・設定したことについてお話したいと思います。

クラウド化に向けて

閑話休題ですが、これらの仕組みをクラウドに持っていくにあたってはAWSのSESなどのマネージドサービスを検討しました。残念ながら、既存のメール配信のマネージドサービスは、突発的に大量にメールを送信する可能性がある弊社の環境とは相性が良くありませんでした。逆に、大量のメールを定期的に送信するような環境であれば積極的に利用すべきです。

我々の場合は、クラウド上に自前でメールサーバを構築し、運用するという選択をしました。

メールを送信するということ

メールを送信する。ということは当然受信する相手がいるわけです。いくらこちらからメールを送り付けたところで、受信者側の対応如何でこちらからのメールは一方的に破棄されてしまいます。受信者側の対策は世の中には公開されていません。どうすれば100％相手に到達するかといったノウハウは受信側からは提供されません。

受信側はおそらく送り手側が怪しいメールの送信者でないかという観点で受信したメールを受け入れるべきか判断しているはずです。送信元としてはそれが正しく自分たちの送出したメールであり、さらに迷惑メールを送信するようなサーバではないことを証明し続けるほかありません。

送信ドメイン認証

自らの出自を明らかにするための方法として送信ドメイン認証という考え方があります。細かい説明はもっと詳しいサイトがあるのでそちらに譲りますが、要するに送信者のアドレスが正規なものであることを証明する技術です。 SPF / DKIM / DMARC などがあります。設定の優先度はSPF＞DMARC＞DKIMの順でしょうか（DMARCはDKIMの設定を実施していなくても設定できます）。

サービス開始当初はSPFとDKIMのみ設定していましたが、一部のフリーメールでは、どちらも正しく設定されているのにスパム判定されてしまいました。 DMARCを投入することで問題なく受け入れてもらえるようになりました（DMARCの投入にはそれなりに面倒がありましたが、それはまたの機会に）。

レピュテーションへの対策

レピュテーションは送信元メールサーバのIPアドレスの「評判」です。行儀の悪いメールサーバの評判は悪くなり、逆に正しく振る舞うほどに評価は上昇します。評価が悪くなっていく状況を我々はよくIPアドレスが「汚れる」と言っています。 IPアドレスが汚れれば汚れるほど、そこからやってくるメールは、受信側に受け取ってもらえない可能性が高まります。

評判を公表しているサイト

いくつかのベンダーがIPアドレスのレピュテーションを公開してくれています。これが全てではありませんが、我々は以下のようなサイトを参考にしています。 AWSでEIPをとったタイミングでこれらのサイトで検索してみると、近い過去にメールサーバとして使われていたかどうかなどがわかる場合もあります。

SenderScore.org (Return Path)
Senderbase.org (Cisco)
BarracudaCentral (Barracuda Networks)

DNSBLの監視

最も端的にIPアドレスが汚れているか判断できるのはDNSBLだと思います。いわゆるブラックリストです。これに登録されてしまうと、即座にブロックが始まるので、できれば迅速に対応したいところです。どれだけ手厚くみていても、たった一通のバウンスメールで登録されてしまうこともあります。油断は禁物です。

複数のブラックリスト検索には一覧検索に優れたサイトを使います。現状を知るには良い方法です。

MultiRBL

影響度が大きいと思われるブラックリストは個別に監視して、登録され次第リストからの消去などのアクションを起こすようにします。他にもいくつか見ていますが、主に下記あたりは注視しておいたほうがよいです。

それでも問題は起きる

とまあこれだけ対策しても、大量にメールを送信すると問題は発生します。

メール送信が始まってものの１０分ほどでとあるドメイン宛のメールがすべて遅延するようになりました。

おそらく単位時間あたりの流量や、それまでのメール送信元サーバのIPアドレスからのメール到達の実績との差異などがトリガーとなっているのだと思われます。普段はほとんどメール送信がないメールサーバからいきなり大量にメールが送信されると、その挙動そのものが怪しげなものに見えるようです（先述の通り、こちらからするとこれはこれで正しい挙動なのですが）。一定の期間後メールは受信してもらえるのですが、この遅延は入会へのモチベーションに対しては致命的です。

暖気

確証は有りませんでしたが、通常時のメール流量が殆どないメールサーバーからの送信が怪しいのであれば、最初から少しは流しておけばいいと考えました。特に流量による制御を実施していると思われるフリーメールに対しては、だいたいサービスリリースの２週間くらい前からメールを定期的に送信しておくようにしました。我々はメールサーバの暖気と呼んでます。実際こちらを実施することにより、長期間のメールのブロックはかなり減りました。