термин · настройки smtp office 365

Что такое настройки SMTP Office 365 и как они влияют на почту приложения?

Параметры SMTP Office 365 — это не один универсальный хост и пароль. Microsoft документирует несколько вариантов для приложений и устройств: аутентифицированную отправку клиента через smtp.office365.com, SMTP-релей на основе коннектора через MX-эндпоинт тенанта и Direct Send внутренним получателям Microsoft 365. Они различаются аутентификацией, TLS, портами, адресом отправителя, поддержкой внешних получателей, лицензированием, лимитами и административной настройкой. Выбирайте вариант по рабочей нагрузке и границе доверия, используйте OAuth там, где применяется отправка клиента, включайте SMTP AUTH ограниченно, проверяйте точные идентификаторы конверта и From и считайте принятие реле отдельным от окончательной доставки или попадания во «Входящие».

Параметры SMTP Office 365 описывают несколько маршрутов

Документация Microsoft 365 и Office 365 различает клиентскую отправку по SMTP, ретрансляцию SMTP и Direct Send. При клиентской отправке аутентификация выполняется от имени почтового ящика Exchange Online, а отправка идёт через smtp.office365.com. При ретрансляции SMTP приложение или устройство рассматривается как почтовый сервер организации, а соединение аутентифицируется входящим коннектором. Direct Send анонимно отправляет письма на MX-эндпоинт Microsoft 365 тенанта для получателей внутри организации. За похожими SMTP-командами стоят операционно разные продукты. Не копируйте имя хоста и порт с форума, не решив, какой маршрут вам нужен. Сначала зафиксируйте тенанта, принятые домены, администратора, нагрузку, адреса отправителей, исходную сеть, круг получателей, метод аутентификации, политику TLS, объём и ответственного за сбои. SMTP-транспорт не авторизует исходное бизнес-событие, не подтверждает согласие получателя и не делает очередь приложения надёжной.

Настройки клиентской отправки по SMTP

Актуальное руководство Microsoft по настройке указывает smtp.office365.com как DNS-имя для клиентской отправки и предписывает не подставлять вместо него IP-адрес. Рекомендуется TCP-порт 587, порт 25 допускается в документированном сценарии, а TLS 1.2 или TLS 1.3 с включённым STARTTLS обязателен. Приложение аутентифицируется как лицензированный почтовый ящик Microsoft 365 или Office 365 и может отправлять письма внутренним и внешним получателям в пределах документированных лимитов. Используйте адрес почтового ящика как явный адрес отправителя и тестируйте права Send As, если видимый From отличается. Храните учётные данные или токены в менеджере секретов на стороне сервера. Успешный вход в аккаунт не доказывает, что видимый From разрешён, что получатель действителен или что письмо попадёт во «Входящие». Клиентская отправка — это маршрут, привязанный к почтовому ящику, поэтому блокировка пользователя, изменение лицензии, решения условного доступа и настройки SMTP AUTH могут прервать работу приложения, в котором ничего не менялось.

Используйте OAuth и включайте SMTP AUTH точечно

Microsoft рекомендует современную аутентификацию (Modern authentication) с OAuth для клиентской отправки по SMTP. Её документация по OAuth определяет область SMTP.Send и формат SASL XOAUTH2, а делегированные потоки и потоки для приложений требуют регистрации в Microsoft Entra и разрешений Exchange. Считайте токены доступа и обновления секретами, запрашивайте только необходимые разрешения, проверяйте привязку к тенанту и почтовому ящику, проводите ротацию учётных данных приложения и удаляйте неиспользуемые разрешения. Microsoft также рекомендует отключить SMTP AUTH для организации Exchange Online и включать его только для почтовых ящиков, которым он всё ещё нужен. Существуют и настройка на уровне организации, и переопределение для отдельного почтового ящика, причём настройка почтового ящика может иметь приоритет. Параметры безопасности по умолчанию (Security defaults) отключают SMTP AUTH. Не отключайте базовые настройки безопасности для всего тенанта только ради сохранения одного устаревшего устройства. Если нагрузка не может выполнить требования OAuth и TLS, отдайте предпочтение коннектору, поддерживаемому современному клиенту, локальному релею или другому документированному сервису.

Лимиты клиентской отправки влияют на архитектуру приложения

Актуальное сравнение Microsoft документирует ограничения клиентской отправки по SMTP: 10 000 получателей в день и 30 писем в минуту. Считайте их текущими лимитами сервиса, которые могут измениться и взаимодействовать с другими лимитами Exchange Online. Считайте получателей, а не только письма — с учётом To, Cc, Bcc, повторов и рассылки нескольким адресатам. Настройте в приложении ограничения скорости, справедливого распределения между тенантами, параллелизма, числа попыток и времени в очереди ниже потолка сервиса. Общий почтовый ящик может создавать конкуренцию между людьми и автоматикой, а одни учётные данные, используемые многими приложениями, скрывают владельца. Отслеживайте запас по скорости и числу получателей, но никогда не обходите лимит, чередуя почтовые ящики или домены отправителя. Если нагрузка регулярно приближается к лимитам отправки почтового ящика, рассмотрите по актуальным рекомендациям Microsoft ретрансляцию через коннектор, High Volume Email для подходящего внутреннего трафика, Azure Communication Services Email для доставки из приложений или другой специализированный транспорт.

Настройки ретрансляции SMTP через коннектор

Ретрансляция SMTP в Microsoft 365 использует MX-эндпоинт тенанта, а не smtp.office365.com, и входящий коннектор, идентифицирующий систему отправки организации. Microsoft рекомендует аутентифицировать коннектор с помощью TLS-сертификата; другой документированный способ идентификации — публичный статический IP-адрес. Приложение подключается по TCP-порту 25 и может отправлять письма с адресов в принятом домене без лицензированного почтового ящика для каждого отправителя. Этот сценарий подходит для контролируемых почтовых серверов, устройств или шлюзов со стабильными сертификатами и понятным владельцем сети. Он требует больше администрирования: область действия коннектора, жизненный цикл сертификата, смена публичных IP-адресов, обратный DNS, политика принятых доменов, предотвращение злоупотреблений и мониторинг чёрных списков. Никогда не создавайте открытый релей. Ограничьте, какие внутренние системы, тенанты, отправители, получатели и классы писем принимает шлюз. Коннектор распознаёт соединение как исходящее от организации; он не проверяет, что произвольные входные данные приложения легитимны.

Direct Send — доставка внутренним получателям, а не универсальный релей

Direct Send отправляет письма на MX-эндпоинт тенанта как внешний SMTP-сервер, без аутентификации от имени почтового ящика или коннектора. Microsoft документирует его для доставки получателям внутри организации Microsoft 365 или Office 365, а не как маршрут на произвольные внешние адреса. Устройству или приложению нужен доступ к TCP-порту 25, и оно должно использовать отправителя в принятом домене. Поскольку с точки зрения сервиса, обращённого в интернет, этот путь анонимный, важны репутация отправителя, DNS, исходный IP-адрес и решения защиты от подделки. Не открывайте шлюз Direct Send для недоверенных сетей и не используйте его для обхода аутентификации почтового ящика. Продумайте отчёты о недоставке и ответственность поддержки, потому что принтер или приложение могут не уметь безопасно принимать сообщения об отказах (bounce). Если нужна доставка внешним получателям, после оценки идентификации и объёма выберите клиентскую отправку, ретрансляцию через коннектор, Azure Communication Services Email или другой поддерживаемый метод.

Разделяйте адрес в конверте, видимый From и аутентификацию

Каждый маршрут передаёт SMTP-конверт с командами отправителя и получателей, а также видимые заголовки по RFC 5322. Отправитель конверта определяет, куда приходят транспортные отказы, и часто служит идентификатором для SPF; видимый From определяет, что видят читатели, и является основным идентификатором для DMARC. Аутентификация почтового ящика через OAuth, идентификация коннектора или приём по исходному IP-адресу не создают автоматически выравнивание SPF, DKIM или DMARC для каждого собственного домена From. Составьте перечень точных значений MAIL FROM, From, Reply-To, домена DKIM d= и селектора, а также подключающегося IP-адреса на контрольных полученных образцах. Опубликуйте одну действительную политику SPF для соответствующего домена, настройте подпись DKIM там, где она поддерживается, и оцените выравнивание DMARC. Не добавляйте вторую SPF-запись и не ослабляйте политику DMARC организации ради одного устройства. Разделяйте в моделях статусов приём Microsoft, приём сервером назначения, последующий отказ, фильтрацию в почтовом ящике, попадание во «Входящие» и действия человека.

Реализуйте надёжную границу приложения

Размещайте SMTP Microsoft 365 за авторизованным серверным воркером или контролируемым релеем. Сохраняйте бизнес-событие до подключения, включая стабильный ключ идемпотентности, тенанта, класс писем, ревизию шаблона, одобренных отправителя и получателей, основание (согласие или необходимость), статус стоп-листа и историю попыток. Применяйте правила для отправителей и получателей каждого тенанта до формирования SMTP-команд. Ограничивайте размер письма, число адресатов, вложения и значения заголовков. Храните токены, пароли, закрытые ключи сертификатов и администрирование коннекторов вне исходного кода, логов, аналитики, тикетов и промптов. Задавайте конечные тайм-ауты и, используя полную расширенную диагностику и рекомендации Microsoft, классифицируйте ответы 4xx как кандидатов на ограниченный повтор, а ответы 5xx — как постоянные для данной попытки. Разрыв соединения после DATA, но до итогового ответа, неоднозначен: сохраните попытку и сверьте её результат, прежде чем отправлять повторно. У SMTP нет гарантии «ровно один раз» на уровне продукта.

Протестируйте конфигурацию и сценарии сбоев до внедрения

Используйте выделенных контролируемых получателей и исходную сеть, повторяющую продакшен. Проверьте разрешение DNS, доступность порта, согласование STARTTLS, имя хоста и цепочку сертификата, получение токена OAuth и его область, настройки SMTP AUTH для организации и почтового ящика, авторизацию Send As, сопоставление коннектора, принятые домены и выбор MX-эндпоинта. Отправьте образцы с обычным текстом, HTML, вложением, Unicode, отказом и ожидаемым объёмом. Фиксируйте исходные заголовки, доверенные Authentication-Results, SMTP-ответы, идентификаторы трассировки и данные трассировки сообщений, не храня содержимое клиентов. Негативные тесты должны охватывать отозванные токены, просроченные сертификаты коннектора, изменённый публичный IP-адрес, отключённый SMTP AUTH для почтового ящика, Security defaults, недействительный From, внешнего получателя через Direct Send, поминутные лимиты и лимиты получателей, временную отсрочку, постоянное отклонение и потерю соединения в районе DATA. Отрепетируйте приостановку нагрузки и перенос надёжно сохранённых задач без обхода постоянных ошибок политики или получателей.

Используйте актуальные рекомендации Microsoft и протестируйте своего тенанта

Конфигурация SMTP Microsoft 365 зависит от политик тенанта, идентификаторов, коннекторов и сетевого окружения. Используйте актуальную документацию Microsoft Learn и протестируйте выбранный маршрут в своём тенанте, прежде чем полагаться на него для продакшен-почты.

Частые вопросы

Какое имя хоста SMTP для клиентской отправки в Microsoft 365?

Сейчас Microsoft документирует smtp.office365.com для аутентифицированной клиентской отправки и рекомендует использовать DNS-имя, а не фиксированный IP-адрес сервиса.

Какой порт использовать для клиентской отправки по SMTP?

Microsoft рекомендует TCP-порт 587 и документирует порт 25 для поддерживаемого сценария клиентской отправки; STARTTLS и TLS 1.2 или TLS 1.3 обязательны.

Поддерживает ли клиентская отправка в Microsoft 365 OAuth?

Да. Microsoft рекомендует OAuth и документирует область SMTP.Send и SASL XOAUTH2. Регистрация в тенанте, разрешения, хранение токенов и привязка к почтовому ящику всё равно требуют аккуратной настройки.

Чем ретрансляция SMTP отличается от Direct Send?

Ретрансляция через коннектор аутентифицирует почтовую систему организации и может поддерживать внешних получателей. Direct Send использует MX-эндпоинт тенанта без такого коннектора и предназначен для внутренних получателей.

Нужно ли включать SMTP AUTH для каждого почтового ящика?

Нет. Microsoft рекомендует отключить его на уровне организации и включать только для почтовых ящиков, которым он всё ещё нужен, отдавая предпочтение современной аутентификации и поддерживаемым альтернативам.

Означает ли приём письма SMTP Office 365 доставку во «Входящие»?

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

Может ли приложение использовать порт 465 для клиентской отправки Microsoft?

Согласно актуальному руководству Microsoft, устройство, использующее по умолчанию порт 465, не поддерживает версии TLS, необходимые для клиентской отправки по этому маршруту Microsoft 365.

Где следует проверять конфигурацию SMTP Microsoft 365?

Используйте актуальную документацию Microsoft Learn и протестируйте выбранный маршрут в своём тенанте, прежде чем полагаться на него для продакшен-почты.