※ この記事は、Introducing more control over Direct Send in Exchange Online の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。
2025 年 8 月 12 日更新: よくある質問 (FAQ) を記事に追加しました。また、ダイレクト送信機能についてさらに詳しく解説した新しい記事 ダイレクト送信と Exchange Online テナントへ直接メールを送ることの違いも公開していますので、あわせてご参照ください。
公開情報等では「直接送信」などの記載になっている場合がございますので、ご注意ください。
ダイレクト送信は、オンプレミスのデバイス、アプリケーション、またはサード パーティのクラウド サービスから、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 の失敗によってすでに影響を受けていましたが、受信トレイに届く可能性がありました。しかし、パートナー タイプのインバウンド コネクタを設定せずにダイレクト送信の拒否機能を有効化すると、これらのメッセージは即座に拒否されることになります。
- もし Azure Communication Services (ACS) を利用して自組織のテナント宛てにメールを送信しており、その際に “MAIL FROM” アドレスとして Microsoft 365 の承認済みドメインを使用している場合、RejectDirectSend を有効化すると、これらのメールは Microsoft 365 テナントへの配信がブロックされます。ダイレクト送信の拒否設定において ACS トラフィックを信頼済みとして扱うためのソリューションが完成し、現在サービス全体への展開が進行中です。この機能は 2025 年 11 月 1 日までに全世界でご利用いただける予定です。一方、ACS から送信されるメールのドメインが Microsoft 365 の承認済みドメインやサブドメインでない場合は、RejectDirectSend を有効化しても ACS トラフィックには影響しません。また、ACS のメール トラフィックが MX レコードをサード パーティ サービスに向けている Exchange Online ドメインを利用している場合は、下記の FAQ に記載のコネクタ設定手順をご参照ください。
最後に
Exchange 管理者の皆様には、この機能をぜひお試しいただき、一般提供 (GA) に向けた検証と改善のためのフィードバックをご提供いただければ幸いです。
FAQs
すべてのお客様が -RejectDirectSend パラメーターを有効化しなければ、自身のテナントが保護されているとは言えませんか？
いいえ。このパラメーターは、Microsoft 365 における多層的な保護の一つです。お客様が承認していないダイレクト送信トラフィックを明確に拒否できる厳格な制御を提供します。テナントやドメインが適切に構成されていれば、なりすましメールは既存の認証チェックによって迷惑メール フォルダーや検疫に振り分けられます。この設定を有効化しなくても、既存の保護機能によって自社ドメインのなりすましメールから十分に守られています。また、この設定を有効化しても、他のサード パーティ ドメインによるなりすましについては、引き続き既存の保護機能が利用されます。
MX レコードを他のサービスに向けているお客様は、Exchange Online を使用してサード パーティのクラウド サービスを使用してメール フローを管理するの手順にすでに従っている必要があります。すべてのお客様は、クラウド メールボックスのなりすまし対策保護の推奨事項に従ってスプーフィングからの保護も設定する必要があります。
RejectDirectSend 設定は、MX レコードがサード パーティ サービスを指している場合でも機能しますか？
はい、MX レコードがサード パーティ サービスを指している場合や Exchange Online を直接指している場合でも RejectDirectSend は機能します。MX の場所には依存しません。ただし、MX を他のサービスに向けている場合は、そのサービスからのトラフィックのみを受け入れるコネクタを作成し、他のトラフィックを除外する構成が推奨されます。推奨されるテナント構成でコネクタを設定している場合、認証されていないダイレクト送信のトラフィックが届くことはなく、拒否の設定が利用されることはありません。
ドメインの MX レコードはサード パーティ サービスを指しており、誰かが MX をバイパスして直接 Exchange Online テナントにメールを送信しています。-RejectDirectSend 設定を使えば、Exchange Online テナントをサード パーティ サービス経由のメールだけ受け付けるように制限できますか？
いいえ。-RejectDirectSend は、P1 送信ドメイン (エンベロープ FROM) がテナントの承認済みドメインであり、かつインバウンド コネクタに紐付けられていないメールのみを拒否します。
MX がサード パーティ サービスを指しており、そのサービス以外からのメールを受け付けたくない場合は、サポート記事 Exchange Online を使用してサード パーティのクラウド サービスを使用してメール フローを管理する の手順 4 で推奨されているように、TlsSenderCertificateName (推奨) または SenderIpAddresses パラメーターを使ってインバウンド コネクタを作成し (第 3 者機関証明書または IP アドレスを指定する必要があります)、RestrictDomainsToCertificate または RestrictDomainsToIPAddresses を $True に設定してください。これにより、インバウンド コネクタを通過したメールのみがテナントに配信され、それ以外は拒否されます。詳細はダイレクト送信と Exchange Online テナントへ直接メールを送ることの違いをご参照ください。
-RejectDirectSend を有効化し、承認済みドメインから送信する必要があるパートナー向けにインバウンド コネクタを作成しました。パートナーからのメールが本当にそのコネクタに紐付いているかどうかを確認するにはどうすればよいですか？
パートナーからのメールがコネクタに紐付いているかどうかを確認するには、パートナーからテスト メールを送信してもらい、しばらく時間をおいてデータが反映された後、以下のコマンドを実行してください。
1 | Get-MessageTracev2 -MessageId "your message ID here" | Get-MessageTraceDetailv2 | fl |
出力結果の中で、コネクタ名が次のように表示されていることを確認できます。
また、メールのエンティティ ページでもコネクタ名 (コネクタの GUID) が表示されていることを確認できます。
RejectDirectSend を有効化しましたが、自社の承認済みドメインから送信する必要があるサード パーティ ベンダーが、コネクタに関連付けられる静的 IP 範囲や専用証明書を持っていません。この場合、ダイレクト送信をブロックしつつ、このサード パーティ ベンダーからのメールのみ許可するにはどうすればよいですか？
サード パーティ ベンダーが静的 IP 範囲や専用の証明書を提供できない場合、またはさらにカスタマイズが必要な場合は、RejectDirectSend 設定で組織全体のダイレクト送信をブロックする代わりに、トランスポート ルール (メール フロー ルール) を利用して、ダイレクト送信メールを隔離またはリダイレクトする方法があります。トランスポート ルールでは、サード パーティ ベンダー固有の例外条件を柔軟に追加できます。たとえば、ベンダーが特定の X- ヘッダーを付与している場合、そのヘッダーを条件に例外を設定できます。
例:
- メッセージの送信者が “組織外” で、送信者ドメインが “contoso.com” の場合、ホストされた検疫にリダイレクトする
- メッセージ ヘッダー (ヘッダー名と値を指定) が一致する場合を除く
(検疫以外のアクションも選択可能です)
RejectDirectSend パラメーターを設定するために必要な権限は何ですか？
RejectDirectSend パラメーターの設定には、Exchange Online の “Organization Configuration” ロールが割り当てられている管理者権限が必要です。通常、このロールは “Organization Management” ロール グループに含まれています。
RejectDirectSend は承認済みドメインのサブドメインである P1 送信ドメインアドレスにどのような影響を与えますか？
RejectDirectSend は、承認済みドメインで「すべてのサブドメインのメールを受信する」が有効になっている (MatchSubDomains=TRUE) 場合、その承認済みドメインのサブドメインである P1 アドレスからのメールに影響します。
この投稿の変更点:
- 2025 年 10 月 6 日: ACS トラフィックを「信頼済み」として扱う方法について詳細を追記しました。
- 2025 年 8 月 29 日: 承認済みドメインのサブドメインに関する FAQ を追加しました。
- 2025 年 8 月 12 日: 既知の問題および FAQ を追加しました。
- 2025 年 8 月 4 日: ダイレクト送信と Exchange Online テナントへ直接メールを送ることの違いへの参照を追加しました。
- 2025 年 7 月 30 日: コメントでのよくある質問に基づいて、本文にいくつかの説明を加えました。