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

[アーティクル]
08/11/2023

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 が生成され、送信者に送信されます。

ヒント

E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータセキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview コンプライアンスポータルのトライアルハブで今すぐ開始してください。サインアップと試用期間の詳細については、こちらをご覧ください。

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

TLSA リソースレコード

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

TLSA レコードの例:

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

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

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

¹ 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 アウトバウンドを使用Exchange Online方法

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

顧客が SMTP DANE インバウンドを使用Exchange Online方法

現在、受信 SMTP DANE はExchange Onlineではサポートされていません。近い将来、受信 SMTP DANE のサポートが提供される予定です。

推奨される TLSA レコード構成とは

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 接続が宛先サーバーでサポートされていません。

テクノロジ	その他の情報
メール転送エージェント - 厳格なトランスポートセキュリティ (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 を使用してメールを検証する、セットアップ手順

SMTP DANE を使用した電子メールの送信に関するトラブルシューティング

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

[メッセージトレースの詳細] ビューを使用した Exchange 管理センターポータル。
DANE または DNSSEC エラーが原因でメッセージが送信されない場合に生成される NDR。
リモート接続アナライザーツール 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC8460で導入された SMTP TLS-RPT (トランスポート層セキュリティレポート) を採用する
リモート接続アナライザーツール 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 レポートを送信します。

レコードの例:

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 レコードが返されました。

注:

4/5.4.312 DNS query failed

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

注:

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

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

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

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

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

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

注:

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

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

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

注:

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

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

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

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

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

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

注:

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

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

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

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

注:

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

送信メールが送信されるときに、受信ドメインで 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)

Share via

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