Как работает электронная почта: полное техническое руководство по протоколам, этапам и архитектуре

Электронная почта остаётся основой цифровых коммуникаций для бизнеса и частных лиц, однако её внутренняя механика плохо понятна большинству пользователей. В своей основе доставка электронной почты — это многоэтапный процесс ретрансляции, управляемый точной цепочкой протоколов: 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)

Часто упускаемый из виду в упрощённых объяснениях, Mail Delivery Agent (MDA) — это компонент, который принимает сообщение, принятое получающим MTA, и помещает его в почтовый ящик нужного пользователя на диске. Dovecot и Courier — распространённые MDA. MDA применяет квоты почтовых ящиков, применяет серверные правила фильтрации (Sieve-скрипты) и записывает сообщение в соответствующий формат хранения (Maildir или mbox).

DNS и MX-записи

Система доменных имён (DNS) является основой маршрутизации электронной почты. Без действительной 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` позволяет принимать сообщения с неуказанных IP, но помечать их. Жёсткий отказ `-all` предписывает принимающим серверам отклонять их. 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, отклонение DMARC или занесение IP в чёрный список.
• Диагностика: проверьте сообщение об ошибке на наличие конкретной причины отклонения. Выполните `dig TXT yourdomain.com` для проверки SPF. Проверьте статус в чёрных списках через MX Toolbox или аналогичный сервис.

Симптом: письмо доставлено в папку со спамом

• Причина: мягкий отказ SPF, отсутствие 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) по расписанию

Часто задаваемые вопросы

В чём разница между портами 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 является наиболее частой причиной того, что легитимная почта оценивается как спам.