Адреса почтовых серверов: критерии выбора и настройки

Проблема проявляется позже: часть писем уходит в spam, Gmail отклоняет транзакцию, SPF возвращает permerror, а миграция на новый MTA оставляет половину домена на старом маршруте.

Адреса почтовых серверов — это не поле «сервер входящей почты» в настройках Outlook. Это связка DNS, FQDN, IP, PTR, TLS, SMTP Submission, IMAP и политик аутентификации домена. Ошибка в любом звене ломает доставку либо создаёт канал для подмены отправителя.

Разделите входящий маршрут, исходящую отправку и доступ пользователей

Сначала зафиксируйте архитектуру. В корпоративной почте обычно смешивают три разных задачи:

1. Приём внешней почты. За него отвечают MX-записи домена. Внешний MTA ищет MX и доставляет сообщение на указанный FQDN по TCP/25.

2. Исходящая отправка. Пользовательский клиент или приложение передаёт письмо на SMTP Submission-сервер. Обычно это TCP/587 с STARTTLS либо TCP/465 с неявным TLS.

3. Доступ к ящику. Клиент читает почту по IMAP, обычно на TCP/993. POP3 допустим, но для корпоративной схемы почти всегда проигрывает IMAP.

Не подменяйте эти роли одной записью mail.example.ru без понимания, куда она ведёт. Один FQDN может обслуживать несколько функций, но DNS и сертификаты должны отражать это явно.

Порт 25 не является портом пользовательской отправки. Это межсерверный SMTP. На нём часто запрещена аутентификация, а у провайдеров и облачных сетей нередко ограничен исходящий трафик. Настройте клиентскую отправку через 587. Поддержите 465, если это требуется парком клиентов или провайдером. Для обоих вариантов используйте TLS не ниже 1.2.

MX отвечает только за входящую доставку. Он не делает исходящие письма доверенными и не настраивает SMTP Submission.

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

Вопрос «как узнать адрес почтового сервера» не решается поиском универсального smtp.domain.com. Готовых адресов для всех доменов не существует. Значения зависят от выбранной схемы:

• собственный Postfix, Exim или Exchange;
• облачная почта;
• хостинговая почта;
• отдельный relay для транзакционных писем;
• платформа рассылок;
• гибридная схема с локальным MTA и облачными ящиками.

Начните не с панели почтового клиента, а с инвентаризации. Зафиксируйте все источники, которые отправляют почту от имени домена: пользовательские ящики, CRM, ERP, сайт, helpdesk, сканеры, мониторинг, CI/CD, сервисы рассылок. У каждого источника свой SMTP endpoint, свой IP или пул IP, свой метод DKIM-подписи.

Для собственного сервера минимальная схема обычно выглядит так:

• mx1.example.ru — имя принимающего MTA;
• A и при необходимости AAAA для mx1.example.ru;
• MX домена example.ru, указывающий на mx1.example.ru;
• PTR для внешнего IP, согласованный с именем MTA;
• сертификат TLS, содержащий имя SMTP-хоста;
• отдельный FQDN, например submission.example.ru, для клиентской отправки, если роли разделены;
• imap.example.ru для IMAPS, если доступ к ящикам не организован через единый hostname.

Не обязательно создавать отдельное имя на каждую роль. Но не экономьте на разделении там, где оно упрощает диагностику, сертификаты и ACL. SMTP relay приложения и пользовательский Submission лучше не смешивать на одном анонимном входе без ограничений.

У облачного провайдера адреса серверов берите только из его актуальной документации или из административной панели. Не копируйте MX-цели, include: в SPF и Autodiscover-записи из чужого домена. Особенно опасны старые инструкции с адресами, оставшимися после миграции или смены тарифа.

Для команды, которая строит инфраструктуру на ранней стадии, почта не должна выпадать из технической оценки проекта: наряду с unit-экономикой и рынком полезно сверять критерии оценки студенческих стартапов инвесторами с реальными эксплуатационными рисками — доменом, репутацией IP и зависимостью от внешних сервисов.

MX-записи: порядок, резервирование и запрет на CNAME

MX — это маршрут до получателя. Число в MX-записи задаёт приоритет: меньшее значение означает более высокий приоритет.

Пример логики:

Отправляющий сервер сначала пытается доставить письмо на mx1.example.ru. При временной недоступности он переходит к следующей релевантной цели. Резервный MX не должен быть фиктивной записью, ведущей на тот же IP, тот же хост и ту же зону отказа. Иначе это не резервирование, а дублирование DNS.

Цель MX должна быть каноническим именем хоста. Не указывайте CNAME.

Неверная схема:

• example.ru MX 10 mail.example.ru
• mail.example.ru CNAME provider.example.net

Корректная схема требует, чтобы mail.example.ru имел собственную A/AAAA-запись либо чтобы MX указывал непосредственно на допустимое каноническое имя, предоставленное оператором почты. CNAME в цели MX нарушает правила DNS для почтовой маршрутизации и создаёт несовместимость между MTA.

Отсутствие MX не означает, что домен гарантированно не принимает почту. По стандартной SMTP-процедуре отправляющий сервер может попытаться обратиться к A или AAAA записи самого домена. Это часто становится неожиданностью для доменов, которые используются только для сайта.

Если домен сознательно не должен принимать письма, публикуйте Null MX:

• приоритет 0;
• целевое значение .;
• никаких других MX-записей.

Не используйте такой домен в From или envelope sender. Null MX сообщает принимающим системам, что домен не обслуживает почту. Отправка с него создаст предсказуемые проблемы с доставкой и проверками.

TTL выбирайте под режим изменений, а не по шаблону из чужой инструкции. Значение 3600 секунд часто встречается в примерах облачных провайдеров, но не является универсальной нормой. Перед миграцией уменьшите TTL заранее, после стабилизации верните значение, соответствующее вашей политике DNS-кэширования и допустимому времени переключения.

SMTP, IMAP и PTR: адрес сервера должен подтверждаться с обеих сторон

Корректный FQDN сам по себе не даёт репутацию. Получающий MTA сопоставляет несколько признаков:

• IP-адрес, с которого установлено SMTP-соединение;
• PTR этого IP;
• имя, которое сервер сообщает в EHLO или HELO;
• A/AAAA-запись имени из PTR;
• TLS-сертификат и имя, к которому подключается клиент;
• SPF, DKIM и DMARC домена отправителя.

Настройте прямое и обратное разрешение согласованно. Если внешний IP 203.0.113.10 имеет PTR smtp1.example.ru, то smtp1.example.ru должен резолвиться обратно в 203.0.113.10. Желательно, чтобы это же имя использовалось в приветствии SMTP и было покрыто сертификатом.

Не выдавайте динамический, общий или неуправляемый IP за сервер исходящей корпоративной почты. PTR на имя провайдера, не связанное с вашим MTA, не всегда означает блокировку. Но это лишний отрицательный сигнал, особенно при новой репутации IP.

Для пользовательских клиентов применяйте следующие параметры:

1. Укажите FQDN, который присутствует в сертификате. Не подставляйте голый IP-адрес вместо имени сервера.

2. На TCP/587 включите STARTTLS до SMTP AUTH. Не допускайте аутентификацию в открытом соединении.

3. На TCP/465 используйте неявный TLS с начала соединения.

4. На IMAP включите TLS на 993. Не оставляйте plaintext-доступ на 143 без отдельной причины и строгого STARTTLS.

5. Запретите relay для неаутентифицированных клиентов. Исключение — явно ограниченные сети, внутренние шлюзы и сервисные сценарии с ACL.

6. Разделите учётные данные пользователей и учётные данные приложений. У приложения должен быть отдельный SMTP credential, лимиты и журналирование.

POP3 и IMAP решают разные задачи. POP3 загружает письма локально и исторически ориентирован на простую модель одного клиента. IMAP работает с состоянием ящика на сервере: папки, флаги, поиск, несколько устройств. Для бизнес-почты IMAP обычно является рабочим вариантом. POP3 оставляйте только там, где его требует устаревшая интеграция.

SPF, DKIM и DMARC: адрес отправки без аутентификации не считается настроенным

С 1 февраля 2024 года Gmail требует от всех отправителей писем на личные аккаунты Gmail SPF или DKIM, корректные прямые и обратные DNS-записи для отправляющего домена либо IP, а также TLS при передаче. Для массовых отправителей требования жёстче.

Если объём превышает 5 000 сообщений в сутки на личные ящики Gmail, потребуются:

• SPF и DKIM одновременно;
• DMARC минимум с p=none;
• выравнивание домена в From со SPF или DKIM;
• one-click unsubscribe для маркетинговых и подписных писем;
• спам-рейт ниже 0,30% в Gmail Postmaster Tools.

Не трактуйте SPF как разрешение «всему, что отправляет почту». SPF проверяет конкретный домен envelope sender и IP или hostname отправляющего узла. Заголовок From, который видит пользователь, может не совпадать с Return-Path. Поэтому SPF без DKIM и DMARC не защищает видимый адрес бренда от всех сценариев подмены.

Отдельная проблема — лимит DNS lookups. SPF допускает не более 10 механизмов или модификаторов, которые вызывают DNS-запросы при вычислении. Типовая авария выглядит так: маркетинговая платформа добавляет include, затем CRM, затем helpdesk, потом сервис транзакционных уведомлений. Визуально TXT-запись корректна. На проверке получается permerror.

Не добавляйте include: по инерции. Постройте карту источников. Удалите неиспользуемые сервисы. Консолидируйте отправку через relay, если архитектура это допускает. Проверяйте не только текст SPF, но и фактическое число lookup по всем вложенным include, redirect, a, mx и exists.

SPF с одиннадцатым DNS-запросом не «почти работает». Для получателя это permerror.

DKIM решает другую часть задачи. Он подписывает содержимое письма и выбранные заголовки. Для каждого отправляющего сервиса назначайте отдельный selector. Не публикуйте одну DKIM-ключевую запись для всех подряд платформ, если затем невозможно определить источник подписи и безопасно выполнить ротацию.

DMARC объединяет SPF и DKIM вокруг домена в From. Он задаёт политику обработки неаутентифицированных писем и отправляет агрегированные отчёты на указанный адрес. Актуальная спецификация — RFC 9989, опубликованный в мае 2026 года вместо RFC 7489.

Внедряйте DMARC по данным, а не по убеждению

Политика p=reject без инвентаризации источников отправки блокирует легитимную почту. Особенно уязвимы рассылки через внешние платформы, пересылки и mailing lists. Сервис может корректно подписывать письмо своим DKIM-доменом, но не пройти alignment с вашим From.

Рабочая последовательность выглядит так:

1. Опубликуйте DMARC с p=none и адресом для агрегированных отчётов rua.

2. Собирайте отчёты не меньше месяца. Выделите все IP, селекторы DKIM и envelope-домены.

3. Сопоставьте каждый источник с владельцем: корпоративный MTA, CRM, сервис биллинга, сайт, кадровая система, подрядчик.

4. Настройте SPF и DKIM для легитимных источников. Добейтесь alignment хотя бы по одному механизму.

5. Устраните неизвестные источники. Не добавляйте их в SPF, пока не установлен владелец и цель отправки.

6. Переведите политику на p=quarantine минимум на сопоставимый период наблюдения.

7. Только после стабильных отчётов и проверки критичных потоков рассмотрите p=reject.

Не используйте pct как замену анализа. Частичное применение политики может снизить радиус ошибки, но не исправляет неучтённый источник. Реальная защита начинается с полного списка систем, имеющих право писать From: @example.ru.

Типовые ошибки при смене почтового провайдера

Миграция часто ломается не на переносе ящиков, а в DNS и исходящей аутентификации.

Первая ошибка — оставить старые MX после переключения. Часть внешних MTA продолжает доставлять на прежний сервер. Там письма могут приниматься в неиспользуемый ящик, отклоняться или становиться очередью, которую никто не контролирует. После перевода входящего маршрута удалите MX, ведущие на старую систему, если гибридная схема не требует их сохранения.

Вторая — поменять MX и забыть про исходящую отправку. Пользователи начинают работать через новый облачный сервис, а сайт продолжает слать с прежнего IP без PTR, DKIM и актуального SPF. В результате письма «от того же домена» получают разную репутацию и разные результаты проверок.

Третья — назначить один публичный IP всем ролям без ограничений. На нём оказываются пользовательский SMTP, relay приложений, тестовые уведомления и массовая рассылка. Жалоба на рассылку бьёт по доставке счетов и переписки сотрудников. Разделяйте потоки хотя бы логически: разными SMTP credentials, DKIM selectors, envelope-доменами и лимитами. При достаточном объёме — разными IP и поддоменами.

Четвёртая — считать DNS-панель источником истины. Она показывает опубликованные значения, но не отвечает на вопросы: какой MTA реально принимает почту, какой IP отправляет сообщения, какой сертификат отдан на порту 587, проходит ли DKIM после модификации письма на relay. Проверяйте цепочку снаружи.

Консольная последовательность для диагностики

Перед вводом домена в эксплуатацию и после любого изменения маршрута выполните этот минимум:

1. Проверьте MX: dig MX example.ru +short. Убедитесь, что цели не являются CNAME и приоритеты соответствуют схеме.

2. Проверьте адреса MX-целей: dig A mx1.example.ru +short и при необходимости dig AAAA mx1.example.ru +short.

3. Проверьте обратную запись внешнего IP: dig -x 203.0.113.10 +short.

4. Сверьте прямое и обратное разрешение имени из PTR.

5. Проверьте SMTP на 25 с внешней сети: openssl s_client -starttls smtp -connect mx1.example.ru:25.

6. Проверьте Submission: openssl s_client -starttls smtp -connect submission.example.ru:587.

7. Проверьте неявный TLS на 465: openssl s_client -connect submission.example.ru:465.

8. Проверьте IMAPS: openssl s_client -connect imap.example.ru:993.

9. Получите SPF: dig TXT example.ru +short. Посчитайте фактические DNS lookup, включая вложенные include.

10. Получите DKIM по каждому selector: dig TXT selector1._domainkey.example.ru +short.

11. Получите DMARC: dig TXT _dmarc.example.ru +short.

12. Отправьте тест на внешний ящик и разберите заголовки: Received, SPF, DKIM, DMARC, TLS, IP отправителя, envelope sender.

Адреса почтовых серверов выбирают не по привычному имени mail. и не по строке из старой инструкции. Начните с маршрутов и ролей. Затем закрепите FQDN, DNS, PTR, TLS и аутентификацию. После этого настройте клиентские порты и проверьте реальную SMTP-транзакцию. Почтовая инфраструктура считается собранной только тогда, когда вся цепочка подтверждается снаружи.