Как читать заголовки письма и найти причину отказа

MAATRIX

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

Где взять полные заголовки письма

То, что вы видите в интерфейсе почты — «От», «Кому», «Тема», дата — это только небольшая видимая часть заголовков. Полный набор скрыт по умолчанию, потому что обычному пользователю он не нужен, но открыть его может каждый.

В Gmail откройте письмо, нажмите на три точки в правом верхнем углу открытого письма и выберите «Показать оригинал» (Show original). Откроется отдельная страница с полным текстом заголовков и кнопкой «Скачать оригинал» — исходный .eml-файл письма целиком, с заголовками и телом.

В Яндекс.Почте это пункт «Свойства письма» в меню письма (три точки или стрелка рядом с датой) — там показывается технический блок с заголовками.

В Outlook (веб-версия) — три точки над письмом → «Просмотреть исходный код сообщения» (View message source). В десктопном Outlook — двойной клик по письму, чтобы открыть его в отдельном окне, затем «Файл» → «Свойства» → поле «Интернет-заголовки» внизу окна.

В Apple Mail — меню «Вид» → «Заголовки сообщения» → «Все заголовки» (или сочетание Cmd+Shift+H в некоторых версиях).

В Thunderbird — Ctrl+U на открытом письме, либо меню «Вид» → «Исходный текст письма».

Если у вас свой почтовый сервер на Postfix, iRedMail или Mailcow, самый надёжный способ — смотреть заголовки прямо в логах или через swaks/mailx при тестовой отправке, но для разбора конкретного полученного письма веб-интерфейс почтового ящика получателя обычно быстрее.

Название пункта меню в разных клиентах звучит по-разному — «показать оригинал», «показать исходный код письма», «интернет-заголовки», «просмотреть источник» — но суть одна: вы получаете текстовый блок, где хронологически и построчно записано всё, что происходило с письмом от момента отправки до попадания в ваш ящик.

Поле Received: реальный путь письма

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

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

Пример одной записи:

Received: from mail.example-sender.com (mail.example-sender.com [203.0.113.45])
	by mx.google.com with ESMTPS id a1b2c3d4e5
	for <you@yourdomain.ru>;
	Thu, 03 Sep 2026 14:22:07 -0700 (PDT)

Здесь видно: от какого хоста и с какого IP пришло письмо (from), какой сервер его принял (by), и метка времени приёма. Если в цепочке несколько таких записей, сравнивая метки времени между соседними строками, вы находите, на каком именно переходе возникла задержка — например, письмо ушло с сервера отправителя в 14:20, а следующий сервер принял его только в 16:45: два с половиной часа потеряны между этими двумя серверами, и это уже конкретная зацепка для дальнейшего разбора (перегруженная очередь, грейлистинг, таймаут DNS у промежуточного сервера).

Важно проверять IP-адрес и имя хоста в каждой записи Received на правдоподобность: если письмо якобы прошло через mail.yourcompany.com, а IP в скобках принадлежит совершенно другой сети (это легко проверить через whois <IP> или любой онлайн-whois), это тревожный признак — либо подделка заголовков, либо открытый релей где-то в цепочке.

Authentication-Results: прошли ли проверки для этого письма

Общая статья про SPF/DKIM/DMARC объясняет, как настроить эти механизмы на своём сервере — что такое SPF, DKIM и DMARC и как их поднять. Но когда вопрос не «как настроить», а «почему конкретное письмо не прошло», ответ ищется не в общих рекомендациях, а в заголовке Authentication-Results этого самого письма — там принимающий сервер прямо пишет вердикт по каждой проверке.

Пример из письма, принятого Gmail:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=default header.b=Xy7aBc12;
       spf=pass (google.com: domain of sender@example.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=sender@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Каждая проверка даёт один из статусов: pass (прошла), fail (провалена), softfail (SPF разрешает мягко, с оговоркой), neutral (домен не декларирует политику), none (записи не найдено вообще), temperror/permerror (техническая ошибка проверки — например, DNS не ответил).

Если видите spf=fail — значит IP отправляющего сервера не входит в список разрешённых в SPF-записи домена отправителя. Если dkim=fail — подпись письма не совпала (письмо изменилось в пути, либо ключ на сервере отправителя не совпадает с опубликованным в DNS). Если dmarc=fail — это уже почти всегда означает, что письмо отправлено с домена, но не прошло ни SPF, ни DKIM в достаточной мере, и политика DMARC домена сработала.

Такой результат сразу даёт направление: если письмо ваше собственное и spf=fail — проверяйте SPF-запись своего домена и IP сервера, с которого реально ушло письмо (частая причина — отправка через сторонний сервис рассылок, IP которого не добавлен в SPF). Если dkim=fail — проверяйте, не сломалась ли ротация DKIM-ключей или не искажает ли письмо промежуточный сервер (некоторые списки рассылки переписывают тело письма и ломают подпись — это нормально и ожидаемо).

Здесь же обычно можно найти заголовок Received-SPF, который дублирует результат SPF-проверки в отдельной строке с более развёрнутым пояснением, если Authentication-Results показался недостаточно подробным.

Диагностические заголовки спам-фильтра

Многие спам-фильтры добавляют собственные заголовки с оценкой и обоснованием — но не все системы это делают одинаково открыто. Настроенный на своём сервере rspamd (см. настройку защиты от спама на rspamd) добавляет заголовок вида:

X-Spam-Status: No, score=2.1 required=5.0 tests=DKIM_SIGNED,SPF_PASS,
	FREEMAIL_FROM,HTML_MESSAGE autolearn=disabled
X-Spam-Score: 2.1

Здесь tests= — это список конкретных правил, которые сработали на письме, и по каждому можно понять, что именно добавило или сняло баллы. FREEMAIL_FROM — письмо с бесплатного почтового домена, HTML_MESSAGE — письмо в HTML без текстовой альтернативы, и так далее. Сумма меньше порога required — письмо прошло, выше — было бы отклонено или помечено спамом.

У сторонних почтовых сервисов (Gmail, Mail.ru, Яндекс) диагностика скромнее — крупные провайдеры не раскрывают внутреннюю логику спам-фильтра в заголовках, чтобы её нельзя было обходить целенаправленно. Но иногда встречаются полезные пометки вроде X-Gm-Message-State (внутренний идентификатор Gmail, бесполезен для диагностики) или заголовки от корпоративных антиспам-шлюзов (Proofpoint, Mimecast, Barracuda), которые действительно расшифровывают причину — например X-Barracuda-Spam-Score: 5.2 с приложенным списком сработавших правил.

Если диагностических заголовков нет вообще — это тоже информация: значит, ответ нужно искать в Received (задержка/маршрут) и Authentication-Results (аутентификация), а не гадать по спам-баллам, которых просто не существует для этого письма.

Практическая методика: разбор конкретного письма по шагам

Когда у вас есть конкретное проблемное письмо — не дошедшее, попавшее в спам или сильно задержавшееся — разбор по заголовкам обычно даёт прямой ответ за несколько минут, вместо перебора общих причин из статьи про переход с Gmail на свой почтовый сервер или общих версий про путь письма.

Последовательность:

1. Откройте полные заголовки этого конкретного письма (см. первый раздел).
2. Пройдите цепочку Received снизу вверх. Найдите первую и последнюю запись, сравните временные метки между соседними строками. Если разрыв большой — вот ваша задержка, и вы знаете, на каком именно сервере.
3. Проверьте Authentication-Results. Если spf=fail, dkim=fail или dmarc=fail — вот причина попадания в спам или отказа, и вы знаете, какую именно проверку чинить.
4. Поищите X-Spam-Status / X-Spam-Score или заголовки антиспам-шлюза. Если есть — смотрите список tests= и находите конкретное сработавшее правило.
5. Если все проверки прошли и задержек в Received нет — проблема не в заголовках этого письма, а в чём-то на стороне получателя (личный фильтр, правило пересылки, переполненный ящик) или в репутации IP/домена отправителя в целом, которую заголовки одного письма не покажут — тут уже нужен разбор через постмастер-инструменты (Google Postmaster Tools, Яндекс.Почта для доменов) и проверку DNS-записей самого домена, а не отдельного письма.

Таблица для быстрой ориентации:

Собственный архив заголовков как справочник

Одна проверка одного письма решает одну проблему. Но если вы администрируете свой почтовый сервер (Postfix, iRedMail, Mailcow), полезно завести привычку сохранять заголовки показательных писем — и хороших, и плохих.

Практический подход:

• Заведите папку (локально или в тикет-системе) с двумя категориями: good-headers/ и bad-headers/.
• Каждый раз, когда письмо доставляется без проблем и вы уверены, что оно прошло все проверки — сохраните его заголовки (или весь .eml) в good-headers/ с коротким комментарием: дата, откуда, куда, через что ушло.
• Каждый раз, когда возникает проблема — письмо ушло в спам, отклонено, задержалось — сохраните заголовки в bad-headers/ с тем же комментарием и итоговым диагнозом (например, «DKIM не совпал после ротации ключа 15 августа»).

Через несколько таких случаев у вас появляется наглядный референс: открываете рядом хороший и плохой пример для похожей ситуации (скажем, оба письма ушли через один и тот же relay) и построчно сравниваете Authentication-Results и цепочку Received. Разница обычно видна сразу — не нужно заново вспоминать, как выглядит нормальный результат SPF, если вы уже сохранили эталон.

Это особенно выручает при разборе постфикс-специфичных проблем — если письма периодически уходят в спам на Postfix или на Mailcow, сравнение заголовков доставленного и отклонённого письма с одного и того же сервера почти всегда быстрее указывает на разницу в конфигурации, чем перебор настроек вслепую.

Если вы разворачиваете почтовый сервер с нуля на VPS — учитывайте с самого начала, что придётся не только настроить SPF/DKIM/DMARC, но и уметь читать результат по каждому письму: для стабильной репутации домена и IP это ежедневная рутинная проверка, а не разовая настройка.

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