電子メールが「届く」を守るとは
Googleと米Yahooが発表した電子メール送信者向けのガイドラインにて、送信者に対する条件強化が発表され、業界ではちょっとした話題になりました。これは2024年2月から実施されることになり、個人メールアドレスとしてGmail保有者が多く存在する現状、実際に電子メールに関わる人間のうち、準備のできていなかった人々の頭を悩ませました。
そして神奈川県公立高校入試のインターネット出願でGmailに対するメールの不達、あるいは遅配が発生したことで、SPFやDKIM、DMARCといった電子メールを守る技術に対する注目度が今この瞬間は非常に上がっています。
「やっておけばよかったのだ」と事後に言うのはいつだって簡単です。ところで、あなたの家の防災用品はどこにありますか？避難場所について家族と共有していますか？あなたの会社のBCPに関する資料はどこにある？会社や学校の避難経路を覚えていますか？…現実には、備えがある人間ばかりではないのです。いつだって、事態が起きた後に人々は思い出すのです。そして往々にして、これらの備えは平時には軽視されるのです。しかし、どうしてやっておかなかったのでしょうか？後回しにされたのでしょうか？軽視されたのでしょうか？そもそも電子メールは届かないなんてことがあるのでしょうか？
この記事では電子メールが「届く」までにまつわる全体的な状況を伝えることに注力し、敢えて技術的な詳細へ立ち入ることはなるべく避けます。
SPFやDKIMについての説明は優秀な記事が世の中にたくさんあります。というか「なりすまし対策ポータル ナリタイ」https://www.naritai.jp/ を参照してください。最高のサイトです。
「届く」は空気
電子メールは送信ボタンをポチっと押せば、数十秒で相手に届きます。電話だって同じです。電気も水道も、止まった経験など片手で数える程度しかないでしょう。つまるところ、他のインフラストラクチャと同様、電話やメールといった通信もまた、一種のインフラストラクチャです。
SlackやTeamsの流行により電子メールの重要性は少々下がりましたが、やはりバリバリ現役のコミュニケーションツールであることに変わりはありません。企業の名刺にはいつだって電子メールアドレスが載っています（あなたも名刺を持っているなら、書いてあるのではありませんか？）。企業を脅かす標的型攻撃やウィルスも、メールという口を通して入ってくることが多いです。重要な契約書も、機密情報も、メールで添付して送ったことがあるのではありませんか？
イカれたメンバーを紹介するぜ！全部担当！俺！以上！
とはいえ障害の起きないシステムはありません。いくら優秀なプロフェッショナルを揃えたとしても、全知全能の神ではありません。どれだけ事前に備えても、現実には起こってから初めて分かる欠陥が山ほど埋もれていて、爆発する時を息を潜めて待っているものです。
そしてもっと悪いことに、現実には大抵、優秀なプロフェッショナルは揃いません。メールのことなど全く知らない人間が運用担当者になることも珍しくありません。「電子メールの専任担当チーム」というのはむしろ、見たことがありません。電子メールが重要なインフラストラクチャであるにも関わらず、です。他のさまざまな社内システムの運用担当チームが、ついでに電子メールの面倒も見ているものです。中小企業ではチームですらなく、たった一人でこの役割を果たしていることが珍しくありません（いわゆる「一人情シス」）。
これらのバックオフィス系のシステムは直接企業に利益を齎さないため、戦力的に今一つ優れない保守的な人間が収まっていることが多いです（もちろん例外はいますが…！）。彼らの至上命題は「問題が起きないこと」であり、動いているものに手を加えることにかなり後ろ向きです。この姿勢から、必要なパッチ適用もされずに塩漬けにされたシステムを山ほど見てきました。多くの場合、電子メールに関するシステムも同じ扱いです。とにかく問題を起こさず、「届く」ならそれがいい、それ以上は何もいらないというのが多くの現場の本音です。
「届かない」なんてあり得るの？
AWSやGCPといったIaaSが出てきた頃、中小企業のよくわかっていない担当者が「クラウドなんでしょ？仮想マシンは壊れないんだから、バックアップは不要では？」と真面目な顔で言ってきた、なんて話を上司から聞いたことを覚えています。これは誤りです。この世の中に壊れないものはありません。いいですか、この世の中に壊れないものはありません。あるのは「壊れたことに気が付かせないままなんとかする仕組み」だけです。それは魔法でもなんでもなく、ただコストを支払って有事に備える仕組みを構築、維持しているだけです。実際にAWSやGoogleのデータセンターでは毎日数十数百のサーバーが壊れていることでしょう。あなたの体内で細胞が日々死んでいても、平気でいられるのと同じように。あなたの街で道が工事中でも、迂回路を通って目的地に辿りつけるのと同じように。
電子メールを構成するサーバー群もこの例に漏れません。壊れます。壊れるということは、届かない時もあるのです。むしろ、電子メールのうち受信を司るMX（Mail eXchange）レコードには優先度という必須フィールドが存在し、これに従って順に配信を試み、失敗したら次の優先度のサーバーへ配信を試みるようになっています。「壊れたことに気が付かせないままなんとかする」のです。全ての配信に失敗した場合は、自身の中に一旦メールを貯めておき、時間を空けて再送にチャレンジします。相手のメールサーバーが復活していることを期待して。このようにしてメールは遅配することもあります。
しかし、あなたはメールが届かなかったことなど（宛先間違い、迷惑メールフォルダに配信されたケースを除けば）片手で数えるほどしか経験がないのではないでしょうか？それは電子メールに関係するサーバーの面倒を見る人々の努力の賜物です。全てが正しく動いているからこそ、届くのです。
一方で、自分自身でメールサーバーを一度でも構築したことがある人なら、メールが届かない経験は山ほどあるはずです。悲しいほどさまざまな理由をつけてあなたのメールは受け取ってもらえず、よしんば届いたとて迷惑メールフォルダに直行。なぜなのでしょうか？
電子メールは誰のもの？
電子メールの世界は開かれています。SMTPという通信のルールを守るサーバー同士が結ばれているだけです。各サーバーは自由に実装し、構築することができます。
あなたがやる気になったなら、今すぐにでも自分自身のドメインで、自分のメールサーバーを持つことができます。それはGmailと引けをとらないほど十分な機能を持っていて、メールを送受信する能力を持っています。いい話ですね。誰でも電子メールの世界に自由に参加する権利を持っている！電子メールはみんなのもの！誰にも独占されない！自由サイコー！自由万歳！
問題は、この権利が悪い人にも等しく与えられていることです。ウィルスを送りつけたい人、詐欺をやりたい人、あなたの会社の秘密の情報を盗み出したい人。誰もが自分でサーバーを建て、電子メールの世界に入ってくることができます。そして銀行や行政になりすまして、あなたを騙そうとするのです。
電子メールは一通一通を送信するコストが低く、長年スパムとの戦いを続けています。その上、悪い用途でメールを使う人たちによるなりすましと戦い続けています。その結果、電子メールの世界は基本的に「登場人物、全員悪人。」というケンシロウもびっくりの世紀末状態です。あなたの迷惑メールフォルダにこれまで何通のスパムが入って消えていったか、誰も覚えていないことでしょう。誰もがスパムやウィルス入りのメールを受け取っています。Gmailが1日で弾いているスパムメールの通数は一体どの程度なのでしょうね？想像もつきませんが、それが膨大な数値であることだけは分かります。
悲しい世界観も伝わったところで「みんなのもの」である電子メールについて、もう少しだけ具体的にメールの世界を覗いてみましょう。
シンプルな世界： 送る人、受け取る人
電子メールの歴史は非常に古く「電気信号を用いてメッセージを伝える」という概念と捉えれば、モールス信号が発明された1800年初頭まで遡ることも可能です。つまり、計算機（コンピューター）の歴史とほぼ同時期から、電子メールという概念は存在しているわけです。まぁ、便利ですからね。
最もシンプルな話をすれば、電子メールのやりとりにはサーバーすら必要ありません。2つのコンピューターが電気的に繋がっていて、片方の中にある情報（メッセージ）が相手に伝わればよいわけです。
しかし、両方のコンピューターの電源がついていないとこれは成立しません。家のパソコンの電源を落としていたからメールが受け取れなかった、なんて話では困ります。ということで、一般的には「送る人」「受け取る人」の他に「送る人のメールサーバー」「受け取る人のメールサーバー」があります。この4つがメールをやりとりするわけです。
つまり、こうです。
送信者 ↓ 送る
送信者のメールサーバー
↓ 送る
受信者のメールサーバー
受信者 ↑ 受け取る（ポストと同じ感覚で自分のサーバーから受け取る）
上のフローを見て「なぁんだ、意外とメールって簡単じゃん」と思っていただけたら幸いです。そうなんです。メールって簡単なんです。基本的には。
ええ。基本的には。
複雑な世界： アーカイブ、検閲、訴訟・・・
実際のビジネスメールの構成はこれほど単純ではいられません。先述した一人情シスや情シスチームへ、こんなミッションがたびたび発生します。
「先週メールした重要資料を間違えて捨てちゃった！なんとかして！」
「3年前に退職した人間のメールに大事なパスワードが入ってたみたいだ、復元できない？」
「我が社が開発する新商品の名称が入ったメールは上司承認を経てからでないと送信させたくない。できるよね？」
「どうも、インターネット上を通るメールは暗号化されていないと経路で盗聴される可能性があるらしい。うちのメールは全部暗号化されているんだよね？」
「どうも、ウィルスというのはメールでよく入ってくるらしい。我が社ももっと強力なアンチウィルス/スパムメールサーバーを導入しよう！」
「内部調査の結果◯◯君が機密情報を漏洩した可能性が高いことがわかった。本人、あるいは他人が改ざんできない領域にメールのコピーはあるかい？場合によっては法廷で証拠として提出したい。」
ビジネス用途で渡される電子メールは、ビジネスが求める複数の要件を満たす必要があるのです。このため、送信者/受信者の組織内で複数の役割のサーバーをいくつも経由することがよくあります。
送信者 ↓ 送る
送信者のメールサーバー(Webメール)
↓ 送る
送信者のメールサーバー(アーカイブ・フィルター・承認)
↓ 送る
送信者のメールサーバー(アンチウィルス・スパム)
↓ 送る
ーーー組織の境界線ーーー
受信者のメールサーバー(アンチウィルス・スパム)
↓ 送る
受信者のメールサーバー(アーカイブ・フィルター・承認)
↓ 送る
受信者のメールサーバー
受信者 ↑ 受け取る（ポストと同じ感覚で自分のサーバーから受け取る）
ややこしいですね。見るからにサーバーが増えています。しかし、この程度の台数なら割と普通です。実際にはバックアップサイトが福岡にある〜とか、特殊な経路向けに用途を絞った別メールサーバーがある〜とか、クラウド上に別システムがあってそちらでも同じドメインのメールを送出することがある〜とか、Webサイトのお問い合わせフォームがメールを送る〜とか、とにかくいっぱいあります。
組織の大きさにある程度比例して、電子メールシステム全体は複雑性を増します。より高度な内容を、より多くの人間のために提供する以上、複雑になるのです。
半径85cmが この手の届く距離
さて、先ほどの「複雑な世界」の例ではしれっと『ーーー組織の境界線ーーー』という線が出てきました。ここを境にサーバーの管理者が変わるわけです。
…そう！つまり電子メールが送られてから届くまでの全経路のうち、自組織が手を出せるのは自組織のサーバーまでです。
ここで情シスに届いたミッションの一つを思い出してみましょう。
「どうも、インターネット上を通るメールは暗号化されていないと経路で盗聴される可能性があるらしい。うちのメールは全部暗号化されているんだよね？」
もちろん！全部暗号化されています！とあなたは自信を持って答えますが、それが自組織の範囲内にしか過ぎないことを、あなたは敢えて伏せるでしょう。電子メールが開かれていて独占されていないため、それぞれのサーバー管理者は別々であり、手が出せない範囲があるのです。
さて、ここで問題を一つ出してみましょう。
あなたはとある企業のたった一人の情報システム運用担当者です。
非常に長い付き合いのある得意先の一つに、非常に物持ちがよくケチなOLD TECHという会社があるとしましょう。太古の昔に作られたメールサーバーを今でも誤魔化し誤魔化し使っています。
OLD TECH社のサーバーはあまりにも古いので、サポートされる暗号方式はすでに欠陥が発覚していて危険なSSLv2だけだとしましょう。当然SPFもDKIMも記載がありません。
あなたは自社のメールサーバーを最新に更新する計画を立てましたが、バージョンを上げるとSSLv2の送信が不可能になることが分かりました。あなたの会社は暗号化なしの電子メール送信を禁止しています（まともな感覚ですね！）。
さらに悪いことに、自社のスパムメール受信率が高いことから、SPFチェックを通過しないメールを強制的に迷惑メールフォルダへ配送する機能を同時に有効化することが計画で決定しています。
一言で言えば、メールサーバーはよりセキュリティ上で正しい状態に近づきますが、OLD TECH社とのメールは送受信共に支障をきたします。
さて、どうするのが正しいのでしょうか？
もちろん、正しいのはOLD TECH社が目を覚まし、まともな暗号化方式に対応し、SPFレコードを書くことです。誰もが簡単にわかることです。しかし、それを進めることができるのはOLD TECH社自身以外には誰もいません。あなたは手が出せないのです。
こんなケースないでしょう！と思った方、実は私一回このようなケースに現実に遭遇しています。自社の都合にもうすこし柔軟性がありましたが、結局は「届くこと」を重視して、対象ドメインのみセキュリティレベルの低下を甘んじて受け入れる設定を許容しました。分かっていて経路を殺すことは現場レベルでは非常に困難なのです。
SPFとDKIM
さて、ここまで電子メールを巡る悲しみや辛みを語ってきました。ワルだらけの世紀末電子メール界で、相互運用性（お互いに「届く」こと）のためにセキュリティが犠牲になるケースも見ました。
悲しみを少しでも減らすために、SPFやDKIM対応を進めるのは非常に重要なことです。
OLD TECH社は今回のケースを受けてサーバーを更新し、最新の暗号化方式に対応しました。これに続いて「SPFとDKIMをセットしてくれ！なんか、DNSレコードに書くらしい！すぐできるよね！」という指示が飛んできたとしましょう。
さて…すぐ、できるのでしょうか？
この会社にはいくつ「出口」がありますか？
非常に簡単に言えば、SPFとは「本物はこのIPアドレスからメールを送りますよ」というリストです。このIPアドレスリストに載っているところからきたメールは、本物っぽいです。リストに載っていないIPアドレスから来たメールは、偽物っぽいです。リストに載っていないので。
SPF対応は一見すると非常に簡単です。説明の通り「本物」のメールサーバーのIPアドレスを書いて、終わり！おしまい！となりそうです。実際、小さい組織ならメールサーバーは1台しかなく、対応は一瞬で終わりです。
しかし、それなりに大きな組織になってくると話は別です。アンチスパム・アンチウィルスサーバーはクラウド上にありIPアドレスが不定期で変わったりします。そういえば会議室予約システムは自社ドメインで外部にメールを送ることがありました。Webサイトに設置したフォームはPHPを使ってメールを出していたような。あれ、プリンターも不具合通知のために自分でメールを送信するんじゃなかったかな？非常用電源装置も緊急時にはメールを送る機能が付いていたような？自社開発したあのシステムはどうだっけ？私の組織内にある全てのシステムのうち、外部にメールを送信するのはどれなんだろう？？？
きちんと全てを最初から管理できている組織はあまり多くありません。時間経過と共に新サービスが勝手にメールを出していたり、解約済みのシステムがSPFに書きっぱなしだったり…。きちんと洗い出して、組織内からメールが出ていく全ての出口を把握しないと、SPFも正しく記載できないのです。これにはそれなりのマンパワーが必要です。時と共に記憶は薄れます。担当者の退職によって情報が欠落する企業では特に。
人類には早すぎる？概念 「電子署名」
SPFは簡単に言えば「本物のIPアドレス」のリストだと言いました。リストにあるなら本物っぽい、載ってなければ偽物っぽい。シンプルです。
一方DKIMとは、本物しか取得できないハンコをメールにくっつけて「私は本物のメールですよ」と証明するものです。詳細に立ち入らないためざっくりした書き方しかできませんが、SPFより見るからに難しそうです。
このDKIMの難しさが牙を剥きます。設定するために誰が何をしなければならないのか、すぐに飲み込めないのです。きっとメール関係の技術者でない限り、何も参照せずにDKIMの全体図を描き「誰が何を使って署名し、誰が何を使って検証するか」説明できないでしょう。
『技術者なら公開鍵ペアと電子署名など分かって当たり前だ！』という声はごもっともですが、現実に電子メールの面倒を見ている人間にはあまり期待できる素養ではありません。特に、それができなければ支障をきたすような「尻に火がついた状態」でない場合、彼らは敢えて学ぶこともしたがりませんし、システム変更などもってのほかです。任期を終えるまで、ただ何事もなく時間が過ぎることを天に祈っているタイプの人間に期待できますか？
そしてSPFにて指摘した「出口何個あるか問題」も襲い掛かります。DKIMに完璧に対応するためには、それなりに高機能なメールサーバー（※メッセージハッシュに電子署名できるプログラム）を挟む必要があります。全ての出口に、です。抜け漏れなくできるでしょうか？実際にやるとなると、それなりに骨が折れることが想像できたかと思います。
…で、誰が幸せになるんだい？
さて、OLD TECH社は重い腰を上げてSPFやDKIM対応に頑張って取り組みました。コストも時間も掛かりました。頑張ったのでいい結果が欲しいですよね？でも得られるのは「届く」という当たり前の状態です。不達により損する機会こそ減りますが、誰に感謝されることもありません。
なりすましやスパム対策を実施すると
自社のメール到達率 ↑UP
スパム・なりすましメールの到達率 ↓DOWN
となるわけです。しかし、化石級のメールシステムを動かしていたり、新ドメインで世紀末メール界に新参者として突撃しない限り、自社のメール到達率というのは最初から十分な値にあるものです。
…つまり！頑張っても悪い連中の悪行が阻まれるだけで、自社はたいして嬉しくない…という事情があるのです。もちろん、不達が出ればビジネスリスクはありますが、結局は「今届いている」なら気にしないわけですね。
しかし、GmailやYahooは違います。個人宛に飛んでくる無数のスパム・なりすましメールと日々終わることのない格闘に明け暮れています。可哀想になるくらいに。だからこそ、彼らは基準を厳しくしたいのです。
そして彼らが基準を厳しくすることで「届かなくなる」ので皆焦っているわけです。しかし、根本的には自ドメインの信用を損ねるスパム・なりすましメールが横行することから目を逸らし、コストを節約してきた組織だからこそ今になって焦っているとも言えます。そのコストを支払う絶好のタイミングですから、ぜひ対応を進めましょう。
DMARC
いいとこ取りしよう！
さて、DMARCは先述のSPF,DKIM対応を済ませた組織だけが手を伸ばせるシステムです。案外難しいことはなく、SPFとDKIMのそれぞれが持っている欠点を補うため、組み合わせて判定を行おうね、というのが基本的な考えかたです。
SPFは転送に弱く、DKIMは導入上のハードルが高いという欠点があります。DMARCで「どちらか通ればホンモノだよ」と示しておけば、DKIM導入が難しいところはSPFでカバー、絶対に通したい主流のメール経路はDKIMで転送時含め確実にカバー、といった運用ができます。ね、結構簡単でしょ？
電子メールの健康診断
一般的な組織は（雑だとしても）SPF対応まで済ませていることは多く、DKIM導入時に同時にDMARCまで対応するかどうか検討する、というケースが多いでしょう。この際、DMARCレポートという形でGoogleやYahooといった外部サーバーからDMARCチェックの状況を知らせるレポートを受け取ることが可能です。無骨なJSONが添付されてくるので目で読むのはしんどいので、解析ツールに食わせるといいでしょう。相手サーバーでDMARCチェックがどの程度成功/失敗したのか知ることができます。言ってみれば、電子メール経路の健康診断のようなものですね。
思わぬ経路からメールが出ていてSPFに失敗しているとか、ついているはずのDKIMがついていない…なんてこともレポートから気がつけたりします。特に自社内のメール出口がきっちり把握できていない場合、レポートは非常に頼りになる存在です。ぜひ活用しましょう。
できることから少しずつ
SPF,DKIM,DMARC全てで、判定失敗時の取り扱いに対する希望を書くことができます。多くの企業ではSPF失敗時の取り扱いを最も緩いものにして放置する傾向がありますが、当然これではスパム・なりすましに対する効果が薄くなります。DKIM,DMARCも同様です。これらの緩やかな取り扱い希望はあくまでも導入時の影響を軽減し、正しい状態に持っていくための最初のステップです。どうか、うちはDKIMもDMARCも書いてあるから！OK！と手を止めないでください。せっかく対応したのだから、十分効果がある状態まで持ち込みましょう。
この記事が気に入ったらサポートをしてみませんか？