Outlookでメールを送信できない場合、原因はアプリの設定だけとは限りません。Microsoft 365やExchange Online、契約中のメール事業者の障害、メールゲートウェイの滞留、ネットワークやセキュリティ製品の制御、認証方式、PCやOutlookアプリの状態、宛先側の受信設定を順に切り分ける必要があります。
重要なのは、「送信できない」ことと、「送信元では受け付け済みだが宛先で配送が遅れている」ことを分けて考えることです。たとえばMicrosoft 365側の外部ドメインからの受信遅延では、送信元のゲートウェイがメールを受け付けていても、Microsoft 365宛てだけ到着が遅れることがあります。送信済みフォルダへの移動だけで配達完了と判断せず、送信経路のログやメッセージ追跡を確認しましょう。
この記事では、Outlookでメールを送信できない主な原因を、サーバー、ネットワーク、Outlookソフトウェア、PC環境、宛先アドレスの5つに整理し、対処法と予防策を解説します。
Outlookの送信トラブルは、社内連絡、顧客対応、契約や請求に関する連絡に直結します。何度も送信ボタンを押す前に、どの段階で処理が止まっているかを整理しましょう。
「送信できない」と感じる現象には、送信トレイに残っている、メールサーバーへ渡った後に配送が遅延している、認証エラーでサーバーへ接続できない、受信側の迷惑メール対策で隔離・拒否されている、といった違いがあります。送信トレイに残る場合は、クライアントからサーバーへ渡せていない可能性があります。一方、送信済みに移動したのに届かない場合は、サーバー間の遅延、受信拒否、隔離を疑います。
NDR(配信不能レポート)が返る場合は、SMTPコードと診断情報を確認します。原則として4xxは再試行の対象となる一時エラー、5xxは設定修正などが必要になりやすい恒久エラーです。たとえば451 4.7.500 Server busyは、宛先側が一時的に処理できず送信元キューで再試行されることを示します。この場合、利用者が手動再送を繰り返すと重複メールやキューの増加につながるため、元メールがゲートウェイやサーバーのキューに残っていないか、再試行回数と最終SMTP応答を確認してください。
Outlookからは送れるのにCRM、問い合わせ管理SaaS、複合機からだけ送れない場合は、Outlookではなく連携システム側の送信経路を確認します。また、CRMなど特定のSaaSから届いたHTMLメールだけ本文が崩れる場合は、Outlookの表示設定だけでなく、送信元製品が生成するMIME構造やメールヘッダーも原因候補です。
Outlookでメールを送信できない状況には、次のようなパターンがあります。
失敗する時刻、宛先、添付の有無、利用端末、利用ネットワーク、送信経路を記録すると原因を絞り込みやすくなります。特定ドメイン宛てだけ失敗する場合は、宛先の入力ミスだけでなく、Microsoft 365など宛先サービス側の受信障害、送信元IPの評価、外部ブロックリストも確認しましょう。
Outlookの送信トラブルで確認すべき要素は、主に次の5つです。
企業では、Outlookだけを個別に見るのではなく、Exchange Online、メールゲートウェイ、DLP、誤送信対策、ファイル共有、認証ログを横断して確認できる運用が有効です。送信時刻、Message-ID、送信者、宛先、DLP判定、ゲートウェイの配送結果を結び付けられるようにしておくと、問い合わせ先のたらい回しを防げます。
Outlookで送信できない原因は、サーバー関連、ネットワーク関連、Outlookソフトウェア、PC環境、送信先アドレスに分類できます。
サーバー関連では、Exchange Onlineやメールプロバイダの障害、メールボックス単位の問題、オンプレミスExchange Serverの不具合、認証・セキュリティポリシーの変更、組織全体の外部宛て送信上限が原因になります。ネットワーク関連では、回線不良、VPN・プロキシ設定、ファイアウォール、証明書不備、メールセキュリティゲートウェイによる通信制限が代表例です。
Outlookソフトウェアの問題には、オフライン作業モード、古いバージョン、アドイン競合、添付ファイルやメール全体のサイズ上限、アカウントやプロファイルの不整合があります。PC環境では、メモリやディスク容量の不足、ウイルス対策ソフトによる誤ブロック、WindowsやOfficeの更新不備が影響することがあります。宛先側では、アドレスの誤り、古い候補の選択、迷惑メール判定、隔離、ドメインブロックなどが不達の要因です。
サーバー関連の問題とは、メールの送受信を処理するサービス側で発生する障害や、サーバー接続に必要な認証・暗号化設定の問題です。Microsoft 365ではExchange Online、自社運用ではオンプレミスExchange Server、プロバイダメールでは契約先のSMTPサーバーが関係します。
サービス障害が原因の場合、Outlookの再起動やPCの設定変更では解決しません。複数ユーザー、Outlook on the Web、管理センターで同時に異常が出る場合は、プロファイル再作成や設定変更を急がず、まずサービス正常性を確認してください。障害復旧後も滞留キューの解消には時間差が生じるため、復旧直後に未達と判断せず、メッセージ追跡とキューの最終状態を確認します。
また、Exchange Onlineではユーザー単位の制限に加え、テナント全体の外部宛て受信者数を対象にするTenant External Recipient Rate Limit(TERRL)が適用されます。上限を超えると、直近24時間の外部宛て受信者数がしきい値を下回るまで、新たな外部宛てメールがブロックされることがあります。CRMの一斉通知、請求書、予約確認、ワークフロー通知なども含め、テナント全体の送信量として管理する必要があります。
メール送信には、Outlookからメールサーバーへの安定した通信が必要です。回線の不安定さ、VPN切断、プロキシやファイアウォールの設定、DLP検査やウイルススキャンの滞留により、送信に失敗することがあります。
「証明書が無効」「証明書名が一致しない」といった警告が表示される場合は、単純な回線障害ではなく、メールサーバーやWebメールに設置されたSSL/TLS証明書の更新不備も疑います。複数端末で同時に発生している場合、Outlookプロファイルを作り直す前に事業者の障害情報を確認しましょう。
Outlookの設定や動作状態が原因で送信できないこともあります。代表例はオフライン状態です。ただし、クラシックOutlookと新しいOutlook for Windowsでは確認場所と動作が異なります。クラシックOutlookでは「送受信」タブの「オフライン作業」が有効だと送信トレイにメールが残ります。新しいOutlookでは、オフラインアクセスの設定とネットワーク再接続後の同期状態を確認してください。オフライン中に作成して送信したメールが送信トレイに入ること自体は、再接続後に同期するための通常動作です。
そのほか、添付ファイルのサイズ超過、アドイン競合、複数アカウント利用時の送信元選択ミス、破損したプロファイルも原因になります。CRMやSaaSからのメールだけ表示が崩れる場合は、Outlookに問題があると決め付けず、送信元SaaSの更新履歴、ヘッダー、MIME形式を確認します。
PC全体の状態が悪いと、Outlookの起動や送信処理にも影響します。メモリ不足、ディスク容量不足、OS更新の失敗、ウイルス感染、セキュリティソフトによる通信遮断などが代表例です。
Outlookだけでなく他のアプリも重い、ブラウザやTeamsも接続しにくい、ネットワークが頻繁に切れるといった症状がある場合は、Outlook以外の要因も疑いましょう。
宛先メールアドレスの入力ミスや古いアドレスの選択も、送信エラーや不達の原因になります。重要な送信では候補を選ぶだけでなく、アドレス文字列とドメインを確認してください。
社外の特定ドメインにだけ送信できない場合は、宛先の入力ミスだけでなく、送信元IPが受信側またはブロックリストで拒否されていないかを確認します。HTMLメールの表示崩れや差出人名の文字化けは、環境依存文字、長い表示名、HTML本文と添付ファイルの組み合わせを含めて再現条件を記録し、必要に応じて送信元ベンダーへ問い合わせましょう。
送信できないときは、最初にサービス全体やメールボックス単位の障害を確認し、その後にネットワーク、Outlook設定、PC環境、宛先の順で切り分けると効率的です。
サーバー関連では、メールサービスの稼働状況、メールボックスの容量、アカウント設定、送信経路、組織全体の送信制限を確認します。Microsoft 365を利用している組織の管理者は、管理センターのサービス正常性とメッセージセンターを確認してください。
突然メールを送れなくなった場合は、影響範囲を確認します。複数ユーザーでメール送受信、認証、検索、管理センターの操作に同時に異常がある場合は、ローカル変更を止め、Microsoft 365のサービス正常性を確認します。障害が見つかった場合はIncident IDを社内チケットに記録し、復旧後も配送キューが解消するまでの時間を利用者へ案内しましょう。
管理者は、影響ユーザーの範囲、NDRのSMTPコードと診断情報、Exchange管理センターのメッセージ追跡、メールゲートウェイのキュー、再試行回数、最終SMTP応答を順に確認します。特にMicrosoft 365宛てだけ遅延・失敗する場合は、送信元の設定変更より先にMicrosoft側の外部メール受信障害を疑います。
特定ドメイン宛てだけ失敗する場合は、Gmail、Microsoft 365、iCloudなど宛先サービス別の成功・失敗を記録します。NDRから550 5.7.xなどのコード、拒否したサーバー、送信元IPを抽出し、SPF・DKIM・DMARCに加えて共有メールゲートウェイのIPレピュテーションを確認してください。同じメールをOutlook on the Webから送っても失敗するなら、PCより配送経路を優先して調べます。
社外宛てメールだけ送れない場合は、TERRLも確認します。Exchange管理センターの「Tenant Outbound External Recipients」レポート、またはExchange Online PowerShellのGet-LimitsEnforcementStatusで、Threshold、ObservedValue、Verdictを確認してください。1通を1,000人へ送る場合も、同じ宛先へ1,000通送る場合も、外部受信者数として1,000件分に数えられます。大量配信はExchange Onlineから分離し、トランザクションメールやメール配信専用サービスを利用することが適切です。
CRMや業務SaaSから送ったメールが届かない場合は、SaaS側の配信ログ、バウンス履歴、通知センターを確認します。「送信APIが成功した」ことと「相手の受信トレイへ配達された」ことは別です。請求、承認、契約などの重要な通知は、メールだけに依存せず、サービス内通知や一覧画面でも確認できるようにしましょう。
メールボックス容量については、対象となるMicrosoft 365 Business Basic/Standard/Premiumのユーザーで最大100GBのメールボックスが提供される変更があります。ただし、すべてのライセンスが100GBになるわけではなく、Exchange Online Plan 1などは対象外です。管理者が設定したカスタムクォータも自動で上書きされないため、ライセンス、サービスプラン、個別クォータを分けて確認してください。
障害が確認できない場合は、利用している送信経路を確認します。OutlookやOutlook on the Webからの通常送信、SMTP AUTH、Exchange Online SMTP relay、Direct Send、メールセキュリティゲートウェイ経由、EWSまたはMicrosoft Graphを利用する連携システムでは、確認すべき設定が異なります。
SMTPを使用する場合は、SMTPサーバー名、ポート番号、暗号化方式、認証方式、ユーザー名、パスワードを確認してください。複合機、基幹システム、レガシーアプリなどで古い認証方式を使っている場合は、OAuth 2.0や要件に合った代替送信方式への移行を進めましょう。
CRM、問い合わせ管理、ワークフロー、メールアーカイブ、予約システムなどがEWS経由でメールや予定表を扱っている場合、Outlook自体が正常でも連携システムからの送信・同期だけが停止する可能性があります。2026年10月1日以降、EWSEnabled=TrueでEWSを継続利用するには、EWSAllowedAppIDsによるApp ID許可リストが必要です。
管理者が事前に許可リストを設定していない場合、Microsoftは直近60日間のEWS利用実績を基にリストを自動生成する場合があります。しかし、60日より長い周期で動くバックアップ、アーカイブ、監査、採用、請求系アプリは漏れる可能性があり、既に不要なアプリが含まれる可能性もあります。ベンダーからEntraアプリケーションIDを取得し、管理者自身で必要なApp IDを設定してください。事前に管理者が設定したリストはMicrosoftによって上書きされません。
本番投入前には、許可アプリが成功することだけでなく、未許可アプリが拒否されることも確認します。障害時はMicrosoft生成リストへ全面的に戻すのではなく、必要なApp IDだけを追加しましょう。なお、組織間の空き時間情報やMailTipsで使われるOrganization Relationshipの通信は、EWSAllowedAppIDsの許可リストとは別扱いです。組織間共有は、EWS許可リストとは分けて移行・検証してください。
オンプレミスExchange Serverを運用している場合は、2026年9月8日公開のセキュリティ更新を基準に適用状況を確認します。対象はExchange Server Subscription Edition、およびPeriod 2 ESU契約下のExchange Server 2016 CU23/2019 CU14・CU15です。Exchange Server 2016/2019は通常サポート外のため、Period 2 ESU未契約の組織はExchange Server SEへの移行を検討してください。OWA Lightは既に廃止されているため、代替手段としては標準のOutlook on the Webを案内します。
ネットワーク関連では、インターネット接続、VPN、プロキシ、ファイアウォール、メールセキュリティ製品、暗号化通信の要件を確認します。
まず、ブラウザでWebサイトを開けるか、Teamsなど他のクラウドサービスに接続できるかを確認します。Webサイトは表示できるのにOutlookだけ送信できない場合は、メールサービスへの接続、Outlook設定、またはメール通信に対するネットワーク制御を疑います。
一時的な通信不良であれば、Wi-Fiを接続し直す、VPNを再接続する、時間を置いて再送信する、別のネットワークへ切り替えることで改善する場合があります。ただし、4xxエラーでサーバー側が再試行しているメールは、手動で繰り返し再送する前にキューの状態を確認してください。
SSL接続時に証明書エラーや警告が出る場合は、ネットワーク障害と決め付けないことが重要です。サーバー名と証明書のSAN、有効期限、証明書チェーンを確認し、契約中のメール事業者の障害情報も確認します。切り分け目的であっても、警告を無視した接続や非SSL接続を恒久的な回避策にしてはいけません。
会社のネットワークでは、プロキシ、VPN、ファイアウォール、メールセキュリティゲートウェイが送信を制限していないか確認します。DLP検査、添付ファイルスキャン、ウイルス対策エンジン、脱PPAP用のリンク変換や添付分離処理が原因でメール処理が滞留することもあります。
切り分けのためにセキュリティ機能を一時停止する場合は、必ず管理者の管理下で実施し、確認後は設定を戻してください。恒久的に保護機能を無効化することは避け、ログを確認したうえで誤検知なら製品ベンダーや管理者とルールを調整します。
POP/IMAPを使用する古いクライアントや機器は、TLS 1.2以降への対応状況を確認しましょう。SMTP送信、通常のOutlook接続、POP/IMAP接続では必要な設定が異なるため、利用プロトコルを区別して調査します。
Outlookアプリ側は、オフライン状態、添付ファイル、アカウント設定、アドイン、バージョンの順に確認します。
クラシックOutlookでは、送受信タブの「オフライン作業」が有効になっていないか確認します。有効な場合、インターネットに接続していてもメールは送信トレイに残ります。
新しいOutlook for Windowsでは、「送受信」タブだけを案内せず、「設定」からオフラインアクセスの設定と、ネットワーク再接続後の同期状態を確認してください。オフライン中に送信したメールが送信トレイにある場合は、必ずしも障害ではありません。再接続後に同期・送信されるかを確認します。
次に添付ファイルとメール全体のサイズを確認します。上限はExchange Online、外部プロバイダ、組織のポリシー、メールセキュリティゲートウェイによって異なります。エラーやNDRに表示される上限値を確認し、必要に応じてOneDriveやSharePointの共有リンクへ切り替えてください。
Outlook on the Webで送信できるか試すことも有効です。ブラウザ版では送れる場合、サービス障害よりもPC版Outlookのプロファイル、アドイン、ローカル設定に原因がある可能性が高まります。複数アカウントを利用している場合は、送信元アカウントも確認してください。
送信ボタンを押した後に処理中のまま進まない、特定の添付ファイルだけ拒否される場合は、送信前検査を行うOutlookアドインを確認します。アドインが利用するMicrosoft Graph APIや外部サービスの遅延も考慮し、送信をスキップする場合の承認条件と監査ログを企業内で定めましょう。
OutlookやOfficeを古い状態で使い続けると、既知の不具合やアドイン競合の影響を受けやすくなります。Windows UpdateとOffice更新プログラムを適用し、最新状態を維持しましょう。
更新前後には、「新しいOutlook」か「クラシックOutlook」か、Windows版かMac版か、Outlookのバージョン、ビルド番号、更新チャネルを記録してください。同じOutlookでも更新チャネルによって修正の配信時期が異なるため、「最新版」と表示されるだけでは十分な切り分けにならない場合があります。
CRMや問い合わせ管理SaaSからのメールだけ本文が崩れる、差出人の表示名が欠落・文字化けする場合は、Outlookの更新だけでなく送信元SaaSの障害情報や更新履歴も確認します。Outlook、Outlook on the Web、Gmailなど複数のクライアントで表示を比較し、可能であればスクリーンショットだけでなく元メールのヘッダーや.emlファイルを保存してベンダーへ連絡してください。
OutlookだけでなくPC全体が不安定な場合は、PC環境を確認します。アプリ再起動で改善する場合もありますが、リソース不足やセキュリティ設定が原因のこともあります。
メモリ不足やディスク容量不足があると、Outlookの起動、検索、送受信が遅くなります。タスクマネージャーでCPUやメモリ使用率を確認し、不要なアプリを終了してください。
ディスク容量が少ない場合は、不要なファイルを削除し、ストレージセンサーやディスククリーンアップを活用します。Outlookデータファイルが肥大化している場合は、古いメールのアーカイブも検討しましょう。ただし、PCの空き容量を確保しても改善しない場合は、Exchange Onlineメールボックスのクォータ超過も別途確認が必要です。
ウイルス対策ソフト、ファイアウォール、メールセキュリティ製品がOutlookの通信を誤ってブロックすることがあります。OutlookやMicrosoft 365に必要な通信が許可されているかを確認してください。
ただし、セキュリティソフトを無効化したまま使い続けるのは危険です。切り分け後は必ず保護状態を戻し、原因が判明した場合は許可ルールや検査設定を管理者と見直しましょう。企業PCでは、自己判断で設定を変更せず、IT部門へ相談することをおすすめします。
Outlookやネットワークに問題がなくても、宛先や相手側の受信環境が原因でメールが届かないことがあります。
メールアドレスの入力ミスは、送信エラーや不達通知の原因になります。全角英数字、余分なスペース、ドットやハイフンの見落としに注意してください。
オートコンプリート候補から選ぶ場合も、古いアドレスが含まれていないか確認しましょう。候補の「X」を押しただけで削除済みと判断せず、退職者、旧ドメイン、統合前のアドレスはアドレス帳側でも整理します。重要なメールでは宛先、CC、BCC、添付ファイルを送信前に確認してください。
送信側のメールアドレス、ドメイン、または送信元IPが相手側でブロックされている場合、メールは届きません。エラーが返らず、迷惑メールフォルダや隔離領域へ入ることもあります。
件名、本文、URL、添付ファイルの種類によっては、フィッシング対策やリンクスキャンにより迷惑メール判定される場合があります。重要なメールが届かないときは、相手に迷惑メールフォルダと隔離メールを確認してもらいましょう。特定サービス宛てにだけ失敗する場合は、利用中のメール事業者へNDR全文、発生時刻、拒否したサーバー、送信元IPを渡し、ブロック状況を確認してもらいます。
取引先との重要連絡では、送信後にTeamsや電話で一報を入れる、件名に会社名や案件名を明記する、過度に広告的な表現を避けるといった工夫も有効です。
送信トラブルを完全に防ぐことは難しいものの、日頃の更新、監視、運用ルールにより影響を小さくできます。企業では、メール障害を前提とした代替連絡手段と、認証・連携仕様の変更への計画的な対応が重要です。
Microsoft 365を利用している組織では、管理センターのサービス正常性とメッセージセンターを定期的に確認しましょう。障害時に誰が情報を確認し、誰が社内へ周知し、どの連絡手段へ切り替えるかを決めておくと混乱を減らせます。プロバイダメールを利用している場合は、契約先の障害・メンテナンスページも手順書に登録しておくと有効です。
メールボックス容量は、ライセンス上の上限だけでなく、カスタムクォータや追加サービスプランを含めて確認します。SMTPを使う複合機、業務システム、外部ベンダー管理アプリは棚卸しし、認証方式と送信経路を把握したうえで移行を進めてください。
EWSを使う連携システムについては、低頻度でしか動かないバックアップ、アーカイブ、監査ツールも含めて棚卸しします。アプリ名だけではなく、実際のApp ID、対象メールボックス、Microsoft Graph対応状況を記録し、EWSAllowedAppIDsの設定前に許可・拒否の両方を検証しましょう。
外部宛ての送信量は、ユーザーごとではなくテナント全体で監視します。TERRLの対象になり得るCRM通知、請求、予約、マーケティング配信を把握し、大量配信は用途に合う専用サービスへ分離してください。
オンプレミスExchange Serverを運用している場合は、累積更新プログラムと2026年9月のセキュリティ更新を含む適用状況を確認し、更新後にはサービス起動状態、メールフロー、標準Outlook on the Webの利用可否を確認します。
社内ネットワーク、VPN、プロキシ、ファイアウォール、メールセキュリティゲートウェイの設定を定期的に確認し、Microsoft 365やOutlookに必要な通信が許可されているかを確認します。DLP、リンク変換、添付分離、ウイルススキャンを含め、送信メールが通過する処理とログの保管場所を明確にしましょう。
メールサーバーやWebメールのSSL/TLS証明書については、有効期限、サーバー名との一致、SAN、証明書チェーンを更新時に確認します。複数端末の同時エラーを個別端末の不具合として扱わない運用が重要です。
また、送信先サービス別に成功・失敗を記録し、Microsoft 365宛てだけ失敗した場合にも抽出できる配信レポートを用意します。大規模障害やネットワーク不通に備え、Teams、電話、チャット、緊急連絡網、SharePointなどを使った情報共有手順を準備しておきましょう。
Outlook、Office、Windows、モバイルアプリは定期的に更新し、既知の不具合とセキュリティ問題に対応しましょう。企業では、更新リングを「検証」「先行」「全社」などに分け、全社展開前に送信、添付、DLP、署名、アドイン、メールセキュリティ製品との連携をテストする運用が有効です。
新しいOutlookへの展開前には、オフライン時の送信トレイ同期、社外宛て、代理送信、共有メールボックス、添付ありのメールをテストします。問い合わせ時には、Outlookの種類、OS、バージョン、ビルド番号、更新チャネル、問題発生時刻、Outlook on the Webで再現するか、アドインの有無を記録してください。
定期的に不要ファイルを削除してディスク容量を確保し、ウイルススキャンを実行しましょう。メールボックス容量が上限に近い場合は、古いメールのアーカイブ、不要な添付ファイルの削除、クラウドストレージの活用で容量を管理します。
セキュリティソフトやファイアウォールの更新・設定変更後に送信できなくなった場合は、変更履歴とログを確認すると原因を特定しやすくなります。
送信先アドレスは確認済みの情報を連絡先へ登録し、退職、部署変更、ドメイン変更などで不要になったアドレスは更新または削除しましょう。
オートコンプリート候補を過信せず、社外宛てや機密情報を含むメールでは送信前の宛先確認を徹底してください。重要メールについては、相手側の迷惑メール・隔離機能による不達も想定し、必要に応じて別手段で到達確認を行いましょう。
Outlookでメールを送信できないときは、次の順番で確認すると原因を切り分けやすくなります。
4xxならキューと再試行状態、5xxなら恒久的な拒否理由を確認するサービス全体の障害が疑われる場合は、復旧を待つだけでなく、Teams、電話、チャット、サービス内通知などで業務連絡を継続してください。
Outlookでメールを送信できない原因は、Outlookアプリだけではありません。サービス障害、メールボックス単位の問題、配送遅延、テナント全体の送信上限、送信元IPの評価、認証・連携仕様の変更、ネットワーク不調、証明書不備、セキュリティ製品、PC環境、宛先ミス、受信側のフィルタリングを順番に確認することが大切です。
特に、EWS廃止に伴うEWSAllowedAppIDsの設定、TERRL、メールゲートウェイのキュー、オンプレミスExchange Serverの更新は、Outlookの再インストールやプロファイル再作成では解決しません。日頃から送信経路と連携アプリを把握し、ログを横断検索できる状態を整え、代替連絡手段と調査に必要な記録を準備しておけば、送信トラブルが起きても落ち着いて対応できます。
セールスや採用などのミーティングに関する業務を効率化し生産性を高める日程調整ツール。どの日程調整ツールが良いか選択にお困りの方は、まず無料で使い始めることができサービス連携や、必要に応じたデザインや通知のカスタマイズなどの機能が十分に備わっている日程調整ツールの導入がおすすめです。


