Received-заголовок: как прочитать маршрут email-сообщения

The Received header is the trace record that each mail server stamps onto a message as it passes through. Every MTA that handles the email - whether it is the originating server, an intermediate relay, or the final delivery agent - prepends its own Received line at the top of the header block. By reading these lines from bottom to top, you reconstruct the full path the message traveled, along with timestamps, IP addresses, and protocol details at each hop.

Format of a Received header

RFC 5321 defines the general structure. A typical Received header looks like this:

The key clauses: from identifies the sending server (HELO/EHLO name and IP), by identifies the receiving server, with specifies the protocol (SMTP, ESMTP, ESMTPS for TLS), id is the internal queue ID, and the timestamp records when the handoff occurred.

Порядок чтения: снизу вверх

Каждый сервер добавляет свой Received-заголовок перед всеми предыдущими. Поэтому самый нижний Received в блоке заголовков - это первый сервер, обработавший письмо (обычно MTA отправителя). Самый верхний - последний сервер перед доставкой в ящик.

Для обычного письма, отправленного через ESP, цепочка может выглядеть так:

1. MTA отправителя (ESP) формирует письмо и передаёт его на свой relay.
2. Relay ESP добавляет Received и передаёт дальше.
3. MX-сервер получателя принимает соединение и добавляет свой Received.
4. Внутренний сервер доставки (если есть) перекладывает письмо в ящик и добавляет финальный Received.

Итого 3-4 Received-заголовка. Для писем, прошедших через mailing list или forwarding, их может быть 6-8.

Диагностика задержек

Каждый Received содержит timestamp. Разница между соседними временными метками показывает, сколько времени письмо провело на каждом этапе. Если между двумя серверами прошло 0.5 секунды, а между следующей парой - 45 минут, задержка произошла именно там.

Типичные причины задержек: сервер перегружен и письмо стоит в очереди, greylisting (первая попытка отклоняется, повторная через 5-15 минут проходит), DNS-проблемы на стороне принимающего сервера, или rate limiting от почтового провайдера.

Received и аутентификация

Received-заголовки дополняются заголовком Authentication-Results, который принимающий сервер добавляет рядом с верхним Received. В нём фиксируются результаты SPF, DKIM и DMARC.

Важный нюанс: Received-заголовки, добавленные до вашего сервера, можно подделать. Отправитель может вставить в письмо произвольные Received-строки, имитируя прохождение через несуществующие серверы. Достоверными считаются только те Received, которые добавлены вашим сервером и серверами, которым вы доверяете. Спам-фильтры учитывают это и анализируют только "верхние" Received-записи, добавленные внутри инфраструктуры получателя.

Что показывает IP в Received

IP-адрес в скобках после имени хоста - это фактический адрес, с которого пришло TCP-соединение. Имя хоста берётся из EHLO/HELO-команды и может быть чем угодно (отправитель контролирует этот параметр). А вот IP - это то, что видит сокет принимающего сервера, и его подделать нельзя.

Поэтому при анализе Received-заголовков IP-адрес надёжнее имени хоста. По IP можно определить: принадлежит ли сервер заявленному ESP, находится ли он в блок-листах, соответствует ли PTR-запись указанному имени.

with ESMTPS: TLS в Received

Протокол в clause "with" показывает, было ли соединение зашифровано. Основные варианты:

• SMTP - базовый протокол без расширений.
• ESMTP - расширенный SMTP (поддержка EHLO), но без шифрования.
• ESMTPS - ESMTP с TLS (STARTTLS или implicit TLS). Это то, что вы хотите видеть.
• ESMTPSA - ESMTP с TLS и аутентификацией (SMTP AUTH). Обычно для submission на порту 587.

Если в цепочке есть hop с "ESMTP" без S, значит на этом участке письмо передавалось открытым текстом. Для внутренних серверов в одном дата-центре это допустимо. Для передачи через интернет - нет.

Received-заголовки и антиспам

Спам-фильтры используют Received для оценки сообщения. Они извлекают IP первого доверенного хопа и проверяют его по DNSBL (чёрным спискам). Если IP отправляющего сервера есть в Spamhaus или Barracuda, письмо получает штраф ещё до анализа контента.

Кроме того, аномалии в Received-цепочке вызывают подозрения: слишком длинная цепочка, несоответствие временных меток (время идёт назад), поддельные внутренние Received-заголовки. Всё это повышает спам-скор.

Практический пример чтения

Допустим, вы видите три Received-заголовка (сверху вниз):

Чтение снизу вверх: приложение ESP передало письмо на свой relay (10:23:45), relay доставил его на mx.gmail.com по TLS за 1 секунду (10:23:46), внутренний сервер Gmail переложил его в ящик ещё через секунду (10:23:47). Общее время доставки: 2 секунды. Задержек нет.