Анализ заголовков письма: кто отправил и через какие серверы шло

Что такое заголовок письма и зачем его читать

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

Часть полей знакома всем: From, To, Subject, Date. Проблема в том, что эти четыре поля отправитель заполняет сам, и подделать их не сложнее, чем написать любой другой текст. Письмо от «Сбербанка» с подходящим адресом в поле From это всего лишь строка, которую кто-то напечатал.

Ценность заголовка в других полях, которые дописывают серверы по дороге и которые отправитель контролировать не может. Received добавляет каждый узел, через который прошло письмо, поэтому цепочка читается снизу вверх и показывает настоящий путь. Authentication-Results содержит вердикт принимающей стороны по SPF, DKIM и DMARC. Return-Path хранит адрес, куда уйдёт отчёт о недоставке, и он часто не совпадает с тем, что написано в From.

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

Читать эту простыню руками не нужно. Вставьте её в форму выше, и разбор покажет цепочку, результаты аутентификации и находки, на которые стоит посмотреть.

Разбор идёт в вашем браузере

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

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

Как посмотреть заголовки письма

Каждый клиент прячет их по-своему, и формулировки меняются от версии к версии. Искать нужно исходный код письма или «оригинал».

• Gmail — откройте письмо, три точки справа сверху, Показать оригинал. Заголовки будут вверху открывшейся страницы.
• Outlook в вебе — три точки, Просмотр, Просмотреть сведения о сообщении.
• Outlook на компьютере (2016, 2019, 365) — откройте письмо двойным щелчком в отдельном окне, иначе пункт будет неактивен, затем Файл, Свойства, поле Заголовки Интернета. Поле маленькое и прокручивается, выделять содержимое удобнее сочетанием Ctrl+A.
• Apple Mail — Вид, Сообщение, Все заголовки, либо Shift+Cmd+H.
• Thunderbird — Ctrl+U покажет исходник целиком.
• Яндекс.Почта, Mail.ru, Proton — в меню письма есть пункт вида «Свойства письма» или «Показать оригинал».

Копируйте всё от первой строки до первой пустой. Пустая строка — это граница между заголовками и телом письма, и тело здесь не нужно. Вставить письмо целиком тоже можно: всё после пустой строки игнорируется.

Received: путь, записанный задом наперёд

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

Инструмент переворачивает список, поэтому первый показанный шаг это тот, с которого письмо начало путь. В каждой строке видно, кто передал письмо, кто принял, с какого адреса и когда. Разница между метками времени показывает, сколько письмо простояло на этом шаге.

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

Authentication-Results и мера доверия к нему

В этом заголовке принимающий сервер записывает, что он решил про SPF, DKIM и DMARC. Это самое близкое к вердикту, что несёт в себе письмо.

И это же само по себе бесполезно как доказательство. Заголовок пишет тот, кто письмо получил, и ничто не мешает отправителю написать такой же самому: подделка визуально неотличима от настоящего. Значимым его делает сервер, который его поставил. Строка, добавленная вашим провайдером на полученном вами письме, содержательна. Та же строка в письме, которое вам переслали, не доказывает ничего.

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

Почему DMARC не проходит при прошедших SPF и DKIM

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

DMARC не спрашивает, прошла ли проверка. Он спрашивает, чей домен её прошёл. Результат SPF засчитывается, только если домен конверта совпадает с доменом в видимом From. Результат DKIM это только если с ним совпадает домен подписи. Достаточно одного из двух, но хотя бы одно совпадение обязано быть.

Письма через рассылочный сервис регулярно проходят обе проверки и не совпадают ни по одной. Конверт принадлежит домену возвратов сервиса, подпись принадлежит самому сервису, а читатель видит в поле From ваше имя. Обе проверки настоящие, а DMARC всё равно падает: с его точки зрения в деле участвуют три разных домена.

Чинится это не добавлением ещё одного include в SPF, а подписью от своего домена. Любой серьёзный сервис это умеет: обычно вы публикуете CNAME на селектор._domainkey.вашдомен.ru, указывающий на их ключ. Как только подпись начинает нести ваш домен, выравнивание появляется само, и DMARC проходит.

Строгое и мягкое выравнивание

DMARC допускает две степени совпадения, и разница важна там, где есть поддомены.

• Мягкое (relaxed) — режим по умолчанию. Совпасть должны организационные домены, поэтому подпись от mail.example.ru выровнена с From на example.ru.
• Строгое (strict) — включается тегами adkim=s или aspf=s. Домены должны совпадать буквально, и поддомен выше уже не засчитывается.

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

О чём говорят задержки

Секунды между шагами это норма. Минута и больше обычно означает одно из двух. Либо на принимающей стороне была очередь — это ничья не вина и чинить нечего. Либо сработал greylisting: письмо намеренно отложили, потому что отправитель незнаком, и приняли, когда его сервер повторил попытку через несколько минут.

Greylisting сам по себе полезный сигнал: он случается с новыми адресами отправки и перестаёт, когда у адреса появляется история. Если он срабатывает на каждом письме с адреса, который шлёт месяцами, значит принимающая сторона вас не узнаёт, и корень обычно в обратной зоне или в том, что письма уходят с меняющегося пула адресов.

Чего заголовки не скажут

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

Для той части, которая относится к настройке, а не к доставке, чекеры записей отвечают прямее: они читают то, что опубликовано в DNS прямо сейчас, а не то, с чем столкнулось одно конкретное письмо.

Признаки фишинга в письме: что видно по заголовкам

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

Текст письма подделать легко. Заголовки подделать трудно, потому что дописывают их серверы по дороге, а не отправитель. Поэтому вопрос «настоящее письмо или нет» решается именно здесь, и разбор выше показывает всё нужное.

Вот на что смотреть по порядку.

Домен в поле From ничего не доказывает. Это обычная строка, которую отправитель заполняет сам. Письмо «от банка» с адресом на домене банка может быть отправлено кем угодно с любого сервера мира. Само по себе совпадение имени ни о чём не говорит.

Return-Path не совпадает с From. В подлинной рассылке эти адреса либо совпадают, либо принадлежат одному организационному домену. Если в From стоит банк, а в Return-Path что-то вроде набора букв на бесплатном хостинге, письмо отправлено не тем, за кого себя выдают. Оговорка: у легитимных рассылок через сервис Return-Path часто указывает на домен сервиса, и это нормально.

SPF fail у письма от известной компании. Крупные отправители настраивают SPF всегда. Отметка spf=fail в Authentication-Results означает, что письмо ушло с сервера, которому домен отправлять не разрешал. Для письма якобы от банка или маркетплейса это почти приговор.

DKIM отсутствует или подписан чужим доменом. Смотрите тег d= в заголовке DKIM-Signature. Если там домен, не имеющий отношения к отправителю из From, подпись настоящая, но принадлежит не тому. Полное отсутствие DKIM у крупной компании тоже подозрительно.

DMARC не пройден. Строка dmarc=fail означает, что ни SPF, ни DKIM не сошлись с видимым отправителем. Это самый сильный из доступных признаков, потому что он суммирует остальные.

Цепочка Received начинается не там. Читайте её снизу вверх: нижняя строка показывает, откуда письмо вышло. Если письмо якобы от российского банка, а первый узел находится на хостинге в другой стране и не имеет отношения к домену, это несоответствие.

Как отличить поддельное письмо от настоящего

Разобранные признаки складываются в ответ, но у него есть граница, и её стоит знать до того, как полагаться на зелёные отметки.

Чему заголовки не научат

Заголовки отвечают на вопрос об отправителе, а не о содержании. Письмо может быть безупречно аутентифицировано и при этом мошенническим: если взломан настоящий аккаунт, SPF, DKIM и DMARC пройдут, потому что письмо действительно отправлено с легитимного сервера.

И обратное тоже верно. Пересылка ломает SPF, а списки рассылки часто ломают DKIM, поэтому одиночный fail у письма от коллеги обычно означает не подделку, а промежуточный сервер.

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