Microsoft 365 вимикає SMTP AUTH з паролем у грудні 2026 року: що перестане надсилати пошту і що робити

Наприкінці грудня 2026 року Exchange Online за замовчуванням вимикає звичайну автентифікацію (Basic authentication) для SMTP AUTH у всіх наявних тенантах Microsoft 365. Усе, що надсилає пошту через скриньку Microsoft 365 за логіном і паролем, почне отримувати відмову: форма заявки на сайті, CRM, офісний сканер, скрипт, який уночі розсилає рахунки. Розповідаємо, що саме змінюється, як за один день знайти всіх таких відправників, які є шляхи і де в кожного обмеження, а також чому пошту своїх систем ми надсилаємо через Google Workspace і власний код.

Терміни

Що змінюється і коли

Microsoft опублікувала поточний графік у блозі команди Exchange 27 січня 2026 року. У ньому чотири кроки:

Дату вже двічі переносили. У квітні 2024 року Microsoft планувала вимкнення на вересень 2025 року, потім посунула початок на 1 березня 2026 року з повною відмовою до 30 квітня 2026 року, а в січні 2026 року замінила це графіком вище. Напрямок жодного разу не змінився. SMTP AUTH лишається останнім місцем в Exchange Online, де ще працює звичайний пароль: для решти протоколів, як-от POP, IMAP і Exchange Web Services, звичайну автентифікацію вимкнули ще в жовтні 2022 року.

Для власника висновок простий. Грудневий крок адміністратор може скасувати одним налаштуванням, тож 1 січня нічого не втрачається назавжди. Наступний крок, оголошений на другу половину 2027 року, скасувати вже не вийде, і все, що сьогодні тримається на паролі, однаково доведеться переводити.

Кого стосується

Що надсилає пошту в такий спосіб

Людей зміна не зачепить. Працівники, які відкривають Outlook на ноутбуці чи телефоні, входять через сучасну автентифікацію і нічого не помітять. Вона стосується пристроїв і програм, які колись налаштували на адресу smtp.office365.com, порт 587, скриньку й пароль, а потім забули про них.

У компаніях, з якими ми працювали, такі відправники зазвичай живуть у п'яти місцях:

• сайт: форми заявок і замовлень, листи для скидання пароля, підтвердження замовлень, часто через SMTP-плагін у WordPress або налаштування SMTP у застосунку на Laravel чи Symfony;
• робочі системи: CRM, ERP або облікова програма, яка розсилає сповіщення, комерційні пропозиції й рахунки із загальної адреси на кшталт info@ або noreply@;
• офісна техніка: БФП і сканери з функцією «сканувати в пошту», де пароль колись увів у меню пристрою працівник, який давно звільнився;
• моніторинг і бекапи: сервери, сигналізації та завдання резервного копіювання, які повідомляють про збої листом;
• старі скрипти: нічне вивантаження, звіт для директора, нагадування клієнтам, які написав підрядник і які крутяться на сервері, куди ніхто не зазирає.

Спільне в них одне: пароль зберігається десь поза головою людини, у файлі налаштувань, у налаштуванні плагіна, у меню пристрою. Саме це Microsoft і хоче прибрати, і причина зрозуміла. Пароль від спільної скриньки, записаний у п'яти місцях і відомий трьом колишнім підрядникам, лишається одним із найпростіших шляхів до пошти компанії.

Що ламається

Як виглядає збій

Після вимкнення програма, яка намагається увійти за паролем, замість надсилання отримує від сервера помилку автентифікації. В оголошенні Microsoft наведено відповідь, яку клієнти побачать після остаточного вимкнення: 550 5.7.30, Basic authentication is not supported for Client Submission. Що буде далі, залежить від того, як написана програма.

Сканер покаже помилку на екрані, і того ж ранку хтось піде до адміністратора. Завдання моніторингу впаде беззвучно, і про це дізнаються лише під час тієї аварії, про яку воно мало повідомити. Найгірше із сайтом: багато форм показують «Дякуємо, ми з вами зв'яжемося» незалежно від того, пішов лист чи ні, тож відвідувач іде задоволений, а заявка зникає.

Форма, яка дякує і губить заявку, гірша за зламану.

Тому на сайті, який ми приймаємо від іншого підрядника, ми перевіряємо це одним із перших. На нашому власному сайті кожна заявка з кожної форми спершу записується в журнал на сервері, а лист іде вже потім, як сповіщення поверх неї. Якщо скринька відмовить, заявка однаково лишиться в журналі та в адмінці. Якщо ваш сайт лише надсилає лист і нічого не зберігає, грудневі зміни стануть добрим приводом виправити і це. Чому заявки губляться, ми розбирали у статті Чому сайт не приносить заявок.

Як знайти

Усі відправники за один день

У Microsoft є готовий звіт для адміністраторів, і починати краще з нього. У новому центрі адміністрування Exchange відкрийте Reports, далі Mail flow, далі звіт SMTP AUTH clients. У ньому перелічено всі адреси, які надсилали пошту через SMTP AUTH, домен, кількість листів, версію TLS і протокол автентифікації. TlsAuthLogin у цій колонці означає звичайну автентифікацію, тобто логін і пароль; XOAUTH2 означає сучасну, з нею все гаразд. Звіт охоплює до 90 днів і вивантажується в CSV.

Звіт показує скриньки, а не пристрої. Наступний крок: зіставити кожну адресу з тим, що за нею стоїть:

• пошукайте smtp.office365.com у налаштуваннях сайту й застосунків: у файлі .env застосунку на Laravel, у налаштуваннях пошти застосунку на Symfony, у SMTP-плагіні WordPress;
• відкрийте налаштування CRM, облікової програми та служби підтримки і знайдіть сервер вихідної пошти;
• пройдіться офісом: принтери й сканери зберігають налаштування пошти в меню пристрою або на його вебсторінці;
• запитайте того, хто веде ваші сервери, які завдання надсилають листи і з якої адреси.

Далі перевірте все до грудня, а не чекайте на нього. SMTP AUTH можна вимкнути для однієї скриньки, поки решта компанії працює як завжди. Візьміть скриньку, з якої надсилає сайт, вимкніть її в робочий день зранку, надішліть тестовий лист із кожної форми та з кожного пристрою, які мають через неї працювати, і подивіться, що впаде. Команди взято з документації Microsoft щодо SMTP AUTH:

# вимкнути SMTP AUTH для однієї скриньки (перевірка)
Set-CASMailbox -Identity noreply@example.com -SmtpClientAuthenticationDisabled $true

# повернути налаштування організації
Set-CASMailbox -Identity noreply@example.com -SmtpClientAuthenticationDisabled $null

# загальний перемикач організації ($false означає увімкнено)
Set-TransportConfig -SmtpClientAuthenticationDisabled $false

Така перевірка займає годину і дає список, якого не дасть жодна таблиця інвентаризації. Якщо список довгий або ніхто не знає, хто налаштовував половину з нього, це звична ситуація після зміни підрядника, і про неї ми писали у статті Як прийняти сайт або застосунок від іншого розробника.

Шляхи розв'язання

Чотири варіанти та їхні обмеження

Увімкнути звичайну автентифікацію знову після грудня можна, і для сканера у філії це буває чесною тимчасовою відповіддю. Але планом це не назвеш. Справжній вибір іде між чотирма шляхами, і вони пасують різним відправникам.

Двох шляхів краще уникати. Direct Send, коли пристрій кладе лист у ваш тенант без входу, доставляє тільки всередині компанії, а Microsoft пише в документації, що готує його вимкнення за замовчуванням. Azure Communication Services Email у деяких посібниках досі радять для зовнішньої пошти, але у вересні 2026 року Microsoft оголосила, що Azure Communication Services як окрему пропозицію закривають до 30 вересня 2028 року, і Email є в цьому переліку. Будувати на ньому щось нове зараз означає переїжджати двічі.

OAuth для сайту

Що потрібно в коді

Для сайту чи застосунку OAuth буде найчистішим шляхом, якщо ви хочете й далі надсилати пошту зі свого домену в Microsoft 365. Роботи при цьому більше, ніж зі зміною пароля, і вона йде з двох боків: у порталах адміністрування Microsoft і в коді.

З боку Microsoft адміністратор реєструє застосунок у Microsoft Entra, надає йому дозвіл застосунку Exchange Online SMTP.SendAsApp, підтверджує згоду адміністратора, потім через PowerShell створює в Exchange Online суб'єкт-службу (service principal) для цього застосунку і дає йому права на скриньку, з якої він надсилатиме. У документації Microsoft окремо попереджає про деталь, на якій багато хто спотикається: суб'єкту-службі потрібен Object ID зі сторінки Enterprise applications, а не той, що показано на сторінці реєстрації застосунку.

З боку коду застосунок більше не зберігає пароль. Він зберігає ідентифікатор застосунку і секрет чи сертифікат, просить у Microsoft токен доступу з областю https://outlook.office365.com/.default і з цим токеном входить на smtp.office365.com. Токени живуть недовго, тож код має запитувати нові й правильно поводитися, якщо запит не вдався. Поштові бібліотеки сучасних PHP-фреймворків уміють входити за токеном, але цю частину хтось має написати, правильно зберігати секрет і стежити, щоб усе працювало, коли строк секрету закінчиться.

Старі плагіни й старі пристрої часто не вміють OAuth зовсім. Для них вибір такий: конектор relay, HVE для внутрішньої пошти, оновлення прошивки або перенесення цього відправника на інший сервіс. Сайт на версії WordPress, Laravel чи PHP, яку роками не оновлювали, може просто не мати поштової бібліотеки з такою можливістю, і тоді питання пошти стає частиною більшого питання. Ще три строки для старих PHP-сайтів припадають на ті самі тижні, про них стаття Symfony 6.4, Drupal 10 і PHP 8.2: три строки підтримки до 2027 року.

Наш вибір

Чому ми надсилаємо через Google Workspace

Нас часто питають, яку поштову платформу ми радимо, тож розповімо, як робимо самі. Наші власні сайти й системи надсилають пошту через Google Workspace, а самі системи наші: ми пишемо їх під свою роботу і самі їх розвиваємо, тому шлях листа від форми до журналу й до надсилання лишається кодом, який ми знаємо рядок за рядком.

У нас були клієнти на Microsoft 365, і як поштову скриньку для людей ми нічого проти нього не маємо. Але як основа для систем, які ми будуємо і змінюємо щотижня, він здається нам надто важким і неповоротким. Щоб правильно надіслати одне сповіщення із сайту, тепер потрібні Microsoft Entra, центр адміністрування Exchange, PowerShell, дозволи та згоди, а графік лише цієї зміни з 2024 року переписували двічі. Для великої компанії з IT-відділом це звичайне життя. Для бізнесу, якому треба, щоб сайт надіслав заявку менеджерові, це забагато механіки.

Для сайту пошта є частиною системи, а не налаштуванням скриньки.

Тому наша порада не залежить від того, чий логотип на поштовій скриньці. Пошту людей тримайте там, де вашим людям зручно. Пошту сайту й систем заберіть зі спільної людської скриньки та її пароля: дайте їй свій шлях, свій журнал і своє сповіщення, якщо щось не пішло. Чи буде це OAuth до Microsoft 365, relay чи окремий сервіс, залежить від того, що надсилає і кому. Як сайт, CRM і облік мають обмінюватися даними, не ламаючись, ми розбирали у статті Як зв'язати CRM, сайт, склад і облік так, щоб дані сходилися.

План

Що зробити до грудня

Більшості малих і середніх компаній шести тижнів вистачить, якщо почати зараз, а не 28 грудня:

• цього тижня: запустіть звіт SMTP AUTH clients за останні 90 днів і вивантажте його;
• наступного тижня: зіставте кожну адресу з пристроєм, системою чи скриптом і призначте за кожен відповідального;
• далі: виберіть шлях для кожного відправника, починаючи із сайту і всього, що пише клієнтам;
• до середини грудня: переведіть відправників, перевірте кожного з вимкненим SMTP AUTH для його скриньки і змініть паролі спільних скриньок, які більше не використовуються для надсилання;
• після свят: тримайте звіт відкритим ще місяць, щоб упіймати те, що надсилає раз на місяць чи раз на квартал.

Якщо після грудня ви вирішите ввімкнути звичайну автентифікацію знову для пристрою, який поки не можна замінити, запишіть, що це за пристрій, чому і до якої дати його замінять. Цей список знадобиться, коли Microsoft оголосить остаточну дату у 2027 році. Стежити, щоб пошта, форми та інтеграції сайту працювали місяць за місяцем, входить у підтримку та обслуговування сайтів, а перенесення пошти між серверами й сервісами входить у нашу роботу з DevOps і хмарної інфраструктури.

Цю дату разом з іншими строками, важливими для власників, ми ведемо в календарі технологічних строків The Structure, нашого бренду в M&A софтверних компаній. Якщо попереду продаж чи інвестор, що ця зміна означає для угоди, розібрано в нотатці Mail sent with a password: the Microsoft 365 change that reaches a deal (англійською).

FAQ

Джерела

• Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline, блог команди Exchange, січень 2026 року
• How to set up a multifunction device or application to send email using Microsoft 365, Microsoft Learn
• Authenticate an IMAP, POP or SMTP connection using OAuth, Microsoft Learn
• Manage High Volume Email for Microsoft 365, Microsoft Learn
• SMTP AUTH clients report in the Exchange admin center, Microsoft Learn