← Cloudflare Email Service / email-service / concepts
Жизненный цикл письма
Жизненный цикл письма описывает весь его путь через Cloudflare Email Service. Понимание этого процесса помогает оптимизировать реализацию отправки писем и устранять проблемы с доставкой.
Email Sending и Email Routing используют разные конвейеры обработки. Исходящий поток охватывает письма, которые вы отправляете через сервис, а входящий поток охватывает письма, получаемые на доменах, настроенных для Email Routing.
Исходящий поток (Email Sending)
Каждое письмо, отправленное через Cloudflare Email Service, проходит через следующий конвейер обработки:
flowchart LR
A[Request Received] --> B["Rate Limit, Authentication & Suppression Check"] --> E[Delivery Attempt]
E --> G{Success?}
G -->|Yes, successfully delivered| F[Final Status & Metrics]
G -->|No - Soft Bounce| H[Retry with Exponential Backoff]
G -->|No - Hard Bounce| F
H -->|Retries remaining| E
H -->|Max retries exceeded| F
Сведения об этапе
-
Запрос получен: Система проверяет формат письма, авторизацию отправителя и структуру сообщения. Некорректные запросы отклоняются сразу и не переходят на следующий этап.
-
Проверка ограничения скорости: Система проверяет отправку ограничения на аккаунт, домен и получателя для предотвращения злоупотреблений. Запросы, превышающие эти лимиты, временно отклоняются, и их нужно повторить позже.
-
Аутентификация и репутация: Система выполняет проверки аутентификации писем и оценивает репутацию отправителя:
- SPF (Sender Policy Framework): Проверяет, что IP-адрес отправителя авторизован для отправки писем от имени домена, сверяясь с записями DNS TXT. Это предотвращает спуфинг домена и повышает доставляемость.
- DKIM (DomainKeys Identified Mail): Проверяет криптографическую подпись письма, чтобы подтвердить целостность сообщения и домен отправителя. Это повышает доверие со стороны серверов получателей.
- DMARC (Domain-based Message Authentication): Применяет политики владельца домена для обработки писем, не прошедших проверку SPF или DKIM, что помогает предотвращать фишинг и подделку бренда и одновременно предоставляет отчеты с обратной связью.
Эти механизмы аутентификации совместно подтверждают легитимность отправителя и защищают от мошенничества с электронной почтой. Отправители с низкой репутацией могут столкнуться с ограничением скорости или задержкой обработки.
-
Проверка по списку подавления: Система сверяет получателя со списком подавления вашего аккаунта, который включает отказы, жалобы и отписки. Получателям из этого списка письмо не доставляется.
-
Попытка доставки: Система подключается к почтовому серверу получателя и пытается доставить сообщение по SMTP. Если доставка не удаётся, система применяет разную логику повторных попыток в зависимости от типа сбоя:
- Мягкие отказы (ответы 4xx): Система повторяет попытки доставки с экспоненциально возрастающим интервалом
- Жёсткие отказы (ответы 5xx): Система помечает письмо как окончательно не доставленное, без повторных попыток
-
Обработка ответов сервера: Система обрабатывает коды ответов SMTP от сервера получателя, чтобы определить итоговый статус письма:
- коды 2xx: Письмо доставлено успешно
- коды 4xx: Произошёл временный сбой, письмо будет отправлено повторно
- коды 5xx: Произошёл постоянный сбой, и письмо не может быть доставлено
-
Итоговый статус и метрики: В зависимости от ответа сервера система присваивает письму один из следующих итоговых статусов:
- Доставлено: Письмо успешно принято сервером получателя
- Доставка не выполнена: Доставка письма окончательно не удалась (hard bounce) либо превышено максимальное число повторных попыток (soft bounce). Этот статус отображается как
deliveryFailedпри запросе к GraphQL Analytics API.
Схема обработки входящих писем (Email Routing)
Каждое письмо, полученное на домене с настроенным Email Routing, проходит через следующий конвейер обработки:
flowchart LR
A[SMTP Receipt] --> B[Authentication Check]
B --> C{Authenticated?}
C -->|Yes| D[Rule Match]
C -->|No| R[Reject]
D --> E{Action?}
E -->|Send to email| F[ARC Sign & SRS Rewrite]
E -->|Send to Worker| W[Worker]
E -->|Drop| X[Drop]
W --> Y{Worker action?}
Y -->|forward| F
Y -->|reply| F
Y -->|setReject| R
F --> G[Outbound Delivery]
G --> H[Final Status & Metrics]
Сведения об этапе
-
Приём по SMTP: Отправляющий сервер подключается к MX-серверу Cloudflare и передаёт сообщение по SMTP. Сообщения крупнее ограничение на размер входящих сообщений отклоняются на этом этапе.
-
Проверка аутентификации: Система выполняет SPF, DKIM, DMARC и ARC проверки входящего сообщения. Письма, не прошедшие проверку подлинности согласно политике DMARC отправителя, отклоняются. Письма с IP-адресов из Realtime Block List также отклоняются на этом этапе. Подробнее см. в Сведения Postmaster для получения подробностей.
-
Совпавшее правило: Система сверяет адрес получателя с настроенными правила маршрутизации. Если субадресация включена эта функция, получатели с суб-адресами обрабатываются по базовому правилу маршрутизации. Если ни одно правило не подходит и правило catch-all включено, применяется правило catch-all.
-
Действие: Система применяет действие сработавшего правила:
- Отправка на email-адрес: Сообщение пересылается на подтверждённый целевой адрес (этап 5).
- Отправка в Worker: Сообщение передаётся вашему Worker. Worker может вызывать
forward(),reply(), илиsetReject(). - Drop: Сообщение отбрасывается без уведомления. Дальнейшая обработка не выполняется.
-
Подпись ARC и перезапись SRS: Для пересылаемых сообщений система добавляет ARC-подпись, сохраняющую исходные результаты аутентификации, и переписывает отправителя конверта с помощью Sender Rewriting Scheme. Это позволяет пройти проверку SPF на сервере получателя.
-
Исходящая доставка: Система подключается к почтовому серверу назначения и доставляет сообщение. Временные отказы повторяются с экспоненциальной задержкой. Постоянные отказы возвращаются исходному отправителю в той же сессии как ошибки SMTP вышестоящего сервера. См. Postmaster: ошибки SMTP.
-
Итоговый статус и метрики: Итоговый результат фиксируется и доступен через Activity log и GraphQL Analytics API.