英語で読む

次の方法で共有


名前付きエンティティ (DANE) の SMTP DNS ベースの認証のしくみ

SMTP プロトコルは、メール サーバー間でメッセージを転送するために使用されるメイン プロトコルであり、既定ではセキュリティで保護されていません。 トランスポート層セキュリティ (TLS) プロトコルは、SMTP 経由でのメッセージの暗号化された転送をサポートするために、何年も前に導入されました。 これは一般的に、要件としてではなく日和見的に使用され、多くの電子メール トラフィックがクリア テキストに残され、悪意のあるアクターによる傍受に対して脆弱です。 さらに、SMTP は、パブリック DNS インフラストラクチャを介して宛先サーバーの IP アドレスを決定します。これは、なりすましや中間者 (MITM) 攻撃の影響を受けやすいです。 この脆弱性により、多くの新しい標準が作成され、電子メールの送受信のセキュリティが強化されました。その標準の 1 つは、DNS ベースの名前付きエンティティの認証 (DANE) です。

DANE for SMTP RFC 7672 は、ドメインの DNS レコード セットにトランスポート層セキュリティ認証 (TLSA) レコードが存在することを使用して、ドメインとそのメール サーバーが DANE をサポートしていることを通知します。 TLSA レコードが存在しない場合、メール フローの DNS 解決は、DANE チェックが試行されずに通常どおりに機能します。 TLSA レコードは、TLS のサポートを安全に通知し、ドメインの DANE ポリシーを発行します。 そのため、メール サーバーを送信すると、SMTP DANE を使用して正当な受信メール サーバーを正常に認証できます。 この認証により、ダウングレードや MITM 攻撃に対する耐性が高くなります。 DANE には DNSSEC への直接の依存関係があります。これは、公開キー暗号化を使用して DNS 参照のレコードにデジタル署名することで機能します。 DNSSEC チェックは、再帰 DNS リゾルバー (クライアントの DNS クエリを作成する DNS サーバー) で行われます。 DNSSEC は、DNS レコードが改ざんされず、本物であることを保証します。

ドメインの MX、A/AAAA、DNSSEC 関連のリソース レコードが DNSSEC authentic として DNS 再帰リゾルバーに返されると、送信メール サーバーは MX ホストエントリまたはエントリに対応する TLSA レコードを要求します。 TLSA レコードが存在し、別の DNSSEC チェックを使用して本物であることが証明されている場合、DNS 再帰リゾルバーは TLSA レコードを送信メール サーバーに返します。

本物の TLSA レコードを受信すると、送信側メール サーバーは、本物の TLSA レコードに関連付けられている MX ホストへの SMTP 接続を確立します。 送信側メール サーバーは、TLS を設定し、サーバーの TLS 証明書を TLSA レコード内のデータと比較して、送信者に接続されている宛先メール サーバーが正当な受信メール サーバーであることを検証しようとします。 認証が成功した場合、メッセージは (TLS を使用して) 送信されます。 認証が失敗した場合、または移行先サーバーで TLS がサポートされていない場合、Exchange Onlineは、15 分後に同じ宛先ドメインの DNS クエリから始まり、その後 15 分後、次の 24 時間ごとに検証プロセス全体を再試行します。 再試行の 24 時間後に認証が失敗し続ける場合、メッセージの有効期限が切れ、エラーの詳細を含む NDR が生成され、送信者に送信されます。

DANE のコンポーネントは何ですか?

TLSA リソース レコード

TLS 認証 (TLSA) レコードは、サーバーの X.509 証明書または公開キーの値を、レコードを含むドメイン名に関連付けるために使用されます。 TLSA レコードは、ドメインで DNSSEC が有効になっている場合にのみ信頼できます。 DNS プロバイダーを使用してドメインをホストしている場合、DNSSEC は、ドメインを構成するときに提供される設定である可能性があります。 DNSSEC ゾーン署名の詳細については、次のリンクを参照してください: DNSSEC の概要 |Microsoft Docs

TLSA レコードの例:

TLSA レコードの例を示すスクリーンショット。

TLSA レコードの種類に固有の構成可能なフィールドは 4 つあります。

[証明書の使用状況] フィールド: 送信先の電子メール サーバーの証明書を送信電子メール サーバーで検証する方法を指定します。

略語 説明
01 PKIX-TA 使用される証明書は、X.509 トラスト チェーンからのトラスト アンカーパブリック CA です。
11 PKIX-EE チェックされた証明書は宛先サーバーです。DNSSEC チェックでは、その信頼性を確認する必要があります。
2 DANE-TA 信頼チェーンのトラスト アンカーによって検証する必要がある X.509 ツリーのサーバーの秘密キーを使用します。 TLSA レコードは、ドメインの TLS 証明書の検証に使用するトラスト アンカーを指定します。
3 DANE-EE 移行先サーバーの証明書とのみ一致します。

1 Exchange Online RFC 実装ガイダンスに従って、DANE が SMTP で実装されている場合は、証明書の使用法フィールドの値 0 または 1 を使用しないでください。 証明書使用状況フィールドの値が 0 または 1 の TLSA レコードがExchange Onlineに返された場合、Exchange Onlineはそれを使用できないものとして扱います。 すべての TLSA レコードが使用できないと検出された場合、Exchange Onlineは電子メールの送信時に 0 または 1 の DANE 検証手順を実行しません。 代わりに、TLSA レコードが存在するため、Exchange Onlineは、送信先の電子メール サーバーが TLS をサポートしている場合は電子メールを送信するか、宛先メール サーバーが TLS をサポートしていない場合は NDR を生成して、電子メールを送信するための TLS の使用を強制します。

TLSA レコードの例では、証明書の使用状況フィールドは '3' に設定されているため、証明書の関連付けデータ ('abc123....xyz789') は、移行先サーバーの証明書にのみ一致します。

セレクター フィールド: 移行先サーバーの証明書のどの部分をチェックするかを示します。

略語 説明
0 証明 書 完全な証明書を使用します。
1 SPKI (サブジェクト公開キー情報) 証明書の公開キーと、使用する公開キーが識別されるアルゴリズムを使用します。

TLSA レコードの例では、セレクター フィールドが '1' に設定されているため、証明書の関連付けデータは、宛先サーバー証明書の公開キーと、公開キーが使用するアルゴリズムを使用して照合されます。

一致する型フィールド: 証明書が TLSA レコードで表される形式を示します。

略語 説明
0 Full TSLA レコード内のデータは、完全な証明書または SPKI です。
1 SHA-256 TSLA レコード内のデータは、証明書または SPKI の SHA-256 ハッシュです。
2 SHA-512 TSLA レコード内のデータは、証明書または SPKI の SHA-512 ハッシュです。

TLSA レコードの例では、照合型フィールドは '1' に設定されているため、証明書の関連付けデータは、移行先サーバー証明書のサブジェクト公開キー情報の SHA-256 ハッシュです。

証明書の関連付けデータ: 移行先サーバー証明書との照合に使用される証明書データを指定します。 このデータは、セレクター フィールドの値と一致する型の値によって異なります。

TLSA レコードの例では、証明書の関連付けデータは 'abc123. に設定されています。xyz789'. この例の Selector Field の値は '1' に設定されているため、移行先サーバー証明書の公開キーと、それを使用するために識別されるアルゴリズムを参照します。 また、この例の [照合の種類] フィールドの値は '1' に設定されているため、移行先サーバー証明書からサブジェクト公開キー情報の SHA-256 ハッシュを参照します。

SMTP DANE の RFC 実装ガイダンスに従って、[証明書の使用法] フィールドを 3 に設定し、[セレクター] フィールドを 1 に設定し、[照合の種類] フィールドを 1 に設定した TLSA レコードをお勧めします。

SMTP DANE を使用したメール フローのExchange Online

次のフローチャートに示す SMTP DANE を使用したExchange Onlineのメール フロー プロセスでは、DNSSEC を使用したドメインとリソース レコードのセキュリティ、宛先メール サーバーでの TLS サポート、および宛先メール サーバーの証明書が、関連する TLSA レコードに基づいて想定されているものと一致することを検証します。

SMTP DANE エラーによって電子メールがブロックされるシナリオは 2 つだけです。

  • 宛先ドメインは DNSSEC のサポートを通知しましたが、1 つ以上のレコードが認証されていないとして返されました。

  • 宛先ドメインのすべての MX レコードには TLSA レコードがあり、TSLA レコード データに対して予想されていたものと一致する宛先サーバーの証明書がないか、TLS 接続が宛先サーバーでサポートされていません。

    SMTP DANE を使用した Exchange オンライン メール フローを示すスクリーンショット。

テクノロジ その他の情報
メール転送エージェント - 厳格なトランスポート セキュリティ (MTA-STS) は、宛先メール サーバーが TLS をサポートしているかどうかを指定するドメイン ポリシーを設定するためのメカニズムを提供し、TLS をネゴシエートできない場合の対処方法 (送信を停止するなど) を提供することで、ダウングレードと中間者攻撃を阻止するのに役立ちます。 Exchange Onlineの受信および送信 MTA-STS の今後のサポートの詳細については、今年後半に公開される予定です。

Microsoft Ignite 2020 からトランスポート ニュースをExchange Onlineする - Microsoft Tech Community

rfc8461 (ietf.org)
Sender Policy Framework (SPF) では、IP 情報を使用して、宛先メール システムがカスタム ドメインから送信されたメッセージを信頼できるようにします。 送信者ポリシー フレームワーク (SPF) がスプーフィングを防ぐ方法
DomainKeys Identified Mail (DKIM) では、X.509 証明書情報を使用して、宛先メール システムがカスタム ドメインから送信されたメッセージを信頼します。 カスタム ドメインで DKIM をメールに使用する方法
ドメイン ベースのメッセージ認証、レポート、準拠 (DMARC) は、 Sender Policy Framework と DomainKeys Identified Mail と連携して、メール送信者を認証し、宛先メール システムがドメインから送信されたメッセージを信頼できるようにします。 DMARC を使用してメールを検証する、セットアップ手順

DNSSEC を使用した受信 SMTP DANE

前提条件

開始する前に、次の前提条件を満たしていることを確認してください。

  1. ドメインを "承認済みドメイン" として追加し、ドメインの状態を Microsoft 365 管理 センターで "正常" にする必要があります。 このドキュメントでは、ドメインの MX レコードが優先度 0 または 10 に設定されており、"フォールバック" またはセカンダリ MX レコードがないことを前提としています。 フォールバック MX レコードがある場合は、変更が正しく実行されるように、Exchange Online管理者と緊密に連携する必要があります。
  2. この機能の完全なセキュリティ上の利点を受け取るために、ドメインで DNSSEC を有効にしていることを確認します。
  3. PowerShell Exchange Onlineアクセス権と、PowerShell で説明されているコマンドレットを実行するためのアクセス許可Exchange Online必要があります
  4. DNSSEC を使用して受信 SMTP DANE でセキュリティで保護するドメインが、任意のスマートホスト構成または任意のコネクタで参照されている場合は、手順に従う前に、smarthost 名を tenantname.mail.protection.outlook.com に切り替える必要があります。

注意

サード パーティのゲートウェイを使用するドメインに対して DNSSEC を有効にする場合は、手順 1 ~ 3 に従って、サード パーティのゲートウェイの手順 3 の最後にあるメモに従います。

警告

"承認済みドメイン" contoso.comに対して DNSSEC を使用して受信 SMTP DANE を構成し、ビジネス パートナーが contoso-com.mail.protection.outlook.com エンドポイントへのコネクタを使用している場合は、DNSSEC で受信 SMTP DANE を構成する前に、パートナーがコネクタを更新して、 tenantname.onmicrosoft.com エンドポイントまたは tenantname.mail.protection.outlook.com エンドポイントを参照するようにする必要があります。 それ以外の場合、有効化を完了すると、ビジネス パートナーのコネクタのメールが失敗します。 有効化が完了すると、パートナーは新しい contoso-com.<random>.mx.microsoft エンドポイントを使用して元のコネクタを再確立できます。

DNSSEC を使用して受信 SMTP DANE を設定する

注意

DNS レコードのプロビジョニングと更新が完了するまでに時間がかかる場合があります。 複数のレイヤーのキャッシュが原因で、DNS の変更が予想以上に表示されるまでに時間がかかる場合があります。

DNSSEC で受信 SMTP DANE を設定するには、次の手順を実行します。

  1. 既存の MX レコードの TTL を、可能な限り最も低い TTL (ただし 30 秒以下) に更新します。 次に、前の TTL が期限切れになるまで待ってから続行します。 たとえば、既存の MX レコードの TTL が変更前に '3600 秒' または '1 時間' であった場合は、手順 2 に進む前に 1 時間待つ必要があります。

  2. Exchange Online PowerShell に接続します。

    警告

    MTA-STS を使用している場合は、ポリシー モードを "テスト" に設定し、MTA-STS txt レコードの ID を更新する必要があります。 (現在の時刻を UTC で新しいポリシー ID として使用できます)。次に、ポリシーの "max_age" が期限切れになるまで待ってから続行します。 たとえば、既存の STS ポリシーの "max_age" が 変更されるまで 3600 秒 または 1 時間 だった場合は、続行する前に "1 時間" 待つ必要があります。

  3. DNSSEC で SMTP DANE を有効にするドメインの場合は、まず次のコマンドを実行してドメインで DNSSEC を有効にする必要があります ("domain" を選択したドメインの名前に置き換えます (例: contosotest.com)。

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>
    

    注意

    このコマンドの実行には数分かかることがあります。

    成功した実行の出力例

    結果 DnssecMxValue ErrorData
    成功 contosotest-com.o-v1.mx.microsoft

    成功応答は、ドメインの MX 値を提供します。 この値は、DNSSEC で有効にするドメインの新しい MX レコードが指す名前です。 たとえば、「 contosotest-com.o-v1.mx.microsoft 」のように入力します。

  4. "DnssecMxValue" の値を取得し、ドメインをホストしている DNS レジストラーに移動し、手順 3 で返された値を使用して新しい MX レコードを追加し、TTL を可能な限り最も小さい値 (30 秒以下) に設定し、新しい MX レコードの優先順位を 20 に設定します。

    注意

    サード パーティのメール ゲートウェイを使用していて、サード パーティの電子メール ゲートウェイが受信メールを送信する新しいExchange Onlineターゲット ホストとしてこの値を使用する場合は、サード パーティの管理ポータルに移動し、サード パーティがExchange Onlineに送信するために使用するターゲット スマート ホストを更新してから、DNSSEC テストを介して動作するメール フロー (Microsoft Remote Connectivity Analyzer: Test Input で"DANE Validation (DNSSEC を含む)"ではなく、テスト入力中に "DNSSEC 検証" を選択していることを確認します。 メールが期待どおりに流れている場合は、次の手順を続行する必要はありません。 このドメインに対して SMTP DANE を有効にする場合は、手順 7 に進みます。

    警告

    MTA-STS を使用している場合は、ポリシー モードが "テスト" に設定されていることを確認します。 次に、レガシ MX レコード情報を含む現在の mx 行を削除し、新しい MX 行として新しい FQDN を MTA-STS ポリシー ファイルに追加します。 次に、ポリシーのポリシー ID と MTA-STS TXT レコードを更新します (新しいポリシー ID として UTC で現在の時刻を使用できます)。

  5. 新しい MX が受信 SMTP Email テスト (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) を介して動作していることを確認します。テスト手順を展開し、mx.microsoft で終了するメール交換体が正常にテストされたことを確認します。 DNS キャッシュによっては、このテストを再試行しなければならない場合があります。

    成功出力の例

    実装されたプロセスの成功を通知する出力の例を示すスクリーンショット。

  6. mail.protection.outlook.com を指すレガシ MX の優先度を現在の優先度から 30 に変更します。手順 3 で作成した MX レコードの優先度を、優先度 0 (最も高い優先度) に設定するように変更します。

  7. "mail.protection.outlook.com"、"mail.eo.outlook.com"、または "mail.protection.outlook.de" で終わるレガシ MX レコードを削除します。 次に、mx.microsoft で終わる MX レコードの TTL を 3600 秒に更新します。 必要に応じて、DNSSEC テストを使用して、すべてが期待どおりに動作していることを確認できます ( リモート接続アナライザーの [DANE 検証 (DNSSEC を含む)]) ではなく、テスト入力中に [DNSSEC 検証] を選択してください。 DNS キャッシュと TTL によっては、このテストを再試行しなければならない場合があります。

    レガシ MX レコードの TTL の有効期限が切れると、正常な出力は次のようになります。

    ドメインが DNSSEC 検証テストに正常に合格したことを通知する出力の例を示すスクリーンショット。

  8. DNSSEC の有効化が完了したら、同じドメインに対して SMTP DANE を有効にする場合は、次のコマンド [replace (DomainName) を選択したドメインの名前に置き換えます (たとえば、contosotest.com)] を実行します。

    Enable-SmtpDaneInbound -DomainName <DomainName>
    
    結果 ErrorData
    成功
  9. 選択したオンライン ツールと Microsoft リモート接続アナライザー: テスト入力を使用して、TLSA レコードが伝達されていることを確認します (15 から 30 分かかります)。

    DNSSEC の有効化が完了し、SMTP DANE レコード (TLSA) がExchange Onlineによってプロビジョニングされると、次のスクリーンショットに示すように正常な出力が表示されます。

    ドメインが Dane 検証テストに正常に合格したことを通知する出力の例を示すスクリーンショット。

    Exchange Onlineは、SMTP DANE 検証の成功の信頼性を高めるために、複数の TLSA レコードをホストします。 TLSA レコードの一部が検証に失敗する可能性があります。 1 つの TLSA レコードが検証に合格している限り、SMTP DANE は正しく構成され、電子メールは SMTP DANE で保護されます。

    警告

    MTA-STS を使用している場合は、ポリシーが機能していることと、メールが期待どおりに送信されていることを検証した後、ポリシー モードを "強制" に戻し、MTA-STS txt レコードの ID を更新します。 (現在の時刻を UTC で新しいポリシー ID として使用できます)。

制限事項

  1. バイラルまたはセルフサービスのサインアップ ドメイン: "セルフサービス" として設定されたドメインは、現在、DNSSEC を使用した受信 SMTP DANE ではサポートされていません。
  2. onmicrosoft.com ドメイン: テナントの "onmicrosoft.com" ドメインは、現在、DNSSEC を使用した受信 SMTP DANE ではサポートされていません。 onmicrosoft.com ドメインに対する DNSSEC を使用した受信 SMTP DANE のサポートを調査しています。ただし、ETA は不明です。
  3. サード パーティゲートウェイ: 受信パスでサードパーティの電子メール ゲートウェイを使用しているお客様 (テナントのメールを受け入れ、一部の処理を行い、Exchange Onlineに中継する) は、サード パーティゲートウェイが DNSSEC 検証で SMTP DANE をサポートしている場合にのみ、サードパーティゲートウェイからExchange Onlineに中継されたメールをセキュリティで保護するためにのみ使用できます。 この構成のお客様は、Exchange PowerShell を使用して DNSSEC で受信 SMTP DANE を設定する必要があります。
  4. その他のサード パーティ製のメール フローとの統合: 送信パスにはサード パーティゲートウェイの顧客がいます。この場合、電子メールはコネクタ経由でサード パーティに送信され、サード パーティは何らかの処理を行い、Exchange Onlineに再送信してから、最終的に電子メールを送信Exchange Online。 これらのお客様は、中断が発生しないように機能を有効にするときに、サード パーティのプロバイダーと連携する必要がある場合があります。 サード パーティリレーは、Exchange Onlineに電子メールを送信するときに DNS 参照を使用し、新しい MX レコードホスト名 -> contoso-com を使用する必要があります。サブドメイン).mx.microsoft は、機能の有効化中に作成されました。 サード パーティは古い MX レコードホスト名を使用しないでください-> contoso-com.mail.protection.outlook.com Exchange Online、GA に達すると機能の有効化から約 2 日以内 (48 時間以内) に A レコードが削除されます。
  5. 完全に委任されたドメイン: Microsoft によってホストされ、NS 委任を使用して、Microsoft のネーム サーバーがドメインに対して権限を持つドメインを使用するドメインは、DNSSEC を使用した受信 SMTP DANE でサポートされます。 これらのドメインでは、DNSSEC で受信 SMTP DANE をサポートする予定です。ただし、ETA は不明です。

DNSSEC で受信 SMTP DANE を有効にしているときに発生する問題のデバッグ

Enable/Disable-DnssecForVerifiedDomain と Enable/Disable-SmtpDane Inbound に関する問題
  1. DomainNotFound

    メッセージ (DNSSEC): 'ドメイン contoso.com AAD に存在していないため、DNSSEC の有効化/無効化が失敗しました。
    メッセージ (SMTP DANE):

    • 'ドメイン contoso.com AAD に存在していないため、SMTP DANE の有効化/無効化が失敗しました。
    • "承認済みドメインの一覧にドメイン contoso.com が見つからないため、SMTP DANE の有効化/無効化が失敗しました。
      原因: 指定されたドメインが、承認済みドメインの一覧に見つかりませんでした。
      実行する操作: Microsoft 365 管理 センターに移動し、ドメインがテナントで確認されていることを確認します。 ドメインがMicrosoft 365 管理 センターで正常な場合は、Exchange 管理 センターに移動し、ドメインが "承認済みドメイン" として追加されていることを確認します。

    DNSSEC

    結果 DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'DNSSEC の有効化に失敗しました....

    SMTP DANE

    結果 ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'SMTP DANE enabling...
  2. DnsSecOperationFailed

    メッセージ (DNSSEC): AdditionalErrorDetails が原因で、'DNSSEC の有効化/無効化が失敗しました。 後で操作を再試行してください。
    メッセージ (SMTP DANE): AdditionalErrorDetails が原因で SMTP DANE の有効化/無効化が失敗しました。 後で操作を再試行してください。
    原因: 適切な DNS ゾーンまたはレコードの作成が失敗しました。
    実行するアクション: コマンドレットを再実行してみてください。

    DNSSEC

    結果 DnssecMxValue ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'DNSSEC enableing failed...

    SMTP DANE

    結果 ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'SMTP DANE enableing ...
  3. PartitionNotFound

    メッセージ (SMTP DANE): ドメイン contoso.com にパーティションがないため、SMTP DANE の有効化/無効化が失敗しました。
    原因: ドメインに対して DNSSEC が有効になっていません。
    対処方法: DNSSEC が有効なドメインを使用していることを確認します。

    結果 ErrorData
    Error ErrorCode: 'PartitionNotFound' ErrorDetails 'SMTP DANE の有効化
  4. DomainNotSupported

    メッセージ (DNSSEC): '指定されたドメインは onmicrosoft ドメイン: contoso-com.onmicrosoft.com です。
    メッセージ (SMTP DANE): '指定されたドメインは onmicrosoft ドメイン: contoso-com.onmicrosoft.com です。'
    原因: ドメインは初期ドメインまたは MOERA ドメインです。 これらは現在サポートされていません。
    対処方法: 'onmicrosoft.com' で終わらないドメインを使用していることを確認します。

    DNSSEC

    結果 DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails '指定されたドメイン ...

    SMTP DANE

    結果 ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails '指定されたドメイン ...
Get-DnssecStatusForVerifiedDomain に関する問題
  1. メッセージ: 'EG001: ドメイン [{domain}]の DNSSEC 機能の状態を取得できません。
    原因: Exchange Onlineでドメインの構成を検証しているときに、ドメインがExchange Onlineに追加されていないことが判明しました。 このドメインを既にExchange Onlineに追加したと思われる場合は、一時的な問題になる可能性があるコマンドレットの実行を再試行してください。
    実行する操作: コマンドレットを再試行します。 失敗が続く場合は、Microsoft 365 管理 センターに移動し、このドメインのセットアップ プロセスを完了します。

  2. メッセージ: 'EG002: ドメイン [{domain}] は、organizationの検証済みドメインではありません。
    原因: Exchange Onlineでドメインの構成を検証しているときに、ドメインがExchange Onlineに追加されているが検証されていないことが判明しました。
    対処方法: Microsoft 365 管理 センターに移動し、このドメインのセットアップと検証プロセスを完了します。

  3. メッセージ: [{domain}] ドメインの MX レコードを取得中に DNS クエリ エラーが発生しました。
    原因: DNS 検証中に、ドメインのクエリ時に一般的な DNS エラーが発生しました。
    実行するアクション: コマンドレットの実行を再試行します。 DNSSEC で SMTP DANE を使用して有効にしようとしているドメインの構成を確認する必要がある場合があります。

  4. メッセージ: 'Domain [{domain}] が見つかりません。
    原因: DNS 検証中に、ドメインのクエリ時に NXDOMAIN エラーが発生しました。
    対処方法: ドメインの MX レコード構成を確認した後、コマンドレットの実行を再試行してください。 DNS の伝達には、一部の DNS プロバイダーで最大 48 時間かかる場合があります。

  5. メッセージ: 'ED003: ドメイン [{domain}] が見つかりました。 本物の MX レコードが見つかりません。
    原因: DNSSEC 検証中に、DNSSEC で保護された A レコード (MX レコードの 'hostname' 値の A レコード) に解決された MX レコードを見つけることができませんでした。
    対処方法: ドメインの MX レコード構成を確認した後、コマンドレットの実行を再試行してください。 DNS の伝達には、一部の DNS プロバイダーで最大 48 時間かかる場合があります。

  6. メッセージ: 'EX002: MX レコードの値が予期したレコードと一致しませんでした。'
    原因: MX 検証中に、予想されるレコードと一致する MX レコードが見つかりませんでした。
    対処方法: ドメイン内の MX レコードを確認します。 1 つの MX レコードが、 Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomainを実行した後に出力される予想されるレコードと一致していることを確認します。

  7. メッセージ: 'EX003: MX レコードの優先度が予期したレコードと一致しませんでした。'
    原因: MX 検証中に、予想される MX レコードが見つかりましたが、その優先順位が 0 に設定されませんでした。
    対処方法: MX レコード ( Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomain の実行時に返される値を含む) を優先度 0 に設定します。

  8. メッセージ: 'EX004: 予期した MX レコードと同じ優先設定を持つ別の MX レコードがあります。'
    原因: MX 検証中に、最も優先度の高い MX レコードが予想される MX レコードではないことが判明しました。
    対処方法: DNSSEC で受信 SMTP DANE を設定するの手順 1 ~ 4 を既に完了している場合は、MX レコードの優先順位を切り替えて MX レコードの優先順位を 0 (最も高い優先順位) に切り替え、構成を検証し、レガシ MX レコードを削除して、手順 5 と 6 を完了します。

  9. メッセージ: 'EX005: 予期した MX レコードよりも低い優先順位の MX レコードがあります。'
    原因: MX 検証中に、想定される MX レコードと一致しないドメインの MX レコードが見つかりました。
    対処方法: DNSSEC で受信 SMTP DANE を設定するの手順 1 ~ 5 を既に完了している場合は、レガシ MX レコードを削除して手順 6 を完了します。

  10. メッセージ: 'EX006: 予想される MX レコードよりも優先順位が高い別の MX レコードがあります。'
    原因: MX 検証中に、予想される MX レコードよりも優先順位が高い別の MX レコードが見つかりました。
    対処方法: レガシ MX レコード ( mail.protection.outlook.commail.eo.outlook.com、または mail.protection.outlook.de で終わる) を優先度 20 に設定します。

  11. メッセージ: 'EX007: MX レコードが見つかりませんでした。'
    原因: MX 検証中に、予想されるレコードと一致する MX レコードが見つかりませんでした。
    対処方法: ドメイン内の MX レコードを確認します。 1 つの MX レコードが、 Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomainを実行した後に出力される予想されるレコードと一致していることを確認します。

  12. メッセージ: 'EX008: 正しい MX レコードが見つかりましたが、設定が予想よりも低くなっています。
    原因: MX 検証中に、予想される MX レコードの優先度が間違っていることがわかりました。
    アクション: MX レコード ( Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomain の実行時に返される値を含む) を優先度 0 に設定します。

  13. メッセージ: 'EX009: 正しい MX レコードが見つかりましたが、設定が予想よりも高くなっています。'
    原因: MX 検証中に、予想される MX レコードの優先度が間違っていることがわかりました。
    アクション: MX レコード ( Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomain の実行時に返される値を含む) を優先度 0 に設定します。

  14. メッセージ: 'EX010: ドメイン [{domain}]の MX レコードを検索中に不明なエラーが発生しました。'
    原因: MX 検証中に、一般的な DNS エラーが発生しました。
    対処方法: ドメインの MX レコード構成を確認した後、コマンドレットの実行を再試行してください。 DNS の伝達には、一部の DNS プロバイダーで最大 48 時間かかる場合があります。

  15. メッセージ: 'EX012: ドメイン [{domain}]に MX レコードが見つかりません。'
    原因: MX 検証中に、予想されるレコードと一致する MX レコードが見つかりませんでした。
    対処方法: ドメイン内の MX レコードを確認します。 1 つの MX レコードが、 Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomainを実行した後に出力される予想されるレコードと一致していることを確認します。

  16. メッセージ: 'EX013: ドメイン [{domain}] に予期される MX レコードが不明です。
    原因: MX 検証中に、予想されるレコードと一致する MX レコードが見つかりませんでした。
    対処方法: ドメイン内の MX レコードを確認します。 1 つの MX レコードが、 Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomainを実行した後に出力される予想されるレコードと一致していることを確認します。

  17. メッセージ: 'ES001: モードが ''強制' の間にポリシーで MX レコードが見つからない可能性があります。
    原因: MTA-STS 検証中に、予想されるレコードと一致する mx 値を見つけることができませんでした。
    実行するアクション: テストする MTA-STS ポリシーのモードを設定します。次に、MXhostname 値 ( Enable-DnssecForVerifiedDomain または Get-DnssecStatusForVerifiedDomainの実行時に返される) を MTA-STS ポリシーの行として追加します。

  18. メッセージ: 'ES002: ポリシーと比較する MX レコードが見つかりません。 ドメイン [{domain}] の DNSSEC 機能を最初に有効にします。
    原因: MTA-STS が見つかりましたが、ドメインの DNSSEC 状態が原因で解決されませんでした。
    対処方法: 「DNSSEC を使用して受信 SMTP DANE を設定する」の手順を完了します。

DNSSEC を使用した受信 SMTP DANE に関するメール フローの問題を軽減する

DNSSEC を使用した受信 SMTP DANE が有効になると、メール フローの問題に関する 3 つの重要なシナリオがあります。

  1. SMTP DANE 検証の失敗に関する問題: この問題を軽減する方法については、「 SMTP DANE 検証の問題を軽減する」を参照してください
  2. DNSSEC 検証の失敗に関する問題: この問題を軽減する方法については、「 DNSSEC 検証の失敗の軽減」を参照してください。
  3. MX 値に関する問題: この問題を軽減する方法については、「 MX 値に関する問題の軽減」を参照してください。
SMTP DANE 検証の失敗を軽減する

SMTP DANE 検証による影響を軽減するには、次のコマンドを実行します。

Disable-SmtpDaneInbound -DomainName <DomainName>
DNSSEC 検証の失敗を軽減する
  1. DNSSEC 検証の失敗による影響を軽減するには、DNS プロバイダーを介してドメイン (contoso.com) で DNSSEC を無効にする必要があります。

    注意

    DNSSEC を無効にしても問題が解決しない場合は、MX 値に問題がある可能性があります。

  2. DNS プロバイダーを介してドメインの DNSSEC を無効にしたら、DNS プロバイダーでサポート チケットを開き、ドメインの DNSSEC を安全に再度有効にする方法を決定します。

MX 値に関する問題の軽減
  1. MX 値が Microsoft 365 管理 Center -> Settings -> Domains の値と一致していることを確認します。

  2. ドメインを選択し、[ DNS レコード] を選択し、[ 正常性の確認] を実行します。

  3. MX レコードが [OK] と表示されていることを確認します。そうでない場合は、管理センターで提供されているものに値を更新します。

  4. DNS レジストラーに移動し、ドメインの MX レコードを見つけます。 ホスト名の値は次のようになります。

    <MX token>.<subdomain>.mx.microsoft

  5. 次のホスト名の値を持つ 2 つ目の MX レコードを作成し、優先順位を 20 に設定します。

    <MX token>.mail.protection.outlook.com

    注意

    "MX トークン" の値を、手順 4 で見つかったドメインの現在の MX レコードの MX トークンに置き換えます。 たとえば、contosotest.com の MX トークンは contosotest-com です。

  6. 手順 5 で作成した MX が動作していることを確認します。

    重要

    2 番目の MX レコードが機能していることを確認する方法の 1 つは、 Microsoft Remote Connectivity Analyzer を使用することです。

    1. ドメイン (たとえば、contoso.com) をテストに入力します。[ テストの実行] を選択します。
    2. [テスト ステップ] を開きます。
    3. ドメイン "admin@(domain)" の受信 SMTP メール フローをテストするためのテスト手順を開きます。
    4. ドメイン '(domain)' の DNS MX レコードの取得を試みるで[追加の詳細] を開きます。
    5. MX レコード.mail.protection.outlook.com (MX トークン) が正常であることを確認します。
  7. メール フローが MX token.mail.protection.outlook.com MX レコードで動作している場合は、次のコマンドを実行します。

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. 次の値と一致する DNSSEC MX レコードを削除します。

    <MX token>.<subdomain>.mx.microsoft

  9. 手順 5 で作成した MX レコードが唯一の MX レコードであり、優先度 0 (最も高い優先順位) に設定されていることを確認します。

お客様が DNSSEC で送信 SMTP DANE を使用Exchange Online方法

Exchange Onlineのお客様は、送信メールのこの強化された電子メール セキュリティを構成するために何もする必要はありません。 この強化されたメール セキュリティは、Microsoft が構築したものであり、すべてのExchange Onlineのお客様に対して既定でオンになり、宛先ドメインが DANE のサポートをアドバタイズするときに使用されます。 DNSSEC と DANE チェックを使用してメールを送信する利点を得るために、これらの標準を使用して電子メールを受信できるように、DNSSEC と DANE を実装する必要があるメールを交換するビジネス パートナーに連絡します。

SMTP DANE を使用したメール送信のトラブルシューティング

現在、Exchange Onlineを使用して電子メールを送信する場合、DANE には 4 つのエラー コードがあります。 Microsoft では、このエラー コード一覧を積極的に更新しています。 エラーは次の中に表示されます。

  1. [メッセージ トレースの詳細] ビューを使用した Exchange 管理 センター ポータル。

  2. DANE または DNSSEC エラーが原因でメッセージが送信されない場合に生成される NDR。

  3. リモート接続アナライザー ツール Microsoft Remote Connectivity Analyzer

    NDR コード 説明
    4/5.7.321 starttls-not-supported: 宛先メール サーバーは、メールを受信するために TLS をサポートする必要があります。
    4/5.7.322 certificate-expired: 宛先メール サーバーの証明書の有効期限が切れています。
    4/5.7.323 tlsa-invalid: ドメインが DANE 検証に失敗しました。
    4/5.7.324 dnssec-invalid: 宛先ドメインから無効な DNSSEC レコードが返されました。

    注意

    現在、ドメインが DNSSEC をサポートしていることを通知したが DNSSEC チェックに失敗した場合、Exchange Onlineでは 4/5.7.324 dnssec-invalid エラーは生成されません。 一般的な DNS エラーが生成されます。

    4/5.4.312 DNS query failed

    この既知の制限を解決するために積極的に取り組んでいます。 このエラー ステートメントが表示された場合は、Microsoft Remote Connectivity Analyzer に移動し、4/5.4.312 エラーを生成したドメインに対して DANE 検証テストを実行します。 DNSSEC の問題か別の DNS の問題か、結果が表示されます。

トラブルシューティング 4/5.7.321 starttls-not-supported

このエラーは通常、宛先メール サーバーに関する問題を示します。 メッセージを受信した後:

  1. 宛先のメール アドレスが正しく入力されていることを確認します。
  2. 宛先サーバーが TLS を使用してメッセージを受信するように正しく構成されているかどうかを判断できるように、このエラー コードを受信したことを宛先メール管理者に警告します。
  3. メールの送信を再試行し、Exchange 管理 センター ポータルでメッセージのメッセージ トレースの詳細を確認します。

4/5.7.322 証明書の有効期限切れのトラブルシューティング

有効期限が切れていない有効な X.509 証明書を送信メール サーバーに提示する必要があります。 X.509 証明書は、有効期限が切れた場合は更新する必要があり、一般的には毎年更新する必要があります。 メッセージを受信した後:

  1. このエラー コードを受信したことを宛先のメール管理者に警告し、エラー コード文字列を指定します。
  2. 移行先サーバー証明書が更新され、TLSA レコードが更新されて新しい証明書が参照されるようにする時間を許可します。 次に、メールの送信を再試行し、Exchange 管理 センター ポータルでメッセージのメッセージ トレースの詳細を確認します。

4/5.7.323 tlsa-invalid のトラブルシューティング

このエラー コードは TLSA レコードの構成ミスに関連しており、DNSSEC 本物の TLSA レコードが返された後にのみ生成できます。 DANE 検証中に、レコードが返された後に発生するシナリオが多数あり、コードが生成される可能性があります。 Microsoft では、各シナリオに特定のコードが含まれるように、このエラー コードの対象となるシナリオに積極的に取り組んでいます。 現時点では、次の 1 つ以上のシナリオによってエラー コードが生成される可能性があります。

  1. 宛先メール サーバーの証明書が、本物の TLSA レコードごとに想定される証明書と一致しない。
  2. 本物の TLSA レコードが正しく構成されていない。
  3. 宛先ドメインが攻撃されています。
  4. その他の DANE エラー。

メッセージを受信した後:

  1. このエラー コードを受信したことを宛先の電子メール管理者に通知し、エラー コード文字列を指定します。
  2. 宛先メール管理者が DANE 構成と電子メール サーバー証明書の有効性を確認する時間を許可します。 次に、メールの送信を再試行し、Exchange 管理 センター ポータルでメッセージのメッセージ トレースの詳細を確認します。

4/5.7.324 dnssec-invalid のトラブルシューティング

このエラー コードは、宛先ドメインが DNSSEC-authentic であることを示したが、Exchange Online DNSSEC-authentic として検証できなかった場合に生成されます。

メッセージを受信した後:

  1. このエラー コードを受信したことを宛先の電子メール管理者に通知し、エラー コード文字列を指定します。
  2. 宛先メール管理者がドメインの DNSSEC 構成を確認する時間を許可します。 次に、メールの送信を再試行し、Exchange 管理 センター ポータルでメッセージのメッセージ トレースの詳細を確認します。

SMTP DANE を使用したメール受信のトラブルシューティング

現在、受信ドメインの管理者が DNSSEC と DANE 構成の検証とトラブルシューティングに使用できる 2 つの方法があり、次の標準を使用してExchange Onlineから電子メールを受信できます。

  1. RFC8460で導入された SMTP TLS-RPT (トランスポート層セキュリティ レポート) を採用する
  2. リモート接続アナライザー ツール Microsoft Remote Connectivity Analyzer を使用する

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 は、送信者が DANE と MTA-STS の成功と失敗に関する詳細を宛先ドメイン管理者に提供するためのレポート メカニズムです。 TLS-RPT レポートを受信するには、レポートの送信先となるメール アドレスまたは URI を含む TXT レコードをドメインの DNS レコードに追加するだけで済みます。 Exchange Onlineは、JSON 形式で TLS-RPT レポートを送信します。

次の表のデータは、レコードの例です。

Domain Name TTL 録音する
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report

2 つ目の方法は、リモート接続アナライザー Microsoft Remote Connectivity Analyzer を使用することです。これは、サービスの外部に電子メールを送信するときに行う DNS 構成に対して同じ DNSSEC と DANE チェックExchange Online実行できます。 この方法は、構成のエラーをトラブルシューティングして、これらの標準を使用してExchange Onlineから電子メールを受信する最も直接的な方法です。

エラーのトラブルシューティング中に、次のエラー コードが生成される場合があります。

NDR コード 説明
4/5.7.321 starttls-not-supported: 宛先メール サーバーは、メールを受信するために TLS をサポートする必要があります。
4/5.7.322 certificate-expired: 宛先メール サーバーの証明書の有効期限が切れています。
4/5.7.323 tlsa-invalid: ドメインが DANE 検証に失敗しました。
4/5.7.324 dnssec-invalid: 宛先ドメインから無効な DNSSEC レコードが返されました。

注意

現在、ドメインが DNSSEC をサポートしていることを通知したが DNSSEC チェックに失敗した場合、Exchange Onlineでは 4/5.7.324 dnssec-invalid エラーは生成されません。 一般的な DNS エラーが生成されます。

4/5.4.312 DNS query failed

この既知の制限を解決するために積極的に取り組んでいます。 このエラー ステートメントが表示された場合は、Microsoft Remote Connectivity Analyzer に移動し、4/5.4.312 エラーを生成したドメインに対して DANE 検証テストを実行します。 DNSSEC の問題か別の DNS の問題か、結果が表示されます。

トラブルシューティング 4/5.7.321 starttls-not-supported

注意

これらの手順は、電子メール管理者が SMTP DANE を使用してExchange Onlineから電子メールを受信するトラブルシューティングを行う場合に使用します。

このエラーは通常、宛先メール サーバーに関する問題を示します。 リモート接続アナライザーが接続をテストしているメール サーバー。 通常、このコードを生成するシナリオは 2 つあります。

  1. 宛先メール サーバーでは、セキュリティで保護された通信はまったくサポートされていないため、暗号化されていないプレーンな通信を使用する必要があります。
  2. 宛先サーバーが正しく構成されておらず、STARTTLS コマンドを無視します。

メッセージを受信した後:

  1. メール アドレスを確認します。
  2. error ステートメントに関連付けられている IP アドレスを見つけて、ステートメントが関連付けられているメール サーバーを特定できるようにします。
  3. メール サーバーの設定を確認して、SMTP トラフィック (一般にポート 25 と 587) をリッスンするように構成されていることを確認します。
  4. 数分待ってから、リモート接続アナライザー ツールを使用してテストを再試行します。
  5. それでも失敗した場合は、TLSA レコードを削除し、リモート接続アナライザー ツールを使用してテストをもう一度実行してください。
  6. エラーが発生しない場合、このメッセージは、メールの受信に使用しているメール サーバーが STARTTLS をサポートしていないことを示している可能性があり、DANE を使用するために、 にアップグレードする必要がある場合があります。

4/5.7.322 証明書の有効期限切れのトラブルシューティング

注意

これらの手順は、電子メール管理者が SMTP DANE を使用してExchange Onlineから電子メールを受信するトラブルシューティングを行う場合に使用します。

有効期限が切れていない有効な X.509 証明書を送信メール サーバーに提示する必要があります。 X.509 証明書は、有効期限が切れた場合は更新する必要があり、一般的には毎年更新する必要があります。 メッセージを受信した後:

  1. エラー ステートメントに関連付けられている IP を確認して、関連付けられているメール サーバーを特定できるようにします。 特定した電子メール サーバーで期限切れの証明書を見つけます。
  2. 証明書プロバイダーの Web サイトにサインインします。
  3. 期限切れの証明書を選択し、手順に従って更新し、更新の支払いを行います。
  4. プロバイダーが購入を確認したら、新しい証明書をダウンロードできます。
  5. 更新された証明書を関連付けられているメール サーバーにインストールします。
  6. メール サーバーの関連付けられている TLSA レコードを新しい証明書のデータで更新します。
  7. 適切な時間待ってから、リモート接続アナライザー ツールを使用してテストを再試行します。

4/5.7.323 tlsa-invalid のトラブルシューティング

注意

これらの手順は、電子メール管理者が SMTP DANE を使用してExchange Onlineから電子メールを受信するトラブルシューティングを行う場合に使用します。

このエラー コードは TLSA レコードの構成ミスに関連しており、DNSSEC 本物の TSLA レコードが返された後にのみ生成できます。 ただし、DANE 検証中に、レコードが返された後に発生するシナリオが多数あり、コードが生成される可能性があります。 Microsoft では、各シナリオに特定のコードが含まれるように、このエラー コードの対象となるシナリオに積極的に取り組んでいます。 現時点では、次の 1 つ以上のシナリオによってエラー コードが生成される可能性があります。

  1. 本物の TLSA レコードが正しく構成されていない。
  2. 証明書は、将来の時間枠に対してまだ有効/構成されていない時間です。
  3. 宛先ドメインが攻撃されている。
  4. その他の DANE エラー。

メッセージを受信した後:

  1. エラー ステートメントに関連付けられている IP を確認して、関連付けられているメール サーバーを特定します。
  2. 識別されたメール サーバーに関連付けられている TLSA レコードを識別します。
  3. TLSA レコードの構成を確認して、優先される DANE チェックを実行するように送信者に通知し、正しい証明書データが TLSA レコードに含まれていることを確認します。
    1. レコードに不一致がないか更新する必要がある場合は、数分待ってから、リモート接続アナライザー ツールを使用してテストを再実行します。
  4. 識別されたメール サーバーで証明書を見つけます。
  5. 証明書が有効な時間枠を確認します。 将来の日付で有効期間を開始するように設定されている場合は、現在の日付に対して更新する必要があります。
    1. 証明書プロバイダーの Web サイトにサインインします。
    2. 期限切れの証明書を選択し、手順に従って更新し、更新の支払いを行います。
    3. プロバイダーが購入を確認したら、新しい証明書をダウンロードできます。
    4. 更新された証明書を関連付けられているメール サーバーにインストールします。

4/5.7.324 dnssec-invalid のトラブルシューティング

注意

これらの手順は、電子メール管理者が SMTP DANE を使用してExchange Onlineから電子メールを受信するトラブルシューティングを行う場合に使用します。

このエラー コードは、宛先ドメインが DNSSEC-authentic であることを示したが、Exchange Onlineが DNSSEC-authentic として検証できない場合に生成されます。 このセクションは、DNSSEC の問題をトラブルシューティングするための包括的なものではなく、ドメインが以前に DNSSEC 認証に合格したが、現在は渡されなかったシナリオに焦点を当てます。

注意

このエラー コードは、Exchange Onlineが宛先ドメインの TLSA クエリで DNS サーバーから SERVFAIL 応答を受信した場合にも生成されます。

メッセージを受信した後:

  1. GoDaddy などの DNS プロバイダーを使用している場合は、DNS プロバイダーにエラーを警告して、トラブルシューティングと構成の変更に対応できるようにします。
  2. 独自の DNSSEC インフラストラクチャを管理している場合、このエラー メッセージを生成する可能性がある DNSSEC の構成ミスが多数あります。 ゾーンが以前に DNSSEC 認証を渡していた場合にチェックする一般的な問題:
    1. 破損した信頼チェーン。親ゾーンが、子ゾーンに存在しないものを指す DS レコードのセットを保持している場合。 DS レコードによるこのようなポインターは、リゾルバーを検証することで、子ゾーンが偽としてマークされる可能性があります。
      • 子ドメイン RRSIG キー ID を確認し、親ゾーンで発行された DS レコード内のキー ID と一致することを確認して解決します。
    2. ドメインの RRSIG リソース レコードは有効な時間ではありません。有効期限が切れているか、有効期間が開始されていません。
      • 有効な期間を使用してドメインの新しい署名を生成することで解決します。

送信メールが送信されるときに、受信ドメインで DNSSEC が有効になっている場合は、ドメイン内の MX エントリに関連付けられている TLSA レコードのクエリを実行します。 TLSA レコードが発行されていない場合、TLSA 参照への応答は NOERROR (このドメインに対して要求された種類のレコードなし) または NXDOMAIN (そのようなドメインはありません) である必要があります。 DNSSEC では、TLSA レコードが発行されていない場合は、この応答が必要です。それ以外の場合、Exchange Onlineは応答の欠如を SERVFAIL エラーとして解釈します。 RFC 7672 に従って、SERVFAIL 応答は信頼できないです。そのため、宛先ドメインは DNSSEC 検証に失敗します。 この電子メールは、次のエラーで延期されます。

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

電子メール送信者がメッセージの受信を報告する場合

たとえば、GoDaddy などの DNS プロバイダーを使用している場合は、DNS プロバイダーにエラーを警告して、DNS 応答のトラブルシューティングを行うことができます。 独自の DNSSEC インフラストラクチャを管理している場合は、DNS サーバー自体またはネットワークに問題がある可能性があります。

よく寄せられる質問

Exchange Onlineのお客様は、DNSSEC や DANE の使用をオプトアウトできますか?

DNSSEC と DANE は、サービスのセキュリティポジションを大幅に向上させ、すべてのお客様に利益をもたらすと強く信じています。 Microsoft は、この展開が Microsoft 365 のお客様に与える可能性のある影響のリスクと重大度を軽減するために、過去 1 年間に精力的に取り組んできました。 展開の監視と追跡を積極的に行い、展開のロールアウト時に悪影響を最小限に抑えます。このため、テナント レベルの例外やオプトアウトは使用できません。 DNSSEC や DANE の有効化に関連する問題が発生した場合、このドキュメントに記載されているエラーを調査するためのさまざまな方法は、エラーの原因を特定するのに役立ちます。 ほとんどの場合、問題は外部の宛先パーティに対して発生し、これらの標準を使用してExchange Onlineから電子メールを受信するために DNSSEC と DANE を正しく構成する必要があることをこれらのビジネス パートナーに伝える必要があります。

DNSSEC と DANE の関係

DNSSEC は、公開キー インフラストラクチャを適用して、DNS クエリに応答して返されるレコードが本物であることを確認することで、DNS 解決に信頼レイヤーを追加します。 DANE は、受信側のメール サーバーが、本物の MX レコードの正当で予期されるメール サーバーであることを保証します。

MTA-STS と DANE for SMTP の違いは何ですか?

DANE と MTA-STS は同じ目的を果たしますが、DANE では DNS 認証に DNSSEC が必要ですが、MTA-STS は証明機関に依存しています。

Opportunistic TLS で十分でないのはなぜですか?

日和見 TLS は、両方がサポートすることに同意した場合、2 つのエンドポイント間の通信を暗号化します。 ただし、TLS が転送を暗号化した場合でも、ドメインの実際のエンドポイントではなく悪意のあるアクターのエンドポイントを指すように、DNS 解決中にドメインがスプーフィングされる可能性があります。 このスプーフィングは、DNSSEC で MTA-STS や SMTP DANE を実装することで対処される電子メール セキュリティのギャップです。

DNSSEC で十分でないのはなぜですか?

DNSSEC は、メール フロー シナリオの Man-in-the-Middle 攻撃とダウングレード (TLS からクリア テキスト) 攻撃に対して完全に耐性がありません。 MTA-STS と DANE を DNSSEC と共に追加すると、MITM 攻撃とダウングレード攻撃の両方を阻止するための包括的なセキュリティ方法が提供されます。

ドメインまたは DNS レコードを追加後に問題を特定して解決する

DNSSEC の概要 |Microsoft Docs

DMARC を使用して電子メール、セットアップ手順を検証する - Office 365 |Microsoft Docs

カスタム ドメインのメールに DKIM を使用する方法 - Office 365 |Microsoft Docs

Sender Policy Framework (SPF) がスプーフィングを防ぐ方法 - Office 365 |Microsoft Docs

Microsoft Ignite 2020 からトランスポート ニュースをExchange Onlineする - Microsoft Tech Community

rfc8461 (ietf.org)