※ この記事は、Introducing more control over Direct Send in Exchange Online の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。
ダイレクト送信は、オンプレミスのデバイス、アプリケーション、またはサード パーティのクラウド サービスから、Exchange Online でホストされているお客様のメールボックスに対して、お客様自身の承認済みドメインを使用してメールを直接送信する方法です。この方法では、認証は一切必要ありません。なぜならこの方法は、送信者のドメインがお客様自身の承認済みドメインであることを除いて、インターネットからの匿名のメールを受信することと同様であるためです。
ダイレクト送信では、お客様がテナントに対して SPF、DKIM、および DMARC を適切に構成していることを前提としています。管理者は、デバイス、アプリケーション、またはサード パーティ サービスが送信に使用する送信元 IP アドレスを SPF レコードに追加することで、メールがスパムとしてフラグ付けされるのを防ぐ必要があります。SPF が適切に構成されていない場合、ダイレクト送信を使用して送信されたメールはスパムとしてフラグ付けされる可能性が高くなります。
SPF は、ドメインのなりすましを防ぐための保護を提供しますが、有効なルーティング シナリオでも SPF の失敗に該当する可能性があるため、Soft Fail させる SPF の構成を使用することをお勧めしています。また、ダイレクト送信を使用する必要がないお客様も多いですがこれまでダイレクト送信をブロックする機能は存在しませんでした。この度、Exchange Online のダイレクト送信を拒否する設定を開発し、本日この機能のパブリック プレビューを発表します。
ダイレクト送信の拒否機能
定義上、ダイレクト送信は、組織のメールボックスに対して自社ドメインから匿名で送信されるメッセージを対象としています。ダイレクト送信の拒否機能を有効にすると、これらの条件に該当するトラフィックがすべてブロックされます。送信ドメインがテナントの承認済みドメインであるかどうかは、簡単かつ明確に評価できる条件です。この場合の送信ドメインとは、P1 エンベロープ From アドレスを指します。この機能では、P2 ヘッダー From アドレスはチェックされません。また、ここでの「匿名」とは、Exchange Online に送信される際に、いずれのメール フロー コネクタにも関連付けられていないメッセージを意味します。
ダイレクト送信のトラフィックには、組織が許可したサード パーティ サービスや、オンプレミスでホストされている独自のメール アプリケーションが含まれる場合があります。この機能を有効化した際にこれらのメッセージが拒否されないようにするには、認証が必要です。これを実現するには、メッセージ送信に使用される証明書 (推奨) または IP アドレスに一致するパートナー タイプのインバウンド コネクタを作成します。パートナー タイプのインバウンド コネクタの詳細については、こちらをご覧ください: Exchange Online でコネクタを使用してメール フローを構成する。
ダイレクト送信を使用しているすべての送信者を現在把握できていない管理者もいるかもしれませんが、まずはドメインの SPF レコードを確認することが良い出発点となります。受信者の受信トレイにメールを正常に配信するためには、ダイレクト送信を使用する送信者が承認済みドメインの SPF レコードに含まれている必要があります。SPF レコードに含まれていない送信者は、すでにメール配信に苦労している可能性があります。
機能を有効化する方法
デフォルトでは、新しいオプトイン設定である RejectDirectSend は False に設定されています。ダイレクト送信の拒否機能を有効化するには、Exchange Online に管理者で接続した PowerShell で以下のコマンドレットを実行する必要があります。
1 | Set-OrganizationConfig -RejectDirectSend $true |
この変更は、サービス全体に 30 分以内に反映されます。この機能を有効化すると、ダイレクト送信で送られたすべてのメールに対して以下のエラー メッセージが返されます。
550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources
ダイレクト送信を再度有効化しない限り、このエラーに該当するメッセージは受信者に送られません。受信者に配信するには、送信者を認証するためのパートナー タイプのインバウンド コネクタを作成する必要があります。
パブリック プレビューとリリース ロードマップ
この機能は、管理者がテストを行いフィードバックを提供するためのパブリック プレビューとしてリリースされています。一部のお客様では、組織に送信されるダイレクト送信トラフィックの追跡が難しく、この機能を有効化することに不安を感じる場合があります。機能リクエストやバグ報告を含むフィードバックは、次のアドレスに送信してください。directsend-feedback[AT]microsoft.com。注意 : ここに送信されたフィードバックには返信されません。この機能に関する質問や問題については、元の記事のコメント欄に記載するか、通常のサポート チャネルを通じてお問い合わせください。
また、Exchange Online Feedback Portal を使用して、他の顧客が投票できる機能リクエストを送信することも可能です。この方法は、私たちが機能に関する意思決定を行う際の参考になります。
私たちは、どのようなダイレクト送信のトラフィックが組織に流入しているかを可視化するための機能を提供する作業を進めています。これにより、管理者は正当なトラフィックを特定して対応し、この機能を自信を持って有効化できるようになります。この取り組みに関する進捗は、元の記事で随時更新していきます。この機能の一般提供 (GA) の具体的な日程は、いただいたフィードバックに基づいて決定されるため、現時点では未定です。GA の発表については、別途お知らせいたします。
将来的には、この機能を新しいテナントに対してデフォルトで有効化する予定です。これは、組織をデフォルトでより安全にするための取り組みの一環です。また、この計画には、新しいテナントがこの機能を無効化できないようにすることも含まれています。これにより、認証されていないダイレクト送信のトラフィックの使用を抑制することを目指しています。
既知の問題
この機能により影響を受ける可能性のある転送シナリオがあります。組織内の誰かがサード パーティにメッセージを送信し、そのサード パーティがそのメッセージを組織内の別のメールボックスに転送する場合です。サード パーティのメール プロバイダーが Sender Rewriting Scheme (SRS) をサポートしていない場合、メッセージは元の送信者のアドレスで戻ってきます。この機能が有効化される前は、これらのメッセージは SPF の失敗によってすでに影響を受けていましたが、受信トレイに届く可能性がありました。しかし、パートナー タイプのインバウンド コネクタを設定せずにダイレクト送信の拒否機能を有効化すると、これらのメッセージは即座に拒否されることになります。
最後に
Exchange 管理者の皆様には、この機能をぜひお試しいただき、一般提供 (GA) に向けた検証と改善のためのフィードバックをご提供いただければ幸いです。