Анализ заголовков письма

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

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

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

Как достать заголовки

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

• Gmail — откройте письмо, три точки справа сверху, Показать оригинал. Заголовки будут вверху открывшейся страницы.
• Outlook в вебе — три точки, Просмотр, Просмотреть сведения о сообщении.
• Outlook на компьютере — откройте письмо в отдельном окне, затем Файл, Свойства, поле Заголовки Интернета.
• 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 прямо сейчас, а не то, с чем столкнулось одно конкретное письмо.