Отправка почты из 1С через Exchange Online: что проверить перед изменением SMTP AUTH в декабре 2026 года

Что меняется, а что нет

К концу декабря 2026 года Microsoft планирует отключить по умолчанию базовую аутентификацию (Basic Authentication) для протокола SMTP AUTH в Exchange Online — того способа, которым 1С, CRM, сайты и офисная техника чаще всего отправляют письма с логином и паролем почтового ящика [1]. Это не полное удаление функции: администратор сможет включить Basic Auth вручную для существующих клиентов Microsoft 365. Новые клиенты, зарегистрированные после декабря 2026 года, такой возможности по умолчанию иметь не будут — им сразу предложат только OAuth [1][2]. Точную дату полного и окончательного отказа от Basic Auth Microsoft обещает назвать во второй половине 2027 года — и это отдельное, более позднее событие, а не автоматическое следствие декабря 2026-го [1].

До конца декабря 2026 года поведение SMTP AUTH не меняется вовсе [1]. Так что технической паники нет — но есть довольно узкое окно, чтобы спокойно, без штурмовщины, разобраться, какие письма в компании реально уходят через Basic Auth, и заменить это на поддерживаемый способ.

В чём проблема и кому она касается

Проблема не в том, что «SMTP полностью запретят». Проблема в том, что многие компании даже не знают полного списка систем, которые тихо отправляют письма от имени почтового ящика на Exchange Online, используя простую пару логин/пароль. Пока это работает — про это не вспоминают. В момент, когда способ авторизации перестанет действовать по умолчанию, накопится очередь неотправленных писем: счета контрагентам, акты, уведомления клиентам, статусы заказов, оповещения от систем мониторинга.

Типичные источники такой отправки:

• 1С (Бухгалтерия, ERP, УТ, CRM, Документооборот) — отправка счетов, документов, писем по расписанию;
• CRM-системы и сайты — уведомления, подтверждения заказов, восстановление пароля;
• многофункциональные устройства и сканеры — «скан на почту»;
• самописные скрипты и сервисные задания — технические алерты, отчёты, выгрузки, часто построенные на отдельной библиотеке для отправки почты.

Общее у них то, что почти никогда никто не составлял единый список «кто и как у нас отправляет почту через Microsoft 365». Из-за этого переход часто откладывают до последнего — а «последний момент» наступит не одномоментно, а постепенно, в виде растущей доли отклонённых писем после того, как администратор тенанта (свой или иногда даже не свой — например, партнёр, управляющий подпиской) переключит настройку по умолчанию.

Что такое Basic Authentication и почему от неё уходят

SMTP AUTH — протокол, по которому приложение или устройство подключается к серверу smtp.office365.com на порту 587 и отправляет письмо от имени определённого ящика. Basic Authentication в этом протоколе означает, что приложение передаёт логин и пароль ящика напрямую при каждом подключении.

При Basic Auth отправляющая система должна иметь доступ к многократно используемому паролю. Он не обязательно хранится в открытом виде: это зависит от приложения и хранилища, а передачу защищает TLS. Риск в том, что компрометация такой учётной записи даёт повторно используемые полномочия. OAuth позволяет отказаться от пароля ящика, но токены и секреты приложения тоже нужно защищать [5][6].

Три способа SMTP-доступа: как отличить их в реальных настройках приложения

Когда вы открываете настройки конкретного приложения или устройства, там может быть один из трёх принципиально разных вариантов — и их стоит уметь различать, а не сводить всё к паре «Basic vs OAuth»:

• Basic Authentication. В настройках учётной записи явно видны логин и пароль (или их сохранённая копия), и именно эти данные передаются на сервер при каждой отправке. Это самый частый вариант в 1С, CRM и на устройствах.
• OAuth 2.0 / XOAUTH2. Приложение сначала обращается к серверу авторизации Microsoft Entra (login.microsoftonline.com) и получает временный маркер доступа (access token), а затем предъявляет его серверу SMTP в формате SASL XOAUTH2 вместо пароля [6]. В интерфейсе приложения это обычно отдельный пункт «OAuth 2.0» или «Современная аутентификация», а не поле «пароль».
• Аутентификация по IP-адресу или сертификату (SMTP relay). Пароль ящика не используется вовсе: Exchange Online проверяет, что подключение приходит с заранее прописанного статического публичного IP-адреса или с определённым TLS-сертификатом. В настройках устройства при этом обычно вообще нет поля для пароля — только адрес сервера и порт.

Проверять, что реально используется прямо сейчас, надёжнее не по описанию в инструкции вендора, а по факту — открыв карточку конкретной учётной записи в приложении и сверив её с отчётом Exchange Online, о котором ниже.

Как устроен пересмотренный график Microsoft

История этого срока — хороший повод не писать «в декабре окончательно отключат всё». Изначально отказ от Basic Auth в SMTP AUTH планировался на сентябрь 2025 года, затем срок сдвигали на март и на 30 апреля 2026 года [3][4]. 27 января 2026 года Microsoft опубликовала очередное обновление графика, объяснив это тем, что многие клиенты всё ещё не готовы, и дав дополнительное время на модернизацию [3][4]. Текущая версия плана выглядит так [1]:

• сейчас — декабрь 2026 года: поведение SMTP AUTH Basic Authentication не меняется;
• конец декабря 2026 года: Basic Authentication отключается по умолчанию для существующих клиентов; администратор может включить её вручную при необходимости;
• новые тенанты, созданные после декабря 2026 года: Basic Authentication недоступна по умолчанию, поддерживается только OAuth;
• вторая половина 2027 года: Microsoft объявит окончательную дату полного удаления Basic Authentication из SMTP AUTH.

Разница между «отключат по умолчанию» и «удалят» принципиальна. В декабре 2026 года переключатель просто встанет в положение «выключено» для тех клиентов, у которых он раньше был включён. Администратор тенанта по-прежнему сможет включить Basic Auth обратно — если он в курсе, что это нужно сделать, и осознанно принимает связанный с этим риск. Проблема в том, что многие администраторы малого и среднего бизнеса просто не читают уведомления Message Center и узнают об изменении по факту — когда письма перестают уходить.

Объявление конкретной даты окончательного удаления во второй половине 2027 года не означает, что удаление произойдёт непосредственно в этот период — Microsoft лишь обещает к этому моменту назвать точную дату, вероятно, с дополнительным сроком на подготовку. Ориентироваться стоит не на 2027 год, а на конец декабря 2026-го: именно тогда прекращается состояние «всё работает само, ничего делать не надо».

Этот план касается только Basic Authentication в SMTP AUTH Client Submission. Отключение самого EWS в Exchange Online — отдельное изменение: его не следует называть предстоящим отключением Basic Auth в EWS, для которого базовая аутентификация уже была выведена из эксплуатации. Если интеграция читает письма или синхронизирует календарь, проверяйте её протокол отдельно [5].

Российская специфика: доступность Exchange Online

Доступность Exchange Online, продления и поддержки зависит от договора, страны и ограничений поставщика. Не следует считать сохранение старой подписки гарантией дальнейшей работы. До выбора схемы отправки проверьте действующие условия для конкретной организации и доступ администратора; техническая миграция OAuth сама по себе этот вопрос не решает.

Во-первых, если компания продолжает пользоваться Exchange Online через унаследованный тенант, зарубежное юрлицо или партнёра, администрирование этой инфраструктуры — включая отслеживание сообщений Message Center и настройку OAuth — может быть на стороне внешнего провайдера, а не штатного ИТ-отдела. Стоит заранее уточнить у того, кто управляет тенантом, следит ли он за этим изменением и когда планирует отключать Basic Auth.

Во-вторых, регистрация приложения в Microsoft Entra ID для OAuth 2.0 (получение client ID и client secret) требует доступа к порталу администрирования Microsoft — доступность и удобство этого шага стоит проверить заранее, а не в последний момент.

Как инвентаризировать: отправители, почтовые ящики, библиотеки и устройства

Первый практический шаг — не трогать настройки, а понять реальную картину: кто и как сейчас отправляет почту.

Отчёт SMTP AUTH Clients в Exchange admin center

С октября 2024 года в новом Exchange admin center доступен отчёт Reports → Mail flow → SMTP AUTH clients, который показывает, какие почтовые ящики или системные учётные записи используют протокол SMTP AUTH, и в столбце типа аутентификации различает Basic Authentication и XOAUTH2, то есть OAuth [7]. По умолчанию отчёт показывает данные за последние 7 дней, при пустом результате стоит расширить период [7]. Из отчёта нужно выгрузить полный список ящиков с пометкой Basic Authentication — это рабочая инвентаризационная база.

Сверка с 1С, CRM, сайтом, устройствами — и с библиотеками внутри самописных интеграций

Отчёт покажет сам факт использования Basic Auth, но не расскажет, где именно в 1С или на сайте физически прописан этот ящик. Дальше нужна ручная сверка, и на практике удобно классифицировать каждого найденного отправителя по трём вопросам: что это за приложение или устройство, поддерживает ли оно OAuth в принципе, и кто за него отвечает [8]:

• 1С и CRM — открыть справочник «Учётные записи электронной почты» или аналогичный раздел настроек и посмотреть, какой протокол и способ авторизации указан для каждой учётной записи, задействованной в отправке документов;
• сайт — проверить настройки исходящей почты (обычно раздел «Уведомления» или «Интеграции»);
• устройства (МФУ, сканеры) — посмотреть настройки «скан на почту» в веб-панели устройства; в большинстве случаев там статический логин и пароль, и такие устройства физически не умеют работать с OAuth;
• самописные скрипты и сервисные задания — отдельная и часто упускаемая категория. Такие интеграции обычно построены на конкретной программной библиотеке для отправки почты (например, встроенный компонент платформы, сторонний пакет для отправки SMTP или готовый модуль внутри конфигурации). Библиотека может быть устаревшей и физически не поддерживать формат SASL XOAUTH2, даже если сама компания-разработчик библиотеки уже выпустила более новую версию с такой поддержкой. Поэтому для каждого самописного отправителя стоит зафиксировать в инвентаризации не только «какое приложение отправляет», но и «на какой библиотеке и её версии это сделано» — от этого зависит, можно ли перейти на OAuth обновлением библиотеки или потребуется посредник.

Какие компоненты поддерживают OAuth, а где нужны обновление библиотеки, посредник или другая схема

У Microsoft нет единого «выключателя», которым можно заменить Basic Auth на что-то одно для всех сценариев. Есть несколько параллельных, официально поддерживаемых путей [7][9].

OAuth 2.0 (client credentials) — когда приложение и его библиотека это умеют

Это прямая замена для приложений, которые способны выполнять HTTP-запросы и хранить/обновлять токены, а библиотека отправки поддерживает SASL XOAUTH2. Механика следующая [6]:

1. В Microsoft Entra регистрируется приложение, для него настраиваются разрешения на доступ к Exchange Online и выдаётся client secret (или сертификат).
2. Приложение по протоколу OAuth 2.0 client credentials обращается на login.microsoftonline.com и получает access token с областью действия https://outlook.office365.com/.default.
3. При подключении к SMTP-серверу приложение вместо пароля передаёт этот токен в формате SASL XOAUTH2.
4. Отдельно настраивается право отправки от имени конкретного ящика (SendAs) для сервис-принципала приложения — это делается через Exchange PowerShell, а не через портал Entra.

Ошибка 535 5.7.3 Authentication unsuccessful сама по себе не определяет причину. Проверяйте назначение токена, срок действия, разрешения, регистрацию service principal в Exchange, доступ к нужному ящику и настройки SMTP AUTH. Отдельный разбор ошибки [10] не доказывает, что большинство отказов вызвано RBAC. Если библиотека не поддерживает XOAUTH2, потребуется её обновление либо защищённый шлюз [6].

SMTP relay-коннектор — для устройств и легаси-систем без доработки

Для устройств, которые физически не умеют работать с OAuth (большинство МФУ, сканеров, старых встроенных SMTP-клиентов), Microsoft продолжает поддерживать релей без аутентификации на уровне логина и пароля вообще [11][12]. Вместо пароля Exchange Online проверяет, что подключение приходит со статического публичного IP-адреса устройства (либо предъявляется TLS-сертификат), заранее прописанного в специальном коннекторе входящей почты [11].

Для SMTP relay нужны подтверждённый домен, доступ по порту 25 и корректный входящий OnPremises-коннектор. По актуальным правилам допустимый домен должен определяться по SMTP-сертификату или по MAIL FROM, а IP-адрес подключения либо домен сертификата — соответствовать коннектору. Одного совпадения видимого поля From (P2) недостаточно; требование нельзя сокращать до «всегда проверяется только MAIL FROM» [12].

Такой релей хорошо закрывает сценарий «устройство отправляет письмо внутреннему сотруднику», но по умолчанию не предназначен как основной канал массовой отправки внешним получателям и требует аккуратной настройки, чтобы его не использовали для подмены внутренних адресов [12].

High Volume Email — когда подходит, а когда нет

High Volume Email (HVE) предназначен для больших потоков внутренних уведомлений от приложений и устройств. По актуальной документации HVE, внешняя доставка не поддерживается: это не небольшой лимит внешних получателей, а неподдерживаемый сценарий. Тариф, доступность в конкретном облаке и способы аутентификации проверяйте отдельно перед подключением. Для счетов внешним контрагентам выбирайте другой канал.

Для типового сценария «1С отправляет счета контрагентам» HVE не подходит: внешние адресаты не входят в поддерживаемую область. Его можно рассматривать отдельно для внутренних уведомлений, не смешивая их с письмами клиентам [14].

Microsoft Graph API и посредник — альтернатива для сложных случаев

Если приложение всё равно дорабатывается под OAuth, стоит рассмотреть отправку не по SMTP вовсе, а через HTTP-вызов Microsoft Graph API с токеном OAuth — некоторые считают это более предсказуемым в эксплуатации способом, чем связка SMTP и SASL XOAUTH2 [10]. Обратная сторона — необходимость переписать логику отправки, а не просто заменить строку авторизации в существующем SMTP-клиенте.

Если обновление самой отправляющей системы или её библиотеки затруднено, растянуто по срокам или физически невозможно (старая версия платформы, устройство без обновления прошивки), реалистичный путь — промежуточный шлюз: сервис, который принимает от системы письмо привычным для неё способом, а сам отправляет его в Exchange Online через OAuth, Graph API или через SMTP relay-коннектор. Это позволяет не трогать саму систему-источник, пока её обновление не запланировано.

Что с этим делать в 1С конкретно

Поддержка OAuth 2.0 для почтовых ящиков появилась в платформе «1С:Предприятие» начиная с версии 8.3.19 — изначально в контексте работы с Google Workspace, у которого Basic Auth для почты закрыли раньше, чем у Microsoft [16]. Позже отдельные прикладные решения — например, 1С:CRM редакции 3.0 в версии 3.1.25.9 — получили в интерфейсе настройки учётной записи явный выбор способа авторизации OAuth 2.0, описанный как более безопасный способ, не требующий хранения пароля от почты в самой программе [17].

Что важно проверить именно в вашей ситуации, а не считать само собой разумеющимся:

• версию платформы. Если используется платформа старше 8.3.19, поддержки OAuth 2.0 для почты может не быть вовсе — потребуется сначала обновление платформы;
• конкретную конфигурацию и релиз. Появление флажка «OAuth 2.0» на уровне платформы не означает автоматически, что интерфейс настройки учётной записи именно в вашей конфигурации (Бухгалтерия, УТ, ERP, Документооборот, отраслевое решение) уже это поддерживает — это добавляется отдельно в каждом прикладном решении;
• список поддерживаемых провайдеров. Подтверждённых данных о том, что штатный механизм OAuth 2.0 в 1С «из коробки» поддерживает именно Microsoft Entra / Exchange Online, а не только Google, в открытых источниках найти не удалось. Это нужно уточнять по документации на ИТС для вашего релиза, либо тестово создать учётную запись и посмотреть, предлагается ли Microsoft/Exchange Online в списке провайдеров OAuth 2.0 при настройке.

Если штатной поддержки OAuth для Microsoft в вашей конфигурации нет или обновление платформы/конфигурации в разумные сроки невозможно, реалистичные пути — доработка (написание собственной процедуры получения и обновления токена, если платформа это в принципе допускает) либо перенос отправки на промежуточный шлюз, описанный выше. Второй вариант часто практичнее, если обновление самой 1С по каким-то причинам затруднено или отложено.

Отдельно стоит проверить и внешние обработки или самописные модули, которые в некоторых компаниях используются для рассылки писем из 1С в обход штатного справочника учётных записей электронной почты. Такие модули иногда обращаются напрямую к низкоуровневым объектам платформы (например, к объекту типа «ИнтернетПочтовыйПрофиль») в обход встроенного мастера настройки [18] — а значит, могут быть построены на собственной, более старой реализации SMTP-клиента внутри встроенного языка. Это тоже нужно включить в общую инвентаризацию библиотек, а не считать частью «типовой 1С».

Как хранить и обновлять токены и секреты без передачи пароля во все системы

Одно из главных преимуществ перехода на OAuth — пароль конкретного сотрудника или общего ящика больше не хранится в базе 1С, конфигурации сайта или CRM. Но взамен появляется новый секрет — client secret (или сертификат) зарегистрированного в Entra приложения — и его тоже нужно защищать осознанно, а не переносить проблему в новое место:

• используйте отдельный сервис-принцип (учётную запись приложения) для каждой интеграции, а не один общий секрет на все системы — компрометация одной интеграции тогда не затронет остальные;
• выдавайте праву SendAs минимально необходимый набор ящиков, а не права на весь тенант;
• не храните client secret в открытом виде в коде обработки, в текстовых настройках 1С или в файле конфигурации на общем сетевом диске — используйте защищённое хранилище секретов (штатные механизмы Windows/Linux, корпоративное хранилище паролей, Azure Key Vault, если инфраструктура это позволяет);
• регулярно обновляйте (ротируйте) секрет — общая рекомендация Microsoft по работе с секретами в Key Vault — не реже раза в 60 дней, чаще при повышенных требованиях к безопасности [20]; для client secret приложения в Entra это означает заранее спланированный процесс выпуска нового секрета и обновления его в 1С или на шлюзе до истечения срока действия старого;
• если платформа поддерживает сертификаты вместо client secret — это предпочтительнее: сертификат сложнее скомпрометировать случайно, скопировав текстовую строку, чем пароль-строку [20].

Отдельно стоит заранее продумать процедуру «что делать, если секрет скомпрометирован или истёк раньше срока» — у ответственного за интеграцию сотрудника должен быть быстрый доступ к порталу Entra, чтобы отозвать старый секрет и выпустить новый, не дожидаясь, пока накопится очередь неотправленных счетов.

Как тестировать переход: очередь, повтор отправки, вложения, адрес отправителя, NDR

Переключение способа авторизации — это не «поменять пароль на токен и проверить одно тестовое письмо». Стоит прогнать полноценный сценарий, максимально приближённый к реальной эксплуатации.

• Очередь и повторная отправка. Проверьте, как 1С или шлюз ведут себя при временной недоступности OAuth-эндпоинта или истёкшем токене: письмо должно оставаться в очереди на повтор, а не теряться молча. Важно проверить обработку именно кода ошибки, а не только факт «письмо не пришло».
• Вложения. Отдельно протестируйте отправку с реальными по размеру и формату вложениями (PDF-счета, сканы, подписанные документы) — лимиты на размер сообщения при переходе на другой способ отправки (в частности, HVE или Graph API) могут отличаться от привычных для обычного SMTP AUTH.
• Адрес отправителя. Для релея проверьте выбранный способ подтверждения допустимого домена — MAIL FROM или SMTP-сертификат — и соответствие IP/сертификата коннектору. Отдельно испытайте отчёты о недоставке с пустым MAIL FROM [12].
• NDR и коды ошибок. В согласованной тестовой среде проверьте постоянный отказ, временный сбой и отчёт о недоставке. Постоянный код 5xx не нужно бесконечно повторять без исправления причины, но письмо должно остаться в журнале или очереди ручного разбора, а не удаляться. Принятие сообщения сервером ещё не подтверждает доставку адресату [19].

Как настроить предупреждение об отказе аутентификации

Самый неприятный сценарий — не резкая остановка всей отправки, а медленно растущая доля «тихо не отправленных» писем: часть счетов уходит, часть — оседает в очереди из-за истёкшего токена или пропущенного администратором переключения настройки, и это может остаться незамеченным неделями, если ответственный сотрудник не проверяет очередь вручную каждый день.

Практический минимум для контроля:

• настройте в 1С (или в шлюзе, если он используется) фоновую проверку исходящей очереди с оповещением ответственного сотрудника — по внутренней почте на другой домен, в мессенджер или системному администратору, — если в очереди появляются письма старше заданного порога времени (например, 30–60 минут) или письма с зафиксированным кодом ошибки аутентификации;
• регулярно, не реже раза в месяц, пока идёт переходный период, сверяйтесь с отчётом SMTP AUTH Clients в Exchange admin center — рост доли Basic Authentication там, где вы ожидали увидеть только OAuth, сигнализирует о забытой интеграции или откате настройки [7];
• для критичных потоков (счета контрагентам, юридически значимые уведомления) имеет смысл параллельно логировать факт успешной отправки на стороне самой 1С, а не полагаться только на отсутствие видимых ошибок в интерфейсе.

Практический результат: карта отправителей и план перехода

По итогам работы у вас должны появиться два конкретных артефакта.

1. Карта автоматических отправителей — по каждому найденному отправителю фиксируется:

• система или устройство;
• почтовый ящик, от имени которого идёт отправка;
• способ авторизации сейчас (Basic Auth, OAuth, IP/сертификат);
• библиотека и её версия — если это самописная интеграция;
• поддерживает ли OAuth в принципе (да / нет / нужно уточнить у вендора);
• ответственный за эту систему сотрудник или подрядчик.

Источники для заполнения — отчёт SMTP AUTH Clients report [7] плюс ручная сверка настроек 1С, CRM, сайта и устройств.

2. План перехода — для каждой строки карты определён один из вариантов:

• перевод на OAuth 2.0 (если приложение и библиотека это поддерживают, или после обновления версии);
• перевод на SMTP relay-коннектор по статическому IP/сертификату (для устройств без возможности доработки);
• вывод отправки через промежуточный шлюз (если обновление системы-источника невозможно в разумные сроки);
• отдельно — решение по HVE, если параллельно стоит задача внутренней массовой рассылки, с пониманием, что это не замена для писем внешним контрагентам [13].

К плану добавляется дата пилота, дата контрольного теста (очередь, вложения, NDR) и настроенное оповещение об ошибках аутентификации — до конца декабря 2026 года.

Ограничения, ошибки и риски

• Не стоит воспринимать декабрь 2026 года как жёсткий обрыв — это переключение значения по умолчанию, которое администратор может временно откатить; но полагаться на это как на постоянную стратегию небезопасно и противоречит цели самого изменения.
• Частая ошибка — тестировать OAuth-интеграцию на тестовом ящике с правами администратора и не проверить, что права SendAs корректно выданы именно для рабочего сервис-принципала на рабочих ящиках.
• Ошибка 535 5.7.3 требует проверки токена, разрешений, service principal и настроек SMTP AUTH, а не автоматического вывода о конкретной причине по одному коду [6].
• Не все устройства, версии 1С и самописные библиотеки можно перевести на OAuth без внешней доработки — для части парка это будет релей или шлюз, а не «просто поставить галочку».
• HVE поддерживает только внутренних получателей тенанта. Не используйте его как канал счетов и документов внешним контрагентам; проверьте отдельный маршрут отправки [14].

Вывод

У вас есть время примерно до конца 2026 года, чтобы разобраться с этим спокойно, а не в режиме аврала. Первый и самый важный шаг — не «настроить OAuth прямо сейчас», а построить честную карту: кто в компании реально отправляет почту через Exchange Online, каким способом, через какую систему и на какой библиотеке это построено. Дальше для каждого отправителя находится свой путь — OAuth, релей или посредник — и переход тестируется на реальных сценариях, включая обработку ошибок и вложений, а не только на факте «письмо дошло один раз». Отдельно стоит настроить оповещение о тихом застревании писем в очереди — это дешевле сделать заранее, чем разбирать, почему контрагент неделю не получал счета.

Источники

[1] techcommunity.microsoft.com — Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline — https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835

[2] mc.merill.net — MC786329 — Exchange Online to retire Basic Auth for Client Submission (SMTP AUTH) — https://mc.merill.net/message/MC786329

[3] techcommunity.microsoft.com — Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) — https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750

[4] innovia.com — Microsoft to Retire Basic Auth SMTP for Exchange Online: What Business Central & NAV Users Need to Know — https://www.innovia.com/blog/microsoft-to-retire-basic-auth-smtp-for-exchange-online-what-bc-nav-users-need-to-know

[5] learn.microsoft.com — Прекращение поддержки обычной проверки подлинности в Exchange Online — https://learn.microsoft.com/ru-ru/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

[6] learn.microsoft.com — Authenticate an IMAP, POP or SMTP connection using OAuth — https://learn.microsoft.com/ru-ru/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

[7] learn.microsoft.com — SMTP AUTH clients report in the new EAC in Exchange Online — https://learn.microsoft.com/en-us/exchange/monitoring/mail-flow-reports/mfr-smtp-auth-clients-report

[8] tiagoscarvalho.com — SMTP AUTH Basic Auth Migration in Exchange Online: OAuth, Relay, HVE or Graph API — https://www.tiagoscarvalho.com/exchange-online/smtp-basic-auth-migration

[9] captaindns.com — Exchange Online SMTP Basic Auth end: OAuth migration — https://www.captaindns.com/en/blog/microsoft-exchange-basic-auth-smtp-end

[10] learn.microsoft.com — SMTP AUTH with OAuth 2.0 Client Credentials Flow returns 535 5.7.3 despite complete configuration per official docs — https://learn.microsoft.com/en-au/answers/questions/5872803/smtp-auth-with-oauth-2-0-client-credentials-flow-r

[11] cloudcoffee.ch — Configure Exchange Online SMTP Relay with a Static Public IP Address — https://www.cloudcoffee.ch/microsoft-365/exchange-online-smtp-relay-public-ip/

[12] learn.microsoft.com — Updated requirements for SMTP relay through Exchange Online — https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/updated-requirements-smtp-relay

[13] petri.com — High Volume Email to Restrict Email Delivery to Internal Recipients — https://petri.com/high-volume-email-delivery-internal-recipients/

[14] learn.microsoft.com — Управление большим объёмом Email для Microsoft 365 — https://learn.microsoft.com/ru-ru/exchange/mail-flow-best-practices/high-volume-mails-m365

[15] mc.merill.net — MC1243552 — High Volume Email for Microsoft 365 now generally available — https://mc.merill.net/message/MC1243552

[16] wonderland.v8.1c.ru — Поддержка OAuth-2 при доступе к почтовым ящикам — https://wonderland.v8.1c.ru/blog/podderzhka-oauth-2-pri-dostupe-k-pochtovym-yashchikam/

[17] 1crm.ru — 1С:CRM редакция 3.0, версия 3.1.25.9 — https://1crm.ru/news/10442/

[18] kvant-c.ru — Настройка почты в 1С: рассылки, шаблоны писем, автоматизация — https://kvant-c.ru/faq/1c-pochta-nastroyka/

[19] learn.microsoft.com — Отчёты о недоставке электронной почты (NDR) и ошибки SMTP в Exchange Online — https://learn.microsoft.com/ru-ru/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online

[20] learn.microsoft.com — Защита секретов Azure Key Vault — https://learn.microsoft.com/ru-ru/azure/key-vault/secrets/secure-secrets

[21] allsoft.ru — Microsoft Office: какие офисные программы можно купить в России в 2026 году — https://allsoft.ru/news-soft/kak-prodlit-litsenziyu-microsoft-365-2025/