大量メール送信のための予備知識 - エムスリーテックブログ

【SREチームブログリレー1回目】

お疲れ様です。エンジニアリンググループ、コアSREの山本です。

他の情報伝達手段が現れた今は「メール」は以前よりも比重は落ちたかもしれませんが、まだまだ多くの人に情報を一気に伝えるための重要なツールです。

エムスリーでは自社サーバを利用してメールの大量送信を実施していますが、メール送信を実施するにあたって気にすべき基本的な事項についてシェアさせてください。

大量メール送信に関連する基本的な設定
まとめ
We are Hiring!

大量メール送信に関連する基本的な設定

メール送信自体はそれほど難しいものではありません。エムスリーではpostfixを利用していますが、設定はほとんどオリジナルでもメール送信自体は可能です。せいぜいドメイン名を登録するくらいでもいけます。

問題は送信したメールを拒否されないかというところにあります。ここでいう「拒否」とは、実際の受信者の方々が嫌がっているという意味ではありません。受信者としてはメールが必要なのだけど、相手方メールサーバの設定などによってスパム扱いされてしまうという問題です。

基本的な設定(SPFと逆引き)

メールを拒否されないための設定として基本的なものには以下があります。

送信IPに対してSPFレコードの設定
送信IPに対してのDNSレコードの逆引きが正引きと一致

これらは有名な話で既にご存知の方が多いとは思いますが、要はメール送信元のIPについて「このドメインからメールを送るよ」という設定をDNSに実施しておくということになります。

SPFはメールのenvelope-fromのドメインのDNSのTXTレコードへの設定となります。 test@example.com というメールアドレスをヘッダFromに設定していても、envelope-fromが test@mail.example.com とするならば、SPFは mail.example.com に対して設定せねばなりません。

SPFには、DNSの参照数に限界があるという課題があります。例えば example.com ドメインのメールを Gmail、SendGrid、HENNGE、Amazon SESその他多数のメールサービスを使って送ろうとすると、それらのメールサービスが提供してくれるレコードを追加していくと徐々に参照回数が増えていきます。

support.google.com

$ dig +short txt _spf.google.com
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig +short txt _netblocks.google.com
"v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig +short txt _netblocks2.google.com
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig +short txt _netblocks3.google.com
"v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

Gmailを使うならば、上記4回レコードを引かねばなりません。include 以外にも a や existsなどでも同じくDNS参照回数を消費します。もしもSPFを正しく設定しているのにうまく動作しないならばこの部分を疑ってもよさそうです。その他255文字制限もありますが、それらを含めて各所に存在するSPFレコードのチェッカーであらかじめ確認しておくと万全です。

DKIM

DKIMは設定されていない場合もよくみます。先ほど私に届いているメールをいくつか見たところでは、日本赤十字社からの献血メールや某クレジットカード会社からのお知らせメールでは使っておりません。

参考までに、Gmailにおいてメールの宛先をクリックすると以下のような表示を見ることができます。

ここで「署名元：m3.com」というものがDKIMによる署名となります。その下にある暗号化はSMTPがTLSで行われたかどうかを示すものですのでDKIMとは関係ありません。

DKIMは非常に簡単に言えば次の形での認証となります。

事前準備

鍵ペアの生成
秘密鍵をMTA側に格納し、署名設定を実施
公開鍵をDNSに格納 (ex. hoge._domainkey.example.com のCNAMEに鍵を設置)

実際の送信時

ユーザがMTAにメールを送信
MTAは格納された秘密鍵を利用してヘッダと本文に対して電子署名を実施してから送信する(署名はDKIMヘッダとして付与)
受信サーバは受け取ったメールのDKIMヘッダを確認し、DNSサーバに公開鍵を取得しにいく
公開鍵を利用して電子署名を検証してヘッダ・本文の改ざんがないことを確認したらDKIMをパスさせる

そして、DKIMがパスしないものについてはそもそも疑わしいとして受信者に送らないなどといった措置が取られます。逆にDKIMが正しいならばそのメールの正当性は非常に高まるため、メールが受信者に到達する可能性が高まります。

エムスリーではDKIMに対応していないメール送信サーバも存在していましたが対応を進めていきました。

注意点は、このDKIMは「その送信サーバが当該公開鍵が設置されたドメインに信頼されていることは言えるが、Fromに書いてあるドメインから信頼されたかはなんとも言えない」ということです。

例えば以下のような場合があります。

From: test@example.net
送信元: mail.example.com
署名元: mail.example.jp

mail.example.jp の管理者が mail.example.com に設置された秘密鍵とペアとなる公開鍵を設置したことはわかりますが、実際に From となっている example.net とは必ずしも関係ありません。このようなものを第三者署名と呼びますしこれも有効ですが、Fromのドメインを信用しているわけではありませんのでご注意ください。

IPの追加削除

メール業界(?)では基本的な話ですが、メールを送信するIPについては各所から厳しい目が向けられています。IPレピュテーションなどと呼ばれていますが、評価がなされていない新しいIPからいきなり大量のメールを送信すると相手サーバからかなり高い確率で送信遅延(一時的に拒否して再送を求める)させられます。

さらに言えばIPがブラックリストに掲載されることもあり、そのブラックリストを参照している各種メールサーバから拒否されることになります。

有名なものが Spamhausです。このリストを参照して拒否されることがあり、相手サーバによっては明確にそれをエラーメッセージとして通知してきます。エムスリーに限らず正当に許可を得てメールを送信しているIPならば解除の依頼を投げれば解除されますが、その間は送信が拒否されてしまうため要注意です。

www.spamhaus.org

したがってゆっくりゆっくりとメール送信を開始してウォームアップした後に段々と本気を出していきます。「ゆっくりゆっくり」というのが感覚的すぎてわからないかもしれませんが、実際には相手先サーバから見たゆっくり度なので1時間3600通でも100ドメイン相手ならばゆっくりかも知れませんし、1時間60通でも一気に1サーバに送れば早すぎると言えそうです。

私はあまり厳密には見ていたわけではないのですが、最初の最初だけは1時間数100通程度の送信から開始しておりました。

メール送信で育てたIPは非常に貴重なので大事にしてあげてください。オンプレならばIPを再利用されることはなくとも、クラウドにメールサービスを置く場合には貴重なIPを手放してしまうと終わりになります。

バウンスメール処理

どうしても大量にメールを送信しているとエラーメールが戻ってくることになります。いわゆるバウンスメールですが、これを適切に処理することも必要となります。例えば存在しない宛先に対していつまでも送り続けることは相手側サーバとしては非常に無駄なことです。このような行為を続けていると送信元IPが疑わしいIPとして評価を下げてしまうこともありそうです。

バウンスメールはメールのenvelope-fromに対して戻ってきます。したがって、envelope-fromとして適切なアドレスを設定しておき、それに対して適切な処置、つまりメルマガならばその購読解除といった処理を走らせることが考えられます。

ただし、例えば一時的にメールのクォータを上回ったとか、一時的なサーバ不調などによってバウンスメールが戻ることもあります。その度にメール送信を止めてしまっていると逆に「メールが届かない」といったクレームがくる可能性もあります。したがって理想的にはバウンスメールの中身を確認しつつ恒久的なエラーと判断した時にメール送信を停止するという作戦が適切そうです。

金で解決

これらの問題は正直なところ面倒です。初期設定はまだしも、メールの送信状況を常に監視して「拒否されてないか」などをチェックします。

しかし、SendGridなどのようなマネージドなサービスを利用すれば上記をいい感じに解決してくれます。SPFもDKIMもバウンスメールも解決してくれますし、IPレピュテーションも一定保ってくれているはずです。

sendgrid.kke.co.jp

ただ、どうしても単純にサーバを用意すれば良いだけの解決策と比較すればお高くなります。お金で解決するのはそれによって得られる工数削減に見合うことも多いと思いますので、その判断ならばそれも十分ありだと思います。むしろ、次回のブログで私が書く予定のめんどくさそうな話を読んで「マネージドでいいや…」って思ってしまう人も多そうですが、うまく運用できるならば確実に安価に済ませられます。お得度は大量送信の「大量」度合いにもよると思います。