セルフホスト型メールは依然として急激に減少傾向にある

インターネットのトップドメインにおける10年間のDNS測定は、インターネット全体で3つのトレンドを明らかにしています。メールは依然として2つのプロバイダーに集約され続け、DMARCの強制実施は停滞し、分類が難しいインフラストラクチャの非常に長いテールが存在しています。 ドメインがメールをどのように処理するかに関するほぼ全ての情報は、公開DNSにあり、カウントされるのを待っています。MXレコードはメールボックスが存在する場所を示します。SPFレコードは、ドメインの名において誰が送信できるかを示します。DMARCレコードは、メッセージ認証に失敗した場合に何が起こるべきかを示します。これら3つを毎日100万ドメインについて組み合わせると、メールインフラストラクチャの気象観測所のようになります。 それが私が実行していることです。このパイプラインは、OpenINTELプロジェクト（トゥウェンテ大学、SURFnet、SIDN Labs）がTrancoトップ1M向けに公開している日次のフォワードDNSスナップショットを取得し、各ドメインのMXホスト名とSPFインクルードを、メールボックスプロバイダー、送信プラットフォーム、SaaSアプリケーションのオープン辞書に対して分類します。典型的な日には、約659,000ドメインがMXレコードを持ち、618,000ドメインがSPFレコードを持っています。OpenINTELのアーカイブにより、2016年まで同じ数値を計算することが可能になり、スナップショットが時系列データに変わります。そして、その時系列データこそが興味深いものです。 現在のデータから得られた3つの発見は、コミュニティの注目に値するように思われます。 ポート25からの大移動 2016年、トップ100万ドメインのうちMXレコードを発行しているドメインの44.6%が独自のメールサーバーを実行していました。2026年7月18日のスナップショットでは、この数値は22.4%であり、過去30日間だけでもさらに半パーセントポイント低下しており、これもコミュニティの注目に値するように思われます。ドメインは消滅したのではなく、移動しました。Google Workspaceは現在、MXレコードを発行しているドメインの21.8%のメールを受け取っており、Microsoft 365は16.8%を受け取っています。これらを合わせると、測定されたインターネットの受信メールの38.6%が2社によって処理されています。他のどのプロバイダーもこれに近づいていません。次に名前が挙がるプロバイダーであるProofpointは1.9%です。 これを市場シェアの物語として読むのは簡単ですが、このコミュニティにとっては、これは本当にレジリエンス（回復力）の物語です。RIPEコミュニティは長年、DNSとCDNの集中化について議論してきましたが、メールは同じ道をたどっており、ただより静かです。人気のあるドメインの3分の1以上がメール受信のために2つのプロバイダーに依存している場合、どちらか一方での障害、フィルタリングの変更、またはポリシーの決定は、すべて同時にエコシステム全体に波及します。そして、CDNとは異なり、メールには優雅なフォールバックがありません。拒否されたメッセージは単に失われます。 二次的な影響もあります。独立したオペレーターが少なくなるほど、残りのオペレーターは、大手2社に合わせて調整された世界における配信性の問題を引き継ぐことになります。2026年に新しいPostfixボックスを立ち上げて、大規模にメールを受け付けてもらおうとしたことがある人なら、私が何を意味するか正確にわかるでしょう。 DMARC：どこでも採用されたが、どこでも強制されていない 現在のスナップショットでは、458,467ドメインがDMARCレコードを発行しています。表向きは、10年かけて達成された成功物語です。実際には、それらのドメインのわずか46.9%しか何も強制していません。つまり、pct=100でp=quarantineまたはp=rejectです。大多数は、受信者に何も行わないように求めるポリシーを発行しています。 私をより驚かせたのは、そのレベルではなく、その方向性です。強制実施されているシェアは徐々に増加していません。過去30日間で0.44パーセントポイント低下しました。GoogleとYahooが2024年に導入したバルク送信者要件は、確かに発行を促進しました。採用曲線のステップで見ることができますが、彼らは「DMARCレコードを持つこと」という基準を設定し、インターネットの非常に大きな部分がそこで止まってしまいました。 レコード自体が、集計データよりも物語をよく語っています。データセットで最も一般的な単一のDMARCレコードは、58,064ドメインによってそのまま発行されており、「v=DMARC1; p=none;」です。さらに32,682ドメインは、末尾のセミコロンを除いて同じ文字列を発行しており、数千ものドメインがそれのわずかなバイトレベルのバリエーションを発行しています。これらはコピー＆ペーストされたスターターポリシーであり、チェックリストを満たすために作成され、その後二度と見直されていません。rua=宛先のないp=noneレコードは、その存在自体を正当化するレポートさえ収集しません。それは誰も保護しません。ただ、採用統計を良く見せるだけです。 誰も名前を呼べない長いテール 辞書ベースの分類には上限があり、それがどこにあるかを正直に伝えたいと思います。約310のプロバイダーパターンに対してMXホスト名を照合し、ESP、フォワーダー、ゲートウェイの辞書に対してSPFインクルードを照合することで、現在約81.5%のSPFインクルードとMXレコードの大部分を属性付けしています。残されたものは、その規模において注目に値します。36,455のユニークなMXホスト名が既知のプロバイダーに一致せず、それぞれ1つのドメインにのみ現れる数万のSPFインクルードターゲットがあります。 テールに現れるものの一部は面白いものです。トップ100万ドメインのうち503ドメインがlocalhostをMXとして発行しており、130ドメインがリテラルの「~」を発行しています。しかし、そのほとんどはインターネットの地味な中間部分です。地域のホスター、自作のEximボックス、バニティホスト名を持つ企業のゲートウェイです。これは、配信性の研究が最も悪く見る対象集団であり、大手プラットフォームしか知らない測定にとっては不可視です。 私は、未一致のホストを毎日実行するたびに公開しています。これは、ある種の招待状でもあります。もしホスト名のパターンを認識したら、修正は次の日のスナップショットに反映されます。 データについて、そしてそれが何を見ることができないか ソースは日次のOpenINTEL Trancoスナップショットです。2022年以前の履歴は、OpenINTELのレガシーAlexaトップ1Mソースを使用しており、構成はいくぶん異なります。各ドメインについて、プライマリMX（優先度最小）がメールボックスプロバイダーを決定します。ルートSPFレコードが送信者を決定します。_dmarc TXTレコードは、ポリシー、サブドメインポリシー、およびpctについて解析されます。 集計、完全な時系列、および日次の変更フィードはプロジェクトの統計ページで公開されています。生のOpenINTELデータは、データ契約に従って各実行後に削除されます。 盲点は、はっきりと述べる価値があります。フラット化されたSPFレコード（10ルックアップ制限を回避するためにIP範囲に置き換えられたインクルードチェーン）は、送信プラットフォームを完全に隠します。既知のプロバイダーへのCNAMEであるMXターゲットは展開されないため、ドメインの小さな割合が「不明」に押し込まれます。MimecastまたはProofpointのホワイトラベル展開は、顧客が独自のホスト名を使用する場合、セルフホスティングと区別がつきません。そして、Tranco自体は米国とEUのドメインに偏っているため、この図は、インターネット全体ではなく、人気のあるインターネットの図です。 これがどこへ向かうのか これらのレコードの10年間は、3つの章からなる一貫した物語を語っています。減速の兆候を見せない集中化、保護ではなく形式として採用された認証標準、そして全く数えられないことを拒む長いテールです。各章には質問が付随しています。 受信メールがコミュニティの明示的な注意に値するシステム的な依存関係になるのは、どの程度の集中度からでしょうか？ 2024年の義務が明らかにそれを達成しなかったことを考えると、DMARCを公開から強制へと実際に動かすものは何でしょうか？ そして、私たちの辞書がその名前を知らないために、インターネットのメールインフラストラクチャのどれだけを見逃しているのでしょうか？ 私には確固たる答えはありません。しかし、明日午後11時、そしてその翌日も同じ測定を実行しています。それは、十分な日数があれば、これらの質問が解決される傾向にある方法です。 基盤となるDNSデータは、トゥウェンテ大学、SURFnet、SIDN LabsのOpenINTEL測定プラットフォーム（van Rijswijk-Deij et al., IEEE JSAC 2016）から提供されます。誤って分類されたMXホストや欠落しているプロバイダーパターンを見つけましたか？修正を歓迎します。次の日次スナップショットに反映されます。