[{"data":1,"prerenderedAt":631},["ShallowReactive",2],{"sc:header-data-ja":3,"sc:footer-data-ja":37,"blog-posts-ja":71},{"lang":4,"home":5,"navigation":14},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/sendman/logo-sendman-white.svg","/products/sendman/logo-sendman.svg",{"ja":10},{"title":11,"url":12,"alt":13},"ホーム","/ja","Sendman",[15,19,25,31],{"name":16,"languages":17},"nav-home",{"ja":18},{"title":11,"url":12},{"name":20,"languages":21},"partner",{"ja":22},{"title":23,"url":24},"パートナー","/ja/partner",{"name":26,"languages":27},"about",{"ja":28},{"title":29,"url":30},"会社概要","/ja/about-us",{"name":32,"languages":33},"blog",{"ja":34},{"title":35,"url":36},"ブログ","/ja/blog",{"data":38},{"mail":39,"logos":40,"socials":44,"links":53,"linksJa":64},"sales@sendman.com",[41],{"img":7,"alt":42,"url":43},"Sendman Logo","/",[45,49],{"icon":46,"url":47,"title":48},"fa-x-twitter","https://x.com/thesendman","X",{"icon":50,"url":51,"title":52},"fa-linkedin","https://www.linkedin.com/company/glueckkanja","LinkedIn",[54,58,61],{"title":55,"url":56,"target":57},"Privacy","https://www.glueckkanja.com/en/privacy","_blank",{"title":59,"url":60,"target":57},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":62,"url":63,"target":57},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[65,67,69],{"title":66,"url":56,"target":57},"プライバシー",{"title":68,"url":60,"target":57},"法的情報",{"title":70,"url":63,"target":57},"お問い合わせと拠点",[72,283,452],{"id":73,"title":74,"author":75,"body":77,"cta":266,"date":267,"description":268,"eventid":266,"extension":269,"hideInRecent":270,"layout":266,"meta":271,"moment":266,"navigation":273,"outro":274,"path":277,"seo":278,"stem":281,"tags":266,"webcast":270,"__hash__":282},"content_ja/blog/exchange-online-blocks-outdated-exchange-servers.md","最後の Exchange Server に期限が付きました",[76],"Sendman Team",{"type":78,"value":79,"toc":258},"minimal",[80,84,87,91,95,98,101,104,123,140,143,146,149,152,156,159,162,165,189,192,195,254],[81,82,83],"p",{},"Exchange Online がメールを受け付ける最低バージョンを引き上げるとき、Microsoft は通常それを誰にも知らせません。2023 年以降、その基準はセキュリティ更新プログラムが出るたびに静かに上がってきました。9 月 2 日、Exchange チームは例外的にこれをブログ記事で告知しました。興味深いのは、そうした理由のほうです。",[81,85,86],{},"9 月第 2 週以降、ハイブリッドの受信コネクタ経由で Exchange Online にメールを渡す Exchange 2016 または 2019 サーバーには、2025 年 10 月のセキュリティ更新プログラムが適用されている必要があります。これは、Microsoft がこの 2 つのバージョン向けに一般公開した最後の更新プログラムでもあります。それより古いサーバーは Exchange Online から見て最新ではないと判断され、最初はレポートに載り、1 か月後にはメールが遅延し、3 か月後にはメールがまったく届かなくなります。この期限について、Microsoft 自身は「This update level was released almost a year ago, and all organizations should have updated to it.」とコメントしています。もっともな話です。",[88,89],"at-a-glance",{":items":90},"[{\"label\":\"対象\",\"value\":\"ハイブリッド構成で使われる OnPremises タイプの受信コネクタ経由で Exchange Online に送信する Exchange Server 2016 および 2019\"},{\"label\":\"最低ビルド\",\"value\":\"Exchange 2019 CU14 または CU15、あるいは Exchange 2016 CU23 向けの 2025 年 10 月のセキュリティ更新プログラム\"},{\"label\":\"適用開始\",\"value\":\"2026 年 9 月第 2 週\"},{\"label\":\"完全ブロック\",\"value\":\"サーバーが最初に検出されてから 90 日後（更新するか、適用を一時停止した場合を除く）\"}]",[92,93,94],"h2",{"id":94},"日ごとに何が起きるか",[81,96,97],{},"一晩で遮断されることはありません。Exchange Online は Microsoft が 2023 年に構築したのと同じトランスポートベースの適用システムを使い、少しずつ締め付けを強めます。サーバーが検出されてから最初の 30 日間は、誰にとっても何も変わりません。そのサーバーは、ほとんどの管理者が開いたこともないレポートに表示されるだけです。その後は 10 日ごとに状況が厳しくなります。Exchange Online は 1 時間ごとに 5 分間、一時的な 450 を返すようになり、その時間が 10 分、20 分と延びていきます。サーバーはメールをキューに入れて再試行するので、メールはすべて届きますが遅れます。最初のチケットには「スキャンが届くまで 20 分かかった」といった内容が書かれているはずです。",[81,99,100],{},"61 日目からは、恒久的な 550 が加わります。こうなるとメッセージはキューで待つことなく、バウンスします。リレー構成で問題になるのはここです。バウンスは送信者に返されますが、その送信者はコピー室のスキャナーで、誰も読まない差出人アドレスを使っています。ドキュメントはそのまま消えてしまいます。91 日目からは、すべてのメッセージがそうなります。",[102,103],"enforcement-ladder",{},[81,105,106,107,111,112,111,115,118,119,122],{},"影響を受けるサーバーは、Exchange 管理センターの ",[108,109,110],"strong",{},"Reports"," > ",[108,113,114],{},"Mail flow",[108,116,117],{},"Out-of-date connecting on-premises Exchange servers"," で確認できます。同じページに ",[108,120,121],{},"Enforcement Pause"," リンクがあり、PowerShell でも同じ操作ができます。",[124,125,130],"pre",{"className":126,"code":127,"language":128,"meta":129,"style":129},"language-powershell shiki shiki-themes github-light github-dark","New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer -NumberOfDays 30\n","powershell","",[131,132,133],"code",{"__ignoreMap":129},[134,135,138],"span",{"class":136,"line":137},"line",1,[134,139,127],{},[81,141,142],{},"テナントごとに暦年あたり 90 日の一時停止日数が与えられ、自由に分割して使えます。使う前に知っておくべきことが 2 つあります。日数は申請した時点からカウントされるため、翌朝にパッチを当てても戻ってきません。また、一時停止で得られるのは時間だけで、この先の方向性は何も変わりません。",[92,144,145],{"id":145},"パッチで稼げるのは数年ではなく数か月",[81,147,148],{},"2025 年 10 月の更新プログラムをインストールすれば、ひとまずリストからは外れます。ただし Microsoft は、次に何が起きるかについて珍しく率直に語っています。Microsoft 自身の見積もりでは数か月後に最低バージョンが再び引き上げられ、今度は一般公開の更新プログラムでは到達できないビルドが基準になります。その日以降、Exchange Online にメールを渡せるサーバーは 2 種類だけです。1 つは有償の Extended Security Update プログラムに参加しているサーバーで、その第 2 期間は 2026 年 10 月に終了し、第 3 期間は予定されていません。もう 1 つは Exchange Server Subscription Edition です。Exchange 2019 CU14 または CU15 であれば、SE へのインプレースアップグレードが可能です。Exchange 2016 の場合は、新しいサーバーと移行が必要になります。",[81,150,151],{},"つまり、サーバールームで何年も誰にも触られずに動いてきたあのサーバーには、サブスクリプションか、移行プロジェクトか、停止計画のいずれかが必要になります。4 つ目の選択肢はもうありません。スロットリングそのものよりも、これこそが Microsoft の記事の本当のニュースです。",[92,153,155],{"id":154},"その-1-台のサーバーについて","その 1 台のサーバーについて",[81,157,158],{},"ほとんどのハイブリッド環境のお客様で、同じ構図が見られます。メールボックスは何年も前に Exchange Online に移行し、Exchange Server が 1 台だけ 2 つの仕事のために残っています。Active Directory の受信者属性の管理と、プリンター、スキャナー、監視、ERP など、建物内で今もプレーンな SMTP しか話せないあらゆるもののためのメールリレーです。",[81,160,161],{},"1 つ目の仕事には、2022 年以降サーバーは必要ありません。Exchange 2019 CU12 以降は Exchange Management Tools が単独で受信者管理を担い、Microsoft は最後のサーバーをアンインストールするのではなくシャットダウンするよう推奨しています。残るのはリレーです。サーバーを動かし続けている理由はこの仕事だけで、しかも少し皮肉なことに、今回の適用が対象とするのはまさにこのトラフィックです。デバイスがそのサーバーに渡すメールはすべて、Exchange Online が現在チェックしている OnPremises コネクタを通って出ていくからです。",[92,163,164],{"id":164},"今週やるべきこと",[166,167,168,172,183,186],"ol",{},[169,170,171],"li",{},"レポートを開き、表示されるサーバーをすべて書き出します。空であれば、良い知らせか、Partner タイプのコネクタかのどちらかです。適用の対象は、今のところ OnPremises タイプだけです。",[169,173,174,175,182],{},"ビルドを ",[176,177,181],"a",{"href":178,"rel":179},"https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates",[180],"nofollow","Microsoft のビルド番号一覧"," と照らし合わせ、2025 年 10 月の更新プログラムが適用されていないサーバーにはインストールします。サーバー 1 台なら、プロジェクトではなく一晩の作業です。",[169,184,185],{},"一時停止日数は本当の緊急時のために取っておきます。90 日は十分に思えますが、間違った月に 60 日を使ってしまえばそうではなくなります。",[169,187,188],{},"次の引き上げの後にどうするかを決めます。選択肢は 10 月までの ESU、Exchange SE、または停止です。",[81,190,191],{},"リレーがそのサーバーの唯一の存在理由なら、4 つ目の判断は簡単です。Sendman はまさにそのために作りましたが、それはまた別の記事で取り上げます。",[92,193,194],{"id":194},"出典",[196,197,198,207,215,222,229,237,245],"ul",{},[169,199,200,201,206],{},"Microsoft Exchange Team: ",[176,202,205],{"href":203,"rel":204},"https://techcommunity.microsoft.com/blog/exchange/exchange-20162019-throttling-and-blocking-up-to-the-final-public-update-baseline/4552717",[180],"Exchange 2016/2019: Throttling and Blocking up to the Final Public Update Baseline","、2026 年 9 月 2 日",[169,208,200,209,214],{},[176,210,213],{"href":211,"rel":212},"https://techcommunity.microsoft.com/blog/exchange/throttling-and-blocking-email-from-persistently-vulnerable-exchange-servers-to-e/3815328",[180],"Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online","、2023 年 5 月",[169,216,200,217],{},[176,218,221],{"href":219,"rel":220},"https://techcommunity.microsoft.com/blog/exchange/how-to-pause-throttling-and-blocking-of-out-of-date-on-premises-exchange-servers/4007169",[180],"How to pause throttling and blocking of out-of-date on-premises Exchange Servers",[169,223,200,224],{},[176,225,228],{"href":226,"rel":227},"https://techcommunity.microsoft.com/blog/exchange/announcing-period-2-exchange-20162019-extended-security-update-esu-program/4511603",[180],"Announcing Period 2 Exchange 2016/2019 Extended Security Update (ESU) program",[169,230,231,232],{},"Microsoft Learn: ",[176,233,236],{"href":234,"rel":235},"https://learn.microsoft.com/en-us/exchange/manage-hybrid-exchange-recipients-with-management-tools",[180],"Manage recipients in Exchange Hybrid environments using Management tools",[169,238,239,240],{},"heise online: ",[176,241,244],{"href":242,"rel":243},"https://www.heise.de/news/Alte-Exchange-Server-riskieren-Mailblockaden-11443696.html",[180],"Alte Exchange-Server riskieren Mailblockaden",[169,246,247,248,253],{},"CodeTwo: ",[176,249,252],{"href":250,"rel":251},"https://www.codetwo.com/admins-blog/persistently-vulnerable-exchange-server/",[180],"Exchange Online transport enforcement system explained","、図中の各段階の時間（分）の出典",[255,256,257],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":129,"searchDepth":259,"depth":259,"links":260},2,[261,262,263,264,265],{"id":94,"depth":259,"text":94},{"id":145,"depth":259,"text":145},{"id":154,"depth":259,"text":155},{"id":164,"depth":259,"text":164},{"id":194,"depth":259,"text":194},null,"2026-09-12T09:30:00+02:00","Exchange Online は、2025 年 10 月の更新プログラムを適用していない Exchange 2016 および 2019 サーバーからのメールを遅延させ始めており、いずれ受信を拒否するようになります。社内に残る最後の Exchange が今もスキャナーのメールを中継しているなら、この記事が役に立ちます。","md",false,{"lang":272},"ja",true,{"headline":275,"copy":276},"リレーは残し、サーバーはなくす","Sendman は Microsoft 365 のための SMTP リレーで、まさにこの記事で取り上げたサーバーのために作られています。プリンター、スキャナー、アプリは既存のログインをそのまま使い、Microsoft Entra ID で検証されます。アプリ登録も同意も不要で、テナント側で変更することもありません。メールは SMTP AUTH を使わずに Exchange Online に届くため、Microsoft による基本認証の廃止の影響を受けません。","/blog/exchange-online-blocks-outdated-exchange-servers",{"title":279,"description":280},"Exchange Online が Exchange 2016 と 2019 のスロットリングを開始","2026 年 9 月以降、Exchange Online は 2025 年 10 月の更新プログラムに満たない Exchange 2016 および 2019 サーバーからのメールをスロットリングし、その後ブロックします。今やるべきことをまとめました。","blog/exchange-online-blocks-outdated-exchange-servers","5jty0bEg7LPyZK8hbHbqFvW4KoYobqAET_5LkQnjRok",{"id":284,"title":285,"author":286,"body":287,"cta":266,"date":440,"description":441,"eventid":266,"extension":269,"hideInRecent":270,"layout":266,"meta":442,"moment":266,"navigation":273,"outro":443,"path":446,"seo":447,"stem":450,"tags":266,"webcast":270,"__hash__":451},"content_ja/blog/smtp-auth-basic-authentication-retirement-timeline.md","SMTP の基本認証は 4 月に終わっていません",[76],{"type":78,"value":288,"toc":433},[289,292,295,298,302,305,308,311,326,329,336,339,342,345,352,355,358,361,363],[81,290,291],{},"Microsoft が 4 月 30 日に SMTP AUTH の基本認証を停止したと読んだのなら、そう理解している人は少なくありません。プリンター販売店や IT サービスプロバイダーの多くが今もウェブサイトにそう書いていますし、数か月の間は、それが計画だったという意味で事実でもありました。1 月、Microsoft はその計画を撤回しました。代わりに示された期日はより遅く、ずっと緩やかです。これは良い知らせですが、それを対応をやめてよいという許可だと受け取る人が出てくるまでの話です。",[81,293,294],{},"この経緯を知ると多くのことが見えてくるので、要点だけまとめます。2022 年 10 月に Microsoft が POP、IMAP、EWS をはじめ Exchange Online の基本認証を無効にしたとき、SMTP AUTH だけは手を付けずに残し、「We are not touching SMTP AUTH and are done turning it off for now.」という印象的な一文を添えました。それでも 2024 年 4 月には 2025 年 9 月という期日を設定し、これは後に、2026 年 3 月 1 日から段階的に拒否を始め、4 月 30 日にはすべての送信を拒否するという計画に変わりました。1 月 27 日、それらすべてを置き換える記事が公開されました。その理由として Microsoft が挙げた「many customers continue to face real challenges modernizing legacy email workflows」という一文は、引用する価値があります。複合機ベンダーに OAuth について問い合わせたことがある人なら、この一文の意味がよくわかるはずです。",[88,296],{":items":297},"[{\"label\":\"12 月まで\",\"value\":\"何も変わらず、SMTP AUTH の基本認証は現在と同じように動作します\"},{\"label\":\"2026 年 12 月末\",\"value\":\"既存のテナントでは既定で無効になり、管理者が再び有効にできます\"},{\"label\":\"新しいテナント\",\"value\":\"2026 年 12 月より後に作成されたテナントではまったく利用できず、サポートされる方式は OAuth です\"},{\"label\":\"2027 年後半\",\"value\":\"Microsoft が完全に廃止する期日を発表します\"}]",[92,299,301],{"id":300},"既定で無効が意味すること","「既定で無効」が意味すること",[81,303,304],{},"既存のテナントには、まだ戻る道があります。12 月末に Microsoft は SMTP AUTH の基本認証をオフにし、管理者はそれを再びオンにできます。発表ではそれがどのスイッチになるのかが示されていないため、現実的に予想されるのは次のような展開です。年明けのある朝、スキャナーが送信しなくなり、どこを見ればよいかを知っている誰かが数分で直します。無害に聞こえますが、12 月の最終週を思い浮かべてみてください。IT チームの半分は休暇中で、経理部は ERP から年度末の決算書類を出そうとしています。",[81,306,307],{},"そして再びオンにしても、Microsoft が最終期日を示すまでの時間稼ぎにしかなりません。Microsoft は 2027 年後半にその期日を発表する予定です。その後は、切り替えるスイッチ自体が残っていません。12 月より後に作成されたテナントでは、そもそも SMTP の基本認証が使えません。来年の予定にテナント移行やカーブアウトが入っているなら、これは見た目以上に重要です。新しいテナントは、古いテナントが問題なく受け入れていたログインを拒否するからです。",[92,309,310],{"id":310},"まだ誰が使っているかを調べる",[81,312,313,314,111,316,111,318,321,322,325],{},"おおよその見当はついているでしょうが、おそらく漏れがあります。Exchange 管理センターには、まさにこのためのレポートが ",[108,315,110],{},[108,317,114],{},[108,319,320],{},"SMTP AUTH clients"," にあります。SMTP AUTH でメールを送信しているすべての送信者アドレスが一覧表示され、基本認証と OAuth のどちらでサインインしているか、どの TLS バージョンを使っているかがわかり、最大 90 日前までさかのぼれます。Microsoft Entra ID のサインインログをクライアントアプリ ",[108,323,324],{},"Authenticated SMTP"," で絞り込むと、ログイン元の IP アドレスを含め、ID 側から同じ状況を確認できます。この 2 つを合わせると、たいていは 3 階の複合機、チームの誰よりも古くからある監視サーバー、そして誰も自分の担当だと認めないアプリケーションが 1 つ見つかります。",[92,327,328],{"id":328},"デバイスごとの移行先",[81,330,331,332,335],{},"スクリプトや自社のアプリケーションは簡単な部分です。Microsoft Graph や ",[131,333,334],{},"Send-MgUserMail"," などのコマンドレットはモダン認証でメールを送信でき、スクリプトの書き換えは半日で終わります。",[81,337,338],{},"ベンダーが OAuth 対応を提供済みのデバイスは、ファームウェアの更新と Entra の設定を少し行えば完了です。時間がかかるのは、それ以外のすべてです。Tony Redmond は控えめにこう書いています。「I hear of many blank looks when customers ask vendors about their plans to upgrade devices to support OAuth for client submissions.」",[81,340,341],{},"デバイスが社内の人にしかメールを送らないのであれば、High Volume Email を検討する価値があります。3 月末から一般提供されており、料金は受信者 100 万件あたり 42 ドルです。そして、この記事で扱っているほかのすべての流れにやや逆行して、専用のエンドポイントでは 2028 年 9 月まで基本認証を受け付け続けます。ただし制限ははっきりしています。宛先は社内の受信者のみで、1 メッセージあたり受信者は最大 50 人、サイズは最大 10 MB です。仕入先や顧客にメールが届くことはありません。",[81,343,344],{},"社外に送る必要があるメールについては、Microsoft は Azure Communication Services を案内しています。SMTP に対応していますが、パスワードは Entra のアプリ登録のクライアントシークレットで、クライアントシークレットには有効期限があります。誰かが定期的にスキャナーのパスワードを変更しなければならず、これはまさに期限の翌日に思い出されるたぐいの作業です。",[81,346,347,348,351],{},"そして、そのどれもできないデバイスが残ります。たいていの建物では、誰もが望むより多く存在します。こうしたデバイスには、すでに持っているログインを受け入れるリレーが必要です。オンプレミスの Exchange Server はその役割を果たせますが、それは Exchange Online がそのメールを受け付けている間だけで、その点は今月、",[176,349,350],{"href":277},"それ自体が別の話題になっています","。",[92,353,354],{"id":354},"スイッチが切られるのを待たない",[81,356,357],{},"新しいスケジュールでは最終期日まで 1 年以上ありますが、12 月を穏やかに過ごせるわけではありません。今月レポートを開けば、10 月に簡単なケースを移行し、11 月に難しいケースを片付け、年末の最終週を本来あるべき形で過ごせます。",[81,359,360],{},"Sendman は、その最後のグループ、つまり OAuth に対応することのないデバイスのために作りました。",[92,362,194],{"id":194},[196,364,365,373,381,388,395,402,410,417,424],{},[169,366,200,367,372],{},[176,368,371],{"href":369,"rel":370},"https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835",[180],"Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline","、2026 年 1 月 27 日",[169,374,200,375,380],{},[176,376,379],{"href":377,"rel":378},"https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750",[180],"Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)","、2024 年 4 月 15 日（その後更新）",[169,382,231,383],{},[176,384,387],{"href":385,"rel":386},"https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mfr-smtp-auth-clients-report",[180],"SMTP AUTH clients report in the new EAC in Exchange Online",[169,389,231,390],{},[176,391,394],{"href":392,"rel":393},"https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/authenticated-client-smtp-submission",[180],"Enable or disable SMTP AUTH in Exchange Online",[169,396,231,397],{},[176,398,401],{"href":399,"rel":400},"https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365",[180],"How to set up a multifunction device or application to send email using Microsoft 365",[169,403,200,404,409],{},[176,405,408],{"href":406,"rel":407},"https://techcommunity.microsoft.com/blog/exchange/high-volume-email-continued-support-for-basic-authentication--other-important-up/4411197",[180],"High Volume Email: Continued support for Basic Authentication & other important updates","、2025 年 5 月 6 日",[169,411,231,412],{},[176,413,416],{"href":414,"rel":415},"https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365",[180],"Manage High Volume Email for Microsoft 365",[169,418,231,419],{},[176,420,423],{"href":421,"rel":422},"https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/email/send-email-smtp/smtp-authentication",[180],"Set up SMTP authentication for sending emails with Azure Communication Services",[169,425,426,427,432],{},"Office 365 for IT Pros: ",[176,428,431],{"href":429,"rel":430},"https://office365itpros.com/2026/01/29/smtp-auth-basic-retirement/",[180],"SMTP AUTH Client Submission Retirement Delayed","、2026 年 1 月 29 日",{"title":129,"searchDepth":259,"depth":259,"links":434},[435,436,437,438,439],{"id":300,"depth":259,"text":301},{"id":310,"depth":259,"text":310},{"id":328,"depth":259,"text":328},{"id":354,"depth":259,"text":354},{"id":194,"depth":259,"text":194},"2026-09-12T09:20:00+02:00","Microsoft がこの春に SMTP AUTH の基本認証を停止したと読んだのなら、それは Microsoft が 1 月に撤回した計画です。実際の期日は 12 月末で、少なくとも今のところ、以前の計画よりも緩やかなものです。",{"lang":272},{"headline":444,"copy":445},"ログインは残し、期限はなくす","Sendman は Microsoft 365 のための SMTP リレーで、OAuth に対応することのないデバイスのために作られています。デバイスは既存のログインをそのまま使い、Microsoft Entra ID で検証されます。アプリ登録も同意も不要で、テナント側で変更することもありません。メールは SMTP AUTH を使わずに Exchange Online に届くため、Microsoft による基本認証の廃止の影響を受けません。","/blog/smtp-auth-basic-authentication-retirement-timeline",{"title":448,"description":449},"SMTP AUTH の基本認証廃止、実際のスケジュール","Microsoft は 2026 年 4 月の停止を撤回しました。SMTP AUTH の基本認証は 2026 年 12 月末に既定で無効になります。何が変わり、何をすべきかを解説します。","blog/smtp-auth-basic-authentication-retirement-timeline","wmT40_eOiwFMbmBdjfyh9DuMfOMHiI_N8JW5lKjTbcw",{"id":453,"title":454,"author":455,"body":456,"cta":266,"date":619,"description":620,"eventid":266,"extension":269,"hideInRecent":270,"layout":266,"meta":621,"moment":266,"navigation":273,"outro":622,"path":625,"seo":626,"stem":629,"tags":266,"webcast":270,"__hash__":630},"content_ja/blog/reject-direct-send-without-breaking-scanners.md","スキャナーを止めずに Direct Send を閉じる",[76],{"type":78,"value":457,"toc":612},[458,461,464,467,471,474,483,486,494,497,500,503,530,537,540,543,546,553,555,569,576,578,610],[81,459,460],{},"Direct Send は、もともと巧妙な仕組みとして作られたものではありません。スキャナーや小さなアプリケーションが、どこにもサインインせずに、自社のアドレスを送信者としてテナントの MX エンドポイントに直接メールを送り込めるようにするためのものです。Microsoft はこれを「mimics incoming anonymous emails from the internet, apart from the sender domain」と説明しています。穏やかな言い方ですが、要するに、スキャナーとインターネット上のほかの誰かを区別する手がかりは、名乗っているアドレスしかないということです。",[81,462,463],{},"2025 年 5 月、これを悪用する者が現れました。Varonis は、70 を超える組織（その大半は米国）に届いたキャンペーンを追跡しました。そのメールは社内から送られたように見えましたが、Exchange Online から見れば実際に社内のメールでした。テナントのスマートホストに対して PowerShell を 1 行実行し、被害者自身のアドレスを送信者にして、偽の Microsoft サインインページに誘導する QR コード付きの PDF を送るだけです。おとりは不在着信や FAX の通知で、複合機が毎日送っている種類のメールでした。だからこそ、誰も疑わなかったのです。",[88,465],{":items":466},"[{\"label\":\"概要\",\"value\":\"承認済みドメインのいずれかを送信者として、テナントの MX エンドポイントに匿名で送信されるメール\"},{\"label\":\"スイッチ\",\"value\":\"組織構成の RejectDirectSend（2025 年 4 月に導入、既定ではオフ）\"},{\"label\":\"引き続き受信されるもの\",\"value\":\"自分で設定した受信コネクタ経由で届き、IP アドレスまたは証明書で照合されたメール\"},{\"label\":\"新しいテナント\",\"value\":\"Microsoft は既定で有効にし、無効にできないようにする予定\"}]",[92,468,470],{"id":469},"microsoft-が追加したスイッチ","Microsoft が追加したスイッチ",[81,472,473],{},"2025 年 4 月から、実際にオフにできるスイッチがあり、必要なのは 1 行だけです。",[124,475,477],{"className":126,"code":476,"language":128,"meta":129,"style":129},"Set-OrganizationConfig -RejectDirectSend $true\n",[131,478,479],{"__ignoreMap":129},[134,480,481],{"class":136,"line":137},[134,482,476],{},[81,484,485],{},"反映までは 30 分ほどです。それ以降、エンベロープの送信者に自社ドメインを使う匿名メールは、設定済みの受信コネクタ経由で届いたものでない限り入口で拒否され、送信側には次のメッセージが返ります。",[124,487,492],{"className":488,"code":490,"language":491,"meta":129},[489],"language-text","550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources\n","text",[131,493,490],{"__ignoreMap":129},[81,495,496],{},"Microsoft は、新しいテナントではこれを既定で有効にし、そのテナントでは無効にできないようにする意向も示しています。日付は決まっていませんが、方向ははっきりしています。",[92,498,499],{"id":499},"まず誰が使っているかを調べる",[81,501,502],{},"ほとんどのテナントがまだスイッチを入れていない理由は単純で、入れたときにほかに何が止まるのか誰にもわからないからです。Microsoft は SPF レコードから始めることを勧めています。Direct Send で送信していながら SPF レコードに載っていないものは、すでに配信に問題を抱えているからです。実際のトラフィックについては、Microsoft が Exchange 管理センターでプレビューとして公開した Change Optics レポートに、この設定で拒否されるメッセージの例が表示されます。コネクタを経由せずに受信したすべてのメールを対象にした履歴メッセージ追跡では、最大 90 日前までさかのぼれます。",[124,504,506],{"className":126,"code":505,"language":128,"meta":129,"style":129},"Start-HistoricalSearch -ReportTitle \"Direct Send\" -ReportType ConnectorReport `\n  -ConnectorType NoConnector -Direction Received `\n  -StartDate (Get-Date).AddDays(-89) -EndDate (Get-Date) `\n  -NotifyAddress admin@contoso.com\n",[131,507,508,513,518,524],{"__ignoreMap":129},[134,509,510],{"class":136,"line":137},[134,511,512],{},"Start-HistoricalSearch -ReportTitle \"Direct Send\" -ReportType ConnectorReport `\n",[134,514,515],{"class":136,"line":259},[134,516,517],{},"  -ConnectorType NoConnector -Direction Received `\n",[134,519,521],{"class":136,"line":520},3,[134,522,523],{},"  -StartDate (Get-Date).AddDays(-89) -EndDate (Get-Date) `\n",[134,525,527],{"class":136,"line":526},4,[134,528,529],{},"  -NotifyAddress admin@contoso.com\n",[81,531,532,533,536],{},"Defender for Office 365 Plan 2 があれば、Advanced Hunting で ",[131,534,535],{},"EmailEvents"," のうちコネクタフィールドが空のものを検索すると、同じメールが見つかります。結果を読む前に知っておくべきことが 1 つあります。これらのレポートが最も役に立つのは、MX が独自のコネクタ経由で届くゲートウェイを指している場合です。MX が Exchange Online を直接指している場合は、通常の受信メールもすべてコネクタなしで届くため、自社ドメインを送信者とするものに絞り込む必要があります。",[81,538,539],{},"見つかるものに驚きはあまりありませんが、リストは予想より長くなります。複合機、ビル管理システム、倉庫のラベルプリンター、そしてときには自社の名義で請求書を送るクラウドサービスです。確定する前に影響を確認したい場合、Microsoft 自身が示す中間策は、この種のメールを拒否する代わりに検疫するメールフロールールです。何も失うことはなく、1 週間後にはスイッチが何を止めていたかが正確にわかります。",[92,541,542],{"id":542},"スキャナーを別の経路に移す",[81,544,545],{},"正当な送信者に対する Microsoft の答えは、オフィスのパブリック IP アドレス、または証明書を信頼する Partner タイプの受信コネクタです。ただし、実際に証明書を持っているスキャナーはほとんどありません。費用はかからず、固定アドレスを持つ単一拠点であれば機能します。注意点もあります。そのアドレスを組織外の誰とも共有してはならず、独自のインターネットブレイクアウトを持つ拠点ごとにエントリが必要で、IP アドレスが唯一の鍵になります。その背後にあるものは何でも、ドメイン内の誰の名義でも送信できます。間違った FAX 通知をクリックした経理部のノート PC も例外ではありません。",[81,547,548,549,552],{},"サインインでき、同僚にしかメールを送らないデバイスは High Volume Email に移行できます。これについては ",[176,550,551],{"href":446},"SMTP AUTH に関する記事","で取り上げました。残りのデバイスがそもそも Direct Send を使っていたのは TLS もログインも使えないからで、こうしたデバイスには、デバイスにできることを受け入れつつ、誰が誰の名義で送信できるかを判断するリレーが必要です。",[92,554,164],{"id":164},[166,556,557,560,563,566],{},[169,558,559],{},"コネクタなしのメッセージ追跡を実行し、Change Optics レポートを開いて、見つかった送信元をすべて書き出します。",[169,561,562],{},"正当な送信元には適切な経路を用意します。既知の IP アドレスには Partner コネクタ、社内にしかメールを送らないデバイスには High Volume Email、それ以外にはリレーです。",[169,564,565],{},"検疫ルールを 1 週間設定し、そこに何が入るかを確認します。",[169,567,568],{},"そのうえで RejectDirectSend を設定し、数日間は 5.7.68 のバウンスに注意します。",[81,570,571,572,575],{},"Sendman はそのリレーとして作りました。スキャナーはサインインするか、許可したアドレス範囲から送信し、",[131,573,574],{},"scan@contoso.com"," としては送信できても、CEO の名義では送信できません。",[92,577,194],{"id":194},[196,579,580,588,596,601],{},[169,581,200,582,587],{},[176,583,586],{"href":584,"rel":585},"https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790",[180],"Introducing more control over Direct Send in Exchange Online","、2025 年 4 月 28 日（その後更新）",[169,589,200,590,595],{},[176,591,594],{"href":592,"rel":593},"https://techcommunity.microsoft.com/blog/exchange/direct-send-vs-sending-directly-to-an-exchange-online-tenant/4439865",[180],"Direct Send vs sending directly to an Exchange Online tenant","、2025 年 8 月 4 日",[169,597,231,598],{},[176,599,401],{"href":399,"rel":600},[180],[169,602,603,604,609],{},"Varonis Threat Labs: ",[176,605,608],{"href":606,"rel":607},"https://www.varonis.com/blog/direct-send-exploit",[180],"Ongoing Campaign Abuses Microsoft 365's Direct Send to Deliver Phishing Emails","、2025 年 6 月 26 日",[255,611,257],{},{"title":129,"searchDepth":259,"depth":259,"links":613},[614,615,616,617,618],{"id":469,"depth":259,"text":470},{"id":499,"depth":259,"text":499},{"id":542,"depth":259,"text":542},{"id":164,"depth":259,"text":164},{"id":194,"depth":259,"text":194},"2026-09-12T09:10:00+02:00","Direct Send を使えば、インターネット上の誰もが自社ユーザーになりすましてテナントにメールを送り込めます。昨年、攻撃者がそれに気付きました。現在は Exchange Online で拒否できますが、問題は何年も前から人知れずこれに頼ってきたスキャナーです。",{"lang":272},{"headline":623,"copy":624},"スキャナーは残し、裏口は閉じる","Sendman は Microsoft 365 のための SMTP リレーです。デバイスは既存のログインでサインインし、Microsoft Entra ID で検証されます。アプリ登録も同意も不要で、テナント側で変更することもありません。あるいは、許可したアドレス範囲からログインなしで送信することもでき、誰が誰の名義で送信できるかはポリシーで決まります。","/blog/reject-direct-send-without-breaking-scanners",{"title":627,"description":628},"スキャナーを壊さずに Direct Send を拒否する","攻撃者は Direct Send を使って自社ユーザーになりすまします。Exchange Online で拒否できますが、スキャナーが依存していることも少なくありません。それらを見つけて先に移行する方法を解説します。","blog/reject-direct-send-without-breaking-scanners","79vYzX5-xWDEi48eNSNFZDjJSLyZr-9tpU_CJNs_Ek4",1791278568045]