Четене на кополовки: откъде е дошъл този имейл?

Модул 1: Как работи имейлът · Време за четене: 11 минути

Учебна цел: След този урок ще можете да отворите кополовките на имейл, да прочетете Received-редовете в правилния ред и да установите от Authentication-Results дали SPF, DKIM и DMARC са били изпълнени правилно.

Основни понятия: кополовки (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, X-кополовки, източник или оригинално съобщение

Какво обикновено не виждате

Вашата пощенска програма показва за дадено съобщение само няколко реда: подател, тема, дата, получатели. В действителност всеки имейл има десетки кополовки (headers) в началото, преди текста. Те се добавят от програмата на подателя и от всеки сървър, през който минава съобщението по пътя си. Заедно те образуват дневника на пътуването на съобщението.

Който може да чете кополовки, може сам да отговори на много въпроси: наистина ли този имейл е от моята банка? Защо пристигна едва след два часа? Защо е в спама? Правилен ли е моят собствен DKIM? Много задачи в този курс изискват да разгледате кополовки. В този урок ще научите как.

Отваряне на кополовките

Всяка програма има различен бутон за това:

На телефон това обикновено не е възможно. В такъв случай препратете имейла до себе си като прикачен файл или го отворете в webmail.

Пример

Иван получава имейл от Анна. Ето как изглеждат най-важните кополовки (съкратено):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Received-редове: отдолу нагоре

Всеки сървър, през който преминава съобщението, поставя ред Received: в началото. Следователно най-старият ред е най-отдолу, а най-новият е най-отгоре. Четете ги отдолу нагоре, за да проследите пътуването:

1. Долен ред: лаптопът на Анна (IP 198.51.100.77, нейната домашна връзка) предава на out.hosting.example, с ESMTPSA (буквата A означава authenticated: тя се е удостоверила) и TLS 1.3. В 10:15:04.
2. Среден ред: out.hosting.example (192.0.2.25) предава на mx1.mailprovider.example, MX записа на example.net. В 10:15:07.
3. Горен ред: пощенският сървър поставя съобщението вътрешно в пощенската кутия на Иван (LMTP). В 10:15:09.

Ред Received винаги има формата from <кой го е предал> by <кой го е приел> with <протокол>; <време>. В скобите след from стои това, което получаващият сървър сам е установил: реалното име (PTR) и реалният IP адрес. Тази част е надеждна дотолкова, доколкото се доверявате на този получаващ сървър. Това, което подателят сам е посочил (helo=), не може да бъде проверено.

Два практически трика:

• Търсене на забавяне: сравнете времената. Ако между два реда има разлика от два часа, значи съобщението е стояло толкова дълго в опашка. Внимавайте за часовите зони (+0100, +0000).
• Намиране на реалния сървър на подателя: потърсете най-горния Received ред, написан от сървър на самия получател, и вижте какво стои там след from. Всичко под него е написано от изпращащата страна и теоретично може да е измислено. В примера 192.0.2.25 е сървърът, който е предал съобщението при получателя; въз основа на него се оценяват SPF и репутацията.

Адресите

Известен трик на измамниците: From, който прилича на Вашата банка, с Reply-To към съвсем различен адрес. При съмнение винаги проверявайте домейна в From и в Return-Path, както и Authentication-Results.

Authentication-Results: преценката на получателя

Получаващият сървър записва в Authentication-Results (RFC 8601) какво е показала неговата проверка:

• spf=pass smtp.mailfrom=example.com: IP адресът на сървъра, който е доставил съобщението, присъства в SPF записа на домейна от Return-Path.
• dkim=pass header.d=example.com header.s=x: DKIM подписът на домейна example.com, със selector x, е валиден.
• dmarc=pass header.from=example.com: домейнът в From е съгласуван с успешен SPF или DKIM, следователно DMARC е успешен.

Други резултати, които можете да срещнете: fail (неуспешно), softfail (SPF завършва на ~all и IP адресът не е включен), neutral, none (няма запис), temperror (временна DNS грешка) и permerror (повреден запис, например два SPF записа). Какво точно означават те и как се поправят, е описано в модул 4.

Внимание: доверявайте се само на Authentication-Results, поставени от сървъра на самия получател (името най-отпред, тук mx1.mailprovider.example). Подправен имейл може да изпрати собствен, измислен Authentication-Results. Добрите сървъри ги премахват, но не всички.

DKIM-Signature: подписът

Кополовката DKIM-Signature е самият подпис. Често са Ви нужни две полета:

• d= домейнът, който подписва (тук example.com);
• s= selector, името на ключа (тук x).

С това можете да намерите публичния ключ в DNS: x._domainkey.example.com. В задачи и при проблеми често трябва да откриете точно тези две стойности. Едно съобщение може да има няколко DKIM подписа, например един от Вашия домейн и един от услугата за изпращане. В урок 4.3 ще разгледаме това по-подробно.

Понякога ще видите също ARC-Seal, ARC-Message-Signature и ARC-Authentication-Results. ARC (RFC 8617) е начин, по който междинни станции, като списък за разпространение на съобщения или сървър за пренасочване, записват какви са били резултатите от проверките преди те самите да променят съобщението. Не е нужно да можете да ги четете още сега.

X-кополовки

Кополовки, започващи с X-, не са стандартизирани. Спам филтрите поставят в тях своята оценка, например X-Spam-Status: No, score=1.2 или X-Spam-Flag: YES. Това помага да видите защо нещо е попаднало в спама. Те се различават според доставчика.

Обобщение

• Кополовките са дневникът на пътуването на имейла. Отворете ги с „показване на оригинала“, „изходен код на съобщението“ или нещо подобно.
• Четете Received-редовете отдолу нагоре. Редът, написан от сървъра на получателя, показва кой IP е доставил съобщението.
• Return-Path е envelope подателят (SPF), From е видимият подател (DMARC), Reply-To указва къде отиват отговорите.
• Authentication-Results дава преценката за SPF, DKIM и DMARC; доверявайте се само на тази, поставена от получаващия сървър.
• В DKIM-Signature стоят d= (домейн) и s= (selector); заедно те показват мястото на ключа: s._domainkey.d.

Тест

Задача

Задача Z1.5: Анализиране на кополовки. Изпратете си имейл от друг адрес (например от работния към личния Ви адрес, или обратно), отворете кополовките и ги поставете във формуляра. Ако нямате втори адрес, използвайте примерния файл kopregels-1.txt, който е приложен към задачата. След това попълнете сами: IP адреса на сървъра, който е доставил съобщението при получателя, домейна в Return-Path, домейна и selector-а на DKIM подписа, както и резултата от SPF, DKIM и DMARC. Програмата анализира същите кополовки, търси DKIM ключа на живо и поставя своя резултат до Вашия. Вашите кополовки не се съхраняват.

За допълнително четене

Стъпките в тези статии важат за панелите на WebOké; при други доставчици процесът е подобен.

• Проверка дали имейлът е доставен с Email Tracking в DirectAdmin
• Ръководство за DirectAdmin 9.3: E-mail Tracking: къде се е дянала моята поща?
• Това имейл съобщение истинско ли е от WebOké? Разпознаване на фишинг и използване на кода за промоцията
• Безплатен курс по DNS 4.4: DKIM: цифровият подпис под Вашата поща
• RFC 5322 (структура на имейл), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)