この連載では、３０年以上の会員システム設計・運用経験をもとに、AI時代に求められる新しい会員システムの設計思想を探究しています。一つひとつの「当たり前」を問い直しながら、未来の会員システムを読者の皆さまと一緒に考えていきます。
前回は、Googleをはじめとするプラットフォームが、メールアドレスではなく「メールアドレスの健康状態」を管理していることを見てきました。
メールはインフラであり、その品質を維持する仕組みが存在しています。
認証されても、なぜ信頼されるとは限らないのか。Identity（本人確認）だけでは、Trust（信頼）は作れないのではないか。
「SPFも設定した。」「DKIMもPASSしている。」「DMARCも導入した。」それなのに、なぜかGmailへ届かない。迷惑メールフォルダへ振り分けられてしまう。あるいは、届いていても全く読まれない──。会員システムやマーケティングの現場で、このような壁にぶつかったことのある人は少なくないでしょう。
しかし、実はこの疑問そのものに、一つの大きな思い込みが隠されています。それは、「技術的な認証さえ成功すれば、メールは届くはずだ」という盲信です。結論から申し上げれば、私はそうは思いません。なぜなら、Googleをはじめとする世界の巨大なメール基盤が見ているものは、単なる「Identity（認証）」ではなく、その先にある「Trust（信頼）」だからです。
今回は、SPF・DKIM・DMARCというセキュリティ技術の本質を紐解きながら、これからの会員システムにおける「信頼を設計する」という思想について深く考えていきます。
第1章 Identity（本人確認）とは何か
まず前提として、SPF、DKIM、DMARCとは一体何のための技術なのかを整理しておきましょう。これらはすべて、送信者の身元を証明するための「Identity（本人確認）」の技術です。
要するに、これらは「このメールは、確かに表記通りの人間・組織が送ったものである」という身元証明をする仕組みです。しかし、ここで設計者として絶対に混同してはならないのは、「本人確認ができたこと」と、「その人間が信頼できる（善人である）こと」は全く別問題であるという事実です。
これは会員システムにおける「ログイン認証」と同じです。IDとパスワードが一致してログインに成功した（Identityが証明された）からといって、その会員がシステム内で不正を働かないという保証にはなりません。
メールも会員システムも、Identityの確認はあくまで「スタートライン」に過ぎません。それ単体では不十分なのです。
通過しても
半分
Googleは二段階で審査している。本人確認（Identity）を通過したメールに対し、さらに送信者の日々の振る舞い（Trust）をスコアリングする。パスポートが本物でも、入国できるとは限らない。
第2章 世界のトヨタグループでも防げなかったビジネスメール詐欺
どれほど認証技術を積み重ねても、それだけでは人間を守れないという生々しい教訓があります。2019年、トヨタグループの欧州子会社であるトヨタ紡織ヨーロッパは、巧妙な「ビジネスメール詐欺（BEC）」の直撃を受け、約3,700万ドル（当時レートで約40億円）規模の巨額の資金を着服される被害に遭いました（報道により金額に幅があります）。
この事件の恐ろしい本質は、攻撃者が高度なクラッキングによってメールシステムを破壊したわけではないという点です。攻撃者が利用したのは、システムではなく、「このメールは、いつも取引している担当者からのものだから信用できるはずだ」という、人間の心理的な隙、すなわち「Trust」でした。
Identityの仕組みをどれだけ完璧に整えても、人間の信頼を騙る悪意を機械的に止めることはできません。
技術だけでは人は守れません。最後に守るべきものは、システムの実装の先にある「人との信頼関係」です。
第3章 Googleは何を見ているのか
では、認証の先にある「Trust（信頼）」を見極めるために、Google（Gmail）は一体何を見ているのでしょうか。当然ながら、彼らはSPFやDMARCの成否だけでメールの価値を判断していません。送信者ガイドラインを読み解くと、認証チェックを通過したメールに対して、さらに「送信者の日々の振る舞い」を厳格にスコアリングしていることが分かります。
- 送信ドメイン・IPアドレスのレピュテーション（過去の名声・信用）
- メール全体のスパム率（迷惑メール報告数）
- 存在しない宛先へのバウンス率
- 急激な送信量の変化
「そんな基準、送信側からは分からないブラックボックスではないか」と思われるかもしれません。しかし、Googleはこれらを可視化する「Google Postmaster Tools」という検証インフラを公式に提供しています。送信者はこれを利用することで、自社ドメインが現在どのように評価されているかをダッシュボード上で客観的に観測できます。
- Google 送信者ガイドライン
- Google Postmaster Tools
ここからは、私自身の解釈です。私は、この設計思想を「Trust（信頼）を管理する仕組み」だと捉えています。Googleが内部で何を「Trust」と呼び、どのような重み付けで評価しているのかを、外部から断定することはできません。しかし、認証を通過した“その先”で、送信者の日々の振る舞いを継続的にスコアリングしていく——この設計を読み解くと、そこには「信頼を測り、積み上げ、管理する」という一貫した思想が流れているように、私には見えるのです。
Trust（信頼）は完全なブラックボックスではなく、
日々の運用データとして「ある程度は可視化できるもの」です。
管理すべきなのは、メールアドレスという文字列ではなく、この「信頼状態」そのものです。
第4章 DKIMは本当に「信頼」を証明できるのか
ここで、実務においてエンジニアが最も誤解しやすい「DKIM」という技術について深掘りしてみましょう。DKIMは非常に優れた暗号技術であり、メールが届くまでの間に本文が改ざんされていないことを数学的に証明できます。しかし、DKIMが証明しているのはあくまで「改ざんされていないこと」だけであり、「そのメールの内容が安全であること」までは1ミリも証明していません。
例えば、正規の企業のメールアカウントが侵害（乗っ取り）された場合や、詐欺集団が自ら契約した正規の配信サービスから大量のスパムを送った場合、そのメールには「本物のDKIM署名」がしっかりと刻まれ、認証も100%「PASS」します。さらに実務のインフラを考えると、画面上の送信元（From）が example.com であっても、裏側のDKIM署名は sendgrid.net や amazonses.com といった外部の配信インフラのドメインになっている構成は普通に存在します。
だからこそ、Googleは「DKIMが通っているから安全だ」とは判断しません。DKIMの通過は、Trustを総合的に判断するための「無数にある材料の1つ」に過ぎないのです。
データ構造が正しいことと、そのデータが信頼できることは異なります。
第5章 DMARCはなぜ存在するのか
SPFができ、DKIMという暗号署名もできました。それでもなお、インターネットからなりすましメールがなくならなかったのはなぜでしょうか。その最大の理由は、ユーザーが画面で目にする「Fromアドレス」の偽装を、従来のSPFやDKIM単体では完全に縛ることができなかったからです。
そこで誕生したのがDMARCです。DMARCは、ユーザーが見ているFromアドレスと、背景にある認証ドメインが一致しているかという「Alignment（整合性）」を厳格にチェックします。これにより、認証の隙を突いたなりすましを徹底的に排除する構造が完成しました。
しかし、DMARCの本質はそれだけではありません。DMARCを導入すると、世界中の受信サーバーから送信ドメインの管理者へ向けて、利用状況を集計した「DMARCレポート」が毎日自動で送り返されてきます。これを解析すれば、「誰が自分のドメインを利用しているのか」「認証に失敗している送信元はないか」「なりすましは発生していないか」を継続的に把握できます。私は、この仕組みこそがドメインにとっての「定期的な健康診断（Health Monitoring）」の本質だと考えています。
データは一度登録して終わりではありません。継続的に状態を観測することが重要です。
送りっぱなしではない。世界中の受信プロバイダから、自社ドメインの認証結果（誰が・どこから・PASS/FAIL）が毎日レポートとして戻ってくる。これがドメインの“定期健康診断”になる。
第6章 クラウドは信用されない。信用されるのは実績である
現在、多くの企業がAmazon SESなどの強力なクラウド型メール配信基盤を採用しています。しかし、ここで勘違いしてはならないのは、AWS自身は「AWSの大規模なインフラから送られたメールだから安全だ」とは一ミリも思っていないという点です。むしろ彼らはその逆で、自社のクリーンなIPアドレス基盤が、悪質なスパム送信者に悪用され、汚染されることを何よりも警戒しています。
そのため、AWSはすべての利用者のバウンス率や苦情率、送信パターンを継続的に監視しており、一定の基準を超えたアカウントには送信制限のペナルティを課したり、送信機能を即座に停止します。これはMicrosoftやGoogle Cloudでも全く同じです。世界の巨大メール基盤が評価しているのは、クラウドのネームバリューではありません。「そのインフラを使って、あなたが日々どんなメールを送り、どんな実績を積み重ねてきたか」という送信者自身の実績です。
クラウドは信用されません。信用されるのは、そのクラウドを利用する送信者の日々の「実績」であり、積み重ねられた関係なのです。
第7章 メール基盤は「届ける技術」ではなく「守る技術」でもある
私たちはつい、「メールサーバー＝メッセージを届けるための道具」と考えてしまいます。しかし、現代のインターネットにおいて、メール基盤の正体は「巨大な防御陣形（セキュリティインフラ）」です。
GoogleやMicrosoftのメールサーバーには、毎分毎秒、想像を絶する数のサイバー攻撃が着信しています。フィッシングやマルウェアのバラまき、サーバーを麻痺させるメールボム、SMTPを狙ったDoS/DDoS攻撃、リソース消費を目的とした大量送信など、その内容は多岐にわたります。彼らが最先端のAIを投入している理由は、単にメールを綺麗に仕分けるためだけではなく、自社の抱える世界最大の通信インフラそのものを死守するためです。
「配信する」というポジティブな機能だけでなく、悪意やデータの風化からシステムを「守る」という設計思想も必要です。
第8章 届けば終わりではない 〜人間の「認知のバウンス」〜
ここまで「メールをどう届けるか」という技術的な側面を述べてきました。しかし、会員システムを運用する上で、最も残酷で、かつ直視しなければならない事実がもう一つあります。それは、「届いたメールは、本当にユーザーに読まれているのか」という問題です。
現代を生きるユーザーの受信トレイは、仕事、SNS、EC、ニュースレター、各種システムの自動通知など、毎日大量のメールの洪水で溢れかえっています。送信側のログにエラーが出ず、サーバーに「250 OK（正常配送）」と記録されれば、技術的には100%の「配信成功」です。しかし、他の大量のメールに完全に埋もれ、開封すらされずにスクロールで流されてしまうなら──。
それは利用者の脳内（認知）における
「実質的なバウンス（不達）」です。
これは決して特別な話ではありません。たとえば——クレジットカードの決済失敗通知。パスワード再設定のメール。契約更新期限のお知らせ。いずれもシステムのログ上は「配信成功（250 OK）」と記録されます。しかし利用者は、毎日届く何十通もの通知の中にそれが埋もれ、気付かないまま決済が止まり、ログインできず、更新期限を過ぎてしまう。送信側から見れば「きちんとお送りしました」なのに、利用者にとっては「届いていない」のと同じ——会員ビジネスの現場では、こうした“すれ違い”が日常的に起きています。
システム上は成功していても、利用者にとっては「存在しなかった」のと同じなのです。Googleが「プロモーション」や「ソーシャル」といったタブを執拗に分ける理由もここにあります。ユーザーが情報の洪水に溺れ、本当に必要なメール（信頼）を見落とすことを防ぐために、インフラ側で交通整理を行っているのです。
ここで一つ、強調しておきたいことがあります。私は「メールを見ない人が増えた」と言いたいのではありません。伝えたいのは、メールだけが情報を受け取る手段だった時代が、終わりつつあるということです。
「メールが届いているかご確認ください」という案内は、今でも多くのWebサービスで使われています。昔は、メールだけが利用者へ情報を届ける手段でした。だから「メールをご確認ください」は自然な言葉だったのです。しかし現在は、登録内容は完了画面でも、マイページでも、プッシュ通知でも、SMSでも確認できます。メールは今も重要ですが、もはや唯一の情報伝達手段ではありません。
私が見直したいのは、メールではありません。
「まずメールを見る」という設計思想です。
これからの会員システムに求められるのは、「メールを送ったかどうか」ではなく、利用者に最も届きやすいチャネルを設計することです。届く場所は、人によって違います。その人にとって最も確実に“認知”が成立する経路を選び取る——それこそが、これからの設計者の仕事になります。
本当に管理すべきものは、「送信に成功した」という自己満足のログではなく、「画面の向こうの人と、本当にコミュニケーションが成立したか」という実態です。
第9章 会員システム設計論 〜メールアドレス・ヘルスチェック〜
GoogleはTrust（信頼）を管理しています。DMARCはHealth（健康状態）を日々観測しています。AWSは配信基盤へのTrustを守っています。であれば、私たちの会員システムもまた、メールアドレスという文字列をデータベースのString型カラムに保存して終わり、という古い設計思想から脱却しなければなりません。これからは、単なる文字列ではなく、以下のような「状態」を持つ設計が必要です。
| フィールド（変数） | 意味・設計上の役割 |
|---|---|
last_verified_at | 最終到達確認日時。最後に生きて届いた日時。 |
bounce_count | 累積バウンス数。不達エラーが返ってきた回数。 |
bounce_type | バウンス種別。Hard（存在しない）か Soft（一時エラー）か。 |
complaint_flag | 苦情有無。迷惑メール報告等を受けた形跡の有無。 |
engagement_score | エンゲージメント。開封・クリックなどの反応（認知の生存）。 |
health_status | 健康状態。Active（正常）/ At Risk（警告）/ Invalid（無効・寿命）。 |
アドレスは単なる連絡先ではない。「信頼状態」を持つ中核ハブ（主キー）として、LINE・SMS・プッシュ通知へ最適なルートをリレーする。マルチチャネル時代に人との関係を維持し続けるためのアーキテクチャ。
これが、私が提唱する「メールアドレス・ヘルスチェック」という設計思想の骨組みです。そしてここから先は、メールだけにとどまりません。連絡手段がSMS、LINE、アプリのプッシュ通知などへと分散していくマルチチャネル時代において、あらゆる通信手段の「健康状態」を管理し、最適なルートでユーザーと繋がり続けるための、共通の基本設計となるものなのです。
まとめ 〜IdentityからTrustへ、そして関係性の設計へ〜
SPF・DKIM・DMARCは、Identity（本人確認）を証明します。これはFACTです。そしてここから先は、私が世界の設計思想を読み解いた解釈です——私は、Googleは「Trust（信頼）」を、DMARCは「Health（健康状態）」を、AWSは「配信基盤への信用」を、それぞれ管理・観測しているのだと捉えています。形だけの認証から、実態を伴う「信頼」の管理へ。世界のメール基盤の設計は、そう動いているように私には見えます。だとすれば、私たちの会員システムが管理すべきものも、メールアドレスという単なる「文字列」ではないはずです。
- その人と、今もつながっているか。
- その関係は、健康か。
- その信頼は、積み重なっているか。
私たちが本当に設計しなければならないのは、画面の向こうにいる人間との「関係性」そのものです。認証は入口に過ぎません。信頼は日々の積み重ねです。関係性は、その先にあります。Identity（本人確認）から Trust（信頼）へ、そして Relationship（関係性）へ——この連なりこそが、これからの会員システムの背骨になります。
そして私は、この「Identity → Trust → Relationship」という考え方を、Relationship OSという一つの設計思想へと整理していきます。その全体像は、本連載の第6回以降で改めてお話しします。
世界のメール基盤は、メールを管理しているのではありません。信頼を管理しています。会員システムも同じです。会員を管理する時代は終わりました。これからは、人との関係を設計する時代です。
連載ロードマップを見る
参考資料・FACTエビデンス
- RFC 7208（Sender Policy Framework：SPF規格）
- RFC 6376（DomainKeys Identified Mail：DKIM規格）
- RFC 7489 および関連RFC（DMARC規格）
- Google Email Sender Guidelines（メール送信者のガイドライン）
- Google Postmaster Tools（ドメイン・IPレピュテーション／スパム率検証インフラ）
- Microsoft Learn：Exchange Online Protection（EOP）/ Smart Network Data Services（SNDS）
- Amazon SES Developer Guide / Sending Best Practices（バウンス率・苦情率に関する送信停止等の規約）
- Apple Developer：iCloud+「Hide My Email」公式ドキュメント
- LINEヤフー株式会社：Yahoo!メール 配信ガイドライン / Yahoo! JAPAN ID 長期未利用対策方針
- 総務省：特定電子メール法（特定電子メールの送信の適正化等に関する法律）および関連ガイドライン
- FBI Internet Crime Complaint Center（IC3）年次サイバー犯罪統計報告
- トヨタ紡織株式会社 2019年9月6日 公式プレスリリース、および Reuters・Bloomberg 等の公開報道
Identity（本人確認）とTrust（信頼）という基盤の上に立つのが、Relationship（関係性）です。第5回では、「メールアドレス」という単なる通信手段を超えた、人と企業の関係を可視化・管理するための設計思想を紹介します。従来の会員システムは「誰が登録したか」を記録してきました。これからは「その人とどのような関係が生まれているのか」を設計し、構築することが求められます。次回、Relationship Database の全体像に迫ります。
送信ドメイン認証（SPF・DKIM・DMARC）の設定から、レピュテーション・バウンス・苦情率を踏まえた「メールアドレス・ヘルスチェック」の設計まで。PayAI NEXTでは、現在の会員データと配信状況をヒアリングし、信頼を継続的に管理する会員システムの設計・運用プランをご提案しています。お気軽にご相談ください。
1997年よりインターネット業界に従事。2007年の創業以来、EC、メディア、SaaS、コミュニティサイトなど数多くの会員ビジネスの立ち上げと成長を支援。
30年近く会員システムの設計・運用に携わる中で、システムは「会員を管理するもの」から「人と人との関係（Relationship）を育てるもの」へ転換すべきだと確信。現在は、AI時代における次世代のシステム設計思想として「Relationship OS」を提唱しています。
また、自身も宿泊施設の運営で現場に立ち続け、『起きている時間はすべて仕事であり、システムへの探求』という圧倒的な熱量で、会員ビジネスの未来に向き合っています。
「人との関係は設計できるのか」という問いに、これからも人生をかけて愚直に向き合い続けていきます。