世界最大手のAI企業におけるメール認証

人工知能（AI）業界は、2年をかけて、誰もが簡単に説得力のあるデジタルなりすましを行えるようにしてきました。そこで私たちは、世界をリードするAI各社が、まさに同じなりすましリスクに対して、自社のドメインをどの程度防御できているかを検証することにしました。2026年8月6日、私たちは30社の主要AI企業を対象に、8つの主要なメールセキュリティプロトコルについて、再帰的DNSルックアップテストをリアルタイムで実施しました。

主な調査結果は単純明快だ。すべての企業が、電子メール認証の基盤となる層を導入している。30社すべてがSPFおよびDMARCレコードを公開しており、少なくとも28社がDKIMを確認している。しかし、こうした基本事項を超えて詳しく見てみると、セキュリティ態勢は急激に低下する。30社中、MTA-STSを公開しているのはわずか2社のみである。DNSレコードにDNSSECで署名しているのは6社のみであり、19社は依然としてSPFレコードの設定を「softfail」のままにしている。

当社のベンチマーク対象企業の中で、AIを中核事業とする企業でMTA-STSを公開しているところは1社もありません。分析対象の中でMTA-STSを公開しているのは、Googleと Microsoftの2社のみです。

これにより、このコホートに属するすべてのAIスタートアップは、たとえDMARCレコードが検証に合格していたとしても、ダウングレード攻撃や転送中のトラフィックの傍受に対して脆弱な状態にあることになる。

ドメインのセキュリティを点検しましょう

ご自身のドメインの状況を確認したいですか？ PowerDMARC ドメインアナライザー を使って、ドメインの設定状況をリアルタイムで確認しながら、完全なベンチマークデータセットを詳しく見てみましょう。

測定内容と方法

本調査の対象には、OpenAI、Anthropic、Google、DeepMind、Microsoft、Meta AI、NVIDIA、Amazon、Apple、IBM、xAI、Mistral、Cohere、Perplexity、Hugging Face、Stability AI、Midjourney、Characterといった、AI分野の主要企業30社が含まれています。AI、ElevenLabs、Runway、Databricks、Scale AI、DeepSeek、Cursor、Replit、Groq、Together AI、Cerebras、Writer、およびGlean。2026年8月6日時点で、各組織の企業トップレベルドメインを評価しました。なお、本レポートではGoogleとDeepMindを別々のトップレベルドメインとして追跡しています。

SPFレコードの設定、DKIMセレクタの有無、DMARCポリシーの導入、DNSSECの検証、MTA-STS、TLS-RPT、BIMI（Brand Indicators for Message Identification）、およびMXサービスプロバイダーという、8つの具体的なプロトコルとパラメータを測定しました。 EDNS0を有効にしたパブリック再帰型リゾルバー（1.1.1.1、8.8.8.8、9.9.9.9、8.8.4.4）に対してクエリを実行し、レコードごとに3～4回の再試行を行いました。SPFアペックスTXTレコードの取得には、大規模なTXTセットにおけるTCP/53フォールバックの問題を回避するため、DNS-over-HTTPSを使用しました。 SPF再帰ルックアップの回数は、RFC 7208のセクション4.6.4に厳密に従って算出しました。

本研究の透明性を完全に確保するため、以下の6つの明確な分析上の限界について指摘しておく：

• DKIMプローブの制限：DKIMセレクタは、標準的なDNSクエリでは列挙できません。30件中28件という当社の集計結果は、下限値を表しています。例えば、meta.comでは100件以上のセレクタをプローブしてもヒットが一切なかったことから、DKIMが欠落しているのではなく、カスタムセレクタが使用されていることが示唆されます。
• ワイルドカード：databrics.com は、_domainkey 配下で DNS ワイルドカードを運用しています。どのようなセレクタクエリでも解決されるため、正確なセレクタの数は意味をなしません。この設定を、ワイルドカードとして記録しました。
• Apexスコープ：本調査では、企業の主要なApexドメインのみを対象としました。マーケティング専用や取引専用のサブドメインについては評価対象外としました。
• サブインクルードにおけるDNSの失敗：amazon.comはspf3.amazon.comに依存していますが、サイズの問題によりそのホスト名の解決に失敗しました。Amazonが記録した合計4回のルックアップ回数が、下限値となります。
• 特定時点の範囲：DNSの設定は変更されることがあります。このデータは、2026年8月6日時点のリアルタイムのスナップショットを反映したものです。
• 「姿勢」と「侵害」：認証ポリシーが緩いということは、なりすまし対策の姿勢が弱いことを意味します。ただし、それはセキュリティ侵害や運用上の過失を意味するものではありません。

本レポートのすべてのデータポイントは、公開リゾルバに対して標準的なdigコマンドを実行することで、個別に検証することができます。

誰もがメール認証の基礎をクリアできる

この基本プロトコルは、AI業界全体で完全に採用されています。30社すべてがSPFレコードを公開しており、30社すべてがDMARCレコードを公開しています。また、29社が有効な集計レポートアドレス（rua）を公開しています。調査対象企業の90％が、p=quarantine（12社）またはp=reject（15社）のいずれかでDMARCを適用しています。

ただし、状況次第です。これらの上位AI企業のうち、正確に50.0%が厳格な「p=reject」ポリシーを適用しています。参考までに、当社が最近発表した「米国におけるDMARCおよびMTA-STS導入状況レポート」によると、全米での「p=reject」適用率は49.0%となっています。世界でもっとも時価総額の高いAI企業は、基本的なDMARCの適用という点において、まさに全米平均と同等の水準にあると言えます。

p=reject が実際にどのような役割を果たしているかを理解したい場合、これは、不正なメッセージが受信トレイに届く前にブロックするための最終的なゲートウェイとして機能します。ベンチマーク対象の 3 社、Hugging Face、Stability AI、Cerebras は、p=none の設定のままとなっており、これはなりすましメールをブロックすることなくトラフィックを監視するものです。

プロトコル採用マトリックス（主要AI企業30社のサンプル）

出典：PowerDMARC ライブDNS調査（2026年8月6日）

30人のうち、MTA-STSを発表した人はわずか2人

基本的なドメイン認証は広く普及している一方で、トランスポート層のセキュリティに関しては状況が大きく異なります。市場をリードする30社のうち、RFC 8461に準拠したMTA-STS（Mail Transfer Agent Strict Transport Security）レコードおよびTLS-RPT（SMTP TLS Reporting）を公開しているのは、GoogleとMicrosoftのみです。AIネイティブのスタートアップや専用ハードウェアプロバイダーで、これらのレコードを公開している企業は1社もありません。当社のMTA-STS解説記事では、このプロトコルの仕組みを詳しく解説しています。

DMARCとMTA-STSは、セキュリティスタックにおいてまったく異なる問題を解決します。DMARCは、ヘッダーのなりすましを防ぐために送信者の身元を認証します。一方、MTA-STSは、中間者攻撃やダウングレード攻撃を防ぐために、メールサーバー間の暗号化されたTLS接続を強制します。どちらのプロトコルも、もう一方に取って代わるものではありません。

公平を期すために言えば、このサンプルにおける6.7%という採用率は、当社の米国調査で報告された全国平均の1.7%を上回っています。真に重要な点は構造的な問題にあります。つまり、AIエコシステムにおいて転送セキュリティを徹底しているのは、グローバルなクラウドメールプラットフォームを運営する2つのテック大手のみなのです。PowerDMARCのMTA-STSチェッカーを使用すれば、転送暗号化の適用状況を確認することができます。

DNSSECのギャップ ― 主要なハイテク企業のAI関連企業すべてを対象に

DNSSEC（ドメインネームシステムセキュリティ拡張）は、DNS応答が改ざんされていないことを暗号学的に証明するものです。当社の調査対象となった30社のうち、自社のゾーンにDNSSECによる署名を行っているのは、Hugging Face、ElevenLabs、Databricks、Scale AI、Writer、Gleanの6社のみです。これは20.0%の導入率に相当し、米国の全国平均である18.0%をわずかに上回っています。

特に注目すべき点は、誰が対象から外れているかという点だ。調査対象となった大手テック企業のうち、主要な企業ドメインにDNSSECによる署名を行っている企業は1社もなかった。Google、Microsoft、Meta、NVIDIA、Amazon、Apple、IBMはいずれも、トップレベルドメインに署名を行っていない。

プロトコルの採用率：AI企業トップ30社とベンチマークの比較（2026年）

出典：PowerDMARC独自調査（2026年8月）｜Valimail 2026年業界レポート

Stability AIの不完全な導入

当社のスキャンにより、Stability AI において典型的なデプロイメントの不備が判明しました。このドメインは、自身のゾーン内に有効な DNSKEY レコードを公開していますが、親レジストラ側に対応する DS（Delegation Signer）レコードが存在しません。信頼の連鎖が最上位レベルで途切れているため、検証を行うリゾルバーは、このゾーンを完全に署名されていないものとして扱います。一見すると保護措置が講じられているように見えますが、エンドユーザーには何のセキュリティも提供していません。

SPF、DKIM、DMARCレコードはいずれもプレーンなDNSを介して配信されるため、DNSSECは電子メールのセキュリティに直接関わるものです。暗号化されたゾーン署名が行われていない場合、攻撃者は転送中のDNS応答を改ざんし、電子メールの制御を完全に回避することが可能になります。

30件のうち19件で、SPFのソフトフェイルが依然として発生している

当社の調査によると、30社のうち19社は、SPFレコードの末尾に「-all」（ハードフェイル）ではなく「~all」（ソフトフェイル）という修飾子を付けています。ハードフェイルを使用しているのは9社のみであり、2社（MetaとWriter）は「redirect=」メカニズムを採用しています。

興味深いことに、p=reject を適用している 15 社のうち 10 社は、依然として SPF レコードに ~all を使用しています。このリストには、Anthropic、Google、DeepMind、NVIDIA、Perplexity、Character.AI、Databricks、Replit、Groq、Glean が含まれます。PowerDMARC の SPF 検索ツールを使用すれば、ご自身のドメインの SPF 構文を確認することができます。

この文脈において、SPFの「ソフトフェイル」と「ハードフェイル」の構文の違いを理解することは極めて重要です。ドメインがDMARCをp=rejectで適用している場合、メッセージの配信はDMARCポリシー全体によって決定されます。DMARCが有効な状態では、SPFにおけるソフトフェイルによってセキュリティ上の脆弱性が生じることはありません。しかし、-allを使用することで、SPFを個別に評価する受信者に対して、明確かつ曖昧さのないシグナルを送ることができます。ソフトフェイルからハードフェイルへの移行は、セキュリティ体制を強化するためのシンプルな手段であり続けています。

p=reject における SPF 予選結果の内訳（15 社）

SPFルックアップ制限を超えているユーザーは、今のところ誰もいない

RFC 7208 では、SPF 評価における DNS ルックアップの回数上限を 10 回と厳格に定めています。この上限を超えると PermError が発生し、SPF チェックは完全に無効となります。調査対象の 30 社のうち、10 回という上限を超えている企業はありません。Writer が 9 回で上限に最も近く、次いで Perplexity が 8 回となっています。OpenAI、Microsoft、Cohere は 7 回です。

OpenAIのSPFレコードは、現代の企業向けメール環境の優れた事例となっています。同社のインクルードチェーンには、Google Workspace、Microsoft 365、HubSpot、Marketo、Oracle Cloudが含まれています。この構成では7つのルックアップが使用されており、余裕として3つのルックアップが残されています。外部のマーケティングツールをあと1つ追加するだけで、レコードが機能不全に陥る可能性があります。

SPF DNS 検索の余裕（10回の検索制限に近づいている選定企業）

すでに5社がSPF管理を外部委託している

規模が大きくなると、ルックアップの手動管理は困難になります。当社のベンチマーク対象企業のうち5社は、SPFインフラの管理に専用のサードパーティ製サービスを利用しています：

これら5つの組織のうち4つは、単純なIPリストではなくSPFマクロを採用しています。SPFマクロは、クエリ実行時に着信接続を動的に評価するため、複雑な企業ネットワークにおいて実績のある標準となっています。

手動での追跡を行わずにルックアップ制限を回避したい組織は、PowerDMARCのPowerSPFホステッドSPFソリューションを検討してみてください。

筆者の設定例は、適切な実装がいかに重要かを浮き彫りにしています。彼らのサードパーティ製リダイレクト機構は、1回の処理で許可されている10回のルックアップのうち9回を消費してしまいます。マネージド型のホスト型SPFサービスを利用すれば、レコードを簡素化できるはずであり、ルックアップの割り当て枠のほぼすべてを消費してしまうような事態は避けられるはずです。

3つの専攻は依然として「監視のみ」の状態にある

Hugging Face、Stability AI、およびCerebrasは、DMARCポリシーを「p=none」に設定しています。この設定では、ドメインを悪用から保護することなく、配信レポートが収集されます。攻撃者はこれらのドメイン名を使用して不正なメッセージを送信することが可能であり、受信側のメールサーバーはそれらを通常通り配信してしまいます。

この方針の選択は、オープンソースのAIモデル重みのダウンロードの中核的なハブとして機能するHugging Faceにとって、特に注目に値する。Hugging Faceを装った説得力のある偽のメールがあれば、開発者を騙して、改ざんされたコードやモデルファイルをダウンロードさせてしまうことは容易である。その一方で、Hugging Faceは、調査対象企業の中でDNSSECによるドメイン署名を実施しているわずか6社のうちの1社であるという点で、高く評価されるべきである。

これが意味すること――そして改善すべき点

これらの実践的なセキュリティ推奨事項は、分析対象となったAI企業に対し、スプーフィングの脆弱性を排除し、ドメインの評判を守るための具体的なロードマップを提供します。これらの電子メール認証およびDNS制御策を実施することで、送信者の厳格な検証が徹底され、転送中の暗号化が確保され、継続的な運用監視体制が確立されます。

1. DMARCの強制適用に向けた取り組み：ポリシーを「p=none」から「p=quarantine」に変更し、その後、「p=reject」に移行する明確な目標期日を設定してください。
2. Harden SPF 資格要件：DMARC 集計レポートで、すべての正当な送信者が要件を満たしていることが確認できたら、SPF レコードの末尾を「~all」から「-all」に変更してください。
3. MTA-STS と TLS-RPT を導入して、転送中のメールを保護しましょう。DMARC は送信者の身元を確認しますが、MTA-STS はサーバー間の転送時の暗号化を保護します。
4. DNSSECを正しく有効にする：DNSゾーンに署名し、レジストラが対応するDSレコードを公開して、信頼の連鎖を確立するようにしてください。
5. SPF ルックアップ制限の管理：DNS ルックアップの総数を注意深く監視してください。マクロベースのホスト型 SPF ツールを使用して、10 回というルックアップ上限に達しないようにしてください。
6. サブドメインを明示的に定義する：DMARCレコードに明示的なsp=ポリシーを設定し、攻撃者が保護されていないサブドメインをなりすますのを防ぎます。
7. 運用責任の割り当て：技術的な対策には定期的な監視が必要です。毎週DMARCレポートを確認する専任のチームメンバーを1名選定してください。

電子メール認証のギャップを埋める

2026年8月の調査によると、AI分野のトップ企業30社すべてが、メール認証の中核となる要素を導入しており、SPF、DKIM、DMARCはいずれの企業でも導入されています。しかし、これらの初期段階を過ぎると、導入は頭打ちになっています。MTA-STSを公開しているのは2社のみ、DNSSECによる署名を行っているのは6社のみ、そして19社は依然としてソフトフェイルのSPFレコードに依存しています。

AI部門は、初期設定フェーズを無事に完了しました。次のステップは、トランスポート暗号化やゾーン署名といった高度な制御手段を導入し、残りの課題を解消することです。これらの改善にはベンダーの変更は必要なく、運用面での注力だけで十分です。

ご自身のドメインの状況を確認したいですか？PowerDMARCの無料ドメインレコードチェッカーでドメインを確認したり、PowerDMARCの無料セキュリティツールスイートを活用してメールセキュリティ体制を強化したりすることができます。メールフィッシングは年々増加の一途をたどっており、ここで取り上げた企業は、まさに攻撃者がなりすましを好むタイプのブランドです。これらの脆弱性がご自身のドメインにどのような影響を与えるかについて詳しくお話ししたい場合は、弊社チームに直接お問い合わせください。

よくあるご質問

大手AI企業はDMARCを採用しているのでしょうか？

はい、当社の調査で評価対象となった主要AI企業30社のうち、100％が有効なDMARCレコードを公開しています。しかし、アクティブなポリシー（隔離または拒否）を適用しているのは90％にとどまり、10％は監視のみのモード（p=なし）のままとなっています。

AI企業のうち、DMARCをp=rejectで適用している企業はいくつあるでしょうか？

30社のうち、まさに15社（50.0％）がDMARCをp=rejectで適用しています。これは、幅広い業界ベンチマークで記録された現在の米国全国平均である49.0％と一致しています。

MTA-STSとは何ですか？また、なぜDMARCはそれに取って代わらないのでしょうか？

MTA-STSは、サーバー間で転送される電子メールに対して、暗号化されたTLS接続を強制します。DMARCは、送信者の身元を認証し、アドレスのなりすましを防止します。これらは電子メールの処理プロセスの異なる部分を保護しているため、どちらのプロトコルも他方を置き換えることはできません。

DNSSECは電子メールの認証において重要なのでしょうか？

はい、DNSSECは、DNSスプーフィングやキャッシュポイズニングからドメインを保護します。SPF、DKIM、DMARCレコードはDNSクエリに依存しているため、DNSSECにより、これらのポリシーレコードが転送中に改ざんされるのを防ぐことができます。

SPF ~all（ソフトフェイル）はセキュリティ上の問題となるのでしょうか？

ドメインで DMARC が p=quarantine または p=reject で適用されている場合は例外です。DMARC の適用が有効になっている場合、ソフトフェイルよりも優先されます。ただし、-all（ハードフェイル）に切り替えることで、SPF を個別に確認する受信者に対して、より強力なセキュリティシグナルを送ることができます。

SPF 10の検索制限とは何ですか？また、その制限に近づいているのは誰ですか？

RFC 7208では、サーバーの悪用を防ぐため、SPF評価における再帰的DNSルックアップを10回までに制限しています。10回を超えるとPermErrorが発生します。我々の調査では、Writerが9回でトップとなり、Perplexityが8回でそれに続いています。

この研究はどのように行われたのでしょうか？

データは2026年8月6日、パブリックな再帰型リゾルバに対するライブDNSクエリを用いて収集されました。RFC規格に基づく8つの主要な電子メールセキュリティプロトコルについて、AI分野の主要企業30社のコーポレート・アペックス・ドメインを評価しました。

• について
• 最新記事

ミレーナ・バグダサリャン

コンテンツスペシャリスト（勤務先： PowerDMARCの

ミレーナは、IT、サイバーセキュリティ、バーチャルイベントなどに関する魅力的なコンテンツ制作に7年以上の経験を持つ、熟練したライター兼コンテンツ制作者です。ニューヨーク大学アブダビ校、UWCチャイナ校、カレッジ・オブ・ヨーロッパなどの名門校を卒業。

最新記事 by Milena Baghdasaryan(全て見る)

• 世界最大手のAI企業におけるメール認証 - 2026年8月10日
• 2026年のビジネスメール詐欺（BEC）対策ツール トップ5 - 2026年7月31日
• 無料のDMARCツール：チェッカー、ジェネレーター、モニタリング（2026年） - 2026年7月30日