Як розпізнати фішинговий лист за його заголовками

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

Ми тримаємо сервер вхідної пошти, тож коли лист поводиться дивно, ми читаємо вихідні заголовки. У цьому посібнику ми рядок за рядком розбираємо реалістичний блок заголовків фішингового листа, а потім показуємо складніший випадок, коли всі перевірки пройдено. Під час читання можна вставити заголовки будь-якого листа в наш аналізатор заголовків email. Він працює у вашому браузері, і заголовки ніколи не надсилаються на наші сервери.

Крок перший: дістаньте заголовки з поштового застосунку

Усі поштові клієнти за замовчуванням приховують заголовки. У Gmail відкрийте лист, натисніть меню з трьома крапками поруч із кнопкою «Відповісти» й виберіть «Показати оригінал». В Outlook у браузері відкрийте меню з трьома крапками, потім «View» і «View message source». В Apple Mail на Mac виберіть «View», «Message», «All Headers». На сторінці аналізатора заголовків є шляхи в меню для 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, особливо якщо йшлося про гроші чи особисті дані.
• Якщо ви вже ввели пароль, негайно змініть його на справжньому сайті, увімкніть двофакторний вхід і змініть його всюди, де використовували повторно. Наш посібник про те, як перевірити, чи не потрапила ваша пошта у витік даних, описує першу годину після витоку.

Джерела

• 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.