クラウド送信者の差出人アドレスドメインを検証するように DMARC を設定する

適用対象: ✅ Built-in security features for all cloud mailboxes, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

ヒント

Microsoft Defender for Office 365 プラン 2 の機能を無料で試すことができることをご存知でしたか? Microsoft Defender ポータル試用版ハブで、90 日間の Defender for Office 365 試用版を使用します。サインアップできるユーザーと試用版の条件については、「Microsoft Defender for Office 365 を試す」を参照してください。

ドメインベースのメッセージ認証、レポート、準拠 (DMARC) は、Microsoft 365 organizationから送信されたメールを検証するための電子メール認証の方法です。この検証は、ビジネスメールの侵害 (BEC)、ランサムウェア、その他のフィッシング攻撃で使用されるなりすまし送信者を防ぐのに役立ちます。

ドメインに対して DMARC を有効にするには、DNS で TXT レコードを作成します。電子メールメッセージの DMARC 検証には、次の要素が含まれます。

MAIL FROM アドレスと FROM アドレスのドメインが揃っていることを確認します。 SPF と DKIM では、次のメールアドレス内のドメインが "align" (一致) する必要はありません。
- MAIL FROM アドレス: SMTP 電子メールサーバー間のメッセージの送信に使用される電子メールアドレス。このアドレスは、 5321.MailFrom アドレス、P1 送信者、またはエンベロープ送信者とも呼ばれます。
- 差出人アドレス: 電子メールクライアントのメッセージ送信者として表示される [差出人ヘッダー] フィールドの電子メールアドレス。このアドレスは、 5322.From アドレスまたは P2 送信者とも呼ばれます。
これらのメールアドレスを異なるドメインで使用し、なりすましに使用する方法の詳細については、「インターネットメールで認証が必要な理由」を参照してください。
- DMARC では、SPF の結果を使用して、次の両方の条件を確認します。
  - メッセージは、MAIL FROM アドレス (SPF の基本的な要件) で使用されるドメインの承認されたソースから送信されました。
  - メッセージ内の MAIL FROM アドレスと From アドレスのドメインがアラインされます。この結果を有効にするには、メッセージの有効なソースが From アドレスドメインに存在する必要があります。
- DMARC では、DKIM の結果を使用して、メッセージに署名したドメイン (s= セレクター値によって検証される DKIM-Signature ヘッダーフィールドの d= 値) が、From アドレスのドメインと一致することを確認します。
説明されている SPF または DKIM チェックの一方または両方が合格した場合、メッセージは DMARC に合格します。説明されている SPF チェックと DKIM チェックの両方が失敗した場合、メッセージは DMARC に失敗します。
DMARC ポリシー: DMARC に失敗したメッセージ (拒否、検疫、または命令なし) を処理する方法を指定します。
DMARC レポート: レポートを送信する場所を指定します。
- 集計レポート (正と負の DMARC 結果の定期的な概要)。
- フォレンジックレポート ( エラーレポートとも呼ばれます。ほぼ即時の DMARC エラーの結果は、配信不能レポートまたはバウンスメッセージに似ています)。

作業を開始する前に、メールドメインに基づいて Microsoft 365 の DMARC について知る必要がある内容を次に示します。

メールに Microsoft Online Email ルーティングアドレス (MOERA) ドメイン (例: contoso.onmicrosoft.com) のみを使用する場合: SPF と DKIM は既に *.onmicrosoft.com ドメイン用に構成されていますが、Microsoft 365 管理センターの *.onmicrosoft.com ドメインの DMARC TXT レコードを作成する必要があります。手順については、この記事の後半のこのセクションを参照してください。 *.onmicrosoft.com ドメインの詳細については、「 "onmicrosoft.com" ドメインがある理由」を参照してください。
メールに 1 つ以上のカスタムドメイン (たとえば、contoso.com) を使用する場合: まだ使用していない場合は、メールに使用するすべてのカスタムドメインとサブドメインに SPF を構成する必要があります。また、メッセージの署名に使用するドメインが From アドレスのドメインと一致するように、カスタムドメインまたはサブドメインを使用して DKIM 署名を構成する必要もあります。手順については、次の記事を参照してください。
- カスタムクラウドドメインの有効なメールソースを識別するように SPF を設定する
- クラウドドメインからメールに署名するように DKIM を設定する
その後、この記事で説明されているように、カスタムドメインの DMARC TXT レコードを構成する必要もあります。また、次の考慮事項もあります。
- サブドメイン:
  - 直接管理下にないメールサービス (一括メールサービスなど) の場合は、メインメールドメイン (contoso.com など) ではなくサブドメイン (marketing.contoso.com など) を使用します。これらのメールサービスから送信されたメールに関する問題が、メインメールドメイン内のユーザーから送信されたメールの評判に影響を与えるのを望んでいません。サブドメインの追加の詳細については、「カスタムサブドメインまたは複数のドメインを Microsoft 365 に追加できますか?」を参照してください。
  - SPF と DKIM とは異なり、ドメインの DMARC TXT レコードは、独自の DMARC TXT レコードを持たないすべてのサブドメイン (存在しないサブドメインを含む) を自動的にカバーします。つまり、サブドメインに DMARC TXT レコードを作成することで、サブドメインでの DMARC の継承を中断できます。ただし、各サブドメインには、DMARC の SPF レコードと DKIM レコードが必要です。
- 登録済みで未使用のドメインを所有している場合: 電子メールや何か ( パークされたドメインとも呼ばれます) に使用されていない登録済みドメインを所有している場合は、それらのドメインから電子メールが送信されないように、それらのドメイン内の DMARC TXT レコードを構成します。電子メールに使用していない場合、このディレクティブには *.onmicrosoft.com ドメインが含まれます。
DMARC による受信メールのチェックには、ヘルプが必要な場合があります。Microsoft 365 への配信前に転送中のメッセージを変更するメールサービスを使用すると、サービスを信頼できる ARC シーラーとして識別できる場合があります。信頼された ARC シーラーは、変更されたメッセージが DMARC チェックに自動的に失敗するのを防ぎます。詳細については、この記事の最後にある「次の手順」セクションを参照してください。

この記事の残りの部分では、DMARC TXT レコードの作成、カスタムドメインの段階的なロールアウト、および Microsoft 365 での受信 DMARC 処理について説明します。

ヒント

Microsoft 365 管理センターで *.onmicrosoft.com ドメインの DMARC TXT レコードを作成するには、この記事の後半のセクションを参照してください。

Microsoft 365 には、 カスタム ドメイン内の DMARC TXT レコードを管理するための管理ポータルや PowerShell コマンドレットはありません。代わりに、ドメインレジストラーまたは DNS ホスティングサービス (多くの場合は同じ会社) で DMARC TXT レコードを作成します。

Microsoft 365 のドメイン所有権証明 TXT レコードを多くのドメインレジストラーで作成する手順が提供されています。 DMARC TXT レコードを作成するための出発点として、次の手順を使用できます。詳細については、「DNS レコードを追加してドメインに接続する」を参照してください。

DNS 構成に慣れていない場合は、ドメインレジストラーに問い合わせてヘルプを依頼してください。

DMARC TXT レコードの構文

DMARC TXT レコードは RFC 7489 で完全に説明されています。

Microsoft 365 のドメインの DMARC TXT レコードの基本的な構文は次のとおりです。

ホスト名: _dmarc
TXT 値: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

または

ホスト名: _dmarc
TXT 値: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

例:

ホスト名: _dmarc
TXT 値: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

_dmarcホスト名の値が必要です。
v=DMARC1; は、TXT レコードを DMARC TXT レコードとして識別します。
DMARC ポリシー: この記事で前述したように、DMARC に失敗したメッセージの対処方法を宛先メールシステムに伝えます。
- p=reject: メッセージは拒否する必要があります。メッセージに対して実際に何が起こるかは、宛先のメールシステムによって異なりますが、通常、メッセージは破棄されます。
- p=quarantine: メッセージは受け入れられますが、マークする必要があります。メッセージに対して実際に何が起こるかは、送信先のメールシステムによって異なります。たとえば、メッセージがスパムとして検疫されたり、迷惑メール Email フォルダーに配信されたり、件名またはメッセージ本文に識別子が追加された受信トレイに配信されたりすることがあります。
- p=none: DMARC に失敗するメッセージに推奨されるアクションはありません。メッセージの動作は、宛先メールシステムの電子メール保護機能によって異なります。この値は、この記事で後述するように、DMARC ポリシーのテストとチューニングに使用します。
ヒント

宛先メールサービスによって DMARC チェックに失敗する Microsoft 365 のドメインからの送信メールは、ドメインの DMARC ポリシーがp=rejectまたはp=quarantineされている場合、送信メッセージの高リスク配信プールを介してルーティングされます。この動作にオーバーライドはありません。
DMARC ポリシーの対象となる DMARC メールの失敗の割合: DMARC に失敗したメッセージの数 (パーセンテージ) に DMARC ポリシーが適用されていることを宛先メールシステムに通知します。たとえば、 pct=100 は、DMARC に失敗したすべてのメッセージが DMARC ポリシーを適用することを意味します。この記事で後述するように、DMARC ポリシーのテストとチューニングには、100 未満の値を使用します。 pct=を使用しない場合、既定値はpct=100。
DMARC レポート:
- DMARC 集計レポート URI: rua=mailto: 値は、DMARC 集計レポートを送信する場所を識別します。集計レポートには、次のプロパティがあります。
  - 集計レポートを含む電子メールメッセージは、通常、1 日に 1 回送信されます (レポートには前日の DMARC 結果が含まれます)。 [件名] 行には、レポートを送信した宛先ドメイン (提出者) と DMARC 結果のソースドメイン (レポートドメイン) が含まれます。
  - DMARC データは、GZIP 圧縮の可能性が高い XML 電子メール添付ファイル内にあります。 XML スキーマは RFC 7489 の付録 C で定義されています。レポートには、次の情報が含まれています。
    - ドメインを使用してメールを送信するサーバーまたはサービスの IP アドレス。
    - サーバーまたはサービスが DMARC 認証に合格するか失敗するか。
    - DMARC 認証に失敗したメールに対して DMARC が実行するアクション (DMARC ポリシーに基づく)。
  ヒント
  
  集計レポートの情報は膨大であり、解析が困難な場合があります。データを理解するために、DMARC レポートには次のオプションを使用できます。
  - PowerShell またはMicrosoft Power BIを使用して自動化を作成します。
  - 外部サービスを使用します。サービスの一覧については、 https://www.microsoft.com/misapartnercatalogの Microsoft インテリジェントセキュリティアソシエーション (MISA) カタログで DMARC を検索します。 DMARC レポートサービスは、DMARC TXT レコードに必要なカスタム値を記述します。
- DMARC フォレンジックレポート URI: ruf=mailto: 値は、DMARC フォレンジックレポート (DMARC エラーレポートとも呼ばれます) を送信する場所を識別します。レポートは生成され、配信不能レポート (NDR またはバウンスメッセージとも呼ばれます) のような DMARC エラーの直後に送信されます。
ヒント

DMARC 集計レポートを定期的に確認して、ドメインからのメールの送信元を監視し、意図しない DMARC エラー (誤検知) をチェックする必要があります。

個々の宛先メールシステムは、DMARC レポートを送信する責任を負います。 DMARC レポートの量と種類は、organizationから送信されるメールの量と種類が異なるのと同じ方法で異なります。たとえば、休日のメール量が少なくなり、組織のイベント中のメール量が増えるとします。特定のユーザーを指定して DMARC レポートを監視し、特定のメールボックスまたは Microsoft 365 グループを使用して DMARC レポートを受信することをお勧めします (ユーザーのメールボックスにレポートを配信しないでください)。

DMARC の詳細については、次のリソースを使用します。

M³AAWG からの DMARC トレーニングシリーズ (メッセージング、マルウェア、モバイル不正使用防止作業グループ)。
DMARC.org の情報。

Microsoft 365 管理センターを使用して、Microsoft 365 で *.onmicrosoft.com ドメインの DMARC TXT レコードを追加する

https://admin.microsoft.comのMicrosoft 365 管理センターで、[すべて表示>Settings>Domains] を選択します。または、[ ドメイン] ページに直接移動するには、 https://admin.microsoft.com/Adminportal/Home#/Domainsを使用します。
[ドメイン] ページで、ドメイン名の横にある [チェック] ボックス以外の行の任意の場所をクリックして、一覧から *.onmicrosoft.com ドメインを選択します。
開いたドメインの詳細ページで、[ DNS レコード ] タブを選択します。
[DNS レコード] タブで、[レコードの追加] 選択します。
開 いた [カスタム DNS レコードの追加] ポップアップで、次の設定を構成します。
- 型: TXT (テキスト) が選択されていることを確認します。
- TXT 名: 「 _dmarc」と入力します。
- TXT 値: 「 v=DMARC1; p=reject」と入力します。
  
  ヒント
  
  DMARC 集計レポートと DMARC フォレンジックレポートの宛先を指定するには、構文 v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>を使用します。たとえば、「 v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com 」のように入力します。
  
  の MISA カタログの DMARC レポートベンダーは、DMARC の結果を簡単に表示および解釈できます。
- TTL: 1 時間 が選択されていることを確認します。
[ カスタム DNS レコードの追加 ] ポップアップが完了したら、[保存] を選択 します。

Microsoft 365 でアクティブなカスタムドメインの DMARC を設定する

ヒント

この記事で前述したように、カスタムドメインまたはサブドメインに DMARC を構成する前に、SPF TXT レコードを作成し、Microsoft 365 で電子メールを送信するために使用するすべてのカスタムドメインとサブドメインに対して DKIM 署名を構成する必要があります。

Microsoft 365 ドメイン用に DMARC を段階的に設定することをお勧めします。目標は、すべてのカスタムドメインとサブドメインの p=reject DMARC ポリシーにアクセスすることですが、意図しない DMARC エラーが原因で宛先メールシステムが良好なメールを拒否するのを防ぐために、途中でテストして検証する必要があります。

DMARC ロールアウトプランでは、次の手順を使用する必要があります。メールの量が少ないドメインまたはサブドメインから開始し、潜在的なメールソースが少ない (不明なソースからの正当なメールがブロックされる可能性が低い):

p=noneの DMARC ポリシーから開始し、ドメインの結果を監視します。例:

marketing.contoso.com の DMARC TXT レコード:

ホスト名: _dmarc
TXT 値: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

DMARC 集計レポートと DMARC フォレンジックレポートは、DMARC チェックに合格および失敗するメッセージの数とソースを示します。正当なメールトラフィックの量が DMARC によってカバーされているか、またはカバーされていないかを確認し、問題のトラブルシューティングを行うことができます。また、送信されている不正なメッセージの数と、送信元を確認することもできます。
DMARC ポリシーを増やして、ドメインの結果を p=quarantine して監視します。

p=noneの影響を十分に監視した後、ドメインのp=quarantineに DMARC ポリシーを増やすことができます。例:

marketing.contoso.com の DMARC TXT レコード:

ホスト名: _dmarc
TXT 値: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

pct=値を使用して、より多くのメッセージに徐々に影響を与え、結果を確認することもできます。たとえば、次の増分で移動できます。
- pct=10
- pct=25
- pct=50
- pct=75
- pct=100
DMARC ポリシーを増やして、ドメインの結果を p=reject して監視します。

p=quarantineの影響を十分に監視した後、ドメインのp=rejectに DMARC ポリシーを増やすことができます。例:

marketing.contoso.com の DMARC TXT レコード:

ホスト名: _dmarc
TXT 値: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

pct=値を使用して、より多くのメッセージに徐々に影響を与え、結果を確認することもできます。
ボリュームの増加や複雑さの残りのサブドメインに対して前の 3 つの手順を繰り返し、最後の親ドメインを保存します。

ヒント

大量の正当なメールをブロックすることはユーザーには受け入れられませんが、誤検知を受け取ることをほとんど避けられません。 DMARC レポートで明らかにされた問題に、ゆっくりと体系的に対処します。の MISA カタログの DMARC レポートベンダーは、DMARC の結果を簡単に表示および解釈できます。
前述のように、サブドメインは親ドメインの DMARC TXT レコード設定を継承します。サブドメイン内の別の DMARC TXT レコードでオーバーライドできます。ドメインとすべてのサブドメインでの DMARC の設定が完了し、DMARC 設定が親ドメインとすべてのサブドメインで実質的に同一である場合は、サブドメイン内の DMARC TXT レコードを排除し、親ドメインの 1 つの DMARC TXT レコードに依存できます。

Microsoft 365 のパークされたドメインの DMARC TXT レコード

ヒント

メールを送信しないパークされたドメインに対して推奨される SPF TXT レコードについては、「カスタムクラウドドメインの SPF TXT レコード」を参照してください。「クラウドドメインからのメールに署名するように DKIM を設定する」で説明されているように、DKIM CNAME レコードは、パークされたドメインには推奨されません。

インターネット上の誰もメールの受信を想定していないドメインを登録した場合は、ドメインのドメインレジストラーで次の DMARC TXT レコードを作成します。

ホスト名: _dmarc
TXT 値: v=DMARC1; p=reject;
- 既定値はpct=100であるため、pct=値は含まれません。
- ドメイン内の送信者から有効なメールを送信する必要がないため、このシナリオでは、 rua=mailto: と ruf=mailto: の値は間違いなく必要ありません。
*.onmicrosoft.com ドメインを使用してメールを送信しない場合は、 *.onmicrosoft.com ドメインの DMARC TXT レコードも追加する必要があります。

Microsoft 365 への受信メールの DMARC

すべてのクラウドメールボックスの次の組み込みのセキュリティ機能は、受信メールの DMARC チェックに影響します。
- メッセージをチェックしたフィッシング対策ポリシーでスプーフィングインテリジェンスが有効か無効か。スプーフィングインテリジェンスを無効にすると、複合認証チェックからの暗黙的なスプーフィング保護のみが無効になります。
- メッセージをチェックしたフィッシング対策ポリシーと、ソースドメインの DMARC ポリシーに基づく指定されたアクション (p=quarantine、または DMARC TXT レコード内のp=reject) で、メッセージがなりすましとして検出されたときに DMARC レコードポリシーを使用するかどうか。
詳細については、「スプーフィング保護と送信者 DMARC ポリシー」を参照してください。

フィッシング対策ポリシーでこれらの設定の既定値を確認するには、「すべてのクラウドメールボックスのフィッシング対策ポリシー設定」の表の設定値をチェックします。
Microsoft 365 では、ソースドメインの DMARC TXT レコードに有効な ruf=mailto: アドレスが存在する場合でも、DMARC フォレンジックレポート (DMARC エラーレポートとも呼ばれます) は送信されません。
Microsoft 365 は、MICROSOFT 365 ドメインの MX レコードが Microsoft 365 を直接指している限り、DMARC TXT レコード内の有効な rua=mailto: アドレスを持つすべてのドメインに DMARC 集計レポートを送信します。

Microsoft 365 (Microsoft 365 以外の場所にある MX レコードポイント) に配信する前に、Microsoft 以外のサービスまたはデバイスを介してインターネットメールをルーティングした場合、DMARC 集計レポートは送信されません。この制限には、コネクタを使用して Microsoft 365 にルーティングされる前に、メールがオンプレミス環境に配信されるハイブリッドシナリオが含まれます。

ヒント

Microsoft 以外のサービスまたはデバイスが Microsoft 365 に送信されるメールの前に配置されている場合、コネクタの拡張フィルター処理 ( スキップリストとも呼ばれます) は、SPF、DKIM (サービスがメッセージを変更した場合)、DMARC 検証のインターネットメッセージのソースを正しく識別します。

DMARC のトラブルシューティング

DMARC エラー、原因、修正プログラムのクイックリファレンステーブルについては、「 Microsoft 365 での電子メール認証のトラブルシューティング」を参照してください。

このセクションでは、一般的な DMARC エラーの診断と解決、さまざまな DMARC ポリシーに対する Microsoft 365 の動作の理解、DMARC 集計レポートとフォレンジックレポートの解釈に役立ちます。

アライメントエラー診断

DMARC 検証の概要で説明されているように、少なくとも 1 つのアラインメントチェックが成功した場合 (SPF または DKIM) 場合、メッセージは DMARC を渡します。両方のアラインメントチェックが失敗した場合にのみ、メッセージが DMARC に失敗します。

アライメントモード

DMARC TXT レコード内の aspf (SPF) タグと adkim (DKIM) タグは、From ドメインが認証されたドメインとどの程度厳密に一致する必要があるかを制御します。どちらも省略可能であり、既定値は r (リラックス) ですが、 s (strict) も使用できます。例:

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

リラックス (r、既定値): 組織ドメイン (ルートドメイン) が一致している必要があります。サブドメインは許可されます。
Strict (s): FQDN は正確に一致する必要があります。サブドメインが一致しません。

注:

aspfタグとadkim タグは独立しています。例に示すように、それぞれ異なるモードを使用できます。 いずれかのアラインメントチェックが成功した場合、メッセージは DMARC を渡します。そのため、一方のチェックに対する厳密なエラーは、もう一方のチェックがリラックスしたアラインメントで渡されるかどうかは関係ありません。

例:

送信元アドレス	MAIL FROM / DKIM-Signature d= アドレス	リラックス (`r`)	Strict (`s`)
`user@contoso.com`	`contoso.com`	✅ 渡す	✅ 渡す
`user@contoso.com`	`bounces.contoso.com`	✅ 渡す	❌ 失敗
`user@marketing.contoso.com`	`contoso.com`	✅ 渡す	❌ 失敗
`user@contoso.com`	`contoso.onmicrosoft.com`	❌ 失敗	❌ 失敗
`user@contoso.com`	`adatum.net`	❌ 失敗	❌ 失敗

一般的なアライメントエラーのシナリオ

シナリオ	現象	根本原因	解決方法
Microsoft 以外のサービスがユーザーに代わって送信する	SPF は adatum.com に渡されますが、DMARC は失敗します	MAIL FROM では、サービスのドメイン ( `bounce.adatum.com`など) が使用され、ドメインとの DKIM 署名は使用されません	サービスでドメインとの DKIM 署名を構成するか、MAIL FROM をドメイン/サブドメインに変更する
Microsoft 365 自動転送	DMARC が宛先で失敗する	転送はエンベロープ送信者を変更します。DKIM 署名が壊れる可能性がある	宛先で ARC 信頼済みシーラーを使用するか、DKIM を使用します (本文が変更されていない場合、転送は存続します)
サブドメインが厳密な配置で送信する	`aspf=s` サブドメイン送信者のエラーが発生する	MAIL FROM は `sub.contoso.com` ですが、From は `contoso.com`	`aspf=r` (リラックス) に変更するか、From アドレスがサブドメインと一致することを確認します
DKIM 署名ドメインの不一致	DKIM はパスしますが、DMARC はまだ失敗します	DKIM `d=` 値 (たとえば、 `adatum.com`) が From domain (`contoso.com`) と一致しない	ドメインを使用してサービスでカスタム DKIM 署名を構成する
共有メールボックスまたは配布グループ	DMARC が断続的に失敗する	返信元またはリダイレクトの変更エンベロープアドレス	DKIM がそのままであることを確認します。中間サービスの ARC を検討する

メッセージヘッダーから配置エラーを診断する

手順 1: メッセージヘッダーを開き、Microsoft 365 の Authentication-Results ヘッダーを見つけます。

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

手順 2: アライメントエラーを特定する:

チェック	ヘッダーフィールド	例の値	From (`contoso.com`) に揃えますか?
SPF アラインメント	`smtp.mailfrom=`	`bounces.adatum.com`	❌ いいえ (別の組織ドメイン)
DKIM アライメント	`header.d=`	`adatum.com`	❌ いいえ (別の組織ドメイン)
DMARC の結果	`dmarc=`	`fail`	どちらのチェックも失敗しました

手順 3: 次の質問に回答して、修正プログラムを決定します。

MAIL FROM アドレスをドメイン (たとえば、bounces.adatum.com ではなく bounces.contoso.com) に変更できますか?
- はい: SPF の配置を修正するように、サービスで MAIL FROM の変更を構成します。
- いいえ: 代わりに DKIM アライメントを使用します (手順 2 に進みます)。
サービスはドメイン (d=contoso.com) で署名できますか?
- はい: サービスでカスタム DKIM 署名を構成します。
- いいえ: サブドメイン戦略を検討します。
  - サブドメインから送信します (たとえば、sub.contoso.com)。
  - そのサブドメインの別の DMARC レコードを発行します。
  - d=sub.contoso.comを使用してサービスに DKIM に署名します。

PowerShell で最近のメッセージの配置を確認する

Exchange Online PowerShell に接続し、次のコマンドを実行します。

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Microsoft 365 の動作に対する DMARC ポリシーの影響

「受信メールの DMARC」で説明されているように、Microsoft 365 の動作は[DMARC レコードの優先] ポリシー設定によって異なります。詳細については、「スプーフィング保護と送信者 DMARC ポリシー」を参照してください。

次の概要は、DMARC レコードポリシーがオン (推奨) の場合に DMARC に失敗する受信メッセージの一般的な動作を示しています。

送信者の DMARC ポリシー	メッセージの処理	Authentication-Results	CompAuth
`p=none`	DMARC 固有のアクションはありません。その他のフィルター処理は引き続き適用されます。	`dmarc=fail action=none`	複合認証 (SPF、DKIM、スプーフィングインテリジェンス) に基づく
`p=quarantine`	迷惑メール Email フォルダー (検疫用に構成可能)	`dmarc=fail action=quarantine`	`compauth=fail reason=100`
`p=reject`	SMTP 中に拒否 (`550 5.7.1`)	`dmarc=fail action=oreject`	`compauth=fail reason=100`

注意

正当な送信者の p=reject をオーバーライドする場合は注意してください。 DMARC が失敗した送信者 (転送済みメール、メーリングリストなど) から、organizationが正当にメールを受信する場合は、次のいずれかの方法を使用します。

送信者を信頼できる ARC シーラーとして構成します (推奨)。
スパムフィルター処理をスキップする特定の条件 (送信者 IP + 送信者ドメイン) を含むメールフロールールを作成します。
[テナントの許可/ブロック] リストに許可エントリを追加します (一時的な有効期限は 30 日です)。

Authentication-Results の DMARC アクション値

Authentication-Results ヘッダーには、次の DMARC アクション値が表示される場合があります。

Action の値	意味
`action=none`	送信者が発行した `p=none`。アクションは実行されません
`action=quarantine`	送信者が発行した `p=quarantine`。メッセージの検疫または迷惑メール
`action=oreject`	送信者が発行した `p=reject`;メッセージが拒否されました ("o" = 配信元)
`action=pct.quarantine`	送信者が`pct=` 100 未満の`p=quarantine`を発行しました。このメッセージはサンプリングされた割合でした
`action=pct.reject`	送信者が`pct=` 100 未満の`p=reject`を発行しました。このメッセージはサンプリングされた割合でした

DMARC レポートの解釈

このセクションでは、受信者がruaアドレスとruf アドレスに送信する DMARC 集計レポートとフォレンジックレポートを解釈するのに役立ちます。

レポートの集計

次の例は、集計レポートの XML 構造を示しています。

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

集計レポートの読み取り

XML 要素	それがあなたに伝えるもの	トラブルシューティングアクション
`<source_ip>`	メッセージを送信した IP アドレス	これが正当な送信者か未承認かの特定
`<count>`	このソースからのメッセージの数	不明な IP からの高カウント = なりすましの可能性
`<disposition>`	受信側が実行した操作 (`none`、 `quarantine`、 `reject`)	受信者がポリシーを受け入れているかどうかを確認する
`<dkim>` 下 `<policy_evaluated>`	DKIM が (渡されただけでなく) アラインされているかどうか	`fail` = DKIM ドメインが From ドメインと一致しない
`<spf>` 下 `<policy_evaluated>`	SPF が (渡されただけでなく) アラインされているかどうか	`fail` = MAIL FROM ドメインが From ドメインと一致しない
`<domain>` 下 `<auth_results><spf>`	SPF がチェックされたドメイン	From domain = alignment の問題と異なる場合
`<domain>` 下 `<auth_results><dkim>`	DKIM 署名ドメイン	DMARC アラインメントの From ドメインと一致する必要がある
`<result>` 下 `<auth_results>`	未加工の SPF/DKIM の合格/不合格 (アライメントチェック前)	`pass` + アライメント `fail` = クラシックアライメントの問題

ヒント

集約レポートからの最も重要な分析情報は、 認証パス と アラインメントパスのギャップを特定することです。

<auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF が渡されましたが、ドメインが一致しません。
この組み合わせは、送信者が承認されている (SPF パス) が DMARC に対して適切に構成されていないことを意味します (アラインメントが失敗します)。

一般的な集計レポートパターンと修正

レポートのパターン	解釈	修正プログラム
既知の IP、SPF auth=pass、SPF aligned=fail	間違った MAIL FROM ドメインを持つ正当なサービス	MAIL FROM でドメインを使用するようにサービスを構成するか、ドメインで DKIM 署名を設定する
既知の IP、DKIM auth=pass、DKIM aligned=fail	サービスが独自のドメインで DKIM に署名する	サービスでカスタム DKIM を構成する `d=contoso.com`
不明な IP、大量、すべてが失敗する	なりすまし/フィッシングキャンペーンの可能性	アクションは必要ありません。 DMARC ポリシーが受信者を保護しています。
既知の IP (Microsoft 365)、SPF aligned=pass	通常の Microsoft 365 メールフロー	健康。アクションは必要ありません。
正当なサービスからのボリュームが少ない、SPF + DKIM が失敗する	サービスは SPF に含まれず、DKIM 署名には含まれません	SPF レコードにサービスを追加したり、DKIM を構成したりします
転送されたメール (メーリングリスト IP)、すべて失敗する	メール転送は SPF を中断します。body modification breaks DKIM	転送されたメールの場合は正常です。 ARC を使用するか、一部のエラーを受け入れます。

フォレンジックレポート

「受信メールの DMARC」セクションで説明されているように、Microsoft 365 はフォレンジックレポートを送信しません。ただし、他のプロバイダーから受け取る場合があります。次の表では、2 つのレポートの種類を比較します。

側面	集計レポート (`rua`)	フォレンジックレポート (`ruf`)
Frequency	毎日 (通常)	ほぼリアルタイム (エラーごと)
Content	ソース IP 別の概要統計	個々のメッセージの詳細
Volume	レポーターごとに 1 日あたり 1 つのレポート	エラーごとに 1 つのレポート (大量になる可能性があります)
プライバシー	IP アドレスとカウントのみ	メッセージヘッダー/本文が含まれる場合があります (編集済み)
サポート	レシーバーで広くサポートされています	制限付きサポート (多くの受信者が ruf を送信しない)
ユースケース	傾向分析、不明な送信者の識別	特定のエラーのデバッグ、フォレンジック調査

注:

Microsoft 365 のメッセージごとのエラーの詳細が必要な場合は、フォレンジックレポートの代わりにメッセージトレースとメッセージヘッダー分析を使用します。

フォレンジックレポート構造 (AFRF/RFC 6591 形式):

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

DMARC レポートのベストプラクティス

Recommendation	詳細
専用メールボックスを使用する `rua`	共有メールボックス ( `dmarc-reports@contoso.com`など) を作成します。個々のユーザーメールボックスを使用しないでください。
Microsoft 365 グループを使用する	グループにより、セキュリティチームのコラボレーションと共有アクセスが向上します
DMARC レポートサービスを検討する	DMARC レポートサービスは、XML をダッシュボードに解析します。 MISA カタログで DMARC を検索します。
`rua`のみで開始する	必要に応じて、後で `ruf` を追加します。フォレンジックレポートは大量に生成される可能性があります。
定期的に監視する	初期デプロイ中に毎週集計レポートを確認します。月 1 回安定
現実的な期待値を設定する	すべての受信者がレポートを送信するわけではありません。カバレッジは通常、メールの合計量の 70 ~ 90% です

クロスドメインレポート

DMARC rua または ruf アドレスが、監視対象 のドメインとは異なるドメイン にある場合、受信ドメインは、レポート配信を承認する DNS TXT レコードを発行する必要があります。

例: レポートを送信する contoso.com の DMARC dmarc@fabrikam.com

fabrikam.comで必要な DNS レコード:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

このレコードがないと、受信側は DMARC レポートを外部アドレスに配信しません。

DMARC のトラブルシューティングのクイックリファレンス

現象	考えられる原因	診断手順	解決方法
`dmarc=fail` SPF と DKIM の両方が個別に渡されます	配置エラー: ドメインが From と一致しない	Authentication-Results で `smtp.mailfrom=` と `header.d=` と `header.from=` を確認する	配置されたドメインを使用して SPF/DKIM を構成する
`dmarc=bestguesspass`	From ドメインに対して DMARC レコードが発行されていない	TXT レコード `_dmarc.domain.com` クエリを実行する	Microsoft はパスを推論します。明示的な DMARC レコードを発行します。
`dmarc=fail action=oreject` メッセージが配信される	DMARC を無効にするか、リスト/オーバーライドを許可する	フィッシング対策ポリシーの設定とテナントの許可/ブロックリストを確認する	厳密な適用が必要な場合は、 DMARC レコードポリシーの適用を有効にする
`dmarc=fail` 転送されたメッセージの場合	転送によって SPF の配置が切断されます。body changes break DKIM	メッセージが中継局を通過したかどうかを確認する (X-MS-Exchange ヘッダー)	転送サービスの信頼できる ARC シーラーを構成する
`dmarc=fail` Microsoft SaaS 以外の送信者の場合	サービスは、MAIL FROM と DKIM で独自のドメインを使用します `d=`	サービスの IP の集計レポートを確認する	サービスでカスタム DKIM 署名を構成する + MAIL FROM を調整する
`dmarc=temperror` または `dmarc=permerror`	DMARC レコードの取得に関する DNS の問題 (タイムアウト、構文エラー)	で DMARC レコード構文を検証する `nslookup -type=TXT _dmarc.domain.com`	DNS 構文エラーを修正します。TXT レコードが 1 つだけ存在 `_dmarc` 確認する
`compauth=fail reason=000`	複合認証に失敗しました (明示的な失敗)	すべての認証結果 (SPF、DKIM、DMARC、ARC) を確認する	基になる SPF/DKIM/DMARC の問題を修正する
`compauth=fail reason=100`	DMARC 明示的にポリシーの適用に失敗する	送信者の DMARC ポリシーによってエラーが発生しました	ソースでの配置を修正するか、正当な場合は ARC/オーバーライドを構成する
集計レポートが受信されない	`rua` アドレスに到達できない、またはクロスドメイン認証が見つからない	メールボックスが存在し、外部ドメインの DNS 承認レコードが存在することを確認する	メールボックスのルーティングを修正します。TXT レコード `domain._report._dmarc` 追加する

DMARC 診断ワークフロー

dmarc=failを使用してメッセージを診断するには、次の手順に従います。

From ドメインを識別する: Authentication-Results ヘッダーでheader.from=値を見つけます。
SPF の配置を確認する: smtp.mailfrom= ドメインは header.from= ドメインと一致しますか?
- はい ( aspf=rと同じ組織ドメイン): SPF がアラインされています。
- いいえ: SPF の配置が失敗します。
- SPF は(spf=pass と spf=fail)まったく合格しましたか? spf=fail場合は、差出人を SPF レコードに追加して、最初に SPF を修正します。
DKIM の配置を確認する: DKIM-Signature の header.d= 値が header.from= ドメインと一致しますか?
- はい ( adkim=rと同じ組織ドメイン): DKIM がアラインされています。
- いいえ: DKIM アライメントが失敗します。
- DKIM は(dkim=pass と dkim=fail)まったく合格しましたか? dkim=fail場合は、キーを発行し、署名を確認して DKIM を修正します。
両方のアラインメントが失敗した場合、DMARC は失敗します。解決オプション:
- SPF の配置を修正する: MAIL FROM アドレスをドメインに変更します。
- DKIM アライメントの修正: d=contoso.comで署名します。
- サブドメインを使用する: 独自の DMARC レコードを使用して sub.domain.com から送信します。
- メッセージが転送される場合: 信頼できる ARC シーラーを構成します。
ポリシーアクションを確認します。
- p=none: 配信に影響はありません (モニターのみ)。
- p=quarantine: メッセージは [迷惑メール] Emailに移動します ([DMARC ポリシーを有効にする] がオンになっている場合)。
- p=reject: メッセージは拒否されます ( [DMARC ポリシーの適用 ] がオンになっている場合)。正当なメールが拒否された場合は、ARC、許可リストを使用するか、ソースでの認証を修正します。

DMARC トラブルシューティングに役立つ PowerShell コマンド

Exchange Online PowerShell に接続し、次のコマンドを実行します。

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

ヒント

特定の送信者の DMARC エラーのトラブルシューティングを行う場合:

エラーの種類を特定するには、 Authentication-Results ヘッダーから開始します。
DMARC 集計レポートと相互参照して、ボリュームとソース IP を確認します。
Get-MessageTrace を使用して特定のメッセージを検索し、Get-MessageTraceDetail を使用して配信イベントを調べます。
送信者が正当な場合は、上書きを作成する前に、それらの送信者と協力して SPF/DKIM アライメントを修正します。

次の手順

Microsoft 365 に届くメールの場合、organizationへの配信前に転送中のメッセージを変更するサービスを使用する場合は、信頼できる ARC シーラーを構成する必要がある場合もあります。詳細については、「信頼できる ARC シーラーを構成する」を参照してください。

電子メール認証エラーを診断して修正するには、「 Microsoft 365 での電子メール認証のトラブルシューティング」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-05-17