Что на самом деле представляет собой блок заголовка
Любое письмо — это две части, разделённые одной пустой строкой: блок строк вида Name: value и текст, который вы читаете. RFC 5322 называет первую часть заголовком, а каждую строку в ней — полем, и никак не ограничивает их число. Ваш почтовый клиент показывает четыре-пять из них. Письмо, прошедшее через три сервера, обычно несёт от тридцати до шестидесяти.
Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"Если читать сверху вниз, это похоже на машинный шум, и по большей части так и есть. Почти всю информацию несут четыре поля, и именно о них это руководство: Received, From, Return-Path и Authentication-Results.
Где прячется полный заголовок
Ничего из того, что дальше, не требует ни инструмента, ни расширения, ни отдельного аккаунта. Каждый почтовый клиент хранит исходное сообщение за одним из пунктов меню, и слово, которое нужно искать, — это всегда какая-то форма слова оригинал, исходный или необработанный.
| Где вы читаете почту | Что открыть | Что вы получите |
|---|---|---|
| Gmail в браузере | Меню «Ещё» (три точки) на открытом письме → Показать оригинал | Весь блок целиком, а над ним — панель, которая уже сама оценила SPF, DKIM и DMARC |
| Outlook.com в браузере | Меню из трёх точек → View → View message source | Всё письмо целиком, как оно пришло, в виде обычного текста |
| Классическое приложение Outlook | Откройте письмо в отдельном окне → Файл → Свойства | Только блок заголовка, в поле внизу диалогового окна |
| Apple Mail на Mac | Вид → Сообщение → Raw Source | Заголовок и текст письма вместе, в отдельном окне |
| Thunderbird на любой системе | Вид → Исходный текст сообщения | Всё письмо целиком, с блоком заголовка сверху |
| Proton Mail в браузере | Меню из трёх точек на письме → View headers | Блок заголовка сам по себе, без текста письма |
| Yahoo Mail в браузере | Ещё → View raw message | Всё письмо целиком, именно в том виде, в котором оно было доставлено |
| Файл, который вам прислали, или тот, что вы экспортировали сами | Откройте .eml в любом текстовом редакторе | Всё целиком, потому что блок заголовка и текст письма — это и есть весь .eml |
Эти пути в меню верны на 5 сентября 2026 года, и они сдвигаются примерно раз в год — именно поэтому фраза выше важнее самой таблицы: как бы ни назывался пункт меню в этом сезоне, в нём обязательно будет корень слова оригинал, исходный или необработанный.
Цепочка Received: читаем снизу
Каждый сервер, принимающий письмо, пишет одну строку Received: и ставит её наверх блока, выше всего, что там уже было. Именно эта привычка порождает самый полезный факт о заголовках: последний переход — это первая строка, которую вы видите, а путь письма записан в обратном порядке.
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)Каждая строка построена из одного и того же небольшого набора слов, и как только вы научитесь их называть, цепочка перестаёт быть просто узором на обоях.
from- Как назвала себя подключившаяся машина, а в скобках после этого — чем она была на самом деле: обратное DNS-имя и IP-адрес, которые принимающий сервер увидел на соединении. Имя перед скобками — это утверждение. Адрес внутри скобок — это наблюдение.
by- Сервер, который написал эту строку. Это единственная сторона в строке, с которой вы вообще можете спросить за её содержимое.
with- Как был сделан переход:
ESMTP,ESMTPS— если соединение было зашифровано,LMTP— для финальной передачи в почтовый ящик. Переход, в котором указаноESMTPбезSна конце, перенёс письмо в незашифрованном виде. for- Получатель конверта на этом переходе — на какой именно из ваших адресов письмо было отправлено на самом деле, до того как его переписало какое-либо правило пересылки. На catch-all-домене или с плюс-тегом это как раз то поле, которое называет утёкший адрес.
- отметка времени в конце строки
- Когда этот сервер закончил принимать письмо. Вычтите время одной строки из времени строки над ней — и вы получите задержку на этом переходе, а значит, узнаете, где на самом деле застряло медленное письмо, вместо того чтобы гадать.
В примере выше письмо вышло из приложения в 09:11:58 и добралось до исходящего сервера отправляющего провайдера двумя минутами и двадцатью тремя секундами позже; следующие два перехода вместе заняли одну секунду. У письма, которое приходит с опозданием на час, почти всегда найдётся одна строка, внутри которой спрятан этот час, — и это редко бывает последняя строка.
Четыре поля, каждое из которых претендует на роль отправителя
На вопрос «кто это отправил» в заголовке есть четыре ответа, и им разрешено не совпадать. Чаще всего они не совпадают по скучным причинам — список рассылки, платформа для маркетинговых писем, правило пересылки, которое вы сами когда-то настроили. Само по себе несовпадение ничего не доказывает. А вот знание, на какое из четырёх полей вы сейчас смотрите, — доказывает.
From:- Адрес, который отправитель хочет показать, плюс отображаемое имя, представляющее собой произвольный текст. Ни то, ни другое ничем не проверяется. Именно это поле ваш почтовый клиент выводит в списке писем, и на телефоне адрес обычно полностью скрыт за именем.
Return-Path:- Отправитель конверта — его вписывает в заголовок сервер, принявший письмо, на основании того, что реально было сказано во время SMTP-сессии. Именно туда уходит письмо о недоставке, и именно этот адрес проверяет SPF, — а значит, письмо вполне может пройти SPF и при этом нести
From:, не имеющий к этому адресу никакого отношения. Reply-To:- Куда уйдёт ваш ответ — и это не обязано быть тем же адресом, откуда пришло письмо. Обычные отправители используют его для служб поддержки и адресов no-reply. А ещё это старейший трюк в отрасли: внимательный читатель проверяет отправителя, решает, что всё в порядке, а потом нажимает «Ответить».
Delivered-To:иX-Original-To:- Какой именно из ваших адресов был использован. На catch-all-домене или с плюс-тегом это как раз то поле, которое называет адрес, отданный вами наружу, — тот самый, что укажет, кто его выпустил на волю.
From: "Example Support <support@example.com>" <billing@example.net>
^-- the display name, which is free text and is all a phone shows
^-- the address, which is notОтображаемое имя — это произвольный текст, поэтому в нём может целиком поместиться чужой адрес. Любой почтовый клиент в мире покажет часть в кавычках и спрячет часть в угловых скобках, и в этом вся атака целиком: написать её ничего не стоит, а работает она ровно на том поле, на которое читатель гарантированно посмотрит.
SPF, DKIM и DMARC в одной строке
Одно поле не похоже ни на одно другое поле в блоке. Authentication-Results: пишет сервер, который принял письмо, — то есть ваш собственный, — а всё, что приходит извне под тем же именем, вырезается или переименовывается ещё до того, как вы это увидите. Это единственная строка в заголовке, которую самозванец написать не может.
Authentication-Results: mx.example.org;
spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comВ этой строке живут три проверки, и они отвечают на три разных вопроса. А четвёртый столбец стоит прочитать дважды.
| Проверка | Что означает успешный результат | Что обычно означает неудачный результат | Чего не доказывает ни то, ни другое |
|---|---|---|---|
spf= | Машина, которая передала письмо, есть в списке, который в DNS публикует домен отправителя конверта. | Либо самозванец, либо обычная пересылка: SPF ломается всякий раз, когда третья сторона ретранслирует письмо, а это не является нарушением и происходит постоянно. | Ничего об адресе в From:. SPF на него вообще никогда не смотрит. |
dkim= | Криптографическая подпись письма совпадает с открытым ключом, опубликованным доменом, который подписал письмо. | Либо письмо изменили в пути — для этого достаточно, чтобы список рассылки дописал в конец подпись, — либо его подписал не тот домен, на который оно претендует. | Того, что домен, поставивший подпись, — это домен в From:. Собственную почту безупречно подписать может кто угодно. |
dmarc= | SPF или DKIM прошли проверку, и домен, для которого они её прошли, совпадает с доменом в From:. | Домен в From: не авторизовал это письмо — ближе к утверждению «отправитель не тот, за кого себя выдаёт» заголовок никогда не подходит. | Того, что письмо безопасно, честно или желанно. Домен, зарегистрированный сегодня утром, уже к обеду может опубликовать безупречный DMARC. |
Этот последний столбец — вся суть, и именно на нём чаще всего спотыкается чтение заголовков. dmarc=pass доказывает, что домен, напечатанный в From:, авторизовал это письмо. Он вообще ничего не говорит о том, заслуживает ли этот домен хоть какого-то доверия с вашей стороны, — а опубликовать такие записи самостоятельно может кто угодно примерно за десять минут.
Пять вещей, которые заголовок не расскажет
- Где находится отправитель. Адреса машины, на которой письмо набирали, в блоке обычно вообще нет. Крупные почтовые провайдеры перестали его публиковать много лет назад, и всё, что остаётся, — это их собственный исходящий сервер, который стоит в дата-центре и назовёт вам разве что имя хостинговой компании.
- Кто отправитель. Домен — это не человек.
dmarc=passдля домена, купленного сорок минут назад, — такая же настоящая, неподдельная проверка, как и любая другая. - Правда ли то, что в нём написано. Аутентификация касается конверта и никогда — утверждений внутри него. Счёт может быть правильно подписан, правильно выровнен и при этом полностью выдуман.
- Прочитали ли его вообще. Заголовок этого не фиксирует никак. Попытку сделать это берёт на себя трекинговый пиксель в теле письма — это совсем другой механизм и совсем другая защита от него.
- Когда оно было написано.
Date:берётся с машины отправителя и с его собственных часов. Письмо со штампом на три часа в будущем гораздо чаще означает неправильно настроенный компьютер, чем что-то интересное; отметкам времени, на которые можно полагаться, — место в строкахReceived, написанных вашим провайдером.
И есть целое семейство полей, которое по своей конструкции не доказывает вообще ничего. Всё, что начинается с X-, — это частное расширение, придуманное тем, кто его написал, и отправитель может вписать туда что угодно: X-Spam-Status: No в письме означает лишь то, что письмо само о себе утверждает, что оно не спам.
Когда письмо пришло на одноразовый адрес
Стоит чётко понимать, что этот сервис возвращает, а что — нет. Письмо, которое вы читаете здесь, приходит уже разобранным, а не в сыром виде: отправитель, тема, дата, текст, HTML и список вложений — то есть именно те поля, за которыми обычно приходит скрипт, — а не блок заголовка. Всё, что описано выше, вы делаете в том ящике, который хранит вашу настоящую почту.
{
"id": "m_7Kq2fV3xTn",
"from": "support@example.com",
"from_name": "Example Support",
"to": "signup-2026@grabmail.io",
"subject": "Confirm your email address",
"date": "2026-09-05T09:14:22+00:00",
"expires_at": "2026-09-10T09:14:22+00:00",
"text": "Confirm your address: <https://example.com/confirm/9a31b0>",
"text_derived": true,
"html": "<!doctype html><html>…",
"attachments": []
}Взамен одноразовый адрес даёт вам сигнал, с которым не сравнится ни одно поле заголовка, и он работает ещё до того, как вы прочли хоть одну строку: вы отдали этот адрес ровно одной стороне. Если письмо приходит на него и утверждает, что оно от кого-то другого, значит, его либо переслала та сторона, которой вы этот адрес дали, либо отправил тот, кому она его передала. Третьего объяснения нет, и проверять тут нечего.
Это тот же самый аргумент, что и у плюс-тега, только без той части, где тег можно отрезать одной строкой кода, — здесь другой сам адрес, поэтому отрезать нечего. Именно поэтому catch-all на домене, которым вы владеете, — это самая сильная версия этого приёма: один адрес на каждую регистрацию, живущий столько же, сколько вы держите домен, а Delivered-To: в вашем собственном ящике называет тот, что утёк.
Проверка, которая всё ещё доступна
Смотрите, куда ведёт ссылка, а не что на ней написано. Поле text — это либо собственная текстовая часть отправителя, либо результат рендеринга HTML — какая именно, говорит text_derived, — а при рендеринге адрес каждой ссылки сохраняется в угловых скобках. Так что адрес, на который вас должна была увести кнопка, лежит прямо в ответе, на виду, без загрузки страницы, картинок или пикселя.
Confirm your address: <https://example.com/confirm/9a31b0>
Not you? Ignore this message. <https://example.com/help>Версия на шестьдесят секунд
- Откройте исходный текст письма. Показать оригинал, View message source или Raw source — в зависимости от того, в каком вы клиенте.
- Сначала найдите
Authentication-Results. Одна строка, написанная вашим собственным провайдером, — единственная, которую никто другой не мог подделать.dmarc=pass— и домен вFrom:действительно авторизовал письмо;dmarc=fail— и не авторизовал. - Сравните
From:сReturn-Path:иReply-To:. Они расходятся по скучным причинам весь день напролёт. А ещё они расходятся по одной интересной. - Читайте строки
Receivedснизу вверх и перестаньте им верить на первой же машине, которая принадлежит не вашему провайдеру. - А потом посмотрите, куда указывают ссылки, — именно эта часть решает, что на самом деле произойдёт с вами.
Всё написанное выше отвечает на один узкий вопрос: авторизовал ли домен в From: это письмо? Это более скромный вопрос, чем «безопасно ли это», и всё равно его стоит задавать — потому что это единственный вопрос, на который заголовок вообще способен ответить.
Вопросы
Как увидеть полный заголовок в Gmail?
Откройте письмо, затем меню из трёх точек в правом верхнем углу, затем Показать оригинал. Gmail откроет новую вкладку с исходным письмом, а над ним — небольшую панель, которая уже сама оценила SPF, DKIM и DMARC: это самый быстрый вердикт из всех доступных где бы то ни было, и он бесплатный.
Можно ли подделать заголовок письма?
По большей части — да. From:, Reply-To:, Date:, тему письма и сколько угодно выдуманных строк Received: — всё это печатает отправитель. Подделать нельзя то, что написал ваш собственный провайдер, когда письмо пришло: верхнюю строку Received и Authentication-Results. Читайте эти две, а ко всему остальному относитесь как к показаниям свидетеля.
Можно ли найти IP-адрес отправителя в заголовке?
Обычно не тот, который вы имеете в виду. Почта, отправленная через любой крупный веб-сервис, несёт адрес исходящего сервера этого сервиса, а не машины, на которой письмо набирали; последнее провайдеры перестали публиковать много лет назад по понятной причине. Почта, отправленная приложением или небольшим сервером, часто всё ещё показывает такой адрес — в скобках, в нижней строке Received, — и эта же строка легче всего подделывается во всём блоке.
В чём разница между <code>From:</code> и <code>Return-Path:</code>?
From: — это то, что отправитель хочет показать, и это никто не проверяет. Return-Path: — это отправитель конверта, которого серверы использовали на самом деле; его вписывает в заголовок машина, принявшая письмо, и именно туда уходит письмо о недоставке. SPF проверяется против Return-Path:, а не против From:, и именно поэтому один только spf=pass говорит меньше, чем кажется. А вот выстроить эти два адреса в одну линию — это уже вся работа DMARC.
В заголовке стоит <code>dmarc=fail</code>. Значит ли это, что письмо поддельное?
Не обязательно. Пересылка ломает SPF по самой своей природе, а список рассылки, дописывающий подпись в конец письма, заодно ломает и DKIM, так что почта, ретранслированная через список, университет или правило вида «пересылать всё на мой другой адрес», регулярно проваливает проверку, оставаясь при этом полностью настоящей. Единственное, что действительно означает провал, — это то, что ничто в письме не доказывает, что домен в From: стоит за ним, а значит, всё, о чём просит вас это письмо, стоит проверить ещё и другим путём.
Для чего нужен <code>Message-ID</code>?
Это имя письма — уникальное, присвоенное отправляющим сервером, и именно на эту строку ссылаются In-Reply-To и References, когда выстраивают переписку в цепочку. Практическая польза в том, что служба поддержки и постмастеры могут найти его в своих логах: указать Message-ID — это разница между «письмо вчера не пришло» и вопросом, на который кто-то реально способен ответить.
Можно ли прочитать заголовки почты, присланной здесь на временный адрес?
Нет — письмо, прочитанное здесь, возвращается уже разобранным: отправитель, тема, дата, текст, HTML и список вложений, а необработанного блока заголовка среди этих полей нет. Компенсация в том, что одноразовый адрес — это доказательство само по себе: он был отдан ровно одной стороне, поэтому письмо, пришедшее якобы от кого-то другого, называет именно ту сторону, что его выпустила, — и никакая подпись для этого не нужна. Письма в любом случае удаляются через 5 дней.
