Проверка SMTP-сервера

Что здесь на самом деле происходит

Открывается тот же разговор, который открыл бы любой другой почтовый сервер. Соединиться, прочитать приветствие, поздороваться, посмотреть на объявленные возможности и, если сервер предлагает шифрование, поднять его и рассмотреть сертификат.

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

Три имени, которые обязаны сойтись

Эта находка удивляет чаще прочих, потому что не имеет отношения к записям, на которые был потрачен вечер.

Когда сервер соединяется, получатель знает наверняка одно: адрес, с которого пришло соединение. Он разрешает этот адрес в обратной зоне, получает имя и разрешает имя вперёд, чтобы увидеть, ведёт ли оно обратно. И то и другое он сверяет с именем, которым отправитель назвался в HELO. Три значения, и предполагается, что они описывают одну машину.

• PTR нет вовсе — изрядная часть получателей отклоняет соединение сразу, до всякой аутентификации.
• PTR есть, но не разрешается обратно — направить имя на адрес может кто угодно, а обратную запись делает только владелец адреса. Если прямой запрос не возвращает тот же адрес, имя ничего не подтверждает.
• HELO расходится с PTR — обычный результат настройки по умолчанию, когда сервер объявляет внутреннее имя вроде localhost.localdomain или идентификатор контейнера.

Привести это в порядок несложно: одна запись PTR у владельца адреса, одно имя в конфигурации почтового сервера и A-запись, связывающая их. Сложность в том, что со стороны DNS-проверок этого не видно, и потому оно переживает множество в остальном аккуратных настроек.

Шифрование и что должен уметь сертификат

Почта между серверами использует оппортунистический TLS: отправитель спрашивает, доступно ли шифрование, и пользуется им, если доступно. Сертификат при этом обычно не проверяется — поэтому самоподписанные сертификаты изо дня в день возят почту без единой жалобы.

Меняют дело две вещи. Опубликованная политика MTA-STS велит отправителям требовать TLS с действительным и совпадающим сертификатом и отказываться от доставки, а не откатываться на открытый канал: сертификат, который вчера всех устраивал, начинает отбивать почту. И с 2024 года Gmail и Yahoo требуют от массовых отправителей передачи по TLS вообще.

Дату истечения стоит внести в календарь по той же причине. Просроченный сертификат на обычном веб-сервере даёт предупреждение, которое можно пролистать. На почтовом сервере под MTA-STS он даёт тишину и почту, которая перестала приходить.

Открытый релей: редко и катастрофично

Релей, который возит почту кому угодно, находят в считанные дни после появления, а вскоре после этого адрес оказывается во всех блоклистах. В современном софте это редкость, потому что ни один актуальный почтовый сервер так не поставляется: такое появляется после правки конфигурации руками или разрешающего правила, добавленного ради решения проблемы с доставкой и забытого.

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

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

Как читать список возможностей

Сервер перечисляет, что поддерживает, в ответ на приветствие. Несколько строк оттуда стоит знать.

• STARTTLS — шифрование доступно. Его отсутствие на публичном почтовом сервере в 2026 году — настоящий пробел.
• SIZE — предельный размер письма, которое сервер примет. Стоит посмотреть, прежде чем винить в возврате фильтры.
• AUTH — предлагается авторизованная отправка. Ожидаемо на порту 587 и несколько необычно на 25.
• 8BITMIME и SMTPUTF8 — сервер работает с не-ASCII содержимым и международными адресами без перекодирования.

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