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