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

• 適用対象:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

ヒント

Microsoft Defender XDR 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 への配信前に転送中のメッセージを変更するメール サービスを使用する場合は、変更されたメッセージが DMARC チェックに自動的に失敗しないように、サービスを信頼できる ARC シーラーとして識別できます。 詳細については、この記事の最後にある 「次の手順 」セクションを参照してください。

この記事の残りの部分では、Microsoft 365 のドメイン用に作成する必要がある DMARC TXT レコード、Microsoft 365 のカスタム ドメイン用の DMARC を段階的かつ安全に設定するための最良の方法、および 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 Intelligent Security Association (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 レコードを追加する

1. https://admin.microsoft.comのMicrosoft 365 管理センターで、[すべて表示>Settings>Domains] を選択します。 または、[ ドメイン] ページに直接移動するには、 https://admin.microsoft.com/Adminportal/Home#/Domainsを使用します。

2. [ドメイン] ページで、ドメイン名の横にある [チェック] ボックス以外の行の任意の場所をクリックして、一覧から *.onmicrosoft.com ドメインを選択します。

3. 開いたドメインの詳細ページで、[ DNS レコード ] タブを選択します。

4. [DNS レコード] タブで、[レコードの追加] 選択します。

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

1. 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 によってカバーされているか、またはカバーされていないかを確認し、問題のトラブルシューティングを行うことができます。 また、送信されている不正なメッセージの数と、送信元を確認することもできます。

2. 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

3. 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=値を使用して、より多くのメッセージに徐々に影響を与え、結果を確認することもできます。

4. ボリュームの増加や複雑さの残りのサブドメインに対して前の 3 つの手順を繰り返し、最後の親ドメインを保存します。

   ヒント

   大量の正当なメールをブロックすることはユーザーには受け入れられませんが、誤検知を受け取ることをほとんど避けられません。 DMARC レポートで明らかにされた問題に、ゆっくりと体系的に対処します。 の MISA カタログの DMARC レポート ベンダーは、DMARC の結果を簡単に表示および解釈できます。

5. 前述のように、サブドメインは親ドメインの DMARC TXT レコード設定を継承します。サブドメイン内の別の DMARC TXT レコードによってオーバーライドできます。 ドメインとすべてのサブドメインでの DMARC の設定が完了し、DMARC 設定が親ドメインとすべてのサブドメインで実質的に同一である場合は、サブドメイン内の DMARC TXT レコードを排除し、親ドメインの 1 つの DMARC TXT レコードに依存できます。

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

ヒント

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

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

   ホスト名: _dmarc
   TXT 値: v=DMARC1; p=reject;

   • 既定値はpct=100であるため、pct=値は含まれません。
   • ドメイン内の送信者から有効なメールを送信する必要がないため、このシナリオでは、 rua=mailto: と ruf=mailto: の値は間違いなく必要ありません。

2. *.onmicrosoft.com ドメインを使用してメールを送信しない場合は、 *.onmicrosoft.com ドメインの DMARC TXT レコードも追加する必要があります。

Microsoft 365 への受信メールの DMARC

• Microsoft 365 に送信されるメールの DMARC チェックは、Exchange Online Protection (EOP) の次の機能の影響を受けます。

  • メッセージをチェックしたフィッシング対策ポリシーで スプーフィング インテリジェンス が有効か無効か。 スプーフィング インテリジェンスを無効にすると、複合認証チェックからの暗黙的なスプーフィング保護のみが無効になります。
  • メッセージをチェックしたフィッシング対策ポリシーと、ソース ドメインの DMARC ポリシーに基づく指定されたアクション (p=quarantine、または DMARC TXT レコード内のp=reject) で、メッセージがなりすましとして検出されたときに DMARC レコード ポリシーを使用するかどうか。

  詳細については、「 スプーフィング保護と送信者 DMARC ポリシー」を参照してください。

  フィッシング対策ポリシーでこれらの設定の既定値を確認するには、「EOP フィッシング対策ポリシー設定」の表の設定値をチェックします。

• 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 レコード ポイント) に配信される前にサード パーティのサービスまたはデバイスを介してルーティングされる場合、DMARC 集計レポートは送信されません。 この制限には、コネクタを使用して Microsoft 365 にルーティングされる前に、メールがオンプレミス環境に配信されるハイブリッドまたはスタンドアロンの EOP シナリオが含まれます。

  ヒント

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

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

次の図を使用して、DMARC 認証の問題のトラブルシューティングに役立てることができます。

次の手順

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