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

Если адресат не видит письмо, сначала выясните, принял ли его сервер, отверг или положил в спам. Я сопоставляю оригинал сообщения, результаты SPF, DKIM и DMARC, DNS и журналы отправки. Одна зелёная отметка не обещает входящие: ниже — порядок диагностики и границы выводов.

Письмо не дошло: выясняю, что произошло

Когда сотрудник говорит «письмо пропало», я сначала уточняю, что проверяли он и адресат: сообщение не отправилось, сервер его отверг или письмо принято и лежит в папке «Спам». Это три разных ситуации. Я сверяю время, адреса отправителя и получателя, тему и идентификатор сообщения, затем смотрю журналы отправки. Если письмо принято, прошу сохранить его оригинал с полными заголовками; пересланная копия уже не годится для точной диагностики. При настройке корпоративной почты я сразу фиксирую, где брать оригинал, журнал и очередь, чтобы поиск не начинался с гадания.

В оригинале ищу Authentication-Results: принимающий сервер обычно указывает там результаты проверок SPF, DKIM и DMARC. Доверяю только результату, добавленному почтовой системой адресата: отправитель может вложить в сообщение строку с таким же названием. Цепочку Received читаю как маршрут, но учитываю границу доверия: ранние записи могли прийти извне. Не делаю вывод по одному X-Spam-Score или X-Spam-Status: формат и пороги зависят от конкретного антиспама, а заголовка может вообще не быть. Универсального правила «пять баллов — значит спам» нет. Сначала сопоставляю результат фильтра и запись на стороне получателя, потом проверяю путь письма.

Если адресат переслал письмо вместо того, чтобы открыть оригинал в своём ящике, часть заголовков уже относится к новому маршруту. Попросите выгрузить исходное сообщение целиком или открыть полный просмотр заголовков именно у получателя. Скриншот показывает интерфейс, но не позволяет сверить DKIM-Signature, Authentication-Results и добавленные почтовыми узлами строки Received. Я также прошу один контрольный пример, который дошёл до того же адресата: так проще увидеть, отличается ли отправляющий узел, результат аутентификации или только решение фильтра. Если образца для сравнения нет, фиксирую это как ограничение, а не выдаю предположение за найденную причину.

• Уточните: отказ, задержка или папка «Спам»
• Сохраните оригинал, а не пересылку
• Запишите время и идентификатор сообщения
• Сверяйте Authentication-Results у получателя

SPF, DKIM и DMARC: проверяю связку

SPF сопоставляет IP подключившегося сервера с политикой домена отправителя конверта SMTP — MAIL FROM. Это не проверка видимого адреса From и не оценка содержания. Для домена публикуют одну SPF TXT-запись: несколько записей приводят к permerror, потому что принимающая сторона не знает, какую оценивать. Есть и лимит: при проверке учитывается не более десяти DNS-поисковых механизмов и модификаторов, которые запускают запросы; превышение даёт permerror. Это не синоним «письмо автоматически в спаме»: решение о приёме и папке остаётся за сервером-получателем. Если в результате стоит softfail, это означает, что отправитель не подтвердился как разрешённый записью SPF; это не команда получателю немедленно поместить письмо в спам. Получатель может принять его, отклонить или применить собственную фильтрацию. Поэтому я проверяю не только слово pass или softfail, но и домен, для которого выполнялась проверка, адрес реального отправляющего узла и ответ сервера на конкретное сообщение. Иначе можно исправлять SPF домена, который вообще не участвовал в этой отправке.

DKIM проверяет криптографическую подпись выбранных заголовков и тела сообщения. В Authentication-Results смотрю итог проверки и домен d= в подписи, но не сравниваю его с From на глаз: согласование доменов оценивает DMARC. Пересылка письма с другого сервера может сломать SPF, потому что адрес отправляющего узла изменился. Если подпись DKIM сохранилась и домен подписи согласован с видимым From, DMARC всё ещё может пройти. А если рассылка добавила подвал или переписала подписанный заголовок, DKIM тоже способен перестать проходить. Подробный разбор настроек вынесен в материал про SPF, DKIM и DMARC.

Для DMARC недостаточно любого SPF pass или DKIM pass: как минимум один успешно проверенный домен должен быть согласован с доменом From. Согласование бывает строгим или допускает общий организационный домен. Политика p=none просит собирать отчёты, но не требует отправлять провалившие проверку письма в карантин или отклонять их. Перед p=quarantine или p=reject я сначала нахожу все легитимные источники отправки и проверяю отчёты. Иначе жёсткая политика накажет собственную бухгалтерию за то, что её не внесли в список. Стандарт DMARC обновлён: в качестве актуальной спецификации использую RFC 9989, который заменил RFC 7489.

PTR и репутация: проверяю именно отправляющий узел

Если компания отправляет почту со своего сервера, я сверяю его имя EHLO, прямую DNS-запись и обратную запись PTR. PTR настраивает владелец IP-адреса — часто это провайдер площадки, а не администратор почтового домена. Для доставки на Gmail отправляющий IP должен иметь корректные прямую и обратную DNS-записи, причём PTR должен вести к имени, которое прямой DNS возвращает к этому IP. Это требование конкретного получателя; нельзя переносить его на все почтовые системы как гарантию доставки. По той же причине старый PTR после переноса — повод проверить маршрут и владельца записи, а не повод объявлять причину спама найденной.

Репутацию проверяю для реального IP отправки и домена, отдельно от результатов аутентификации. Запись в одном DNSBL ещё не доказывает, что все получатели блокируют почту; у разных систем собственные списки, пороги и история взаимодействия с отправителем. Смотрю отказанные адреса, жалобы, всплески объёма, используемые источники и отчёты конкретных почтовых площадок. Неактивные и ошибочные адреса удаляю из рассылки, отписки учитываю. «Прогреть новый IP за две недели» — не норматив и не обещание результата: темп зависит от отправителя, получателей и репутации. Отдельный чек-лист проверки IP есть в статье о репутации почтового IP.

Если SPF, DKIM и PTR выглядят нормально, это не повод сочинять диагноз по словам в теме письма. Слова «бесплатно» или «скидка» сами по себе не объясняют решение фильтра, а HTTPS-ссылка сама по себе не очищает репутацию. Я сравниваю образец, который дошёл, с образцом, который попал в спам: адреса, время, отправляющий узел, результаты аутентификации, ссылки и ответ принимающей системы. Затем проверяю, повторяется ли различие на нескольких сообщениях. У фильтра нет одной кнопки, показывающей всю логику; обещать обратное было бы удобной сказкой, но не диагностикой.

SMTP-отказ — не то же самое, что папка «Спам»

SMTP-код ответа помогает понять, принял ли сервер сообщение. Класс 4xx означает временный отказ: отправляющий сервер обычно ставит письмо в очередь и повторяет попытку по своим правилам. Это не обещает, что письмо обязательно доставят позже. Класс 5xx означает постоянный отказ для текущей попытки; бесконечно повторять её без изменения причины бессмысленно. Я записываю полный ответ вместе с расширенным кодом и текстом сервера, а не только первые три цифры: политика получателя может быть причиной отказа, но сам класс 5xx не сообщает, что письмо попало в спам.

Если отправляющая система зафиксировала успешную передачу следующему серверу, это доказывает только передачу на этом участке, а не появление в папке «Входящие». Тогда прошу администратора получателя проверить трассировку, карантин и правила ящика по идентификатору и времени. Если журнал показывает отказ, смотрю очередь и соединение, проверяю DNS, TLS и точный текст ответа. Не смешиваю их с папкой «Спам»: классификацию после приёма выполняет уже принимающая система. В RFC 5321 описаны временные и постоянные ответы SMTP; конкретный текст отказа всё равно читаю целиком, потому что код без контекста редко даёт готовый диагноз.

• 4xx — временный ответ, проверьте очередь
• 5xx — постоянный ответ, читайте причину
• После приёма проверяйте карантин получателя
• Сохраните полный код и текст ответа

Порядок диагностики на условном примере

В задании указан условный образовательный центр «Курс дела», 33 рабочих места. Я не приписываю ему найденные ошибки, недельный срок исправления или рост доставки: таких подтверждённых журналов и отчётов у меня нет. На этом примере показываю порядок, который применил бы к офисной почте. Сначала беру по одному оригиналу письма, которое дошло, и письма с проблемой. Записываю время, адреса, идентификаторы и отправляющий узел; у адресата уточняю, было ли сообщение принято. Если не было — начинаю с SMTP-ответа и исходящей очереди. Если было — прошу заголовки и проверку карантина.

Дальше сверяю MAIL FROM и From, SPF TXT-записи и число lookup-термов, подпись DKIM и её домен, выравнивание DMARC и политику. После этого проверяю PTR и прямую запись именно того IP, который фигурирует в журнале, а не адрес из старой документации. Сопоставляю ответ получателя с репутацией IP и домена и проверяю, нет ли в исходящей очереди неожиданной активности. Если обнаружен неизвестный источник отправки, одной правки SPF мало: проверяю учётные записи и способ отправки. Исправляю по одной подтверждённой причине и повторяю контрольную отправку; иначе невозможно понять, что изменило результат.

В конце отдаю администратору список проверенных источников, конкретные ошибки и способ перепроверки после исправления. Если причина на стороне получателя, так и говорю — наш DNS не исправит его фильтр. Письма с разными адресами и через разные маршруты могут получать разные решения; один удачный тест не доказывает, что проблема ушла у всех адресатов. Здесь важнее воспроизводимый результат и сохранённые заголовки, чем очередная перестановка записей «на всякий случай». Для контрольной проверки сохраняю исходные данные до изменений: копию записи DNS, время запроса, идентификатор сообщения и полный ответ принимающей системы. После правки сравниваю новый образец с прежним по тем же полям, а не только по тому, что письмо однажды появилось во «Входящих». Если одновременно заменить IP, переписать SPF, поменять подпись и контент, результат нельзя связать с конкретным изменением. Это тот редкий случай, когда последовательность важнее героического количества правок.

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