Microsoft 365のSMTPサーバー設定と活用法｜4つの送信方式・送信制限・2026年問題まで解説

複合機のスキャンtoメール、基幹システムからの自動通知、WordPressの問い合わせフォーム。これらの送信元として「Microsoft 365のSMTPサーバー（smtp.office365.com）」を指定している企業は非常に多く存在します。設定自体はサーバー名・ポート番号・IDとパスワードを入れるだけ。手軽で、追加コストもかからない方法です。

しかし、その手軽さの前提が2026年に大きく変わります。Microsoftは、SMTPクライアント送信における基本認証（ユーザー名とパスワードによる認証）を2026年12月末に既定でオフにすると発表しました。何も対応しないままこの日を迎えると、これまで当たり前に送れていた通知メールやスキャンメールが、ある朝突然エラーで止まる可能性があります。

本記事では、Microsoft 365のSMTPサーバー設定値と有効化の手順を押さえたうえで、Microsoftが公式に案内している4つの送信方式（クライアントSMTP送信／SMTPリレー／直接送信／High Volume Email）の使い分け、見落としやすい送信制限の具体的な数値、そして基本認証の既定オフに向けた移行先の選び方までを一気に整理します。

「とりあえず設定はできたが、これで本当に運用に耐えるのか不安」「メルマガや大量の通知メールをMicrosoft 365から送ってよいのか判断がつかない」という担当者が、自社の構成を点検し、次の一手を決められる状態になることをゴールとします。

Microsoft 365のSMTPサーバーとは？設定値の基本を押さえる

Microsoft 365（旧：Office 365）は、Exchange Onlineというメール基盤を内包したクラウド型の統合サービスです。このExchange Onlineが提供する送信用サーバーが、いわゆる「Microsoft 365のSMTPサーバー」にあたります。

SMTP（Simple Mail Transfer Protocol）はメールを送信・転送するための通信プロトコルです。メールソフトや複合機、業務アプリケーションはメール本文を作ることはできても、それを自力でインターネットへ送り出すことはできません。そこで、SMTPサーバーに「このメールを送ってほしい」と依頼する。この依頼の宛先として指定するのが、Microsoft 365のSMTPサーバーというわけです。

Microsoft 365のSMTPサーバー設定値一覧

まず、実務で必要になる設定値を確定させておきます。Microsoftが公式ドキュメントで案内している、クライアントSMTP送信の設定値は以下の通りです。

受信側の設定値も併せて整理しておきます。

ここで注意したいのが、サーバーのIPアドレスを直接指定してはいけないという点です。Microsoft 365の送信サーバーのIPアドレスは予告なく変わります。必ずホスト名 smtp.office365.com を指定してください。

ポート465が使えない理由

古い複合機や業務システムでは、SMTPのポートとして465が既定値になっていることがあります。しかし、Microsoft 365のクライアントSMTP送信ではポート465は使えません。Microsoftは、ポート465で必要となるTLSのバージョンをサポートしていないと明示しています。

同様に、デバイス側がTLS 1.2以上に対応していない場合も、Microsoft 365のクライアントSMTP送信は利用できません。導入から10年近く経過した複合機やレガシーな業務システムでは、ここで詰まるケースが少なくありません。

ポート25も仕様上は利用可能ですが、多くのISPが送信側の25番ポートを遮断（OP25B）しているほか、社内ファイアウォールで塞がれている場合もあります。基本は587番ポート＋STARTTLSと理解しておけば問題ありません。

Outlook.comのSMTPサーバーとの違い

個人向けのOutlook.comと、法人向けのMicrosoft 365は名前が似ているため混同されがちですが、SMTPサーバーも運用も別物です。

業務システムからの送信元として使うのであれば、独自ドメインで送信ドメイン認証を設定できるMicrosoft 365（Exchange Online）が前提になります。Outlook.comのアドレスを業務システムの送信元に流用する運用は、なりすまし判定のリスクが高く避けるべきです。

Microsoft 365からメールを送る4つの方式と使い分け

ここが本記事で最も押さえてほしいポイントです。Microsoft 365からデバイスやアプリケーションのメールを送信する方法は、ひとつではありません。Microsoftは公式に4つの方式を用意しており、それぞれ「誰に送れるか」「何が必要か」が異なります。

多くのトラブルは、要件に合っていない方式を選んでしまったことが原因です。まず全体像を表で押さえます。

クライアントSMTP送信（SMTP AUTH）

もっとも一般的な方式です。Microsoft 365のメールボックスのIDとパスワードで認証し、smtp.office365.com に接続して送信します。社内・社外どちらにも送れ、クラウド上のどこからでも接続できる汎用性の高さが利点です。

一方で制約もあります。送信に使うメールボックスにはライセンスが必要であり、そのメールボックスに課される送信制限（後述）をそのまま受けます。さらに、認証に使うアカウントと異なる差出人アドレスで送る場合は「送信者（Send As）」の権限付与が必要です。

そして最大の論点が、この方式が基本認証の既定オフ対象であることです。

SMTPリレー（コネクタ経由）

Exchange管理センターで受信コネクタを作成し、自社のIPアドレスまたはTLS証明書でMicrosoft 365に認証させる方式です。送信先はMXエンドポイント（contoso-com.mail.protection.outlook.com の形式）、ポートは25を使います。

この方式の強みは、ライセンス付きメールボックスが不要で、承認済みドメイン内であればメールボックスを持たないアドレス（noreply@example.co.jp など）を差出人にできる点です。クライアントSMTP送信より送信上限も緩やかになります。

ただし要件は重くなります。他組織と共有していない静的なグローバルIPアドレス、またはドメインを含むTLS証明書が必須です。そしてAzureなどサードパーティのクラウドでホストされたサービスからのリレーはサポートされていません。オンプレミス設備を前提とした方式である点は押さえておく必要があります。

直接送信（Direct Send）

認証を一切行わず、デバイスから自社のMXエンドポイントへ直接メールを投げ込む方式です。Microsoft 365側の設定が不要なため、手っ取り早い方法として選ばれがちです。

しかし、宛先は自社Microsoft 365内の受信者に限定されます。GmailやYahoo!メールなど組織外のアドレス宛は拒否されます。社内向けの通知にしか使えない、と理解してください。

加えてMicrosoftは公式ドキュメントで、直接送信は多くの利用者にとって必要な方式ではなく、利用者保護のために既定で無効化する方向で検討していると説明しています（出典：Microsoft Learn）。将来的に閉じられる可能性が高い方式であり、新規の構成で積極的に選ぶ理由はありません。

High Volume Email（HVE）

2026年3月に一般提供（GA）が開始された、大量送信専用のサービスです。専用のHVEアカウントを使い、ポート587で送信します。受信者レート制限やメッセージレート制限がかからないため、人事システムの一斉通知や監視アラートなど、社内向けの大量配信に適しています。

ただし決定的な制約があります。HVEは内部受信者専用の機能であり、外部受信者へのメール送信機能は削除されました。つまり、顧客向けのメルマガや会員向けの通知には一切使えません。

課金も始まっています。Microsoftのアナウンスによれば、HVEの課金は2026年6月1日に開始されており、料金は100万受信者あたり42米ドルのトランザクション課金です。オプトインの機能であるため、利用する場合は管理者が課金設定を行う必要があります。

なお、Microsoft自身が公式ドキュメントで「内部および外部の受信者にメールを送信する場合はAzure Communication Services Emailを使用する」と案内しています。裏を返せば、外部宛の大量送信について、Microsoft 365は解決策を用意していないということです。この事実が、後述するメール配信サービスの必要性に直結します。

参考：Microsoft 365またはOffice 365を使用してメールを送信するように多機能デバイスまたはアプリケーションをセットアップする方法（Microsoft Learn）

Microsoft 365のSMTPサーバー設定手順

ここからは、もっとも利用機会の多いクライアントSMTP送信（SMTP AUTH）を有効化し、実際にメールが届く状態にするまでの手順を解説します。

前提として重要な事実があります。2020年1月以降に作成されたテナントでは、SMTP AUTHは既定で無効です。「設定値を入れたのに送れない」という相談の大半は、この有効化を飛ばしていることが原因です。

STEP 1：テナント全体のSMTP AUTH設定を確認する

Microsoft 365管理センターからExchange管理センター（EAC）へ移動し、組織全体の設定でSMTP AUTHが無効化されていないかを確認します。テナント単位で無効になっている場合、個別のメールボックスをいくら設定しても送信できません。

PowerShellで確認・変更することも可能です。運用としては、テナント全体では無効のまま、送信に使う特定のメールボックスだけを有効にするのがセキュリティ上の定石です。

STEP 2：メールボックス単位でSMTP AUTHを有効にする

Microsoft 365管理センターの［ユーザー］→［アクティブなユーザー］から対象ユーザーを選び、［メール］タブの［メールアプリの管理］で「認証済みSMTP」を有効にします（Exchange管理センターの［受信者］→［メールボックス］からも設定できます）。ここで有効化されるのは、そのメールボックス1つだけです。

複合機、基幹システム、Webサーバーなど、送信元が複数ある場合は用途ごとにメールボックスを分けておくと、後々のトラブル切り分けが格段に楽になります。1つのアカウントをすべての機器で使い回すと、送信制限に達したときにどの機器が原因か特定できなくなります。

STEP 3：送信側のデバイス・アプリケーションに設定値を入力する

複合機や業務システムの設定画面に、前述の設定値を入力します。

差出人アドレスは、原則として認証に使ったメールボックスのアドレスと一致させます。別のアドレスを差出人にしたい場合は、STEP 2で用意したメールボックスに対して「送信者（Send As）」権限を付与してください。権限がない状態で送信すると、5.7.60 Client does not have permissions to send as this sender というエラーで弾かれます。

STEP 4：SPF・DKIM・DMARCを設定する

送信できることと、届くことは別問題です。GmailやYahoo!メールの送信者ガイドラインでは、送信ドメイン認証の設定が事実上の必須要件になっています。

ここで頻出する落とし穴が、SPFレコードの10ルックアップ制限です。Microsoft 365に加え、MAツール、問い合わせフォーム、勤怠システムなど複数のサービスをincludeしていくと、DNS参照回数が10回を超えて permerror となり、SPF認証そのものが失敗します。includeの数が増えてきたら、必ず検証ツールでルックアップ回数を確認してください。

STEP 5：テスト送信で疎通と到達を確認する

設定が終わったら、必ず複数の宛先にテスト送信します。確認すべきは以下の3点です。

Gmailに届いたメールの「メッセージのソースを表示」からSPF・DKIM・DMARCの認証結果（PASS かどうか）を確認できます。ここまで確認して、初めて設定完了と言えます。

2026年12月、SMTPの基本認証が既定オフに

ここからが、2026年以降のメール運用でもっとも重要な論点です。

Microsoftは、Exchange Onlineのクライアント送信（SMTP AUTH）における基本認証の廃止を進めています。当初は2025年9月、その後2026年3月〜4月と予定されていましたが、2026年1月27日に公開された最新のロードマップで段階的な移行スケジュールに改められました。

現時点で決まっているスケジュール

注意すべきは、2026年12月末の「既定で無効化」は猶予であって免除ではないという点です。管理者が再度有効にすることは当面可能ですが、最終的な削除は2027年後半にアナウンスされる見込みで、そのときには再有効化という逃げ道はなくなります。

影響を受けやすいシステム

基本認証でsmtp.office365.comに接続している以下のような機器・システムは、すべて対象です。

厄介なのは、これらが「設定当時の担当者が不在になっている」「長期間、構成変更なく稼働し続けている」というケースが多いことです。まずは自社のどの機器がsmtp.office365.comを向いているか、棚卸しから始めてください。

基本認証が止まると出るエラー

基本認証が無効化された状態で接続すると、以下の応答が返ります。

550 5.7.30 Basic authentication is not supported for Client Submission

このエラーが出た時点で、送信は停止しています。エラー通知が管理者に届かない構成になっていると、顧客からの問い合わせで初めて気づくことになるため、あわせて監視の仕組みも確認しておきたいところです。

移行先の選択肢は3つ

Microsoftが案内している移行先を、実務判断の基準とともに整理します。

3つ目の選択肢は、システム改修が難しいレガシー環境ほど現実的です。接続先ホスト名を変えるだけで移行が完了するという手軽さは、期限が迫る中では大きな武器になります。

参考：Exchange Online to retire Basic Auth for Client Submission (SMTP AUTH)（Microsoft Tech Community）

Microsoft 365のSMTPサーバーにかかる送信制限

基本認証の問題とは別に、恒常的にメール運用を縛るのが送信制限です。ここを把握しないまま一斉配信を試みると、配信途中で止まる、アカウントがブロックされるといった事故につながります。

ユーザー単位の制限

Microsoftが公開している、Exchange Onlineのユーザーごとの制限は以下の通りです。これらはサービスレベルで適用されるハード制限であり、引き上げることはできません。

具体的な数字に落とし込むと、深刻さが見えてきます。たとえば8,000名の会員リストに、宛名差し込みのため1通1宛先で配信する場合、1分あたり30通の制限により、単純計算で約267分（4時間半弱）かかります。配信開始から受信までのタイムラグが4時間以上あるメルマガは、キャンペーン告知としてほぼ機能しません。

さらに受信者レート制限は24時間のスライディングウィンドウで判定されるため、1日目に8,000宛先を送ってしまうと、2日目には残り2,000宛先しか送れません。

テナント単位の外部受信者レート制限（TERRL）

外部宛の送信については、テナント単位でも上限が設けられています。「テナント外部受信者レート制限（TERRL）」と呼ばれるもので、テナントが1日（24時間のスライディングウィンドウ）に送信できる外部受信者の最大数を定めた制限です。上限値はライセンス数に応じて自動的にスケールし、試用版テナントの既定上限は1日あたり外部受信者5,000宛先です。

なお、メールボックス単位で「外部宛2,000宛先／24時間」という制限（External Recipient Rate Limit）の導入が過去に予告されていましたが、2026年1月にMicrosoftが実施の中止を発表しました。この制限は適用されません。過去の解説記事にはこの2,000宛先制限を前提としたものが残っているため、情報の鮮度に注意してください。

適用されるのは、あくまで前述のメールボックス単位の制限（10,000宛先／日、30通／分）と、このテナント単位のTERRLです。

制限に達したときに起きること

制限を超過すると、送信は調整（スロットリング）され、場合によってはアカウントが一時的に送信ブロックされます。復旧には24時間の待機が必要になるケースもあり、「今日中に送らなければならない案内が送れない」という事態に直結します。

参考：Exchange Onlineでの送信制限とブロックされたユーザーのトラブルシューティング（Microsoft Learn）

Microsoft 365のSMTPサーバー設定でよくあるエラーと対処法

設定作業でつまずきやすいエラーを、原因の切り分け順に整理します。

535 5.7.139 Authentication unsuccessful

認証に失敗しているエラーです。原因は大きく3つに分かれます。

第一に、SMTP AUTHがテナント単位またはメールボックス単位で無効になっているケース。これが最多です。テナント全体で有効でも、個別メールボックスで無効なら送信できません。両方を確認してください。

第二に、多要素認証（MFA）が有効なアカウントを使っているケース。基本認証とMFAは併用できないため、アプリパスワードを発行するか、OAuth対応クライアントへ切り替える必要があります。

第三に、単純なパスワード誤り・有効期限切れです。パスワードポリシーで定期変更を強制している組織では、機器に設定したパスワードだけ更新し忘れて、ある日突然送れなくなるという事故が定番です。送信用アカウントはパスワード無期限に設定するか、変更時の更新対象リストに機器を明記しておきましょう。

550 5.7.30 Basic authentication is not supported for Client Submission

前章で解説した、基本認証が無効化されているケースです。2026年12月末以降はこのエラーが一気に増えることが予想されます。対処は再有効化ではなく、OAuthまたは外部リレーへの移行で考えてください。

接続できない・タイムアウトする

ポートと暗号化設定を最初に疑います。465番を使っていないか、STARTTLSが有効になっているか、TLS 1.2以上に対応しているかを確認します。

設定が正しいのに接続できない場合は、ネットワーク側の問題です。社内ファイアウォールやプロキシで587番ポートの外向き通信が塞がれているケース、あるいはISPのOP25Bで25番ポートが遮断されているケースが考えられます。切り分けには、送信元の端末のPowerShellで Test-NetConnection smtp.office365.com -Port 587 を実行し、接続可否を確認するのが確実です（Windowsではtelnetクライアントが既定で無効のため）。

迷惑メールフォルダに振り分けられる

送信自体は成功しているが受信トレイに入らない場合、送信ドメイン認証を疑います。SPFにMicrosoft 365のincludeが含まれているか、DKIM署名が有効になっているか、DMARCポリシーが公開されているかを順に確認してください。

見落としがちなのが、SPFのルックアップ10回超過と、DMARCのアライメント不整合です。差出人アドレスのドメインと、実際の認証ドメインが一致していないと、SPFとDKIMがPASSしていてもDMARCはFAILになります。

特定のキャリア・プロバイダにだけ届かない

Gmailには届くのにドコモ・au・ソフトバンクのキャリアメールだけ届かない、という相談は非常に多く寄せられます。国内キャリアは独自の受信制限やレピュテーション判定を持つため、汎用のメール基盤からの送信では、キャリアごとの最適化が行き届かない場合があります。

この領域はテナント側の設定ではコントロールできません。国内キャリアへの配信ロジックを持つ専用サービスを経由するのが、現実的な解決策になります。

Microsoft 365のSMTPサーバーが適していないケース

最後に、判断基準を明確にしておきます。以下に当てはまる場合、Microsoft 365のSMTPサーバーだけで運用を続けるのは合理的ではありません。

メルマガ・会員向け一斉配信を行う場合

前述の通り、メールボックス単位で1分あたり30通、1日あたり10,000宛先が上限です。宛名差し込みを行う一斉配信では1通1宛先となるため、数千件規模になると配信完了まで数時間を要し、告知のタイミングに間に合いません。加えて、Exchange Onlineはもともとバルクメールを想定した設計ではなく、無理に大量送信を行うとテナント全体のレピュテーション低下を招くリスクがあります。

到達率や配信結果を可視化したい場合

Microsoft 365のSMTPサーバーには、配信結果を分析する機能がほとんどありません。どのアドレスでエラーが発生したのか、バウンスの理由は何かといった情報を体系的に取得できないため、リスト品質の改善サイクルを回せません。

バウンス（エラーメール）管理を自動化したい場合

退会・廃止されたアドレスへの送信を放置すると、送信者としての評価が下がり、正常なアドレスへの到達率まで巻き添えで低下します。Microsoft 365ではバウンスの自動処理・自動除外の仕組みがなく、担当者が手作業でリストを整備し続けることになります。

システム改修せずに基本認証の廃止に対応したい場合

OAuth対応にはファームウェア更新やプログラム改修が伴います。対応ファームウェアが提供されていない機器、ベンダーサポートが終了したシステムを抱えている場合、送信先ホストを差し替えるだけで済む外部リレーサービスが最短ルートになります。

Microsoft 365のSMTP運用を安定させるならメール配信システムを活用する

Microsoft 365は社内の業務コミュニケーション基盤としては優れていますが、外部宛の大量送信や、システムからの確実な自動送信は設計思想の範囲外です。Microsoft自身が外部宛の大量送信について別サービスの利用を案内している事実が、それを端的に示しています。ここを補うのがメール配信システムです。

メール配信システムを使うメリット

Microsoft 365のSMTPサーバーで発生していた制約は、メール配信システムを経由することでそのまま解消できます。送信経路を分離することで、業務メールと自動送信メールが互いに影響し合う事態も防げます。

とくに2026年12月の基本認証既定オフを控えた今、「接続先を変えるだけで移行できる」という点は無視できない価値を持ちます。期限までに全機器のOAuth対応を完了させるより、はるかに現実的な選択肢です。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、既存システムとSMTPリレーやAPIで連携することで、通知メールや一斉配信を簡単に実現できる国産のメール配信サービスです。複合機や基幹システムの送信先をsmtp.office365.comからblastengineに変更するだけで移行できるため、Microsoft 365の送信制限や基本認証の廃止に対する回避策として機能します。

配信速度は1,500万通／時。初期費用は無料で、月額3,000円から利用できます。日本語でのテクニカルサポート（電話・メール）にも対応しているため、移行作業に不安がある場合も相談しながら進められます。メールアドレスの入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

ブラストエンジン公式サイト：https://blastengine.jp/

おすすめのメール配信システム「ブラストメール」

システム連携ではなく、マーケティング担当者が管理画面からメルマガや会員向けのお知らせを配信したい場合は、ブラストメール（blastmail）が適しています。15年連続で導入社数シェアNo.1を獲得しており、導入実績は27,000社以上。専門知識がなくても直感的に操作できるシンプルな管理画面が特徴です。

月額4,000円からのプランが用意されており、登録アドレス数に応じたプラン制のため、配信通数に応じた追加課金は発生しません。Microsoft 365では現実的に不可能だった数千件規模の一斉配信を、管理画面から数クリックで実行できます。

公式サイト：シェア1位のメール配信システム「ブラストメール」

FAQ

まとめ

Microsoft 365のSMTPサーバー設定は、smtp.office365.com／ポート587／STARTTLSという3点を押さえ、SMTP AUTHをテナントとメールボックスの両方で有効化すれば動き出します。ただし、動かすことと、運用に耐えることは別の話です。

本記事の要点を整理します。

今すぐ着手すべきアクションは3つです。第一に、smtp.office365.comを送信先に指定している機器・システムを棚卸しすること。複合機、基幹システム、WordPress、監視ツールまで漏れなくリスト化します。第二に、それぞれが社内宛のみか、社外宛を含むかを分類すること。第三に、社外宛を含むものについて、OAuth対応改修と外部リレーサービスへの切り替え、どちらが現実的かを比較検討することです。

期限まで残された時間は多くありません。まずは構成の棚卸しから着手し、移行方針の決定までを計画的に進めてください。