Microsoft Defender for Office 365でメールが「なりすまし」「DMARC失敗」「迷惑メール」「検疫」と判定される場合、原因が攻撃ではなく、正当なメールゲートウェイやセキュリティサービスによるメッセージ加工にあることがあります。そこで確認したいのが、trusted ARC sealers（信頼できるARCシーラー）の設定です。
結論から言うと、trusted ARC sealersは「すべてのテナントで何となく追加する設定」ではありません。Proofpoint、Mimecast、Barracuda、Sophosなどの中間メールサービスがARCヘッダーを付与しており、そのサービス経由の正当なメールがSPF、DKIM、DMARCの失敗で誤判定されている場合に、メールヘッダーのd=値を確認したうえで必要なベンダードメインだけを登録する設定です。Microsoft Learn日本語版の該当ページは2026年6月2日に更新表示されており、ベンダー別のARCシーラードメイン、検証方法、失敗時の切り分けがより実務向けに整理されています。(Microsoft Learn)
Microsoft Defenderのtrusted ARC sealersとは
trusted ARC sealersは、Microsoft 365に届く前にメールを処理した中間サービスを、Microsoft Defender for Office 365側で「信頼できるARCシーラー」として扱うための設定です。
通常、Microsoft 365ではSPF、DKIM、DMARCなどのメール認証を使い、なりすまし送信者やフィッシングを検出します。しかし、正当なメールセキュリティゲートウェイ、DLP、アーカイブ、転送サービス、メール配送基盤などが、配信途中でヘッダーや本文、添付ファイルを変更すると、以下のような認証失敗が起こり得ます。(Microsoft Learn)
| 認証方式 | 中間サービスで起きやすい問題 | 結果 |
|---|---|---|
| SPF | Microsoft 365から見る送信元IPが変わる | 元の送信ドメインのSPFに失敗する |
| DKIM | 本文やヘッダーが変更される | DKIM署名の検証に失敗する |
| DMARC | SPFまたはDKIMが失敗する | DMARCも失敗しやすくなる |
ARC、つまりAuthenticated Received Chainは、こうした中間サービスによる正当な変更があった場合に、変更前のメール認証結果を保持する仕組みです。Microsoft 365側でそのARCシーラーを信頼すると、Microsoft 365はARCシーラーが保持した元の認証情報を使って、受信メールの検証に活用できます。(Microsoft Learn)
重要なのは、ARCは「危険なメールを通すための許可リスト」ではないという点です。あくまで、正当な中間サービスによる変更で認証が壊れるケースを補正するための仕組みです。
2026年6月2日更新情報で管理者が押さえるべき変更点
今回の公式情報で実務上の確認ポイントになるのは、単なる設定手順ではなく、どのベンダードメインを登録するか、設定後にどう検証するか、失敗時にどこを見るかが具体化されている点です。GitHub上の履歴では、2026年5月28日の更新でトラブルシューティング情報などが大幅に追加され、253行追加・8行削除の変更が行われたことも確認できます。(GitHub)
| 確認ポイント | 公式情報で整理された内容 | 管理者が取るべき対応 |
|---|---|---|
| ベンダー別ARCシーラードメイン | Proofpoint、Mimecast、Barracuda、Sophosの代表的なd=値とセレクターが掲載 | 自社ドメインではなく、実メールヘッダーのd=値を確認して登録する |
| 複数ベンダー利用時の設定 | 複数ドメインを1つの設定に含める必要がある | 既存値を上書きしないよう、現行設定を取得してから変更する |
| 設定後の検証 | arc=pass、oda=1、必要に応じてcompauth=pass reason=130を確認 | 設定後すぐではなく、反映時間を考慮して新規メールでテストする |
| 失敗時の切り分け | arc=fail、arc=none、oda=0、cv=failなどの症状別に原因が整理 | ヘッダー、ARCチェーン、ベンダー側ARC署名、スパム対策ポリシーを分けて確認する |
| 過剰登録のリスク | 使用していないベンダーを追加すると攻撃対象領域が広がる | 現在利用中で信頼できるサービスだけを登録する |
特に注意したいのは、ARCシーラードメインは自社のメールドメインではなく、ARC-Sealヘッダーのd=に表示されるベンダーの署名ドメインである点です。Microsoftの公式情報でも、設定前に実際のメッセージヘッダーからd=値を必ず確認するよう示されています。(Microsoft Learn)
影響範囲：確認が必要な環境、不要な環境
trusted ARC sealersの対象は、Microsoft Defender for Office 365 Plan 1/Plan 2、Microsoft Defender XDR、クラウドメールボックス向けの組み込みセキュリティ機能に関連するMicrosoft 365環境です。(Microsoft Learn)
ただし、対象サービスを契約しているからといって、必ず設定すべきとは限りません。確認すべきなのは、次のような構成です。
| 環境 | 確認すべき理由 | 代表例 |
|---|---|---|
| Microsoft 365の前段にメールセキュリティゲートウェイがある | ゲートウェイがメールを加工し、SPF/DKIM/DMARCが失敗する可能性がある | Proofpoint、Mimecast、Barracuda、Sophosなど |
| メール転送、メーリングリスト、DLP、アーカイブを経由する | ヘッダーや本文、添付ファイルの変更で認証結果が変わることがある | 外部中継、監査基盤、添付ファイル無害化 |
| MXレコードを段階的に切り替えている | 移行中に旧ゲートウェイ経由とMicrosoft 365直送が混在する | MimecastなどからMicrosoft 365ネイティブ保護へ移行 |
| 正当なメールがDMARC失敗で検疫・迷惑メール化している | ARCで元の認証情報を参照できる可能性がある | 取引先メール、業務SaaS通知、転送メール |
一方、受信メールがMicrosoft 365へ直接届いており、途中で正当なサービスによる変更が発生していない場合、trusted ARC sealersを追加する必要性は低いです。また、ARCヘッダーを付与しない中間サービスを使っている場合、Microsoft 365側だけでARCシーラーを登録しても効果は期待できません。公式のトラブルシューティングでも、arc=noneは中間サービスがARCヘッダーを追加していない状態として整理されています。(Microsoft Learn)
設定前に確認すべき権限と前提条件
trusted ARC sealersの設定は、Microsoft DefenderポータルまたはExchange Online PowerShellから行います。作業前に、少なくとも次の3点を確認してください。
| 確認項目 | 内容 |
|---|---|
| 管理権限 | DefenderポータルではDefender XDRの統合RBAC、Exchange OnlineではOrganization ManagementまたはSecurity Administratorロールグループなどが関係する |
| ヘッダー確認手段 | Outlookのインターネットヘッダー表示、またはMessage Header AnalyzerなどでARC-Seal:を確認する |
| 変更前バックアップ | PowerShellでGet-ArcConfigを実行し、既存のArcTrustedSealersを保存しておく |
Microsoft公式情報では、作業に必要なアクセス許可としてDefender XDR統合RBAC、Exchange Onlineアクセス許可、Microsoft Entraアクセス許可が挙げられており、グローバル管理者は非常に強い権限であるため緊急時などに限定すべきと説明されています。運用上は、日常作業をグローバル管理者で行うのではなく、必要最小限の権限を割り当てる設計にしてください。(Microsoft Learn)
Microsoft Defenderポータルでtrusted ARC sealersを追加する手順
Microsoft Defenderポータルで設定する場合は、次の流れで進めます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Defenderポータルを開く | 管理対象テナントが正しいか確認する |
| 2 | [メールとコラボレーション] > [ポリシーとルール] > [脅威ポリシー] > [メール認証設定] > [ARC]へ進む | 画面名は環境や表示言語で多少異なる場合がある |
| 3 | [追加]または既存一覧がある場合は[編集]を選ぶ | 既存の信頼済みシーラーを削除しないよう注意する |
| 4 | 信頼する署名ドメインを入力する | 自社ドメインではなく、ARC-SealまたはARC-Message-Signatureのd=値を使う |
| 5 | 保存する | 設定後、反映まで最大30分を見込んでテストする |
公式手順では、入力するドメインは影響を受けるメッセージのARC-SealおよびARC-Message-Signatureヘッダーにあるd値と一致する必要があるとされています。ここを間違えると、設定済みでもoda=0になり、Microsoft 365がそのARCシーラーを信頼済みとして扱えません。(Microsoft Learn)
Exchange Online PowerShellで設定する手順
複数テナントを管理している場合、変更履歴を残したい場合、既存設定を確認しながら登録したい場合は、Exchange Online PowerShellでの作業が向いています。Set-ArcConfigは、クラウドベースの組織で信頼済みARCシーラーの一覧を変更するためのコマンドレットです。(Microsoft Learn)
まず、現在の設定を確認します。
Get-ArcConfig信頼済みARCシーラーが未構成の場合、結果は返りません。(Microsoft Learn)
新しく設定する基本形は次のとおりです。
Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com","mimecast.com"ただし、ここで最も失敗しやすいのが既存設定の上書きです。-ArcTrustedSealersパラメーターは、指定した値を追加するのではなく、既存の一覧を指定値で置き換えます。既存値を残したい場合は、残すドメインと新しく追加するドメインを同時に含める必要があります。(Microsoft Learn)
安全に追加するなら、次のように現行値を取得してから結合します。
$config = Get-ArcConfig -ErrorAction SilentlyContinue
$current = @()
if ($config -and $config.ArcTrustedSealers) {
$current = @($config.ArcTrustedSealers)
}
$add = @("pphosted.com")
$updated = @($current + $add | Sort-Object -Unique)
Set-ArcConfig -Identity Default -ArcTrustedSealers $updated削除する場合も、いきなり空の値を投げるのではなく、対象だけを除外してから反映します。公式ドキュメントでは、一覧を空にする場合は" "、つまり二重引用符で囲んだスペースを使う例が示されています。(Microsoft Learn)
$config = Get-ArcConfig
$current = @($config.ArcTrustedSealers)
$remove = "mimecast.com"
$updated = @($current | Where-Object { $_ -ne $remove })
if ($updated.Count -eq 0) {
Set-ArcConfig -Identity Default -ArcTrustedSealers " "
}
else {
Set-ArcConfig -Identity Default -ArcTrustedSealers $updated
}代表的なベンダー別ARCシーラードメイン
公式情報では、よく使われるメールセキュリティベンダーのARCシーラードメインが整理されています。以下は設定時の目安ですが、実際には必ず自社に届いたメールヘッダーでd=値を確認してください。Proofpointのように、展開によってカスタムドメインが使われる可能性もあります。(Microsoft Learn)
| ベンダー | ARCシーラードメインの例 | セレクターの例 | 登録時の注意点 |
|---|---|---|---|
| Proofpoint | pphosted.com | arcselector | 一部展開では別ドメインの可能性があるため、必ず実ヘッダーを確認 |
| Mimecast | mimecast.com | arc-2018 | Microsoft 365ネイティブ保護へ移行中は、MX切り替えとキュー消化まで設定を維持 |
| Barracuda | barracudanetworks.com | arc1 | Barracuda製品側でARCが有効か確認 |
| Sophos | sophos.com | arc | Sophos Central側のARC設定も確認 |
登録すべき値は、自社のexample.co.jpのようなメールドメインではありません。たとえばProofpoint経由のメールでヘッダーに次のような値がある場合、登録候補はpphosted.comです。
ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;自社ドメインを登録してしまうと、Microsoft 365は実際のARCシーラーと一致させられず、期待した補正が働きません。
設定後の検証方法
trusted ARC sealersを追加したら、過去に届いたメールではなく、設定反映後に新しく届いたテストメールで確認します。Microsoft公式情報では、信頼済みARCシーラーの追加・変更後、構成が有効になるまで最大30分かかる可能性があるため、その後に送信された新しいメッセージでテストするよう示されています。(Microsoft Learn)
確認すべきヘッダーは主に2つです。
ARC-Authentication-Resultsで確認する値
最後のARC-Authentication-Resultsヘッダーで、次の値を確認します。
arc=pass
oda=1arc=passは前段のARCが検証されたこと、oda=1は前段のARCシーラーが信頼済みであることを示します。これにより、前段で保持された認証結果を現在のDMARC失敗の補正に使える状態になります。(Microsoft Learn)
Authentication-Resultsで確認する値
ARC結果によってDMARC失敗が補正されたかを見る場合は、最後のAuthentication-Resultsヘッダーで次の値を探します。
compauth=pass reason=130reason=130は、信頼済みARCシーラーによるARCオーバーライドで複合認証がパスしたことを示します。ただし、最終的ななりすまし判定はCompAuthの結果に基づきます。ARCに失敗しても、SPF、DKIM、DMARC、複合認証で問題がなければ配信される可能性があります。(Microsoft Learn)
ARCが通っても迷惑メールや検疫になる理由
よくある誤解は、「ARCがpassなら必ず受信トレイに入る」と考えてしまうことです。実際には、ARCが補正できるのは主に中継中の変更で発生したDMARC認証失敗です。Microsoft公式情報でも、ARCはコンテンツベースのスパムフィルター、BCL、スパム対策ポリシー、メールフロールール、許可/ブロック送信者リストをバイパスするものではないと説明されています。(Microsoft Learn)
| 状況 | ARCで解決できる可能性 | 確認すべき場所 |
|---|---|---|
| 中間サービスで本文が変更されDKIMが失敗 | 高い | ARC-Authentication-Results、Authentication-Results |
| 中間サービスで送信元IPが変わりSPFが失敗 | 高い | arc=pass、oda=1 |
| ARCはpassだがSCLが高い | 低い | X-Forefront-Antispam-Report |
| メールフロールールで検疫している | 低い | Exchange管理センターのメールフロールール |
| ベンダーがARCヘッダーを付けていない | 低い | ARC-Seal:の有無 |
| ARCチェーンが壊れている | 中程度 | cv=fail、各i=のARCヘッダー |
X-Forefront-Antispam-ReportでSCL:5以上、またはCAT:SPMなどが見える場合は、ARCではなくスパム判定側の問題として切り分けます。この場合、送信元の正当性、配信内容、スパム対策ポリシー、誤検知申請などを確認する必要があります。(Microsoft Learn)
よくある失敗パターンと対処法
trusted ARC sealersの設定で失敗しやすいポイントは、ほとんどが「登録する値の誤り」「ベンダー側のARC未有効化」「ARCチェーン破損」「ARCとスパム判定の混同」です。公式情報で整理されている症状を、運用時に使いやすい形にすると次のようになります。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
arc=fail | ARCシーラードメインが未登録、または誤登録 | ARC-Sealのd=値を確認し、正しいドメインを登録 |
arc=none | 中間サービスがARCヘッダーを追加していない | ベンダー側でARC署名を有効化できるか確認 |
arc=passだがoda=0 | ARC自体は通っているが、シーラーが信頼済みではない | Set-ArcConfigで正しいd=値を追加 |
compauth=fail reason=000 | ARCチェーン検証に失敗している | cv=値を各ARCインスタンスで確認 |
dmarc=failでARCヘッダーなし | ARC対応の中間サービスを通っていない | 送信元のSPF/DKIM/DMARC設定を修正 |
| ARC passでも検疫される | スパム対策ポリシーやメールフロールールが影響 | 検疫ポリシー、SCL、ルール、許可/ブロック設定を確認 |
| 自社ドメインを登録した | ベンダーの署名ドメインではない値を設定している | 実ヘッダーのd=値に合わせて修正 |
特に危険なのは、「迷惑メールを減らしたいから、関係しそうなベンダードメインをまとめて入れておく」という運用です。公式情報では、アクティブに使用して信頼しているベンダーのみを追加するよう注意されています。不要なARCシーラーを追加すると、侵害されたベンダー経由でなりすましメッセージが認証チェックを通過するリスクが高まります。(Microsoft Learn)
移行・展開時の注意点
Microsoft 365のメール保護を見直すタイミングでは、trusted ARC sealersの扱いを変更管理に含める必要があります。特に、外部メールゲートウェイからMicrosoft 365 Defenderのネイティブ保護へ移行する場合は、MXレコードの切り替え、キューに残ったメール、並行運用期間を考慮します。
| フェーズ | 確認すること | 失敗しやすいポイント |
|---|---|---|
| 現状調査 | 受信経路、MX、メールゲートウェイ、DLP、アーカイブ、転送サービスを棚卸しする | 「誰も管理していない旧ゲートウェイ」が残っている |
| ヘッダー確認 | 実メールからARC-Seal:とd=値を確認する | ベンダー資料だけを見て実メールを確認しない |
| 事前設定 | Get-ArcConfigで既存値をバックアップする | Set-ArcConfigで既存値を上書きする |
| 段階展開 | 一部ドメイン・一部送信元でテストする | 反映前のメールで検証して誤判断する |
| 移行完了 | 使わなくなったベンダードメインを削除する | 旧ベンダーを信頼済みのまま放置する |
| 監視 | 検疫、迷惑メール、誤検知、reason=130の有無を確認する | ARCでは解決できないスパム判定までARC設定で直そうとする |
MimecastからMicrosoft 365ネイティブ保護へ移行するケースでは、公式情報で、MXレコードを完全に切り替え、キューに入ったすべてのメッセージが配信されるまでMimecastのtrusted ARC sealerを維持するよう案内されています。これは、切り替え直後に旧経路のメールがまだ届く可能性があるためです。(Microsoft Learn)
開発者・SaaS運用者が確認すべきポイント
開発者やSaaS運用者がMicrosoft 365テナント管理者ではない場合でも、trusted ARC sealersに関係する場面があります。たとえば、通知メール配信基盤、チケットシステム、メールアーカイブ、メーリングリスト、メール転送、添付ファイル加工、DLPなどを提供している場合です。
この場合、Microsoft 365側の設定だけでなく、送信・中継サービス側で次の点を確認してください。
| 確認項目 | 実務上の意味 |
|---|---|
| ARC署名を付与しているか | Microsoft 365側で信頼設定しても、ARCヘッダーがなければ機能しない |
d=値が安定しているか | 顧客に案内するARCシーラードメインが環境ごとに異なる可能性がある |
| メッセージ変更の順序 | ARCシール後に本文やヘッダーを変更するとARCチェーンが壊れる可能性がある |
| ARC公開キーのDNS公開 | DNS参照に失敗するとcv=failなどの原因になる |
| 顧客向けドキュメント | 「登録すべき値は顧客ドメインではなく、ARC-Sealのd=値」と明記する |
公式情報では、壊れたARCチェーンの原因として、ARCシール後に前段の中継サービスがメッセージを変更したケース、ARCシーラーの公開キー参照を妨げるDNS問題、公開キーのローテーションとDNSキャッシュの影響などが挙げられています。開発者側では、メッセージ加工をARC署名前に完了させる設計、DNS TXTレコードの公開確認、キー更新時の運用設計が重要です。(Microsoft Learn)
設定するか迷ったときの判断基準
trusted ARC sealersを設定するかどうかは、次の順番で判断すると安全です。
| 判断質問 | Yesの場合 | Noの場合 |
|---|---|---|
| Microsoft 365の前段にメールを加工する中間サービスがあるか | 次へ進む | 設定不要の可能性が高い |
| そのサービスはARCヘッダーを付与しているか | ARC-Sealのd=値を確認 | ベンダー側でARC有効化可否を確認 |
| 正当メールがSPF/DKIM/DMARC失敗で誤判定されているか | trusted ARC sealer設定を検討 | まずメール認証・スパム判定の原因を調査 |
登録対象のd=値を実ヘッダーで確認したか | 変更前バックアップ後に設定 | まだ設定しない |
設定後にarc=pass、oda=1を確認できるか | 展開継続 | ヘッダー、ベンダー設定、ARCチェーンを再確認 |
判断に迷う場合は、まず「ARCで直したい問題なのか」を切り分けてください。DMARC失敗が中間サービスによる変更で起きているならARCが有効に働く可能性があります。一方、本文内容がスパム判定されている、送信元レピュテーションが低い、メールフロールールで検疫している、といった問題はARCだけでは解決できません。
管理者が今すぐ確認すべきチェックリスト
最後に、Microsoft Defender for Office 365を運用している管理者が取るべき行動を整理します。
- 受信メール経路に、外部メールゲートウェイ、DLP、アーカイブ、転送サービスがあるか棚卸しする
- 誤判定された正当メールのヘッダーで
ARC-Seal:、ARC-Message-Signature、d=値を確認する Get-ArcConfigで現在のtrusted ARC sealers設定を保存する- 自社ドメインではなく、実ヘッダーにあるベンダーの
d=値だけを登録する - 複数ベンダーを使う場合は、既存値を含めたうえで
Set-ArcConfigを実行する - 設定後は最大30分待ち、新しいテストメールで
arc=pass、oda=1、必要に応じてcompauth=pass reason=130を確認する - ARC pass後も迷惑メールや検疫になる場合は、SCL、BCL、スパム対策ポリシー、メールフロールールを別問題として確認する
- 移行完了後、使わなくなったベンダードメインをtrusted ARC sealersから削除する
trusted ARC sealersは、Microsoft Defenderの検出を弱める設定ではなく、正当な中間メールサービスによって壊れた認証結果を正しく評価するための設定です。最初にやるべきことは、ベンダー名を見て登録することではありません。実際のメールヘッダーを確認し、d=値、ARCの有無、DMARC失敗の原因を切り分けることです。そのうえで、必要なARCシーラーだけを最小限に登録し、反映後のヘッダーで検証してください。
コメント