compauth=fail：Microsoft 複合認証の解説

SPF、DKIM、DMARCを設定したにもかかわらず、メールが依然としてOutlookの迷惑メールフォルダに振り分けられてしまうことがあります。その原因は、多くの場合「compauth=fail」という、標準的なグローバルプロトコルを超えるMicrosoft独自の認証レイヤーにあります。この診断シグナルが何を意味するのか、なぜDMARCとは異なるのか、そして2025年5月のアップデート以降、なぜこれまで以上に重要になっているのかを理解することは、ビジネスメールの配信率を維持するために不可欠です。

複合認証（compauth）とは何ですか？

複合認証（compauth）は、Microsoft 365 および Outlook の Exchange Online Protection（EOP）で使用される、Microsoft 独自の認証スコアリングシステムです。

標準的なSPF、DKIM、DMARCが、標準規格に基づいた明示的な検証チェックとして機能するのとは異なり、compauthは複合的なインテリジェンススコアとして機能します。これは、明示的な認証結果に加え、送信者のレピュテーション、過去のやり取りのパターン、マイクロソフトの内部スプーフィング情報、行動分析などの高度な暗黙的なシグナルを組み合わせています。

最終的な評価結果は、Microsoft 365 で処理されるすべての受信メッセージの Authentication-Results ヘッダーに格納されます。このハイブリッドチェックの結果に応じて、ヘッダーには以下の 4 つの値のいずれかが表示されます：

• compauth=pass: このメッセージは、明示的な認証チェックと暗黙的な安全性評価の両方に合格しました。
• compauth=fail: このメッセージは、Microsoftの複合認証基準を満たしておらず、極めて不審なものと判断されました。
• compauth=softpass: 堅牢な明示的な認証が行われていないにもかかわらず、暗黙的またはレピュテーション信号を介してメッセージが送信された。
• compauth=none: メッセージに対して複合認証の評価は行われませんでした。

Microsoft 365 のメール認証設定についてさらに詳しく知りたい場合は、Office 365 向け DMARC に関するガイドをご覧ください。

compauthとDMARC：その違いとは？

システム管理者にとって、メールが標準的なDMARC検証を通過したにもかかわらず、同時に「compauth=fail」ステータスが発生するという状況は、よく混乱を招く原因となります。

こうした違いがあるため、メッセージが明示的なDMARC検証を問題なく通過したとしても、Microsoftの機械学習モデルによって異常と判定された場合（例：新規登録されたドメイン、送信量の急激な増加、またはパッシブなp=none監視ポリシーで運用されているドメインなど）、compauth=failというステータスが返されることがあります。

逆に、メッセージが明示的なSPFやDKIMのチェックに失敗しても、Microsoftのなりすまし検知機能やローカルな安全送信者履歴がその正当性を裏付ける場合（ARCのオーバーライドによるreason=130や、内部で信頼されているM365送信者に対するreason=201など）、compauth=passとなる可能性があります。

compauthの理由コードとは何ですか？

メールのヘッダーを分析すると、「compauth=fail」または「compauth=pass」という文字列の後に、3桁の具体的な理由コードが続きます。このコードは、Microsoftのフィルタリングエンジンが判断を下した正確な理由を示しています。

注：すべての理由コードは、Microsoftの公式技術ドキュメントから直接引用したものです。送信メッセージを迅速に診断するには、生のメールヘッダーをコピーして、Webベースの「Microsoft Message Header Analyzer」に貼り付けてください。

2025年5月以降、「compauth=fail」がより重要になる理由

2025年5月5日にマイクロソフトが実施した規制強化に伴い、「compauth=fail」という結果がもたらす運用上の影響は、大幅に深刻化しました。マイクロソフトの「送信者要件」では、Outlook.com、Hotmail、Live.comなどの一般ユーザー向けエンドポイントに対して、1日あたり5,000通以上のメッセージを送信する大量送信者を対象とした、厳格かつ自動化された電子メール認証要件が導入されました。

この更新された適用メカニズムの下では、「compauth=fail」という分類は、ゲートウェイレベルでのスパムフォルダへの強制的な振り分け、あるいはメッセージの完全な拒否に直結します。Microsoftのフィルタリングでは、SPFやDKIMが個別に合格している場合でも、p=noneのDMARCポリシーをreason=001の主なトリガーとして扱うようになりました。これまでパッシブ監視モード下でメール配信が容認されていた送信者であっても、Microsoftが管理するすべての環境において、配信率が急激かつ著しく低下する事態に直面することになります。

「compauth=fail」の原因は何ですか？

配信に関する問題を解決するには、Authentication-Resultsヘッダーに記載されている具体的なエラーコードと、その根本原因を照合する必要があります：

• reason=000:送信ドメインのDMARCポリシーが「p=reject」または「p=quarantine」の厳格な設定となっており、メッセージがSPFおよびDKIMの両方の検証に失敗しました。認証失敗の解決方法に関する詳細なトラブルシューティング手順については、DMARCが失敗する原因に関するガイドをご参照ください。
• reason=001 (標準):これは最も一般的なエラーコードです。これは、パッシブな p=none モニタリングポリシーを使用しているドメイン、DMARC レコードが完全に欠落している場合、最適化されていない SPF ソフトフェイル (~all)、または識別子ドメインの不一致を示しています。
• reason=001 および reason=601（サードパーティ送信者）：これは、外部のメールサービスプロバイダー（ESP）やCRMが貴社ブランドに代わってメッセージを送信する際、自社のインフラストラクチャドメインを使用してメッセージに署名した場合に発生します。表示される「From」ヘッダーのドメインが、プロバイダーが使用するトラッキングドメインと一致しないため、重大な整合性エラーが発生します。
• reason=010: Microsoftのなりすまし検知機能により、送信者の行動がフィッシングやドメインなりすましに該当する不正なものと判定されました。

「compauth=fail」の解決方法

複合認証の失敗を修正するには、エラーの原因となっている具体的な状況に応じて、適切な設定変更を行う必要があります。

解決策 1: DMARC ポリシーを p=none より上位のレベルに更新する

パッシブ監視ポリシー（p=none）は暗黙的な認証失敗（reason=001）として扱われるため、ドメインを強制適用モードへ移行させる必要があります。ポリシーを安全に p=quarantine または p=reject へ段階的に移行させてください。監視のみの姿勢から脱却することで、暗黙的な失敗ルールを引き起こす脆弱性が解消されます。この移行期間中に正当なレガシーストリームがブロックされることを懸念される場合は、DMARC ポリシーのオーバーライドを管理するための当社の戦略をご確認ください。

解決策 2: DKIM の正確な整合性を確保する

プライマリメールサーバーを設定し、一意の暗号化DKIMキーを使用してすべての送信メッセージに署名するようにしてください。DKIMヘッダー内の署名ドメインパラメータ（d=）が、表示される「From:」ヘッダーに表示されるルートドメインと完全に一致していることを確認してください。この厳密な暗号化の一致は、MicrosoftのCompAuthエンジンに対して、可能な限り強力な肯定的なシグナルとなります。

解決策 3: サードパーティ製メール配信サービス（ESP）向けにカスタム・リターンパスを設定する

外部プラットフォーム（マーケティングエンジンやサポートデスクなど）を利用する際は、それらのデフォルトの汎用設定に依存しないでください。自社のドメイン名を使用した独自の「MAIL FROM」または「Return-Path」ドメインを設定するか、プロバイダーが自社のドメインのDKIMキーを使用してメッセージに暗号署名できるよう、完全に委任されていることを確認してください。これにより、識別子の不一致が解消され、「reason=601」エラーが発生しなくなります。

修正4と転送の将来像（ARCからDKIM2へ）

従来、組織内のメールの送信経路にメーリングリストや自動転送チェーンが常時含まれている場合、標準的なDKIM署名は機能しませんでした。この問題を解決するために、 Authenticated Received Chain (ARC) を導入することが標準的な推奨策でした。中継サーバーが受信メッセージを検証し、信頼できる暗号化スタンプを使用して署名すると、Microsoft 365はカストディチェーンを読み取り、局所的な失敗を無視して「compauth=pass reason=130」という成功メッセージを出力します。

しかし、電子メール認証の情勢は急速に変化しています。2026年4月22日、IETFのDMARCワーキンググループによる提案（draft-ietf-dmarc-arc-to-historic-00）において、ARCを「歴史的標準」として再分類することが提案されました。これはワーキンググループによるインターネットドラフトであり、確定したRFCではありません。ARC（RFC 8617）は現在も有効なプロトコルとして存続しています。

ARCから得られた知見は、新たに登場しつつある DKIM2仕様にネイティブに組み込まれており、これによって転送時の署名の破損やDKIMリプレイ攻撃への対応が図られています。2026年5月17日付の最新のIETFドラフト（draft-ietf-dkim-dkim2-spec-02）では、メッセージを扱う各システムが変更内容を記録し、改ざん不可能な管理履歴（チェーン・オブ・カスターディ）に独自の署名を付加するようになっています。

現時点で、これが皆様にとってどのような意味を持つか：

• 当面はARCを有効にしておいてください。Microsoftは依然としてreason=130（ARCオーバーライド）を使用して転送メールを送信しているため、Microsoft Trusted ARC Sealの設定を今すぐ削除しないでください。
• DKIM2への備え：仕様は依然として初期草案段階にあるものの、主要なメールボックスプロバイダーでは2026年後半から導入が開始される可能性があります。DKIM2の鍵は既存のDNSレコード構造を利用するため、将来の認証失敗を防ぐ最善の策は、現在のDKIM基盤に不備がないことを確認することです。不要なセレクタを削除し、適切な鍵のローテーションを実施してください。

解決策 5: M365 スプーフィングインテリジェンスを活用してエントリを許可する

社内アプリケーション、レガシーのオンプレミス型アプライアンス、または高度に特殊化された正当な送信者プロファイルにおいて、自動機械学習による誤検知（理由=010）が発生する場合、Microsoft 365 管理者はアルゴリズムを手動で上書きできます。Microsoft 365 Defender ポータルに移動し、Spoof Intelligence インサイト コンソールを開き、その特定の送信者プロファイルに対して、テナントの許可/ブロック リストに明示的な許可エントリを追加してください。

メールヘッダーのcompauthの読み方

これらの値を特定し、診断するには、影響を受けたメッセージから生のインターネットルーティングヘッダーを抽出する必要があります。

1. ヘッダーの抽出：デスクトップ版のOutlookで、対象のメールを別ウィンドウで開き、「ファイル」＞「プロパティ」＞「インターネットヘッダー」の順に選択します。あるいは、管理者が広範囲にわたる配信の問題をトラブルシューティングしている場合は、ユーザーに指示するか、管理ログを使用して生のヘッダーテキストをコピーし、mha.azurewebsites.net のMicrosoft Message Header Analyzer (MHA)に直接貼り付けることで、スキャンしやすく解析済みの形式で表示させることができます。
2. 該当行を特定する：解析済みのテキストの中から、「Authentication-Results」というラベルが付いた特定のブロックを探します。「compauth=」というフレーズを注意深く確認してください。その直後に、評価結果（pass、fail、またはsoftpass）と、それに対応するreason=コードが続きます。
3. データの相互参照：複合認証の結果を単独で判断しないでください。そのヘッダー行内の隣接するパラメータ、特に個々の spf=、dkim=、および dmarc= の結果を確認してください。これらの明示的な値を複合認証の理由コードと並べて比較することで、どのチェックが失敗したか、あるいはどの暗黙的なシグナルが迷惑メールフォルダへの振り分けを引き起こしたかを正確に特定できます。

「compauth=fail」エラーを完全に防ぐにはどうすればよいですか？

数十社に及ぶサードパーティベンダーのヘッダーを手作業で分析し、各社の設定を調整することは、社内ITチームにとって大きな負担となります。PowerDMARCは、包括的な可視化機能と自動化された管理ツールを提供することでこのプロセスを簡素化し、compauth=failエラーの解決や、メール認証レコードの健全な状態維持を支援します。

今すぐDMARCの無料トライアルを開始して、Microsoft 365の配信状況を明確に把握し、設定の不整合を解消し、ドメインを強制的なDMARCポリシーへ安全に移行しましょう。

よくあるご質問

メールヘッダーにおける「compauth=fail」とはどういう意味ですか？

これは、MicrosoftのExchange Online Protectionシステムが受信メッセージを評価し、明示的な認証プロトコル（SPF、DKIM、DMARC）と、暗黙的な脅威インテリジェンスのシグナル（送信者のレピュテーション、なりすまし情報、履歴）を組み合わせて判断した結果、そのメッセージを拒否したことを示しています。

compauthとDMARCの違いは何ですか？

DMARCは、すべてのメールボックスプロバイダーが識別子の整合性を確認するために使用する、オープンなグローバルインターネットプロトコルです。compauthは、標準的なDMARCの結果に加え、リアルタイムのレピュテーションや行動指標を反映させる、Microsoft独自の評価レイヤーです。

SPFとDKIMが有効なのに、なぜCompAuthは失敗するのでしょうか？

ドメインに「p=none」のパッシブなDMARCポリシーが設定されている場合、この現象は頻繁に発生します。Microsoftの更新されたシステムでは、これを配信リスクと見なすためです。また、Microsoftの内部スプーフィング検知システムが、送信者のトランザクション行動や送信履歴を異常であると判定した場合にも、配信に失敗することがあります。

「compauth fail reason=001」とはどういう意味ですか？

理由コード 001 は、メッセージが Microsoft の暗黙的な認証基準を満たしていないことを意味します。これは通常、DMARC または SPF レコードの欠落、識別子の不一致、あるいは強制適用段階に進まずに「p=none」のパッシブな DMARC ポリシーを維持していることが原因で発生します。

Microsoft 365 で「compauth=fail」のエラーを解決するにはどうすればよいですか？

SPFおよびDKIMのドメインが、ヘッダーの「From」フィールドと完全に一致していることを確認してください。また、DMARCポリシーを「p=none」から「p=quarantine」や「p=reject」などの強制適用状態へ変更し、メールの転送に自動化されたプロセスが関与している場合は、信頼できるARCシールを設定してください。

compauth=fail を設定すると、Outlookでメールが迷惑メールフォルダに入ってしまうのでしょうか？

はい。厳格なセキュリティ対策に基づき、「compauth=fail」というステータスは、EOPフィルタリングエンジンが受信メッセージを直接迷惑メールフォルダへ振り分けるか、あるいはネットワークの境界で完全に拒否する直接的なトリガーとなります。

• について
• 最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• DKIMレコードの分割方法 - 2026年6月5日
• compauth=fail：Microsoft 複合認証の解説 - 2026年6月1日
• Windows Defenderだけで中小企業のセキュリティは十分か？ - 2026年5月14日