Почты почтового сервера: из чего состоит путь письма

SMTP-конверт против заголовков: где на самом деле живёт «отправитель»

В SMTP-конверте — bounce@mxclient.net. А в заголовке Return-Path: — что-то ещё. Маркетолог думает, что это «глюк». На самом деле это нормальная архитектура почты, в которой конверт и тело письма — два разных слоя данных.

В терминологии SMTP исходная система (Mail Submission Agent) вводит письмо в транспортную сеть через команду MAIL FROM, а каждого получателя передаёт отдельной командой RCPT TO. Это и есть SMTP-конверт — служебная обёртка, по которой работает межсерверная маршрутизация. Дальше relay-серверы передают письмо следующему узлу, добавляя только трассировочную информацию, а доставляющая система кладёт сообщение в хранилище или отдаёт клиенту по POP3/IMAP. Сама сессия начинается с EHLO (или исторического HELO), где отправляющий узел представляет себя доменным именем — это первый идентификатор, к которому потом применяется SPF.

Адреса в конверте MAIL FROM и RCPT TO технически не равны полям From: и To: внутри заголовков сообщения. И это не баг, а фундамент. Видимый From: нужен человеку, чтобы он понимал, кто пишет. MAIL FROM нужен серверу, чтобы он знал, куда слать bounce и кто несёт ответственность за доставку. Путать эти два слоя — типичная ошибка, из которой потом вырастают «призрачные» возвраты, жалобы на spam и непонятный backscatter: кто-то шлёт письмо с чужого MAIL FROM на несуществующий адрес, а bounce летит ничего не подозревающему владельцу обратного адреса. Отсюда, кстати, и требование SPF к MAIL FROM — закрыть именно этот конвертный слой.

MX-запись — это не IP-адрес. Это имя почтового хоста, до которого SMTP-клиент должен дойти ещё одной DNS-резолюцией по A или AAAA.

По RFC 5322 сообщение состоит из секции заголовков и необязательного тела, разделённых пустой строкой. Синтаксически обязательны поля даты и хотя бы одного адреса отправителя. To:, Subject: и Message-ID: на уровне синтаксиса обязательными не являются, хотя Message-ID: настоятельно рекомендуется добавлять — его отсутствие для многих антиспам-фильтров служит сигналом «подозрительности» и повышает итоговый балл письма. Жёсткий предел длины строки — 998 символов без CRLF, рекомендуемый — 78. Это не декоративная цифра: если ваш генератор рассылок режет длинные заголовки криво (а мы это видели у трёх разных ESP подряд), доставляемость просядет незаметно для вас, но ощутимо для кликрейта.

Механика MX-маршрутизации: как SMTP находит, куда тащить письмо

После того как relay определил домен назначения, он обязан выполнить DNS-запрос. Если для имени существуют MX-записи, SMTP-клиент работает по ним. RFC 974, описывающий этот механизм, появился в январе 1986 года — раньше, чем многие из наших читателей начали работать с email. Если же MX-записей нет, RFC 5321 предписывает отправляющему серверу использовать адресные записи самого домена (A или AAAA) как fallback. То есть формально механизм «без MX» спецификацией допустим — но мы к этому ещё вернёмся, потому что в реальности полагаться на это нельзя.

MX-запись содержит два поля: числовой приоритет (это беззнаковое 16-битное число) и имя почтового узла. Меньшее значение — более предпочтительный MX. Если у вас несколько MX с одинаковым приоритетом, отправляющий сервер должен распределять нагрузку между ними, а не выбирать один «главный». Это не рекомендация, это требование стандарта — и именно на нём строится отказоустойчивость почтовой инфраструктуры крупных провайдеров.

Имя хоста в MX должно разрешаться в адресную запись. Здесь есть пара неочевидных моментов. Во-первых, имя в MX должно быть FQDN — то есть резолвиться без дополнительных правил подстановки домена-поиска. Во-вторых, корень домена как имя в MX корректен: MX 10 example.com допустим, если сам example.com имеет A или AAAA запись — резолвер не пойдёт ни на какой «лишний уровень рекурсии», он отработает стандартную цепочку. На практике чаще используют MX 10 mail.example.com, потому что это отделяет почтовую роль от web и даёт независимую точку для почтовых сертификатов, политик MTA-STS и отдельного IP — но с точки зрения DNS-контракта обе формы валидны.

Наличие нескольких MX и нескольких IP на каждом из них увеличивает число альтернативных попыток доставки, но не гарантирует само попадание письма во «Входящие». Решение о доставке принимает политика получателя, и никакое количество MX его не перевесит.

Типичные ошибки при работе с MX, которые мы видим в продакшене раз в неделю:

• MX указывает на CNAME, а не на A/AAAA. Это нарушение DNS-контракта: CNAME на вершине зоны вообще запрещён, а MX, указывающий на CNAME, ведёт к непредсказуемому поведению резолверов и периодически ломает доставку на стороне крупных провайдеров, которые строго следуют RFC.
• Имя в MX не резолвится в адресную запись. Домен забыли продлить, IP сменили, A-запись удалили при миграции. SMTP-клиент получает NXDOMAIN или SERVFAIL и уходит в retry с экспоненциальной задержкой — срок жизни письма в очереди несложно посчитать по логам.
• Один MX с приоритетом 10, остальные с приоритетом 100. Отправляющий сервер может вообще не попробовать резервный узел, если основной отвечает SMTP-баннером, но не принимает письма — он засчитывает «попытку» и уходит в очередь на повтор. С точки зрения протокола это легитимное поведение.
• Отсутствие MX вообще при наличии A-записи. Формально RFC 5321 разрешает fallback на адресные записи самого домена, и часть отправляющих серверов так и делает. Но на это накладываются политики конкретных провайдеров, антиспам-правила и сложности с приоритизацией. Не полагайтесь на fallback как на постоянную схему — для боевого домена MX обязана быть.

Имя хоста в MX — это не финальная точка. Это DNS-имя, которое требует собственной A или AAAA резолюции. Многие провайдеры забывают, что цепочка DNS-запросов на этом не заканчивается.

Транспортная цепочка: relay, очередь и поля Received

Письмо от Mail User Agent попадает на Mail Submission Agent, который передаёт его на Message Transfer Agent — тот самый SMTP-сервер, который отвечает за межсерверную доставку. Дальше начинается самое интересное для тех, кто разбирает инциденты: трассировка. При прохождении через транспортную систему к письму добавляются trace-поля. По RFC 5322 группа trace включает необязательный Return-Path: и одно или несколько полей Received:. Каждый relay-узел добавляет своё Received: сверху (то есть в начало списка), и по нему можно реконструировать маршрут.

Но есть нюанс, о котором часто забывают. Trace-поля имеют информационный статус. RFC прямо указывает, что они не обязаны быть достоверными, и по одному полю Received: нельзя делать вывод о физическом местоположении сервера или владельце IP. В бизнес-практике это означает, что когда в кейсе клиента мы видим в Received: чужой провайдерский хост, который не имеет отношения к их инфраструктуре, — это ещё не доказательство утечки. Это особенность протокола, и с этим приходится жить.

Количество relay на пути письма — величина переменная и универсального значения не имеет. Оно зависит от инфраструктуры отправителя, маршрутизации получателя, настроек антиспам-шлюзов и шлюзов безопасности на стороне обоих провайдеров. Иногда письмо проходит три узла, иногда — девять. На доставляемость влияет не количество hop'ов само по себе, а время прохождения и качество каждого узла: если один из них стоит в чёрном списке, письмо может не дойти вовсе, сколько бы Received: ни нарисовалось в заголовке.

Очередь сообщений на сервере (mail queue) — это буфер, в котором письмо живёт между попытками доставки. Когда relay не смог доставить письмо с первого раза (получил 4xx-ответ или TCP-таймаут), оно попадает в очередь с пометкой о следующей попытке. Интервал повторов выбирается по экспоненциальной схеме с потолком, и если за весь срок жизни очереди доставка так и не удалась — формируется DSN (delivery status notification) и отправляется по адресу из MAIL FROM. Здесь критично для email-маркетолога: время жизни в очереди напрямую связано с «прогревом» домена. Если вы отправляете с нового IP большие объёмы и очередь не успевает разгружаться, репутация IP падает, и сообщения начинают накапливаться до тайм-аута — а потом возвращаются отправителю с defer-кодами. Это не «плохой контент», это именно проблема очереди и инфраструктуры.

Отдельный прикладной момент: 4xx-ответы — это «мягкая» временная ошибка, очередь продолжит попытки. 5xx-ответы — окончательный отказ, DSN формируется сразу. Если ваша ESP-система показывает график «defer в первые сутки», это индикатор либо перегрузки вашего relay, либо медленного ответа принимающего сервера. Следите за распределением кодов — оно расскажет, где именно ломается цепочка.

Порты и submission: где заканчивается клиентская отправка

В практике мы часто встречаем ситуацию, когда сисадмин настраивает почтовый сервер «по памяти»: 25 для всего, что почта, и забывает про разделение между submission и relay. Это работает, пока не приходит аудит или пока собственный домен не начинают массово использовать для рассылок.

Современная архитектура SMTP разделяет три ключевых TCP-порта:

Порт 25 — это то, по чему общаются между собой MX-узлы. Когда SMTP-клиент резолвит MX получателя и подключается к нему, он подключается именно на 25. Этот порт на клиентских машинах часто закрывают исходящим файрволом, чтобы заблокировать «зомби-рассыльщики», и это правильно: легитимная клиентская отправка идёт через submission.

Порт 587 — стандартный порт message submission, описанный в RFC 6409 ещё в ноябре 2011 года. Это точка, где почтовый клиент (Outlook, Thunderbird, MUA в виде скрипта рассылки) передаёт письмо серверу отправки. Порт 587 предполагает STARTTLS как базовую практику — отправляющий клиент открывает plaintext-соединение, шлёт EHLO, получает в банере STARTTLS, после чего переводит канал в TLS. Без возможности согласовать STARTTLS современные провайдеры часто отказывают. Если вы видите в логах, что провайдер отбивает клиента именно на 587 — почти всегда это либо отсутствие сертификата, либо попытка отправить plaintext в канал, где TLS теперь обязателен.

Порт 465 — это service name submissions, отправка с неявным TLS. Здесь TLS-handshake начинается сразу после TCP-соединения, без отдельной команды STARTTLS. Этот порт исторически был зарезервирован под SMTPS, потом формально «отменён» в RFC, потом фактически восстановлен как легитимный к RFC 8314 в январе 2018 года. Сейчас 465 поддерживается всеми крупными провайдерами как полноценная альтернатива 587, а для скриптов рассылки часто даже удобнее: нет промежуточного состояния, в котором можно случайно утечь служебные команды.

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

Если вы строите инфраструктуру бизнес-почты, закрытие 25-го порта на исходящий трафик клиентов — обязательная гигиена. Иначе любой заражённый трояном ноутбук в офисе превращается в открытый релей и кладёт репутацию вашего MX за одну ночь. Отдельно следите за тем, чтобы submission-порт не слушал 0.0.0.0 без аутентификации — это второй по популярности способ «приютить» чужой спам-трафик на вашем IP.

Современные стандарты доверия: SPF, DKIM, DMARC и MTA-STS

Когда мы говорим клиенту «у вас настроен SPF, но письма всё равно летят в спам», — это не повод выкинуть SPF. Это повод разобраться, что SPF, DKIM, DMARC и MTA-STS делают разные вещи, и что одного без другого недостаточно.

SPF публикуется как одна текстовая DNS TXT-запись для конкретного имени и задаёт, какие хосты уполномочены использовать домен в идентификаторах HELO и MAIL FROM. Здесь критично: SPF проверяет не видимое поле From:, а служебные идентификаторы SMTP-конверта. Несколько SPF-записей для одного owner name стандарт не допускает — это либо hard fail, либо мягкая ошибка, которую антиспам-фильтр интерпретирует как «не настроено». Если у вас после миграции осталась старая SPF от предыдущего провайдера, и вы добавили новую — проверка dig TXT покажет две записи, и всё, вы вне игры. Проверяйте сразу после любых изменений инфраструктуры.

DKIM — это криптографическая подпись, которую отправляющий сервер добавляет к письму. Открытый ключ публикуется в TXT-записи селектора (selector._domainkey.example.com). DKIM проверяет целостность тела и части заголовков — то есть гарантирует, что письмо не было модифицировано в пути. Связь с видимым отправителем не обеспечивается автоматически: DKIM подписывает домен, который указан в d=, а не обязательно домен в From:. Отсюда запрос «подписать DKIM с доменом из From» — это не нарушение DKIM, а работа DMARC поверх него.

DMARC объединяет SPF и DKIM. DMARC проверяет выравнивание домена в видимом поле From: с доменом, успешно прошедшим SPF или DKIM. В relaxed-режиме достаточно совпадения по organizational domain (то есть example.com и mail.example.com считаются совпавшими). В strict-режиме требуется точное совпадение DNS-имён. DMARC — это та самая прослойка, которая превращает «у нас есть SPF и DKIM» в «мы доказали, что это письмо действительно от нас». При внедрении DMARC полезно пройти классический путь — сначала p=none со сбором отчётов через rua, потом p=quarantine с контролем жалоб, и только потом p=reject. Резкий переход в reject без данных rua почти всегда оборачивается потерянными legitimate-письмами от старых подсистем, которые забыли подключить.

MTA-STS — относительно молодой стандарт, RFC 8461, сентябрь 2018. Он позволяет домену получателя через DNS TXT и HTTPS опубликовать политику: ожидается ли TLS с проверяемым PKIX-сертификатом для его MX-узлов, и как должен действовать совместимый отправляющий MTA, если TLS согласовать невозможно. Индикатор публикуется в TXT-записи _mta-sts.<домен>. Это не «сквозное шифрование содержимого» — это защита SMTP-транспорта между серверами от downgrade-атак. Если ваш провайдер не поддерживает MTA-STS, ваше письмо может быть перехвачено на пути — содержимое останется в MIME-обёртке, но инфраструктура получателя потеряет доверие к каналу. Родственный механизм — TLS-RPT (RFC 8460) — позволяет получателю получать отчёты о реальном состоянии TLS на каждой SMTP-сессии, что критично для отладки цепочки доставки.

Важно понимать: успешные SPF/DKIM/DMARC-проверки — это не доказательство безопасности содержимого или отсутствия фишинга. Это доказательство того, что отправляющий сервер имел право использовать домен и не модифицировал письмо в пути. Письмо с валидной DKIM-подписью всё ещё может вести на фишинговую страницу, и это принципиальное ограничение протокола. Технические проверки снижают риск «spoofing от вашего имени», но не отменяют необходимость user education и контент-фильтрации.

Универсального набора DNS-записей для корпоративной почты не существует. SPF, DKIM, DMARC, MTA-STS, TLS-RPT и DANE внедряются в разных комбинациях, и конкретный рецепт зависит от провайдера, объёма рассылки и репутации домена.

Что из этого реально влияет на доставляемость

Мы часто видим, как сисадмины и маркетологи спорят о приоритетах: что важнее — контент письма, прогрев домена или DKIM-подпись. По нашим наблюдениям за дашбордами ESP, в порядке убывания влияния на опенрейт и кликрейт:

1. Репутация IP и домена — формируется месяцами и рушится за неделю при резком росте объёмов или жалоб. Это базовая «кредитная история» вашего домена.

2. Корректность MX-маршрутизации у получателя — если ваш MX отвечает с задержкой или попадает в greylist, никакая подпись не спасёт.

3. Согласованность SPF, DKIM и DMARC — отсутствие alignment с From: — самый частый технический «вылет» в промо-папку.

4. Содержимое и сегментация — высокий процент отписок и жалоб обнуляет всю предыдущую работу с инфраструктурой.

5. TLS-канал и MTA-STS у получателя — работает как дополнительный плюс к репутации, но не как основной фактор.

Путь письма — это не «нажал отправить — письмо пришло». Это цепочка DNS-запросов, SMTP-сессий, криптографических проверок и политик получателя. Каждое звено может сломать доставку независимо от остальных. Если разбирать кейс падения доставляемости, начинать надо не с дизайна письма и не с текста, а с архитектуры: какие MX, какие подписи, какие alignment-проверки, какой TLS. Только после того, как инфраструктурный слой закрыт, имеет смысл смотреть на когорты, сегментацию и гипотезы по контенту.

И вот главное, что мы поняли за годы работы: путь письма — это контракт. Контракт между отправителем и получателем, описанный в RFC с 1986 по 2018 год. Пока вы его соблюдаете, ваши письма имеют шанс дойти. Когда вы его нарушаете — будь то кривая MX-запись, вторая SPF или отсутствие alignment — никакая красота шаблона это не компенсирует.