Как работает доставка email (пошагово)

Большинство недоразумений с доставкой писем сводятся к одному: люди не знают, что именно происходит с письмом между кликом Send и появлением его в инбоксе. Процесс занимает примерно две секунды и состоит из минимум 8 дискретных этапов, каждый со своими точками отказа. Вот вся цепочка.

Шаг 1 — SMTP submission на outbound MTA

Вы кликаете Send. Ваш почтовый клиент (или API ESP, или скрипт) открывает аутентифицированное SMTP-соединение с outbound mail transfer agent — обычно на порту 587 с STARTTLS или 465 с имплицитным TLS. MTA это ваша ESP (SendGrid, Mailgun, Postmark, SendPulse) или собственный сервер (Postfix, Exim, Haraka). Она принимает письмо в очередь на отправку.

На этом шаге ошибки — неверные учётные данные, ограничение по скорости, блокировка порта submission. Дальше MTA берёт на себя реальную работу по доставке.

Шаг 2 — DNS MX lookup для домена получателя

Outbound MTA берёт адрес получателя (например user@example.com) и спрашивает DNS: какие почтовые серверы обрабатывают письма для example.com? Это запрос MX-записи. DNS возвращает упорядоченный список — для Gmail это gmail-smtp-in.l.google.com и четыре backup-сервера с выше́й приоритностью.

Ошибки MX lookup обычно означают, что домен получателя не существует или у него нет почтового сервера — результат: немедленный hard bounce. Если MX-записи есть, но все хосты возвращают ошибки соединения — письмо попадает в retry queue и будет переотправляться 24–48 часов.

Шаг 3 — TLS handshake и EHLO

Ваша MTA подключается к MTA получателя на порту 25 и начинает SMTP диалог. Она отправляет команду EHLO со своим hostname-ом; сервер отвечает своими возможностями. Современные отправители и получатели тут же согласовывают TLS через STARTTLS.

EHLO hostname имеет значение. Gmail и Microsoft проверяют, что имя разрешается в DNS, что есть PTR (reverse DNS) запись на то же имя и что TLS-сертификат совпадает. Несовпадения снижают placement score даже если письмо не отклонено.

Шаг 4 — MAIL FROM и RCPT TO (envelope)

Ваша MTA отправляет MAIL FROM:<bounce@yourdomain.com> (envelope sender, она же Return-Path) и RCPT TO:<user@example.com>. Return-Path определяет, куда идут уведомления об отскоках, и именно по нему проверяется SPF.

Envelope From не то же самое, что header From, который видит получатель. ESP обычно используют свой домен в envelope (bounces+abc@sendgrid.net) и ваш домен в headers. Вот почему DMARC alignment важен — они должны совпадать, иначе SPF alignment не пройдёт.

Шаг 5 — DATA (тело письма)

Ваша MTA отправляет DATA, потом streaming полного письма — headers и body — с терминатором. Получающий сервер отвечает 250 OK и queue ID, говоря, что письмо принято.

Это момент, когда ваша ESP маркирует письмо как «доставленное». Но это не момент, когда письмо попадает в инбокс. Все этапы после этого происходят внутри инфраструктуры получателя, невидимо для вашей ESP. Всё, что ещё может пойти не так — это то, что ваш 99% delivery rate не измеряет.

Шаг 6 — Проверки аутентификации

Receiving MTA теперь запускает набор проверок:

• SPF: совпадает ли IP подключения с SPF-записью домена Return-Path?
• DKIM: валидна ли сигнатура DKIM-Signature header против публичного ключа в DNS?
• DMARC: прошли ли SPF или DKIM и выровнялись ли с header From доменом? Применить DMARC политику при отказе.
• ARC: прошло ли письмо через доверенные forwarders, которые заверили оригинальные результаты аутентификации?

Результаты пишутся в Authentication-Results header. Gmail и Microsoft также консультируют свои исторические данные о вашем домене и IP на этом этапе.

Шаг 7 — Сканирование контента и репутации

Теперь включается фильтр. Каждый крупный провайдер комбинирует несколько механизмов:

• Байесовские и rule-based фильтры вроде SpamAssassin и Rspamd — pattern matching по subject, headers и body.
• ML классификаторы, обученные на user feedback — Gmail's это самый зрелый, Outlook's SmartScreen близко позади.
• DNSBL и URIBL lookups против Spamhaus, Barracuda, SURBL — в чёрном списке ли ваш IP? Есть ли чёрные ссылки в теле письма?
• URL репутация — недавно зарегистрированные домены, URL shorteners, previously-flagged хосты — всё это штрафуется.
• Проверки структуры контента — есть ли plain-text часть? Ratio картинок к тексту? HTML well-formed?

Результаты комбинируются с authentication и reputation scores в один вердикт.

Шаг 8 — Решение о routing письма

Вердикт отправляет письмо в один из четырёх результатов:

• Inbox / Primary tab — хороший результат.
• Category tab (Gmail Promotions, Updates, Social, Forums) — не спам, но скрыто. Open rate там падает примерно на 80% относительно Primary.
• Spam / Junk folder — placement failure. Письмо там, но его вряд ли прочитают.
• Deferral или silent discard — худший случай. 451 4.7.1 deferrals переотправляются, но некоторые провайдеры молча выбрасывают письма при подозрении на abuse. Ваша ESP отчитывается о них как доставленные.

Шаг 9 — Рендер на клиенте

Наконец, получатель открывает почтовый клиент и письмо отображается. Разные клиенты применяют свою post-filter логику: Gmail's AI summary префетчит контент, Outlook удаляет tracking pixels, Apple Mail триггерит MPP pre-fetches. Увидит ли человек письмо на самом деле — зависит от того, куда фильтр его положил и показывает ли клиент ту папку.

Что может сломаться на каждом шаге

Краткий гайд по точкам отказа в реальном мире:

• Шаги 1–2: ваша инфраструктура — auth failures, DNS misconfig, transient ошибки.
• Шаги 3–4: PTR mismatch, TLS issues, SPF alignment failures.
• Шаг 5: rate limits, throttling (421 4.7.0), временные блокады.
• Шаг 6: сломанный DKIM selector, DMARC policy rejections, SPF record issues.
• Шаг 7: blacklist hits, risky контент, bad ссылки, suspicious patterns.
• Шаг 8: зазор между «доставлено» и реально в инбоксе — единственное, что измеряет проверка попадания в инбокс.

Частые вопросы