Як працює електронна пошта: повний технічний посібник з протоколів, кроків та архітектури

Електронна пошта залишається основою цифрової комунікації для бізнесу та приватних осіб, проте її внутрішня механіка погано зрозуміла більшості користувачів. В основі доставки електронної пошти лежить багатоетапний процес ретрансляції, що керується точним ланцюжком протоколів — SMTP для передачі, DNS MX-записи для маршрутизації та IMAP або POP3 для отримання — кожен з яких виконується послідовно, щоб перемістити повідомлення від клієнта відправника до поштової скриньки одержувача за лічені секунди.

Розуміння цієї архітектури є не лише академічним питанням. Системні адміністратори, розробники та всі, хто керує поштовим середовищем, повинні розуміти, як ці компоненти взаємодіють, щоб діагностувати збої доставки, посилювати безпеку, правильно налаштовувати сервери та уникати потрапляння до папки зі спамом. Цей посібник охоплює повну технічну картину, включаючи граничні випадки та режими збоїв, які вступні статті зазвичай оминають.

Ключові компоненти поштової інфраструктури

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

Поштовий клієнт (MUA — Mail User Agent)

Mail User Agent (MUA) — це інтерфейс, через який користувач складає, надсилає та читає електронну пошту. Приклади включають Microsoft Outlook, Apple Mail, Mozilla Thunderbird та браузерні клієнти, як-от веб-інтерфейс Gmail. MUA не доставляє електронну пошту безпосередньо одержувачу. Його завдання — передати повідомлення агенту подання пошти (MSA), який зазвичай працює на порту 587 з автентифікацією, а той, своєю чергою, передає його на вихідний SMTP-сервер.

Поширена архітектурна помилка — розглядати MUA та SMTP-сервер як єдине ціле. Це не так. MUA є клієнтом; SMTP-інфраструктура — це транспортний рівень.

Поштовий сервер (MTA — Mail Transfer Agent)

Mail Transfer Agent (MTA) — це серверне програмне забезпечення, відповідальне за ретрансляцію електронної пошти між системами. Postfix, Exim, Sendmail та Microsoft Exchange є найбільш широко розгорнутими MTA. MTA може виступати як відправником, так і одержувачем, залежно від напрямку транзакції. Саме MTA виконує DNS-запити, встановлює SMTP-з’єднання з віддаленими серверами та ставить повідомлення в чергу для повторної спроби у разі невдалої доставки.

Агент доставки пошти (MDA)

Часто overlooked у спрощених поясненнях, Mail Delivery Agent (MDA) — це компонент, який бере повідомлення, прийняте приймаючим MTA, та розміщує його у правильній поштовій скриньці користувача на диску. Dovecot та Courier є поширеними MDA. MDA застосовує квоти поштових скриньок, правила фільтрації на стороні сервера (скрипти Sieve) та записує повідомлення у відповідний формат зберігання (Maildir або mbox).

DNS та MX-записи

Система доменних імен є основою маршрутизації електронної пошти. Без дійсного MX-запису (Mail Exchange) жоден зовнішній сервер не може визначити, куди доставляти пошту для певного домену. MX-записи містять значення пріоритету — менші числа вказують на вищий пріоритет — що дозволяє адміністраторам налаштовувати основні та резервні поштові сервери. Відправляючий MTA запитує MX-записи, а потім перетворює отримане ім’я хоста на IP-адресу через запис A або AAAA перед встановленням з’єднання.

Процес доставки електронної пошти: покроково

Крок 1: Складання та подання повідомлення

Користувач пише повідомлення у своєму MUA, вказуючи адресу одержувача, тему, вміст тіла та будь-які вкладення. Вкладення та HTML-вміст кодуються за допомогою MIME (Multipurpose Internet Mail Extensions), який обгортає бінарні дані у формат base64, безпечний для передачі через текстовий SMTP. Наприклад, повідомлення з вкладенням PDF розбивається на кілька частин MIME: одна для текстового тіла та одна для закодованого бінарного файлу.

Коли користувач натискає «Надіслати», MUA відкриває автентифіковане зашифроване з’єднання з вихідним поштовим сервером — зазвичай на порту 587 (STARTTLS) або порту 465 (SMTPS). Автентифікація через SASL (Simple Authentication and Security Layer) запобігає несанкціонованому зловживанню ретрансляцією.

Крок 2: SMTP-рукостискання та передача повідомлення

Відправляючий MTA ініціює SMTP-сесію з формальним рукостисканням:

1. Клієнт надсилає `EHLO` (Extended HELO), ідентифікуючи себе за іменем хоста.
2. Сервер відповідає своїми можливостями (наприклад, STARTTLS, AUTH, обмеження SIZE).
3. Клієнт надсилає `MAIL FROM:<sender@domain.com>` для оголошення відправника конверта.
4. Клієнт надсилає `RCPT TO:<recipient@domain.com>` для оголошення одержувача.
5. Клієнт надсилає `DATA`, після чого йдуть повні заголовки та тіло повідомлення.
6. Сесія завершується командою `QUIT`.

Цей SMTP-діалог однаковий незалежно від того, чи відбувається з’єднання між клієнтом і його сервером подання, чи між двома MTA, що ретранслюють пошту через інтернет.

Крок 3: DNS-розпізнавання та пошук MX

Перш ніж відправляючий MTA зможе підключитися до сервера одержувача, він повинен визначити місце призначення. Процес відбувається у суворій послідовності:

1. Запит DNS для MX-записів домену одержувача (наприклад, `example.com`).
2. Отримання одного або кількох MX-записів, кожен з іменем хоста та значенням пріоритету.
3. Розпізнавання імені хоста MX до IP-адреси через запис A (IPv4) або запис AAAA (IPv6).
4. Спроба підключення спочатку до MX-хоста з найвищим пріоритетом (найменшим числом).

Критичний граничний випадок: Якщо для домену не існує MX-запису, RFC 5321 вказує, що відправляючий MTA повинен повернутися до A-запису домену та спробувати доставку безпосередньо. Така поведінка часто використовується в неправильно налаштованих доменах і може призводити до несподіваних шляхів доставки. Крім того, якщо MX-запис вказує на CNAME, це порушує RFC 2181 і може спричинити збої доставки у суворих MTA.

Крок 4: SMTP-ретрансляція між серверами

Після розпізнавання IP-адреси відправляючий MTA встановлює TCP-з’єднання на порту 25 з MTA одержувача. Порт 25 зарезервований для зв’язку між серверами і зазвичай блокується провайдерами для домашніх підключень, щоб запобігти спаму з діапазонів споживчих IP-адрес.

У корпоративних та хмарних середовищах електронна пошта може проходити через кілька ретрансляційних переходів перед досягненням місця призначення. Кожна ретрансляція додає заголовок `Received:` до повідомлення, створюючи відстежуваний журнал аудиту. Аналіз цих заголовків є основним методом діагностики затримок доставки та визначення місця затримки або відхилення повідомлення.

Опортуністичне шифрування STARTTLS узгоджується на цьому етапі, якщо обидва сервери підтримують його. Якщо приймаючий сервер не оголошує STARTTLS, більшість MTA повернуться до незашифрованої передачі, а не відмовлять у доставці — це відома вразливість безпеки, яку MTA-STS (Mail Transfer Agent Strict Transport Security) покликаний усунути шляхом примусового використання зашифрованих з’єднань.

Крок 5: Прийняття, фільтрація та оцінка спаму

Коли приймаючий MTA приймає повідомлення, він не одразу розміщує його у поштовій скриньці користувача. Відбувається серія перевірок:

• SPF (Sender Policy Framework): Приймаючий сервер запитує DNS домену відправника для отримання TXT-запису зі списком авторизованих IP-адрес відправлення. Якщо IP-адреса відправника не вказана у списку, перевірка SPF не проходить.
• DKIM (DomainKeys Identified Mail): Відправляючий сервер криптографічно підписує заголовки та тіло повідомлення приватним ключем. Приймаючий сервер отримує відповідний публічний ключ з DNS та перевіряє підпис. Дійсний підпис DKIM підтверджує, що повідомлення не було змінено під час передачі.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Пов’язує SPF та DKIM разом. Власник домену публікує політику DMARC, що визначає, що робити з повідомленнями, які не пройшли автентифікацію — `none` (лише моніторинг), `quarantine` (надіслати до спаму) або `reject` (відхилити повідомлення). DMARC також забезпечує зведену та криміналістичну звітність.

Після перевірок автентифікації повідомлення проходить через механізми фільтрації вмісту та оцінки спаму (SpamAssassin, Rspamd або пропрієтарні системи). Оцінки призначаються на основі аномалій заголовків, пошуку в чорних списках (RBL/DNSBL), шаблонів вмісту та репутації відправника. Повідомлення, що перевищують поріг, направляються до папки зі спамом або відхиляються повністю.

Крок 6: Зберігання та отримання з поштової скриньки

Повідомлення, що пройшли всі фільтри, передаються MDA, який записує їх до поштової скриньки користувача. Два домінуючі формати зберігання:

• Maildir: Кожне повідомлення зберігається як окремий файл у структурі каталогів. Перевагою є стійкість — пошкоджене повідомлення не впливає на інші.
• mbox: Усі повідомлення в папці об’єднуються в один файл. Простіший, але схильний до пошкоджень та проблем із блокуванням при одночасному доступі.

Поштовий клієнт одержувача потім отримує повідомлення за допомогою IMAP або POP3.

Крок 7: Отримання клієнтом через IMAP або POP3

Завершальний етап доставки — клієнт завантажує повідомлення з поштового сервера. Вибір протоколу має суттєві операційні наслідки.

Порівняння протоколів IMAP, POP3 та SMTP

IMAP є правильним вибором практично для всіх сучасних розгортань. Він зберігає повідомлення на сервері, синхронізує стан прочитано/непрочитано, структуру папок та позначки на всіх підключених пристроях у режимі реального часу. Видалення повідомлення на телефоні негайно відображається у настільному клієнті.

POP3 завантажує повідомлення на локальний пристрій і за замовчуванням видаляє їх із сервера. Це мало сенс в епоху доступу з одного пристрою та обмеженого серверного сховища, але створює серйозні проблеми в середовищах з кількома пристроями та унеможливлює резервне копіювання на стороні сервера. POP3 слід вважати застарілим протоколом для нових розгортань.

Архітектура безпеки електронної пошти: SPF, DKIM та DMARC детально

Ці три механізми утворюють багаторівневий стек автентифікації. Розгортання лише одного або двох з них залишає вразливі місця для експлуатації.

SPF — авторизація на рівні конверта

SPF перевіряє відправника конверта (адресу `MAIL FROM`, що використовується в SMTP-діалозі, а не заголовок `From:`, видимий користувачам). Типовий SPF-запис виглядає так:

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

`~all` softfail дозволяє приймати повідомлення з незазначених IP-адрес, але позначати їх. `-all` hardfail вказує приймаючим серверам відхиляти їх повністю. SPF сам по собі не захищає видимий заголовок `From:`, який бачать користувачі — саме тому необхідний DMARC.

DKIM — криптографічна цілісність повідомлення

DKIM підписує визначений набір заголовків (зазвичай `From`, `To`, `Subject`, `Date`) та хеш тіла повідомлення. Підпис вбудовується у заголовок `DKIM-Signature:`. Селектор та домен у цьому заголовку вказують на DNS TXT-запис, що містить публічний ключ. Якщо повідомлення змінюється після підписання — навіть один символ у тілі — перевірка підпису не проходить.

Важлива операційна примітка: Програмне забезпечення для розсилок та деякі конфігурації переадресації змінюють вміст повідомлення (додають нижні колонтитули, переписують заголовки), що порушує підписи DKIM. Це відома взаємодія між DKIM та менеджерами розсилок, яка вимагає ретельного налаштування.

DMARC — застосування політики та вирівнювання

DMARC вводить концепцію вирівнювання ідентифікаторів: домен у заголовку `From:` повинен збігатися або з доменом, автентифікованим SPF, або з доменом підписання DKIM. Це закриває прогалину, яку SPF залишає відкритою. Політика `reject` є найсуворішою конфігурацією:

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` та `aspf=s` застосовують суворе вирівнювання, вимагаючи точного збігу домену, а не збігу організаційного домену.

Розширені теми: MTA-STS, DANE та ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS дозволяє домену публікувати політику через HTTPS, оголошуючи, що вхідні з’єднання повинні використовувати TLS, та вказуючи, які сертифікати є прийнятними. На відміну від STARTTLS, який є опортуністичним і може бути видалений зловмисником типу «людина посередині», MTA-STS примусово застосовує шифрування. Відправляючі MTA, що підтримують MTA-STS, кешують політику та відмовляються доставляти на сервер, який не може її задовольнити.

DANE (DNS-Based Authentication of Named Entities)

DANE використовує підписані DNSSEC TLSA-записи для прив’язки конкретного TLS-сертифіката або публічного ключа до імені хоста поштового сервера. Це усуває залежність від комерційної моделі довіри центрів сертифікації для автентифікації сервера. Впровадження DANE зростає в урядовому та фінансовому секторах Європи, але залишається обмеженим у масових розгортаннях через необхідність DNSSEC як на домені відправника, так і на домені одержувача.

ARC (Authenticated Received Chain)

ARC був розроблений для вирішення проблеми переадресації, яка порушує DMARC. Коли повідомлення переадресовується через посередника (наприклад, розсилку або псевдонім електронної пошти), оригінальне вирівнювання SPF та DKIM може бути порушено. ARC зберігає ланцюжок автентифікованих заголовків `Received:`, дозволяючи кінцевому приймаючому серверу оцінити стан автентифікації на кожному переході та прийняти більш обґрунтоване рішення щодо доставки.

Поширені збої доставки електронної пошти та діагностика

Розуміння архітектури робить усунення несправностей систематичним, а не спекулятивним.

Симптом: Електронний лист повертається з повідомленням «550 5.7.1 Message rejected»

• Причина: SPF hardfail, відхилення DMARC або занесення IP до чорного списку.
• Діагностика: Перевірте повідомлення про повернення на наявність конкретної причини відхилення. Запустіть `dig TXT yourdomain.com` для перевірки SPF. Перевірте статус у чорних списках через MX Toolbox або аналогічні сервіси.

Симптом: Електронний лист доставлено до папки зі спамом

• Причина: SPF softfail, відсутність DKIM, низька репутація відправника або тригери вмісту.
• Діагностика: Перевірте заголовок `X-Spam-Status` в отриманому повідомленні. Переконайтеся, що підписання DKIM активне. Перевірте, що PTR-запис (зворотний DNS) для IP-адреси відправника відповідає імені хоста SMTP EHLO.

Симптом: Затримка електронного листа з повідомленням «451 Temporary failure»

• Причина: Приймаючий сервер тимчасово недоступний або обмежує швидкість для відправника.
• Діагностика: Відправляючий MTA автоматично поставить повідомлення в чергу та повторить спробу відповідно до свого розкладу повторних спроб. Перевірте журнали MTA для черги повторних спроб. Постійні помилки 451 від великих провайдерів часто вказують на проблеми з репутацією IP.

Симптом: Підпис DKIM не проходить перевірку на приймаючому сервері, незважаючи на правильний DNS-запис

• Причина: Повідомлення було змінено під час передачі (додано нижній колонтитул розсилки, заголовок переписано ретранслятором).
• Діагностика: Використайте інструмент перевірки DKIM на вихідному коді необробленого повідомлення. Перевірте, чи тег `h=` у заголовку DKIM-Signature включає заголовки, які були змінені.

Архітектура електронної пошти для хостингових середовищ

Для бізнесу та розробників, що розгортають власну поштову інфраструктуру, середовище хостингу безпосередньо впливає на доставлюваність та безпеку. Середовище VPS Хостинг надає повний контроль над конфігурацією MTA, PTR-записами та репутацією IP — факторами, які спільні середовища не можуть забезпечити. Запуск Postfix або Exim на VPS дозволяє точно налаштовувати обмеження швидкості, політики TLS та механізми автентифікації.

Організації, що потребують великого обсягу транзакційної електронної пошти або повної ізоляції від сусідніх орендарів, отримують вигоду від Виділених серверів, де IP-адреса відправлення призначена виключно та не ділиться з іншими клієнтами. Репутація IP на виділеному сервері повністю перебуває під контролем оператора.

Для менших операцій, що не потребують самостійно керованого MTA, Хостинг електронної пошти надає повністю кероване поштове середовище з попередньо налаштованими SPF, DKIM та DMARC, знімаючи операційний тягар підтримки програмного забезпечення поштового сервера.

Захист з’єднань вебпошти та поштових клієнтів вимагає дійсних TLS-сертифікатів. Самопідписані сертифікати генерують попередження клієнта та можуть спричиняти збої автентифікації у суворих конфігураціях MUA. Розгортання довірених SSL Сертифікатів на іменах хостів поштових серверів (наприклад, `mail.yourdomain.com`) є обов’язковою базовою вимогою для будь-якого виробничого поштового середовища.

Конфігурація домену є не менш фундаментальною. MX-записи, SPF TXT-записи, DKIM TXT-записи та DMARC TXT-записи — всі вони зберігаються в DNS. Точне та надійне керування DNS через провайдера Реєстрації доменів з потужним редактором DNS є необхідним для підтримки правильної маршрутизації пошти та записів автентифікації.

Аналіз заголовків електронної пошти: читання журналу аудиту

Кожен електронний лист містить набір заголовків, що документують його повний шлях. Вони додаються у зворотному хронологічному порядку — найвищий заголовок `Received:` є найновішим переходом. Типовий ланцюжок заголовків виглядає так:

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

Ключові заголовки для діагностики:

• `Return-Path:` — Адреса відправника конверта, що використовується для сповіщень про повернення. Повинна збігатися з SPF.
• `Authentication-Results:` — Додається приймаючим сервером, документує результати перевірок SPF, DKIM та DMARC.
• `X-Originating-IP:` — Часто додається службами вебпошти для запису IP-адреси клієнта.
• `Message-ID:` — Глобально унікальний ідентифікатор, призначений вихідним MTA. Використовується для кореляції записів журналу між серверами.
• `MIME-Version:` та `Content-Type:` — Визначають структуру MIME тіла повідомлення.

Матриця технічних рішень та ключові висновки

Використовуйте цей контрольний список при налаштуванні або аудиті поштового середовища:

DNS та маршрутизація

• MX-записи опубліковані з правильними значеннями пріоритету та вказують на дійсні імена хостів, а не CNAME
• Записи A/AAAA для імен хостів MX розпізнаються правильно
• PTR-запис (зворотний DNS) для IP-адреси відправлення відповідає імені хоста SMTP EHLO

Стек автентифікації

• SPF TXT-запис опублікований з `-all` або `~all` та охоплює всі легітимні джерела відправлення
• Ключі DKIM мають мінімум 2048 біт; селектор опублікований у DNS та підписання активне на MTA
• Політика DMARC опублікована принаймні з `p=quarantine`; налаштовано зведену звітність (`rua`)
• Режим вирівнювання DMARC встановлено на `s` (суворий) для доменів з високим рівнем безпеки

Безпека транспорту

• STARTTLS увімкнено для всіх вхідних та вихідних SMTP-з’єднань
• Політика MTA-STS опублікована, якщо потрібне суворе застосування TLS
• Дійсний TLS-сертифікат, підписаний центром сертифікації, встановлено на імені хоста поштового сервера

Конфігурація отримання

• IMAP використовується замість POP3 для всіх розгортань з кількома пристроями
• IMAP через SSL/TLS на порту 993 є обов’язковим; незашифрований порт 143 вимкнено або обмежено
• Серверна фільтрація спаму (Rspamd або SpamAssassin) налаштована з актуальними наборами правил

Операційний моніторинг

• Зведені звіти DMARC регулярно переглядаються для виявлення несанкціонованих відправників
• Черга MTA відстежується на наявність відкладених повідомлень, що вказують на проблеми з доставкою
• IP-адреса відправлення перевіряється за основними RBL (Spamhaus ZEN, Barracuda, SORBS) за розкладом

FAQ

У чому різниця між SMTP-портами 25, 465 та 587?

Порт 25 використовується виключно для ретрансляції MTA між серверами та блокується більшістю провайдерів для кінцевих користувачів. Порт 587 є призначеним портом подання для автентифікованих з’єднань клієнт-сервер та використовує STARTTLS для узгодження шифрування. Порт 465 є застарілим портом SMTPS, який обгортає весь SMTP-сеанс у SSL/TLS з самого початку; він був ненадовго застарілим, але тепер офіційно перепризначений для автентифікованого подання з неявним TLS відповідно до RFC 8314.

Чому моя електронна пошта проходить SPF, але все одно не проходить DMARC?

DMARC вимагає вирівнювання ідентифікаторів між автентифікованим доменом та доменом заголовка `From:`. SPF автентифікує відправника конверта (`MAIL FROM`), який може відрізнятися від видимого заголовка `From:`. Якщо ці домени не збігаються (відповідно до налаштованого режиму вирівнювання), DMARC не проходить, навіть якщо SPF пройшов. Виправлення полягає в тому, щоб домен заголовка `From:` збігався з доменом, автентифікованим SPF, або налаштувати підписання DKIM з доменом `From:`, щоб вирівнювання DKIM задовольняло DMARC натомість.

Що спричиняє невдачу перевірки дійсного підпису DKIM на приймаючому сервері?

Найпоширеніші причини: тіло повідомлення або підписані заголовки були змінені під час передачі (нижні колонтитули розсилки, переписування заголовків ретрансляторами); DNS TXT-запис для селектора DKIM був видалений або змінений після підписання; або публічний ключ у DNS не відповідає приватному ключу, що використовувався для підписання повідомлення. Завжди перевіряйте, використовуючи вихідний код необробленого повідомлення, а не переадресовану копію.

У чому практична різниця між IMAP та POP3 для бізнес-середовища?

IMAP синхронізує повний стан поштової скриньки — позначки прочитано/непрочитано, структуру папок, надіслані елементи, чернетки — на кожному пристрої в режимі реального часу, при цьому повідомлення залишаються на сервері. POP3 завантажує повідомлення на один пристрій і за замовчуванням видаляє їх із сервера, унеможливлюючи доступ до цих повідомлень з другого пристрою. Для будь-якого бізнесу, де співробітники отримують доступ до електронної пошти більш ніж з одного пристрою, POP3 створює ізольовані сховища даних та унеможливлює зберігання повідомлень на стороні сервера. IMAP є єдиним відповідним вибором.

Як діагностувати, чому легітимний електронний лист потрапив до папки зі спамом?

Отримайте вихідний код необробленого повідомлення з папки зі спамом та перевірте заголовок `Authentication-Results:` для перевірки результатів SPF, DKIM та DMARC. Шукайте заголовки `X-Spam-Status:` або `X-Spam-Score:`, додані фільтром приймаючого сервера, щоб визначити, які правила спрацювали. Переконайтеся, що IP-адреса відправлення має відповідний PTR-запис, не занесена до жодного RBL та що домен відправлення має повний стек автентифікації. Відсутній або невдалий підпис DKIM у поєднанні з нейтральним результатом SPF є найчастішою причиною того, що легітимна пошта отримує оцінку спаму.