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

Над текстом, который вы читаете, у каждого письма есть блок заголовков. Почтовое приложение его скрывает, но именно там записано, с какого сервера пришло письмо, какой домен за него поручился и куда на самом деле уйдёт ваш ответ. Фишинг обычно выдаёт себя именно там, даже если само письмо выглядит безупречно.

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

Шаг первый: достаньте заголовки из почтового приложения

Все почтовые клиенты по умолчанию скрывают заголовки. В Gmail откройте письмо, нажмите меню с тремя точками рядом с кнопкой «Ответить» и выберите «Показать оригинал». В Outlook в браузере откройте меню с тремя точками, затем «View» и «View message source». В Apple Mail на Mac выберите «Вид», «Сообщение», «Все заголовки». На странице анализатора заголовков есть пути по меню для Outlook для Windows, Yahoo и других клиентов.

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

Заголовки фишингового письма, строка за строкой

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

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

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

Return-Path

Адрес, на который уходят уведомления об отказе, его ещё называют отправителем конверта. Здесь он на mail.example.net, а не на домене банка. Само по себе это мало что доказывает, потому что рассылки через почтовые сервисы выглядят так же. Запомните это для следующих строк.

Authentication-Results

Вердикт, который ваш почтовый провайдер записал при получении письма. SPF пройден, но для mail.example.net, сервера злоумышленника. Подписи DKIM нет. DMARC, единственная проверка, которая смотрит на видимый вами домен в From, для examplebank.com не пройден. Это самая полезная строка во всём блоке.

Received (верхняя)

Её добавил сервер вашего собственного провайдера, mx.example.com, когда принял письмо от 203.0.113.45. Строкам, которые пишет ваш провайдер, можно доверять. Всё, что ниже, написали машины, о которых вы ничего не знаете.

Received (нижняя)

Самый ранний шаг, поэтому цепочку читают снизу вверх. Письмо вышло с машины, которая называет себя desktop-4kq2, и было передано на mail.example.net с авторизованной отправкой (ESMTPA). Система уведомлений банка не работает на чьём-то домашнем компьютере. А украденный или арендованный почтовый ящик работает.

From

Отображаемое имя гласит Example Bank Security, а адрес заявляет домен examplebank.com. В это поле кто угодно может написать что угодно. Провал DMARC выше и есть доказательство того, что строка From подделана.

Reply-To

Если нажать «Ответить», ответ уйдёт на example.org, третий домен. Банку, который хочет, чтобы вы позвонили или вошли в аккаунт, незачем собирать ответы на чужом домене. Фишинг, который просит прислать данные в ответном письме, почти всегда задаёт это поле.

Тема и дата (Subject, Date)

Срочность плюс крайний срок. Date - это лишь то, что заявляет отправляющая машина, но сравните её с метками времени в Received: разрыв в часы или дни между Date и первым шагом может означать, что письмо пролежало в очереди на рассылку спама, прежде чем дойти до вас.

Message-ID

Уникальный идентификатор, который придумывает отправляющая программа. Системы крупных компаний ставят в него собственный домен. Этот заканчивается на desktop-4kq2, ту же домашнюю машину из нижней строки Received. Несовпадение здесь - подсказка, а не доказательство, ведь многие легитимные программы используют обезличенные идентификаторы.

Если сложить всё вместе, картина ясна: письмо, якобы от банка, отправлено с домашнего компьютера через чужой почтовый сервер, не прошло аутентификацию самого банка и ждёт вашего ответа на третьем домене. Когда знаешь, куда смотреть, к такому выводу можно прийти меньше чем за минуту, а анализатор заголовков сам отметит провал DMARC и несовпадение Reply-To.

SPF, DKIM и DMARC простыми словами

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

SPF

Разрешено ли этому серверу отправлять почту от имени домена отправителя конверта? Владелец домена публикует в DNS список разрешённых серверов, и получатель сверяет его с IP-адресом подключения. SPF проверяет домен из Return-Path, а не видимый вами адрес в From, поэтому фишинговое письмо может пройти SPF для собственного домена. См. SPF в нашем глоссарии.

DKIM

Подписано ли письмо каким-либо доменом и менялось ли оно после этого? Отправляющий сервер добавляет криптографическую подпись, а получатель проверяет её по открытому ключу в DNS подписавшего. Значение header.d= называет домен, который поставил подпись. Действительная подпись постороннего домена ничего не говорит о бренде в строке From.

DMARC

Совпадает ли домен из строки From с доменом, прошедшим SPF или DKIM? Именно этот шаг выравнивания связывает проверки с тем именем, которое вы на самом деле читаете. DMARC также позволяет владельцу домена сказать получателям, что делать с провалами: ничего (p=none), отправить в карантин или отклонить. Поэтому поддельное письмо всё равно может попасть во входящие, если настоящая компания не включила строгую политику.

Что означает каждый результат

Сложный случай: все проверки пройдены

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

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

Аутентификация доказывает, что это письмо отправил examplebank-secure.com. Она не может сказать, принадлежит ли этот домен вашему банку. Это уже ваша задача, и сводится она к тому, чтобы очень медленно прочитать сам домен. Вот приёмы, которые мы видим чаще всего:

• Лишние слова. Настоящее название плюс -secure, -login, -support или -verify.
• Подменённые символы. rn вместо m, ноль вместо буквы o, удвоенная или пропущенная буква.
• Другое окончание. Правильное название на .co, .net или новом домене верхнего уровня вместо того, которым пользуется компания.
• Настоящее название как поддомен. В examplebank.com.account-check.net домен - это account-check.net. Читайте домены справа.
• Похожие алфавиты. Кириллическая а выглядит точно так же, как латинская a. В исходных заголовках такие домены часто начинаются с xn--, так кодируются нелатинские доменные имена.
• Всю работу делает отображаемое имя. «Example Bank» перед адресом на бесплатном почтовом домене. Многие телефоны показывают только имя, поэтому нажмите на него, чтобы увидеть адрес.

Если вы не уверены, принадлежит ли домен компании, не используйте для проверки ничего из письма. Сами введите адрес компании в браузере и сравните.

Тревожные признаки в заголовках писем по степени важности

Одни сигналы близки к доказательству, другие что-то значат только в сумме. Примерно так мы их взвешиваем.

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

1. 1

   Скопируйте заголовки целиком

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

2. 2

   Вставьте их в анализатор заголовков

   Наш анализатор заголовков email выводит From, Reply-To и Return-Path рядом, показывает результаты SPF, DKIM и DMARC и перечисляет маршрут доставки начиная с самого раннего шага. Разбор выполняется в вашем браузере.

3. 3

   Сверьте DMARC с доменом в From

   Найдите dmarc= и домен рядом. Провала для знакомого бренда достаточно, чтобы на этом остановиться и удалить письмо.

4. 4

   Медленно прочитайте каждый домен справа налево

   From, Reply-To и домен, прошедший DKIM, должны принадлежать компании. Остерегайтесь приёмов с похожими доменами, описанных выше.

5. 5

   Читайте цепочку Received снизу

   Самая нижняя строка - это место, откуда вышло письмо. Доверяйте только строкам, которые добавил ваш собственный провайдер, вверху. Отправитель может вставить ниже них поддельные строки Received и даже поддельную строку Authentication-Results.

6. 6

   Проверьте ссылки, не нажимая на них

   Заголовки не показывают ссылки в теле письма. На компьютере наведите курсор на каждую кнопку и прочитайте адрес в углу окна. Всё, что ведёт не на настоящий домен компании, - повод уйти.

Если вы думаете, что это фишинг

• Не нажимайте на ссылки, не отвечайте и не открывайте вложения. Ответ подтверждает, что адрес читают, а вложения - обычный путь, которым приходит вредоносная программа.
• Свяжитесь с компанией другим способом. Введите её адрес в браузере или используйте номер с вашей карты или договора, но никогда не тот, что указан в письме.
• Пожалуйтесь в почтовом приложении. В Gmail откройте меню с тремя точками и выберите «Сообщить о фишинге». В Outlook используйте «Report», а затем «Report phishing». Это обучает фильтр для всех пользователей этого сервиса.
• Перешлите письмо в Anti-Phishing Working Group на [email protected], которая передаёт жалобы компаниям по безопасности и разработчикам браузеров.
• В США сообщите о письме в FTC на ReportFraud.ftc.gov, особенно если речь шла о деньгах или личных данных.
• Если вы уже ввели пароль, сразу смените его на настоящем сайте, включите двухфакторный вход и смените его везде, где использовали повторно. Наше руководство о том, как проверить, не попал ли ваш email в утечку данных, описывает первый час после утечки.

Источники

• IETF, RFC 7208: Sender Policy Framework (SPF), включая значения pass, fail, softfail и neutral.
• IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), опубликован в 2026 году и заменяет RFC 7489.
• IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status, где определён заголовок Authentication-Results.
• Федеральная торговая комиссия США, How to Recognize and Avoid Phishing Scams, адреса для жалоб в FTC и APWG.
• Anti-Phishing Working Group, Report Phishing.