用語 · Office 365のSMTP設定

Office 365のSMTP設定とは何か、アプリケーションのメールにどう影響するのか

Office 365 SMTPの詳細は、単一の共通ホストとパスワードではありません。Microsoftは、smtp.office365.comを介した認証済みクライアントサブミッション、テナントのMXエンドポイントを介したコネクタベースのSMTP relay、内部Microsoft 365受信者へのDirect Sendを含む、複数のアプリケーションおよびデバイスパターンを文書化しています。これらは認証、TLS、ポート、送信者ID、外部受信者のサポート、ライセンス、上限、管理設定が異なります。ワークロードと信頼境界に基づいてパターンを選択し、クライアントサブミッションが該当する場合はOAuthを使用し、SMTP AUTHを限定的に有効化して、正確なエンベロープIDとFrom IDをテストし、リレーによる受け付けは最終配信や受信トレイ到達率とは別に扱ってください。

Office 365 SMTPの詳細は複数の経路を説明する

Microsoft 365とOffice 365のドキュメントは、クライアントSMTPサブミッション、SMTPリレー、Direct Sendを区別しています。クライアントサブミッションはExchange Onlineのメールボックスとして認証し、smtp.office365.com経由で送信します。SMTPリレーは、アプリケーションやデバイスを組織のメールサーバーとして扱い、受信コネクタで接続を認証します。Direct Sendは、組織内の受信者に向けて、テナントのMicrosoft 365のMXエンドポイントに匿名でサブミッションします。これらは、似たようなSMTPコマンドの裏にある、運用上まったく異なる仕組みです。どの経路を使うかを決めずに、フォーラムからホスト名とポートをコピーしてはいけません。まず、テナント、承認済みドメイン、管理者、ワークロード、送信者ID、送信元ネットワーク、受信者の範囲、認証方式、TLSポリシー、送信量、障害時の担当者を記録してください。SMTPによる転送は、送信のきっかけとなるビジネスイベントを認可するものでも、受信者の同意を立証するものでも、アプリケーションのキューを永続化するものでもありません。

クライアントSMTPサブミッションの設定

Microsoftの現在のセットアップガイドでは、クライアントサブミッションのDNS名としてsmtp.office365.comが記載されており、IPアドレスで代用しないよう指示されています。TCPポート587を推奨し、文書化されたシナリオではポート25も認めており、STARTTLSを有効にしたTLS 1.2またはTLS 1.3を必須としています。アプリケーションは、ライセンスが割り当てられたMicrosoft 365またはOffice 365のメールボックスとして認証し、文書化された上限の範囲内で内部と外部の受信者に送信できます。メールボックスのアドレスを明示的なIDとして使い、表示上のFromが異なる場合はSend Asの権限をテストしてください。認証情報やトークンはサーバー側のシークレットマネージャーに保管します。アカウントへのログインが成功しても、表示上のFromが許可されていること、受信者が有効であること、メッセージが受信トレイに届くことは証明されません。クライアントサブミッションはメールボックス単位の経路であるため、ユーザーの停止、ライセンスの変更、条件付きアクセスの判定、SMTP AUTHの設定によって、アプリケーション側は何も変わっていなくても送信が止まることがあります。

OAuthを使い、SMTP AUTHの有効化は最小限にとどめる

Microsoftは、クライアントSMTPサブミッションに、OAuthを使った先進認証を推奨しています。OAuthのドキュメントでは、SMTP.SendスコープとSASL XOAUTH2の形式が定義されており、委任型とアプリケーション向けのフローは、Microsoft Entraでの登録とExchangeの権限に従います。アクセストークンとリフレッシュトークンは秘密情報として扱い、必要な権限だけを要求し、テナントとメールボックスの紐付けを検証し、アプリケーションの認証情報をローテーションし、使っていない許可は削除してください。Microsoftはまた、Exchange Onlineの組織全体でSMTP AUTHを無効にし、まだ必要なメールボックスに対してのみ有効にすることを推奨しています。組織全体の設定とメールボックスごとの上書き設定の両方があり、メールボックスの設定が優先される場合があります。セキュリティの既定値群ではSMTP AUTHが無効になります。古いデバイスを1台動かし続けるためだけに、テナント全体のセキュリティのベースラインを無効にしてはいけません。ワークロードがOAuthとTLSの要件を満たせない場合は、コネクタ、サポートされている最新のクライアント、オンプレミスのリレー、または文書化された別のサービスを選んでください。

クライアントサブミッションの上限はアプリケーションの設計に影響する

Microsoftの現在の比較表では、クライアントSMTPサブミッションのスロットリングは、1日あたり受信者10,000人、1分あたりメッセージ30通とされています。これらは変更される可能性のある現在のサービス上限であり、Exchange Onlineの他の上限と相互に影響することがあるものとして扱ってください。メッセージの数だけでなく、To、Cc、Bcc、再試行、ファンアウトにわたる受信者の数を数えます。アプリケーションのレート、テナント間の公平性、同時実行数、試行回数、キューの滞留時間の制御は、サービスの上限より低く設定してください。共有メールボックスの経路では、人による利用と自動化による利用が競合することがあり、多くのアプリケーションで1つの認証情報を使うと担当が見えなくなります。レートと受信者数の余裕を監視しますが、メールボックスや送信ドメインを切り替えて上限を回避しようとしてはいけません。ワークロードが日常的にメールボックスのサブミッション上限に近づくようであれば、Microsoftの最新のガイダンスに基づいて、コネクタによるリレー、対象となる内部トラフィック向けのHigh Volume Email、アプリケーションからの配信向けのAzure Communication Services Email、または用途に特化した別の転送手段を検討してください。

コネクタベースのSMTPリレーの詳細

Microsoft 365のSMTPリレーは、smtp.office365.comではなくテナントのMXエンドポイントと、組織の送信システムを識別する受信コネクタを使います。Microsoftは、TLS証明書でコネクタを認証することを推奨しており、文書化されたもうひとつの識別方法として公開の固定IPアドレスがあります。アプリケーションはTCPポート25で接続し、送信者ごとにライセンス付きのメールボックスを用意しなくても、承認済みドメインのアドレスから送信できます。このパターンは、証明書とネットワークの管理が安定している、管理下のメールサーバー、アプライアンス、ゲートウェイに適しています。その分、管理の手間は増えます。コネクタの適用範囲、証明書のライフサイクル、公開IPの変更、逆引きDNS、承認済みドメインのポリシー、不正利用の防止、ブロックリストの監視です。オープンリレーを決して作らないでください。ゲートウェイが受け付ける内部システム、テナント、送信者、受信者、メッセージの種類を制限します。コネクタは接続が組織のものであることを認識するだけで、任意のアプリケーションの入力が正当であることを検証するものではありません。

Direct Sendは内部受信者への配信であり、汎用のリレーではない

Direct Sendは、メールボックスやコネクタとして認証することなく、外部のSMTPサーバーとしてテナントのMXエンドポイントにサブミッションします。Microsoftはこれを、Microsoft 365またはOffice 365の組織内の受信者への配信手段として文書化しており、任意の外部アドレスへの経路としては位置付けていません。デバイスやアプリケーションにはTCPポート25へのアクセスが必要で、承認済みドメインの送信者を使うべきです。インターネットに面したサービスから見ると匿名の経路であるため、送信者レピュテーション、DNS、送信元IP、なりすまし対策の判定が重要になります。Direct Sendのゲートウェイを信頼できないネットワークに公開したり、メールボックスの認証を回避するために使ったりしてはいけません。プリンターやアプリケーションはバウンスメッセージを安全に受け取れない場合があるため、配信不能レポートとサポートの担当をモデル化しておいてください。外部への配信が必要な場合は、IDと送信量を評価したうえで、クライアントサブミッション、コネクタによるリレー、Azure Communication Services Email、またはサポートされている別の方法を選んでください。

エンベロープのID、表示上のFrom、認証を区別する

どの経路にも、SMTPのエンベロープの送信者と受信者のコマンド、そしてRFC 5322の表示されるヘッダーがあります。エンベロープの送信者は転送時のバウンスを制御し、多くの場合SPFのIDにもなります。表示上のFromは読み手に見えるものを制御し、DMARCの中心となるIDです。OAuthによるメールボックスの認証、コネクタのID、送信元IPによる受け付けは、任意の独自Fromドメインについて、SPF、DKIM、DMARCのアライメントを自動的に作り出すものではありません。管理下で受信したサンプルで、正確なMAIL FROM、From、Reply-To、DKIMのd=ドメインとセレクター、接続元IPを洗い出してください。該当するドメインに有効なSPFポリシーを1つ公開し、対応している場合はDKIM署名を設定し、DMARCのアライメントを評価します。1台のデバイスを直すために2つ目のSPFレコードを追加したり、組織のDMARCポリシーを緩めたりしてはいけません。ステータスモデルでは、Microsoftによる受け付け、宛先サーバーによる受け付け、後からのバウンス、メールボックスでのフィルタリング、受信トレイへの到達、人によるアクションを区別してください。

永続的なアプリケーションの境界を実装する

Microsoft 365のSMTPは、認可されたサーバーのワーカーか管理下のリレーの背後に置いてください。接続する前にビジネスイベントを永続化し、安定した冪等キー、テナント、メッセージの種類、テンプレートのリビジョン、承認された送信者と受信者、同意または必要性の根拠、サプレッションの状態、試行履歴を含めます。SMTPコマンドを生成する前に、テナントごとの送信者と受信者のルールを適用します。メッセージのサイズ、受信者のファンアウト、添付ファイル、ヘッダーの値に上限を設けてください。トークン、パスワード、証明書の秘密鍵、コネクタの管理情報は、ソースコード、ログ、分析、チケット、プロンプトの外に保管します。有限のタイムアウトを設定し、完全な拡張診断とMicrosoftのガイダンスに基づいて、4xxの応答は上限付きの再試行の候補、5xxの応答はその試行について恒久的なものと分類してください。DATAの後、最後の応答を受け取る前に切断された場合は結果が曖昧です。その試行を保存し、再送する前に突き合わせてください。SMTPには、プロダクトレベルでのexactly-onceの保証はありません。

展開の前に設定と失敗モードをテストする

専用の管理下の受信者と、本番と同じ形の送信元ネットワークを使ってください。DNSの名前解決、ポートへの到達性、STARTTLSのネゴシエーション、証明書のホスト名とチェーン、OAuthトークンの取得とスコープ、組織とメールボックスのSMTP AUTHの設定、Send Asの権限、コネクタの照合、承認済みドメイン、MXエンドポイントの選択を確認します。プレーンテキスト、HTML、添付ファイル、Unicode、バウンス、想定送信量のサンプルを送信します。顧客のコンテンツを保持することなく、rawのヘッダー、信頼できるAuthentication-Results、SMTPの応答、トレースの識別子、メッセージ追跡の証拠を記録してください。ネガティブテストでは、取り消されたトークン、期限切れのコネクタ証明書、変更された公開IP、メールボックスで無効化されたSMTP AUTH、セキュリティの既定値群、無効なFrom、Direct Sendでの外部受信者、1分あたりの上限と受信者数の上限、一時的な遅延、恒久的な拒否、DATA前後での接続の切断を扱うべきです。恒久的なポリシーや受信者の失敗を回避することなく、ワークロードを一時停止し、永続化したジョブを移す手順を予行演習しておきましょう。

最新のMicrosoftガイダンスを使用し、テナントをテストする

Microsoft 365 SMTP設定は、テナントのポリシー、ID、コネクタ、ネットワーク環境によって異なります。最新のMicrosoft Learnドキュメントを使用し、本番メールに依存する前に選択した経路をテナントでテストしてください。

よくある質問

Microsoft 365のクライアントSMTPのホスト名は何ですか？

Microsoftは現在、認証付きのクライアントサブミッションにsmtp.office365.comを文書化しており、固定のサービスIPアドレスではなくDNS名を使うよう指示しています。

クライアントSMTPサブミッションにはどのポートを使うべきですか？

MicrosoftはTCPポート587を推奨しており、サポートされているクライアントサブミッションのシナリオではポート25も文書化しています。いずれもSTARTTLSと、TLS 1.2またはTLS 1.3が必須です。

Microsoft 365のクライアントサブミッションはOAuthに対応していますか？

はい。MicrosoftはOAuthを推奨しており、SMTP.SendスコープとSASL XOAUTH2を文書化しています。ただし、テナントへの登録、権限、トークンの保管、メールボックスとの紐付けには、引き続き慎重な設定が必要です。

SMTPリレーとDirect Sendの違いは何ですか？

コネクタによるリレーは組織のメールシステムを認証し、外部の受信者にも対応できます。Direct Sendはそのようなコネクタを使わずにテナントのMXエンドポイントを使うもので、内部の受信者向けです。

SMTP AUTHはすべてのメールボックスで有効にすべきですか？

いいえ。Microsoftは、組織全体で無効にし、まだ必要なメールボックスに対してのみ有効にすることを推奨しており、先進認証とサポートされている代替手段を優先するよう求めています。

Office 365のSMTPでの受け付けは、受信トレイへの配信を意味しますか？

いいえ。受け付けは範囲の限られた転送上の結果です。その後の配信、配信不能、受信側のフィルタリング、メールボックスのどのフォルダに入ったか、人によるエンゲージメントは、それぞれ別の証拠です。

アプリケーションはMicrosoftのクライアントサブミッションにポート465を使えますか？

Microsoftの現在のガイドによると、デフォルトでポート465を使うデバイスは、このMicrosoft 365の経路でクライアントサブミッションに必要なTLSバージョンに対応していません。

Microsoft 365 SMTP設定はどこで検証すべきですか？

最新のMicrosoft Learnドキュメントを使用し、本番メールに依存する前に選択した経路をテナントでテストしてください。

出典

さらに学ぶ

SMTPリレーサービスの評価方法サブミッションのセキュリティ、認証、キュー、再試行の挙動、上限、配信イベント、サプレッション、分離、移行への適合性でSMTPリレーサービスを評価します。GoogleのSMTPリレーサービス評価ガイド認可モデル、TLS、送信者ID、クォータ、エラー処理、認証、オブザーバビリティ、移行リスクの観点からGoogle WorkspaceのSMTPリレーを評価します。メールプロトコルSMTP：アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションメールのワークフローをどう形作るのかを学びます。SMTPポート25、465、587：実践ガイド役割とTLSモードに応じて適切なSMTPポートを選び、接続、ハンドシェイク、認証、メッセージの受け付けの失敗を診断します。メール到達率サービスの評価方法対象範囲、根拠、認証、フィードバックループ、サプレッション、プライバシー、移行のしやすさ、運用への適合性でメール到達率サービスを評価します。