Microsoft 365経由で送信するアプリケーションには、サポートされているメール ルートと正しい認証が必要です。クライアントSMTP送信、コネクタベースのSMTPリレー、および直接送信は、異なる信頼モデルと受信者モデルを使用します。
変更する前にルートを確認する SPF, DKIM または DMARC。 DNS送信の依存関係を記述することはできますが、サポートされていないルートを承認されたリレーに変更したり、ダイレクト送信を外部の受信者に配信したりすることはできません。
アプリケーションが行う必要があることを記録する
アプリケーションのホスティング場所、送信者の ID、対象の受信者、サポートされている認証およびトランスポート機能を特定します。責任のあるビジネス サービスと管理者を記録します。
組織内のデバイスとサードパーティがホストするアプリケーションを区別します。すべての製品が同じコネクタを使用できると仮定するのではなく、そのホスティング モデルに関する現在の Microsoft ガイダンスを確認してください。
外部受信者がビジネス ワークフローの一部である場合は、外部受信者用の別のテストを含めます。内部のみの成功では、外部の配信ルートは確立されません。
サポートされているルートを比較する
Microsoft の現在のセットアップ ガイドでは、次のアプローチが区別されています。
クライアントSMTP送信では、認証されたクラウド メールボックスが使用され、内部および外部の受信者がサポートされます。
SMTPリレーは受信コネクタを使用し、前提条件が満たされている場合は外部にリレーできます。
ダイレクト送信は内部受信者への配信であり、インターネット中継ではありません。
大容量電子メールは、HVE アカウントを使用する別個の内部受信者サービスであり、外部配信の代替サービスではありません。
この比較は、完全な構成やライセンス仕様ではなく、選択の補助として扱ってください。現在のファーストパーティの指示にある、該当する認証サポート、ネットワーク アクセス、制限、および前提条件を再確認してください。
古いデバイス ガイドに記載されているという理由だけで、非推奨または不適切な認証方法を有効にしないでください。アプリケーションと現在のサービスが実際にサポートするルートを選択します。
SMTPリレーを使用する前にコネクタの信頼性を理解する
Microsoft は、 SMTPリレー構成のための証明書ベースまたはパブリック IP ベースの認証を文書化しています。ネットワークとホスティングの要件が重要です。
証明書ベースのルートには、証明書構成に適切な承認済みドメイン関係が必要です。 IP ベースのルートは、デバイスに表示されるプライベート アドレスではなく、Microsoft に表示されるパブリック アドレスに依存します。
Microsoft の現在のガイドでは、Azure がホストするサービスなどのサードパーティがホストするアプリケーションを、このSMTPリレーの取り決めから除外しています。 IP 認証を使用する場合、アドレスは静的である必要があり、他の組織と共有しないでください。共有アドレスとホスティングの制限を注意深く確認してください。組織外で共有されるインフラストラクチャ用の IP コネクタを作成すると、管理者が意図したものとは異なる信頼スコープが作成される可能性があります。
Microsoft が生成または検証したMXエンドポイントと現在のコネクタ手順を使用します。短縮ドメイン名からエンドポイントを作成したり、別のテナントの設定をコピーしたりしないでください。
ダイレクト送信と外部リレーを混同しないでください
直接送信では、クラウドベースの組織外の受信者への配信は行われません。 Microsoft のガイダンスでは、これを、関連するメール サーバーの責任と適切な制限がある上級顧客向けのオプションとして扱っています。
合成例では、スキャナーは従業員への送信に成功しますが、ワークフローで顧客の外部アドレスを追加すると失敗します。この症状は、受信者のスコープに外部リレーが含まれていないルートと一致しています。
SPFインクルードを追加しても、その受信者の範囲を変更することはできません。無関係なレコードを編集する前に、ルートとアプリケーションの要件を再評価してください。
選択したルートの後に本人確認を行う
参考文献: RFC 9989 §4.4.
サポートされるルートが構成されたら、実際のアプリケーションから受信したメッセージを検査します。表示されている From、評価されたSPF ID、関連するDKIM署名、および信頼できるDMARC結果を記録します。
コネクタによる接続の受け入れと受信者の調整された認証結果は、異なるものを確立します。送信ゲートウェイまたは追加のリレーも最終結果に影響を与える可能性があります。
ドメインのセットアップにはMicrosoft 365認証ガイドを使用し、 アライメント ローパス不一致の診断。
ルート固有の受け入れ記録を保持する
選択した方法、ホスティング モデル、信頼メカニズム、受信者の範囲、所有者および代表的な結果を保持します。正確なプロバイダーの指示と構成日付を含めて、後で管理者が変更された要件を特定できるようにします。
認証と配信の失敗を個別に記録します。拒否された接続、サポートされていない受信者ルート、および調整に失敗した受信メッセージには、さまざまな修正が必要になる場合があります。
完全な結果は、単に有効なだけではなく、説明責任のある信頼と検証されたメッセージを備えたサポートされたアプリケーション ルートです。 TXTレコード または内部テストが成功した場合。