『良いメール』とは？ 「届かない」とユーザーに言われたときに考えること

こんにちは、シェルフィーのエンジニア、@kasumidyaya です。

私が所属するCREチームでは、弊サービスのユーザーから日々寄せていただくお問い合わせから、テクニカルな調査やサポート業務、サービス体験向上のための機能改善といった業務をしています。

本記事は、システムやサービスから送信されるメールがユーザーから「届いてません」と言われた際に考えることや私の実務上で実際に得た経験則を交え、対応の一例としてまとめたものです。

メールの配信技術の分野は歴史が深く、自分もエンジニアとして浅慮な部分がまだまだあるので指摘ポイントがあればお手柔らかにお願いします。

また、弊サービスからのメール配信にはAmazon SES（Simple Email Service）を利用しているため、この記事ではSES活用時における事例や対応例を記載しています。

この記事で伝えたいこと

記事の内容はおおよそ以下のことが伝われば良いなと思って書いています。

• メールが届かない場合に原因として考えること
• メールがバウンスされた際のSESの振る舞い
• メールサービスの思想から考える、『良いメール』とは

ユーザーから「メールが届かない」と言われたら

弊社のサービスである Greenfile.work（グリーンファイルドットワーク）も、日々ユーザーにメールが配信されています。波はありますが、この記事公開時点では 20,000−25,000件/日 前後の配信ペースで、ユーザーがアクティブだとピーク時は1時間あたり4,500件ほどのボリュームです。建設業界向けのBtoBという特性もあり、祝休日はほとんどメールは配信されません。

そういった背景もあり、ユーザーから「システムからメールが届かない」といった問い合わせを受けることがありました。

問い合わせ内容を確認すると、その後にユーザー側でのアクションで解決したケースの代表的なものとして以下のような例がありました。

• 迷惑メールボックスに入っていた
• ユーザーの会社セキュリティによって弾かれていた
• ユーザーの利用端末のセキュリティによって弾かれていた

たかがメール、されどメール

Greenfile.workのユーザーから実際に寄せられた中で対応リソースが大きかったのは、思い返すとユーザー企業のセキュリティで弾かれているケースだったと思います。

というのも、こちらからはメールが送信されているだろうことを確認しているものの、引き続きユーザーは受信できていないとなると、サポート応対のラリーも増えユーザーのストレスも増えてしまいます。

しかしユーザーの多くは一般社員かつ、弊社の顧客の多くはゼネコン（建設業界内の大手企業）のため社内セキュリティが厳しいかつ、セキュリティ部門がしっかりと独立してる企業がほとんどですので、ユーザーの方はまさか自社内のセキュリティが関係してるとはなかなか思い至りません。

私達も全力でサポートに努めますが、先方企業のセキュリティ都合が想定された場合はこちらで出来ることは限られているため、ユーザーを通じて先方のセキュリティ担当の方とテクニカルな対応を相談させてもらったこともあります。

Greenfile.workは業界構造も相まって、ゼネコンから協力会社へサービスへ招待したり、逆に協力会社の操作によってゼネコンが通知メールを受け取るシーンも多く、メールを起点としてサービス上での操作を促すことが多いためメールの受信可否はユーザーオンボーディングの成功率にも関わってくるので問い合わせ内容としてはヒヤヒヤする一例です。

一方で、上記のような確認を取ってもらっても受信できないケースもありました。

メールがバウンスされてしまっている

こういったなぜか届かないといったケースの場合、メールがバウンスされている可能性を考えます。バウンスメールにはソフトバウンスとハードバウンスがあり、SESではそれぞれの状況によって再送信する・しないの振る舞いに違いがあります。

ソフトバウンス

一時的な理由によるメール配信の障害。

• 受信者のメール受信ボックスの容量がいっぱいだった
• 送信メールのデータ容量が大きく、受信者が受け取れなかった
• 受信者との通信で接続がタイムアウトした（メールサーバーが落ちていた）等

→SESは複数回、再送信を施行する。それでも配信できない場合は配信を停止。

ハードバウンス

永続的な理由によるメール配信の障害。

• メールアドレスが存在しない、ドメインが実在しない
• メールプロバイダーに迷惑メール・スパムと判断された
• 受信者が受信拒否をしている

→再送信を施行しない。　※DNSルックアップの失敗を除く

Amazon SES における E メール配信可能性の概要 - Amazon Simple Email Service
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-concepts-deliverability.html#send-email-concepts-deliverability-understanding

苦情（Complaints）

SESは、ハードバウンスにあたるスパムや迷惑メールなど、受信者にメール受信をリクエストされなかった率を重視しています。これはバウンス率とは別に、苦情率として分けられています。

SESのQ&Aページでもかなり厚めな解説がされており、監視対象としての重要さが伺えます。

Amazon SES 送信レビュープロセスに関するよくある質問 - Amazon Simple Email Service
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/faqs-enforcement.html#e-faq-cm

メールがバウンスされた後にSESは何を行うか

SESの場合、再配信を施行したものの配信がいずれかの理由で失敗したメールアドレスは、バウンスのケースに応じたサプレッションリストに登録されます。

サプレッションリスト

サプレッションリストは、いわば「このメールアドレスには送りませんリスト」です。

システムからの操作でメール送信が送信されているはずなのに受信が確認できない……といった場合、これらのリストにアドレスが登録されている可能性があります。

サプレッションリストには主に3つのタイプが設定されています。

グローバルリスト

グローバルリストは、SESの全ユーザー間で共有されるリストです。
グローバルリストへは、ハードバウンスの判定がされたアドレスが対象になります。

SES内部で保有されアドレスの評価が保護されているため、AWSユーザーである私たちは確認や削除といった操作も行えず、無視もできません。

つまり、SESによって配信された世の中のいずれかのサービスによってハードバウンスされたアドレスの評価をSESは共有してくれています。そのアドレスが1回だけハードバウンスを起こした程度なら、グローバルからは短期間で自動的に削除されるようです。ただ、リストに残ってる状態でさらにどこかでハードバウンスが確認されると期間が延び、最大で14日は残るようです。

アカウントレベル

アカウントレベルのリストは、私たち独自のリストが構築、適用されます。
このリストへはバウンスと苦情の判定がされたアドレスが登録されるデフォルトのリストになります。なので、ユーザーからメールが届かないと寄せられたらまず確認すべきリストです。

このリストへは追加も削除も行えるため、SESのコンソール上にインターフェイスが用意されています。また、SES APIも用意されているため、一括登録などはコードを書いて実行することもできます。

このリストにアドレスがあることで配信が停止されている場合、90日後に自動的に削除されます。ただし、その状況下でメールの配信に成功すると、アカウントレベルのリストからは削除されないようです。

ただ、SES的にはこのコンソール上での調査業務をあえて考慮していないのか、リスト内を検索するといったUIは用意されていません😇
私たちの例でいうと、特定ユーザーのメールアドレスが登録されているかを調べるには、スクリプトを使って有無を確認します。

小ネタですが、Gmailにある「迷惑メールを報告」ボタンからスパム扱いを受けても、SESへは評価として届かないそうです。あくまでGmail内で評価と処理が完結しているようで、ユーザーには優しいですがサービス提供者としてはバウンス率などの指標に現れないのは少々悩ましいですね。

• Gmail では、SES に苦情データが提供されません。受取人が Gmail ウェブクライアントの [Spam] (スパム) ボタンを使用して、受信したメールを迷惑メールとして報告した場合、アカウントレベルのサプレッションリストには追加されません。

Amazon SES アカウントレベルのサプレッションリストの使用 - Amazon Simple Email Service
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/sending-email-suppression-list.html

設定セットレベル

設定セットは、条件に応じた制御・抑制を行えます。これは、アカウントレベルのサプレッションリストへ上書きするかたちを取ります。例えばアカウントレベルのリストへはバウンスも苦情も登録されますが、設定セットで定義した特定のメールの条件に該当した場合の苦情を受けたアドレスのみ、アカウントレベルのリストに追加する…..といったことも出来るようです。

弊社では正直なところ、設定セットを駆使した細かな制御まで運用が追いついていません。
個人的にも関心が高い部分なので、有識者の方いればユースケースなどもらえると嬉しいです<(_ _)>

設定セットレベルの抑制を使用してアカウントレベルのサプレッションリストを上書きする - Amazon Simple Email Service

サプレッションリスト毎に振る舞いに細かな違いがあるので、より詳細なことは公式のドキュメントを読むことをおすすめします。

Amazon SES グローバルサプレッションリスト - Amazon Simple Email Service

「メールが届かない」が続くとどうなるか

さて、どうやらSESはメールの配信に失敗するとサプレッションリストに登録されるぞ、というのはわかりました。では、これに気をかけずユーザーにメールが配信されない状況が続くとどうなるでしょうか。

アカウントレベルのサプレッションリストはあくまでSESのユーザー独自のリストなので、極端な話いくら登録されてもSES的には不都合はありません。気にすべき点は、ハードバウンスされグローバルリストに登録されるケースが多発した場合です。

サプレッションリストのバウンスは、アカウントのバウンス率に反映されます。バウンス率が高すぎる場合、当社はお客様のアカウントを確認し、アカウントの E メール送信機能を一時停止することがあります。

Amazon SES グローバルサプレッションリスト - Amazon Simple Email Service
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/sending-email-global-suppression-list.html

そう、SESから悪い評価を受け、最悪の場合メールがユーザーへ送られなくなります！

評価メトリクス

SESに限った話ではありませんが、SESはメールの配信プログラムの成功率を重要視しています。そのため、SESのダッシュボードにもわかりやすく直近1週間のバウンス率、苦情率のグラフが設置されていますね。

また、バウンス率と苦情率を元に、使用しているSESアカウントのステータスが評価されています。

• 正常 - アカウントに影響なし
• レビュー中
  • 何らかの理由でSESに審査対象とされた。レビュー期間中に評価メトリクスが正常値に抑える対応が必要
• 一時停止
  • バウンス率や苦情率が高すぎ、メールが配信されない状態。対応を行った後にリクエストが必要。
  • バウンス率: 10%以上を超えた場合
  • **苦情率: 0.1%**を超えた場合

弊社では幸い、正常以外のステータスを確認したことはありません。

ですが、ユーザーの増加や施策の変更等なにが理由でバウンス率がスパイクするかはなかなか予想が難しいため、定期的な監視を怠りたくないものです。

メール配信成功率の測定指標と信頼性の評価

私の調べた限りではありますが、一般的にはバウンス率は2％〜5%以下が健全だそうで、メールマガジンなどマーケティング系の配信であれば、10％以下が良いとされているようです。

SESではガイドラインとして、ハードバウンス率は5％未満を推奨しています。
ちなみにOracleでは以下のようなバウンス率を推奨していました。

• ハード・バウンス・レート: 2%
• 総合バウンス・レート(ソフトとハード): 5%
• スパムの苦情: 0.2%

バウンスについて - Oracle Eloqua Help Center

https://docs.oracle.com/cloud/latest/related-docs/OMCAE/Help/Deliverability/Bounces.htm

SES自身も、メールプロバイダーからの信頼性の評価をとても重視しています。
一定以上のバウンス率や苦情率が高いとSESがメール配信を停止してしまうのも、プロバイダーからの信頼性を損ないたくないので、「僕（SES）はプロバイダーから信頼を獲得するのに頑張ってるから、君（SESユーザー）も僕からの信頼を得られるように頑張ってね」ということを言ってます。

このあたりはSESが「良いメール配信とは」といったことをまとめているので、以下のセクションで触れたいと思います。

良いメール配信とは、を解く

メール配信における大きな問題のひとつは　「いかにスパム扱いされないか」 だと思います。

受信者がスパム扱いしてしまう理由は予測しきれませんが、メールの量や受信間隔、コンテンツの品質や見やすさなどいろいろな軸があると思います。とくに、メールの件名は最初に目に付く要素だったり、受信者が件名でフィルターをかけてるかもしれないので簡単に変更をかけづらいケースもあったりと、地味に頭を捻るポイントかと思います。

メール内容が受信者にとって価値を感じられるように努力するのは私達の責務ですが、SESを始めとしたメール配信サービスの提供者、メールクライアントサービスの提供者それぞれ情報を発信しているので、各社が説く「良いメール」とはなんだろうかを考えてみます。

SESが説く『メール配信可能性』

SESは『Amazon SES における E メール配信可能性の概要』 という、いかにメールがきちんと届く可能性を最大化させるかといいう開発者向けのガイドを公開しています。

出典：Amazon SES における E メール配信可能性の概要 - Amazon Simple Email Service
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-concepts-deliverability.html

メール配信問題の理解 - 積極的な対応 - 継続的な情報の入手 - メール送信プログラムの向上

上記のサイクルを回しましょう、というのがSESの提起内容です。

SESが提供するシステムはこのサイクルに則った様々なツールが用意され、活用出来るようになっていますが、SESユーザーでなくとも大切な概念だと思います。

SESの考えとしては、上記でも書いたように「受信者やプロバイダーからの信頼を得続けよ」という思想を根底ににサービスが提供されているのだと思います。
ガイドとして展開されている内容は「いかにメール配信可能性を維持し続けるか」といったシステマチックなロジックには受け取れますが、信頼を得続ける、または落とさない為のサービスやツールを提供してくれているなと感じます。

Google発表の『メール送信者のガイドライン』

Googleは今年2月に メール送信者のガイドライン の内容を適応する旨の発表がありました。
これがきっかけで、メールを配信する機能をもったサービス各社はSPFやDKIM、DMARCの対応に奔走したのは記憶に新しいと思います。このガイドラインに主旨のひとつは、メール配信者への認証強化の催促だと思われます。

その中でも、特に『購読の要件とガイドライン』には以下の説明がありました。

簡単に登録できるようにする

配信を承諾している受信者のみに送信するには:

• 受信者がメールの配信を許可していることを確認します。
• 受信者の登録を行う前に、各受信者のメールアドレスを確認します。
• 定期的にメールを送信して、受信者が登録の継続を希望するかどうかを確認します。
• あなたからのメールを開封していない、あるいは読んでいないユーザーについては、配信登録を解除することを検討します。

簡単に登録解除できるようにする

受信者がいつでも簡単にメールの配信登録を解除できる方法を提供してください。ユーザーがメールの受信を停止できるようにすることで、開封率、クリック率、送信効率を上げることができます。

これは、Gmailの機能に「メーリングリストの登録解除」という機能があり、「簡単に登録解除できるようにする」を実現した機能です。

これは、メールヘッダに List-Unsubscribe と List-Unsubscribe-Post の2つで構成されたヘッダーがあるとで、Gmail上に以下のように メーリングリストの登録解除 というリンクが表示されます。

Gmailが、ユーザーのメール購読体験を重視していることの象徴のような機能ですね。
近年は、メール自体に「購読を解除する」といったリンクからワンクリック程度で直ぐにメールの配信をキャンセルできる配慮がされたメールが増えていると思います。
むしろ、メルマガ程度であればキャンセルにログインを必要とするのは少々嫌厭されるようになってきたと感じます笑

サービス提供者が考えるべき、メール配信の体験

ここまでいろいろなガイドやドキュメントを読んでみて、SES、Gmailはサービス提供者に良いヒントを与えてくれていると感じました。
良いメールとはあらためて、受信者が価値に感じ、購読体験を損なわないメールだと思います。

ただ、メール内容などを考えるのはエンジニアではない場合もあると思います。自分がエンジニアで内容に携わっておらずとも、どんな内容のメールがどのくらいの頻度やタイミングで配信されるかを確認し、バウンスバウンス率やスパムと判定されてしまうリスクを考慮した上で実装に臨みたいと引き続き思います。
私もいくつかのメルマガや通知メールを、サービスのユーザーでなくても好んで受信されるよう登録していたりします。他社サービスのメール配信を学んで、良いところや体験が悪いと感じた点は、常に頭の片隅で経験をストックして自分の関わるサービスへ活かしたいと考えています。

ここまで読んでいただきありがとうございました。