「メール到達率」に騙されるな

この記事は、[メール Advent Calendar 2018](https://qiita.com/advent-calendar/2018/mail) の20日目に書かれています。

メール配信サービスの売り文句を見てみると、多くの場合で「到達率」というキーワードが出てきます。そりゃあメールマガジンを配信する側からすればより多くの顧客にリーチしたいわけで、高い方がいいに決まっています。ところがそれらの売り文句を見ていると「到達率」という言葉のニュアンスにブレが大きいような印象を受けます。これは技術的観点とマーケティング的観点の違いによるものだったり、そもそもエラーになった原因の分析が不正確だったりすることにより生じるブレではないかと考えています。

## 大前提としてメールは基本的に届く
メール配信をする人はその到達率に目くじらを立てていると思いますが、そもそもメールはちゃんと送っていればちゃんと届きます。メールというかSMTPはRFCでそのプロトコルが定義されていて、それに沿って送れば届くようにできています。当たり前です。
じゃあ何故届かないメールというのが存在し得るのかということになりますが、それは何らかのルールや作法に反しているからということに他なりません。

## メールアドレスに誤りがあれば届かない
たまに勘違いをしてる人がいるんじゃないかという疑念を持ってるんですが、送信先のメールアドレスが「間違っていない・存在している」という大前提がなければそのメールは届きません。だって受け取る人がいないんですから。「汚い配信リスト」であっても違う「自称高到達率」を誇るサービスを使うと届くようになると思ってる人の話をたまに聞くんですが、そんなことはありません。
1000件のメールアドレスのリストに送信して、100件が`Unknown User`としてエラーが返ってきたとすると、到達率は90%となります。これを別のサーバや配信サービスを使って送ったとしてもやはり90%になります。極稀に例外も想定できますが、それはちょっと置いておきます。
この到達率を上げようとすると、エラーとなったアドレスをリストから除外して、次回は900件に対して送るようにすればよいわけです。俗に「リストのクリーニング」という作業ですね。これをせずに到達率を上げたいなんていうのは笑止千万です。
一般のユーザは移り気なもので、登録しているメールマガジンのアドレスを変更せずにメールアドレスを変えたり携帯キャリアを変えたりします。一度、`Unknown User`となったメールが別の機会に送った時に届くようになる可能性は極めて低いです。届いたとしてもメールアドレスが全く別の人に使われたりしただけという可能性の方が高いので、ガンガンリストから除外してしまった方が効率としてはよっぽど有用です。

例外的に携帯キャリア宛のメールでドメイン指定拒否の条件に当てはまってしまった場合、表向きは`Unknown User`という550エラーが返ってくる場合があります。もうちょっと正直なエラー理由を返してくれてもいいのにとは思いますが、長らくそういう仕組みなのでしょうがないのかもしれません。これはよく見かける「ドメイン指定拒否してる人は許可してね」という注意文を書いたり、そもそもの登録時のフローの中で確認メールを送ったりして一度は正常な到達性を確保しておくしかないかもしれません。

## 基礎的な事項に引っかかることがあると届かない
メールの作成に当たってはRFCに定められた様々なルールがあります。また受信サーバによって異なる閾値の制限が課されている場合があります。具体的には

- Subjectの長さ（RFC上は定義がないが長過ぎると拒否される場合がある）
- 本文の1行の長さ（RFC上は998文字がMUSTで、78文字がSHOULD）
- メール全体のコンテンツサイズ（受信サーバによる）

などです。これらはの制限は受信サーバによってまちまちで、本文の長さに対してRFCを厳格に守るサーバもあれば、緩く受け取ってくれるサーバもあります。コンテンツサイズも昔は1〜2MBが当たり前でしたが、最近は25MBとかも当たり前に受け取ってくれます。
ただどちらにせよユーザのフィーリングにも関わりますので、それぞれ適切なサイズで送信すべきでしょう。
そして「到達率の高いはずのリスト」であっても、こういった点が守られていないと突然到達率が下がる＝エラー率が上がることがあります。

## その他受信サーバの都合で届かないことがある
大手のメールサービスや携帯キャリアなどの場合はあまりないかもしれませんが、受信サーバ側の不具合や都合などによってエラーとなる場合もあります。最近だとソフトバンクがフィルタの設定をやらかして[.co.jpドメインからのメールが受信できない](https://www.softbank.jp/mobile/info/personal/important/20180917-11/)というミスをやらかしたりしています。
最近個人的にもやらかしたんですが、受信したメールのSPF判定に失敗する（DNSタイムアウトしてTXTレコードが引けない）と送信元に対して451エラーを返していました。送信元のTXTレコードのデータサイズが大きすぎてファイアウォールに蹴られていたという理由だったのでなんだかなぁという感じですが、そういうこともあります。
比較的よくある真っ当な制限のパターンでは、Fromに指定されているアドレスのドメインが存在しないと拒否したり、逆引きできないと拒否したりということがあります。大体はエンベロープFROMで判定されるので、ヘッダFROMと食い違っていても通ることはありますが、この辺りはケースバイケースですね。いずれにせよ、この手の問題は「受信サーバ側でDNSが引けなくて、結果エラーになる」というパターンがたまにありえます。

## 受信制限に引っかかることがある
そうは言ってもメルマガ担当者が知りたいのはそういうことじゃないのはわかってます。[前回](https://qiita.com/phase-d/items/d4351129973c174dd893)もちょっと書きましたがどこのメール受信サーバでも大なり小なり「受信制限」というものを設けています。これをいかに回避して効率的に送れるかというのがメール配信サービスを選ぶ時の最大のポイントのひとつと言っても過言ではありません。
ただしこれに引っからないようにするためには、そもそも配信リストをキレイに保つというユーザ側の努力が必要な部分と、適切な速度に調整しながら送信するというシステム・サービス側の努力の両面が必要です。どんなに高到達率を謳うサービスであっても、「汚いリスト」で配信を行えば一発でブロックされる可能性があります。ちょっと賢くなると、何らかのロジックで「エラーが高そうだ」と判断したら以降の配信リストをまるごと止めるということも可能かもしれませんが、それはシステム・サービス全体として到達率を保つための努力の一環です。
それから前回も触れましたが、「受信制限」が発動された際、多くの場合は421エラーが返されそのままサーバ内にメールが滞留して再送を続けます。つまり最終的にエラーとして確定するのはキュー生存時間を経過した後で、その理由としても421エラーが書かれているはずですので、エラーメールをちゃんと捕捉・分析する術があれば受信制限を喰らったかどうかはある程度判別できます。

## スパム判定に引っかかった場合はどうなるのか
さらにメルマガ担当者が知りたいポイントはここでしょう。今どきの多くのメール受信サーバは何らかのスパム対策の制限を持っています。またどの段階でその判定を下してエラーを返すのか、あるいは返さないのかは受信サーバによってまちまちです。
送信元のIPアドレスがRBLなどに載ってしまっていると、そもそものSMTP接続自体を拒否するというのは比較的よくあります。他にも様々なロジックでスパムの判定を行い、そういったソリューションを提供している各社がしのぎを削っています。
ただし抑えておきたいのは受信側・送信側それぞれから見て、どういった理由で拒否して、どういった反応を返すのかというパターンはたくさんあるでしょう。大きく分けて以下のパターンが考えられます。

- SMTP接続上で550などのエラーを返す
- SMTP接続上で450などのエラーを返す
- SMTP接続上では200を返し受信して、実際には迷惑メールフォルダなどに振り分ける

これらはサーバを管理する側のポリシー次第なので、正解も対策もあまりないかもしれません。あるドメイン宛はちゃんと届いた、別のドメインは550エラーになった、さらに別のドメイン宛は迷惑メールに振り分けられたということは起こりえます。
上の2つのパターンの場合は、送信側のサーバに対して正直にエラー理由を返してくれていればそれなりに避けるためのヒントになるかもしれません。一方、迷惑メールに振り分けられるパターンだと、実際に受信した側のメールヘッダなどに理由が書かれていないと真相は分かりづらいですし、それをどうやって確認するのかというのが難しいこともあります。
さて、到達率という観点で見た場合、上の2つはエラーとして計上されると思いますが、迷惑メールフォルダに入ったかどうかを送信側から確認する術はなく、送信は成功したものとしてカウントされるでしょう。特に迷惑メールフォルダに入れる場合、SMTP接続上でエラーを返すよりより柔軟で多彩な判定を行っている場合がほとんどです。また企業などの場合は誤判定リスクを警戒して、SMTP接続上でエラーを返すより全て受信して怪しいものには適切なフラグを立てるだけという運用をしている場合も多いと思われます。また「たまたまある時だけ特定のドメイン宛のメールがNGワードに引っかかって、迷惑メールとして振り分けられた」という事象も想定はできます。さらには某携帯キャリアがそうですが、宛先の存在しないメールであっても全て受信して後からMAILER DAEMONが返ってくるという場合もあり、送信側のログだけ見ていると正確に分析できないことさえあります。
このように統計の取り方次第ですが、迷惑メールと判定されて読まれていないメールでさえも到達率という観点では「届いている」とカウントされるシチュエーションは往々にしてありえます。

## SPFやDKIMやDMARC
よく到達率を上げるためのノウハウとして、SPFとDKIMを設定しろと書かれているのを見かけますが、そこまで決定的に有効ではないのかなと考えています。全てのメールにはSPFとDKIMとあとはDMARCが設定されるべきだとは思いますし、[Googleのガイドライン](https://support.google.com/mail/answer/81126?hl=ja)でも「送信ドメイン認証を付けないと迷惑メールとして分類される恐れがあるよ」とは言っていますが、それはメルマガの到達率を上げるためではなく、どこかの誰かが自ドメインを騙ってスパムを送信した時にそれらの判定に失敗したことを理由として正しくスパムだと判定されればいいなというのがその仕組み本旨です。巡り巡って自ドメインのレピュテーションが上がる可能性はありますが、あくまで可能性です。つけてなくても、SPFやDKIMやDMARCの判定が「None」とされても、とりあえずメール自体は届きます。
最近ではスパムメールですらSPFが定義されていてPassすることが当たり前ですし、DKIMやDMARCをちゃんと設定しているものすら見かけます。スパム用に適当なドメインを取得してしまえばいいんですから簡単ですね。なので真っ当なメール運用を目指すならばこれらの設定をちゃんとしましょう。むしろメールに関わる人のマナーや常識と言っても良いかもしれません。
それで言えば同じくGoogleはガイドラインの中で一括送信のメールは`Precedence: bulk`をヘッダにつけろと言っていますが、あまりそういうメールを見たことがありません。迷惑メール判定回避という意味では正直でよっぽど効果があると思うんですが、どうなんでしょう？
とはいえ、メールの明るい未来のためにこれらを設定するべきということには変わりません。Webの分野で「常時SSL化」が叫ばれるのと同じように、メールの分野における新しい常識と考えるべきものです。

## で、結局到達率って何なの？　どうすれば上がるの？
基本的に到達率は「（総配信数−エラー数）÷総配信数」で計算されますが、ここまで見てきたように、エラーの原因は様々です。
そもそも配信サービス側が高い到達率を謳っていて、それを信じてサービスを選ぼうとする場合、その到達率をどのように測定したのかに注意を払う必要があります。ここまでの話を踏まえて、エラー数をどう数えるかを見てみても

- 配信リストに由来してエラーとなった数
- 宛先サーバの都合によりエラーとなった数
- 受信制限に引っかかって最終的にエラーとなった数
- ドメイン認証に由来してエラーとなった数
- その他アンチスパムに引っかかってエラーとなった数

と言ったパターンが考えられます。これらに加えて、「届いてはいるけど迷惑メールとして振り分けられた数」が入りますのでさらにややこしくなります。それらの細かい具体的な理由は受信サーバによって異なってくるので、精緻な分析はなかなかに手間がかかります。
そしてもちろんユーザの使い方や本文の書き方に由来する側面もありますし、システムやサービス側に由来する側面もあります。また売り文句として到達率を使っている場合、そのサンプルをどうやって抽出したのかというのも重要になります。何より冒頭に書いたとおり、メールは基本的に届くという前提に立てば、ちゃんと送ればちゃんと届くようにだいたいできています。
重要なのは到達率の高さに一喜一憂するのではなく、エラーが発生していた際にどのようなエラーがどの程度起きていたのかを正確に分析して、次回以降にそれを低減するための努力は必要で、特にリストのメンテナンスなどユーザ側でできることは意外とあります。それをした上でシステム側に属する問題であれば、またそちらのアプローチから改善を試みればよいわけです。
サービス提供側が謳っている「到達率」を鵜呑みにするよりも、自分の運用方法で実測した「到達率」を正しく分析することが肝要なのではないです。配信サービスの中の人目線で言うと、高い到達率というか低いエラー率を維持できてるいるユーザもいれば、エラー吐きまくりなのに一向に改善する兆しがないユーザもいるので、実際のところは使い方次第なんだなぁと感じてしまいます。