メールアドレスにも寿命がある。
〜メールアドレスではなく、「メールアドレスの健康状態」を管理する〜

目次 / OVERVIEW

会員システムを運営していると、この問い合わせは珍しくありません。以前は、メールアドレスの入力ミスや、ユーザー側の受信設定が原因であることがほとんどでした。しかし、最近は事情が大きく変わってきています。

• 仕事用メールを個人用のGmailへ自動転送している
• 会社を退職して、そのメールアドレス自体が使えなくなった
• 送信者認証（SPF / DKIM / DMARC）の強化によって、転送メールが届かなくなった

特に2024年以降、GoogleやYahoo!による送信者ガイドラインの強化により、メールの認証や転送時の判定は世界的に厳しくなりました。システム上では、メールアドレスは正しく登録されています。しかし、そのメールアドレスでは、もう本人につながらない。このようなケースが、確実に増えています。

私は前回の記事で、「一人が3〜4個のメールアドレスを持つ時代」について書きました。今回は、その続きです。複数のメールアドレスを持つことが当たり前になった今、私たちがもう一つ見直さなければならない事実があります。それは、

メールアドレスにも、寿命がある。

こう書くと、ほとんどの方が同じことを思われるはずです。「実際には、どれくらい起きるのか」と。正直に申し上げると、これを正確な統計で示すことはできません。ただ、私自身が30年以上、会員システムの現場で見てきた経験から、おおよその肌感覚はあります。

どれくらいの割合で起きるかは、サービスの種類・利用者層・運営年数によって大きく変わります。例えば、事業開始から5年以上が経過すると、登録当初のメールアドレスではもう本人につながらないケースが数%程度になることもありますし、学生向けサービスなど、ライフステージが大きく変わるサービスでは、それが10%を超える場面も経験してきました。これより多いことも、少ないこともあります。数字そのものに意味があるのではなく、どんなサービスでも確実に起きているという点が大切です。

念のため申し添えると、これらは調査に基づく統計ではなく、あくまで30年以上現場で見てきた経験としての目安にすぎません。

それでも、あえて数字を挙げたのは、正確な割合を示したいからではありません。お伝えしたいのは、メールアドレスの寿命が、どこか遠くの話ではないということです。割合の大小にかかわらず、今このときも、自分たちの会員データベースの中で、確実に起きている問題だからです。

メール配信システムは、昔からこの問題に向き合ってきた

実は、この問題は新しいものではありません。メール配信サービスは、ずっと以前からこの課題に向き合ってきました。例えば、

• 配配メール
• MyASP
• SendGrid
• Amazon SES
• Xserverやさくらインターネットなどのレンタルサーバーのメール機能

これらには共通点があります。それは、メールが届かなかった理由（バウンス）をシステマチックに管理していることです。サービスによって画面や運用方法は異なります。しかし、「届かないメールアドレスへ送り続けない」という考え方は共通しています。

つまり、メールを届ける仕組みは、昔から「メールアドレスは変わるもの」「使えなくなるもの」として設計されてきました。一方で、多くの会員システムは、今でも「メールアドレスは変わらない」という前提で設計されています。ここに、大きなギャップがあります。

会員システムは、なぜ「管理」してこなかったのか

ここで、一つの疑問が浮かびます。なぜメール配信システムはメールアドレスの状態を管理し、会員システムは管理してこなかったのでしょうか。「会員システムの怠慢だ」と言いたいわけではありません。私は、両者の「仕事」がそもそも違っていたからだと考えています。

メール配信システムの仕事は、「届けること」です。届かないメールアドレスへ送り続ければ、自分たちの送信品質（レピュテーション）が下がってしまう。だから、メールアドレスが「今どうなっているか」を、常に見続ける必要がありました。

一方、会員システムの仕事は、長らく「登録すること」でした。入会してもらい、情報を記録し、会員として管理する。登録された瞬間の情報が正しければ、役割を果たしたことになります。だから、登録されたあとのメールアドレスが「今どうなっているか」までは、そもそも管理対象に入っていませんでした。

つまり、両者は同じメールアドレスを扱いながら、見ているものがまったく違っていたのです。メール配信システムが見ていたのは、メールアドレスの「今の状態」。会員システムが見ていたのは、登録時点で記録された「情報」でした。

会員システムは、メールアドレスを
「属性（Attribute）」として記録してきました。
しかし、これからは「状態（State）」として捉える必要があります。

属性（Attribute）とは、登録された時点で記録される、固定的な情報です。氏名や住所と同じように、メールアドレスも「登録された一つの値」として扱われてきました。一方、状態（State）とは、時間とともに変化していく、今このときの状況です。同じメールアドレスでも、昨日は届いたのに今日は届かない、ということが起こり得ます。

会員システムがこれまで「メールアドレスは変わらない」という前提で設計できたのは、メールアドレスを属性としてしか見てこなかったからです。会員システムが学ぶべきこと。それは、メールアドレスを「属性（Attribute）」ではなく、「状態（State）」として捉え直すことです。

バウンス（不達）とレピュテーションの真実

バウンスとは、送信したメールが配信できなかったことを意味します。一般的には次の二つに分類されます。

メール配信サービスが、これらを厳しく管理する理由があります。それは、レピュテーション（送信者評価）を守るためです。レピュテーションとは、送信ドメインや送信IPアドレスに対する信頼度です。GmailやYahoo!メール、Outlookなどは、「この送信者は信頼できるか」を継続的に評価しています。例えば、

• 存在しないメールアドレスへ送り続ける
• バウンス率（不達率）が高い
• 迷惑メールとして何度も報告される

このような状態が続くと、送信者の評価は徐々に下がります。その結果、本来届くはずのメールまで迷惑メールフォルダへ振り分けられたり、受信拒否されたりする可能性があります。メール配信サービスが守っているのは、送信品質なのです。

しかし、バウンスは一筋縄ではいかない

ここが実務で最も難しいところです。「バウンスした。」だから「メールアドレスは存在しない。」とは限りません。

例えば、キャリアメールでは、迷惑メール対策のためにSMTP通信の段階で受信を拒否することがあります。送信側から見ると、配信エラーやハードバウンスのように見えます。しかし実際には、メールアドレスは存在しています。受信側が受け取りを拒否しただけなのです。つまり、「バウンス＝存在しないメールアドレス」ではありません。

Gmailでも同じことが起こる

「Gmailなら安心。」そう思われがちですが、実際には違います。同じ送信元から送ったメールでも、

• あるGmailでは受信トレイへ届く
• 別のGmailでは迷惑メールフォルダへ入る
• さらに別のGmailでは受信自体が拒否されることもある

Googleは、SPF・DKIM・DMARC・ドメインの評価・IPアドレスの評価・メール本文・利用者の迷惑メール報告・過去の受信履歴など、多くの要素を組み合わせて配送方法を決定しています。つまり、存在するメールアドレスだからといって、必ず届くわけではありません。

Yahoo!メールにも「寿命」がある

日本ではYahoo!メールも重要な存在です。長い歴史があり、多くのECサイトや会員サイトで利用されてきました。そのため、会員データベースの中には、何年も前に登録されたYahoo!メールアドレスが残っていることも珍しくありません。

一方で、Yahoo!メールは長期間利用されない場合、メールボックスやメールアドレスが利用停止となる場合があります。会員システムから見れば「登録されている正しいメールアドレス」です。しかし実際には、利用できない状態になっていることがあります。これも、メールアドレスにも寿命があることを示す一つの例です。

メールアドレスにも、健康状態がある

ここまで、会社メール、Gmail、キャリアメール、Yahoo!メールと、別々の事例を見てきました。しかし、これらはバラバラの話ではありません。すべて「同じメールアドレスでも、その状態（State）は刻々と変化している」という、一つのテーマで説明できます。一度、頭の中を整理してみましょう。

ここまで見てくると、メールアドレスは単純に「存在する」「存在しない」だけでは判断できないことが分かります。

同じ「登録されているメールアドレス」であっても、その状態は驚くほど異なります。つまり、メールアドレスにも健康状態（Health）があるのです。人間に健康診断があるように、メールアドレスにも健康診断が必要な時代になりました。

メールアドレスは、「生きている」「死んでいる」という二択ではありません。正常に届く状態もあれば、迷惑メールフォルダへ振り分けられる状態、一時的に受信を拒否される状態、長期間利用されず寿命を迎えた状態もあります。

言い換えれば、これからの会員システムが向き合うべきなのは、メールアドレスが「ある」か「ない」かではありません。「今、どんな状態（State）にあるのか」です。前章で触れた、メールアドレスを「属性（Attribute）」ではなく「状態（State）」として捉えるという考え方は、この健康状態という発想とそのまま重なります。健康状態（Health）とは、メールアドレスのState（状態）を表す、最も分かりやすい指標なのです。

だから、これからの会員システムが管理すべきなのは、メールアドレスそのものではありません。そのメールアドレスが、今も会員と確実につながるための連絡先として機能しているか。その健康状態を継続的に把握し、必要に応じて更新していくことです。

まとめ

メールが届くかどうか。これは、多くの運営者が関心を持つテーマです。しかし、本当に考えるべきことは、「メールが届いたか」という結果ではありません。そのメールアドレスは、今も本人につながる連絡先として機能しているか。という視点です。

第1回では、一人が複数のメールアドレスを使い分ける時代になったことについて考えました。その背景には、一人が用途やライフステージに応じて複数のデジタルアイデンティティ（Identity）を持つようになったという変化があります。仕事用、プライベート用、サービス登録用、そして昔使っていたメールアドレス。メールアドレスは変わっても、その人自身は変わりません。つまり、Identityは変わらなくても、Identityにつながるメールアドレスは変化し続けるのです。

これまでの会員システムは、登録された情報——つまり属性（Attribute）が正しいことを前提に設計されてきました。しかし、これからの会員システムでは、登録された属性（Attribute）だけでは十分ではありません。そのメールアドレスが、今どのような状態（State）にあるのかを継続的に把握することが重要になります。メールアドレスは登録して終わる情報ではありません。時間とともに変化し続ける、生きた連絡先だからです。

では、なぜそこまでして、その状態を見続ける必要があるのでしょうか。

メール配信システムが守っているのは、送信品質です。では、会員システムが守るべきものは何でしょうか。私は、それは人とのRelationship（関係性）だと考えています。

メールアドレスは、それ自体が目的ではありません。Identityにつながり、人とのRelationshipを維持するための入口です。だから、本当に管理すべきなのはメールアドレスという文字列ではありません。

そのメールアドレスが、今もIdentityにつながり続け、
人とのRelationshipを維持できる
「状態（State）」にあるか。

私は、これからの会員システムは、この視点を持つ必要があると考えています。Identity（人）を理解し、State（状態）を把握し、その先にあるRelationship（関係性）を育てる。この連載が目指している設計思想は、まさにこの流れです。次に紹介する「メールアドレス・ヘルスチェック」は、その第一歩となる考え方です。

連載ロードマップを見る