Email認証は、Microsoft 365 organizationとの間で送受信されるメールを検証し、ビジネス メール侵害 (BEC)、ランサムウェア、その他のフィッシング攻撃で使用されるなりすまし送信者を防ぐのに役立ちます。
ただし、正当なメール サービスによっては、メッセージが Microsoft 365 organizationに配信される前に変更される場合があります。 転送中の受信メッセージを変更すると、Microsoft 365 で次の電子メール認証エラーが発生する可能性があります。
- SPF は、新しいメッセージ ソース (IP アドレス) のために失敗します。
- コンテンツの変更により DKIM が失敗します。
- DMARC は SPF および DKIM エラーのために失敗します。
認証された受信チェーン (ARC) は、正当な電子メール サービスによるメッセージの変更による受信電子メール認証エラーを減らすのに役立ちます。 ARC は、電子メール サービスで元の電子メール認証情報を保持します。 メッセージを変更したサービスを信頼し、電子メール認証チェックでその元の情報を使用するように、Microsoft 365 organizationを構成できます。
信頼できる ARC シールを使用するタイミング
Microsoft 365 organizationは、Microsoft 365 受信者に配信されるメッセージが次の方法で定期的に影響を受ける場合にのみ、信頼できる ARC シーラーを識別する必要があります。
- 中間サービスは、メッセージ ヘッダーまたは電子メール コンテンツを変更します。
- メッセージの変更により、他の理由で認証が失敗します (添付ファイルを削除するなど)。
管理者が Defender ポータルで信頼できる ARC シーラーを追加した後、Microsoft 365 は ARC シーラーが提供する元の電子メール認証情報を使用して、サービスを通じて Microsoft 365 に送信されるメッセージを検証します。
ヒント
Microsoft 365 organizationに信頼できる ARC シーラーとして、正当で必要なサービスのみを追加します。 このアクションは、影響を受けるメッセージが電子メール認証チェックに合格するのに役立ち、電子メール認証エラーが原因で正当なメッセージが迷惑メール Email フォルダーに配信されたり、検疫されたり拒否されたりするのを防ぎます。
はじめに把握しておくべき情報
「https://security.microsoft.com」で Microsoft Defender ポータルを開きます。 Email認証設定ページに直接移動するには、https://security.microsoft.com/authenticationを使用します。
Exchange Online PowerShell へ接続するには、「Exchange Online PowerShell に接続する」を参照してください。 スタンドアロンの EOP PowerShell に接続するには、「Exchange Online Protection PowerShell への接続」を参照してください。
この記事の手順を実行する前に、アクセス許可を割り当てる必要があります。 以下のオプションがあります。
Microsoft Defender XDR統合ロールベースのアクセス制御 (RBAC) (コラボレーションがEmail &場合>Defender for Office 365アクセス許可は
アクティブです。Defender ポータルにのみ影響します。PowerShell ではなく、承認と設定/セキュリティ設定/コア セキュリティ設定 (管理) または承認と設定/セキュリティ設定/コア セキュリティ設定 (読み取り))。Exchange Onlineアクセス許可: Organization Management ロール グループまたはセキュリティ管理者ロール グループのメンバーシップ。
Microsoft Entraアクセス許可: グローバル管理者ロール*またはセキュリティ管理者ロールのメンバーシップは、ユーザーに Microsoft 365 の他の機能に必要なアクセス許可とアクセス許可をユーザーに付与します。
重要
* Microsoft では、アクセス許可が最も少ないロールを使用することをお勧めします。 アクセス許可の低いアカウントを使用すると、組織のセキュリティが向上します。 グローバル管理者は高い特権を持つロールであり、既存のロールを使用できない場合の緊急時に限定する必要があります。
Microsoft Defender ポータルを使用して信頼できる ARC シーラーを追加する
https://security.microsoft.comのMicrosoft Defender ポータルで、[Email & コラボレーション>ポリシー & ルール>ポリシー>Email認証設定] セクション>ARC に移動します。 または、Email認証設定ページに直接移動するには、https://security.microsoft.com/authenticationを使用します。
[Email認証設定] ページで、[ARC] タブが選択されていることを確認し、[
追加] を選択します。ヒント
[ARC] タブに信頼できるシーラーが既に一覧表示されている場合は、[
編集] を選択します。開いた [ 信頼できる ARC シーラーの追加] ポップアップで、ボックスに信頼された署名ドメイン (たとえば、fabrikam.com) を入力します。
ドメイン名は、影響を受けるメッセージの ARC-Seal ヘッダーと ARC-Message-Signature ヘッダーの d 値に表示されるドメインと一致する必要があります。 メッセージ ヘッダーを表示するには、次のメソッドを使用します。
- Outlook でインターネット メッセージ ヘッダーを表示します。
- https://mha.azurewebsites.netでメッセージ ヘッダー アナライザーを使用します。
必要な回数だけこの手順を繰り返します。 既存のエントリを削除するには、エントリの横にある [
] を選択します。[信頼できる ARC シーラーの追加] ポップアップが完了したら、[保存] を選択します。
Exchange Online PowerShell を使用して信頼できる ARC シーラーを追加する
PowerShell を使用して信頼された ARC シーラーを表示、追加、または削除する場合は、PowerShell Exchange Onlineに接続して次のコマンドを実行します。
既存の信頼できる ARC シーラーを表示する
Get-ArcConfig信頼された ARC シーラーが構成されていない場合、コマンドは結果を返しません。
信頼できる ARC シーラーを追加または削除する
既存の ARC シーラーを指定した値に 置き換えるには 、次の構文を使用します。
Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "Domain1","Domain2",..."DomainN"TenantId\ 値は、委任された組織でのみ、独自のorganizationでは必要ありません。 これは、Microsoft 365 の多くの管理ポータル URL (
tid=値) に表示される GUID です。 たとえば、a32d39e2-3702-4ff5-9628-31358774c091 です。次の使用例は、organizationで信頼できる唯一の ARC シーラーとして "cohovineyard.com" と "tailspintoys.com" を構成します。
Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"既存の値を保持するには、追加する新しい ARC シーラーと共に保持する ARC シーラーを必ず含めます。
他のエントリに影響を与えずに ARC シーラーを追加または削除するには、 Set-ArcConfig の「例」セクションを参照してください。
信頼できる ARC シーラーを検証する
メッセージが Microsoft 365 に到達する前にサービスからの ARC シールがある場合は、メッセージの配信後に最新の ARC ヘッダーのメッセージ ヘッダーをチェックします。
最後の ARC-Authentication-Results ヘッダーで、 arc=pass と oda=1を探します。 これらの値は、次を示します。
- 前の ARC が検証されました。
- 前の ARC シーラーは信頼されています。
- 前のパスの結果を使用して、現在の DMARC エラーをオーバーライドできます。
例:
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
172.17.17.17) smtp.rcpttodomain=microsoft.com
smtp.mailfrom=sampledoamin.onmicrosoft.com; dmarc=bestguesspass action=none
header.from=sampledoamin.onmicrosoft.com; dkim=none (message not signed);
arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=sampledoamin.onmicrosoft.com]
dkim=[1,1,header.d=sampledoamin.onmicrosoft.com]
dmarc=[1,1,header.from=sampledoamin.onmicrosoft.com])
ARC の結果を使用して DMARC エラーをオーバーライドしたかどうかをチェックするには、最後の Authentication-Results ヘッダーでcompauth=passとreason=130を探します。 例:
Authentication-Results: spf=fail (sender IP is 10.10.10.10)
smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
header.d=contoso.com;dmarc=fail action=none
header.from=contoso.com;compauth=pass reason=130
注:
信頼された ARC シーラーからの ARC 結果パスは、転送中のメッセージの変更によって発生する SPF、DKIM、または DMARC のエラーをオーバーライドする可能性があります。 ただし、最終的なスプーフィングの決定は、 複合認証 (CompAuth) の結果に基づいています。 SPF、DKIM、DMARC、複合認証の評価に合格した場合、ARC に失敗したメッセージは引き続き配信される可能性があります。
信頼できる ARC シーラーのメール フロー図
このセクションの図では、メール フローと、信頼できる ARC シーラーの有無による電子メール認証の結果への影響を対比します。 どちらの図でも、Microsoft 365 organizationは、Microsoft 365 に配信される前に受信メールを変更する正当な電子メール サービスを使用します。 この変更により、メール フローが中断され、ソース IP を変更して電子メール メッセージ ヘッダーを更新することで、電子メール認証エラーが発生する可能性があります。
次の図は、信頼できる ARC シーラー を使用しない 結果を示しています。
次の図は、信頼できる ARC シーラー を使用 した結果を示しています。
次の手順
https://mha.azurewebsites.netで、メッセージ ヘッダー アナライザーを使用して ARC ヘッダーを確認します。