Настройка AWS SES: почему письма падают в спам
Письмо, ушедшее в спам, — это не пришедший сброс пароля, потерянная регистрация и клиент, который так и не узнал о счёте. Отправка при этом формально работает: запрос уходит, сервер отвечает, в отчётах ноль ошибок доставки. Ломается не код, а репутация домена и подпись сообщения.
Типовая причина — домен не подписан DKIM, в DNS нет селектора, а SPF заканчивается на мягком правиле. Провайдер получает письмо без криптографической подписи и без выравнивания домена отправителя, поэтому оно уходит в спам или в карантин. Лечится это не правкой шаблона, а настройкой AWS SES: подтверждение домена, публикация селекторов, включение подписи и политика DMARC хотя бы в режиме наблюдения с отчётами.
Второй источник — жалобы и отклонённые письма. Адрес, которого больше нет, при каждой отправке даёт постоянный отказ; пока отказы не обрабатываются, доля ошибок растёт и аккаунт переводят в ограниченный режим с урезанной скоростью отправки. Ручная отправка из консоли или скрипта без подписки на уведомления о доставке, отказах и жалобах означает, что мы не знаем, кто именно отвалился, и продолжаем тратить репутацию на тот же список.
Доставляемость писем строится на логике, а не на удаче: очередь с повторными попытками для временных отказов, немедленное исключение адреса при постоянном отказе, отписка при жалобе. Для транзакционных писем это обязательный минимум — иначе метрики зависят от случая. Разбираем, как это выстроить по шагам.
Что даёт корректная работа с AWS: доставляемость и репутация домена
Корректно выставленные DKIM-подписи и политика DMARC — это не формальность: получатели перестают помечать поток как подозрительный, и доля писем, попавших во входящие, перестаёт скакать от рассылки к рассылке. Репутация домена превращается в предсказуемую метрику, а не в результат удачи, и по ней видно эффект каждого изменения в настройках.
Прогрев отправителя снимает главную причину провалов на старте: объём отправки наращивается постепенно, и репутация не обваливается от резкого скачка. Отдельно отслеживается, какая доля писем уходит в спам у основных получателей, — при ровном прогреве она держится в пределах десятых долей процента.
Время доставки писем сокращается до минут и выравнивается по всем сегментам базы; если очередь встала, видно, на каком участке. Обработка отказов работает автоматически: жёсткие отказы выводят адрес из активного списка, мягкие повторяются с нарастающей паузой, поэтому ручная чистка базы исчезает как регулярная задача.
Доля жалоб на спам остаётся ниже порога, после которого провайдер начинает резать поток целиком. По каждой кампании видно, какой сегмент даёт всплеск, — его отключают до того, как просядет вся отправка по домену.
Режимы отправки: общий шлюз, свой домен или выделенный канал
Перед запуском рассылок AWS SES предлагает три режима, и выбор между ними определяет, сколько работы ляжет на инфраструктуру дальше. По умолчанию аккаунт находится в тестовом режиме отправки: письма уходят только на подтверждённые адреса, а лимиты отправки минимальны. Рабочий режим открывается после подтверждения домена и настройки аутентификации — SPF, DKIM и DMARC.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Общий шлюз отправки | Пилот, небольшой объём транзакционных писем | Репутация адресов общая с другими отправителями, лимиты общие — доставляемость зависит не только от вас |
| Свой домен с подтверждением и DKIM | Регулярные письма от своего бренда, нужен контроль репутации | Настройка DNS-записей и прогрев; ошибка в DKIM или несовпадение с политикой DMARC останавливает отправку |
| Выделенный канал отправки | Большие объёмы, жёсткие требования к доставляемости | Нужен прогрев и постоянный поток писем; пауза в отправке просаживает репутацию адреса |
Чем платят за каждый режим: общий шлюз экономит время на прогреве, но размывает ответственность за репутацию; свой домен даёт предсказуемость, требуя дисциплины в DNS; выделенный канал снимает зависимость от соседей, но не прощает простоев и всплесков объёма. Во всех режимах bounce handling и обработку жалоб настраивают отдельно — без них лимиты отправки срезаются автоматически, и рассылка останавливается на середине.
Этапы внедрения: от аудита DNS-записей до передачи регламентов
Порядок работ фиксированный: снимаем картину почтовой инфраструктуры, затем настраиваем конфигурацию отправки и подпись, и только потом включаем жёсткие политики. Пропущенный аудит оборачивается конфликтом записей и спамом.
- Аудит DNS и текущей почты. Сверяем SPF со всеми сторонними отправителями, MX, существующие селекторы DKIM, TTL и поддомены. Фиксируем, кто ещё шлёт письма от имени домена.
- Схема доменов и конфигурация отправки. В AWS SES задаём поддомен под рассылку, регион, суточный лимит отправки и поведение при его превышении. Транзакционные и маркетинговые потоки разводим, чтобы репутация одного не топила другой.
- Подпись DKIM. Публикуем публичный ключ CNAME-записью, включаем подпись, сразу готовим второй селектор под ротацию — переключение без простоя.
- SPF, MAIL FROM, черновая DMARC. Настраиваем собственный поддомен под выравнивание отправителя, публикуем DMARC в режиме мониторинга с отчётами: сначала собираем статистику, а не блокируем.
- Обработка отказов и жалоб. Жёсткие отказы уводим сразу в стоп-лист, мягкие — с повторами. Иначе отправки на несуществующие адреса быстро съедают репутацию.
- Проверка подписи и мониторинг доставки. Тестовые письма на внешние ящики, разбор заголовков на выравнивание DKIM и SPF, алерты по доле отказов и жалоб.
- Передача регламентов. Документация: ротация ключей, добавление отправителей в SPF, порядок ужесточения DMARC и разбор инцидентов.
Дальше команда сама добавляет отправителей и ужесточает политику по данным отчётов.
Что остаётся у вас после сдачи: записи, конфигурации, регламенты
Сдача — это не момент, когда «письма уходят». У вас на руках остаётся комплект артефактов, по которому команда сможет менять домен, добавлять новые потоки писем и разбирать инциденты без нас. Каждый документ привязан к реальной конфигурации в сервисе рассылки, а не написан «по мотивам», поэтому расхождений между описанием и продом не возникает.
- Набор почтовых записей для домена: значения SPF, публичные ключи DKIM и политика DMARC с пояснением, какой тег за что отвечает и в каком порядке их менять при смене провайдера.
- Схема маршрутизации: какие потоки идут через основной домен, какие через поддомен, как разделены транзакционные и сервисные письма, куда возвращаются ответы.
- Политика подписи: владелец ключа, срок ротации, порядок перевыпуска без окна недоставки.
- Регламент обработки отказов: разбор жёстких и мягких ошибок, пороги, после которых адрес уходит в список подавления, и порядок снятия.
- Правила работы с репутацией: лимиты отправки, прогрев новых потоков, что делать при падении доставляемости.
- Инструкция для поддержки: как по заголовкам письма определить причину недоставки и в какой журнал смотреть.
- Матрица доступов: где хранятся ключи, кто вправе править записи, как передать это при смене ответственного — плюс чек-лист приёмки из тестовых сценариев.
Кейс: транзакционные письма перестали попадать в спам
Клиент пришёл с транзакционными письмами: подтверждение регистрации, сброс пароля, чеки. Во «Входящие» попадало около 62% отправлений, остальное оседало в спаме и на вкладке «Промоакции», а доля отказов держалась на 8% — базу адресов годами не чистили, и каждый отказ поддержка разбирала руками.
Что изменили в потоке
Развели транзакционный и рекламный потоки по отдельным поддоменам: акционные рассылки перестали тянуть вниз репутацию чеков. На отправке через Amazon SES включили подпись DKIM и политику DMARC с отчётами, а отказы и жалобы завели в автоматику — адрес с жёстким отказом сразу уходит в список исключений, жалоба поднимает уведомление дежурному. Объём исходящих наращивали постепенно, чтобы репутация не проседала под нагрузкой.
Через месяц во «Входящие» попадает 98-99% писем, отказы — 0.8%, ручные разборы сократились с полусотни обращений в неделю до трёх-четырёх, реакция на жалобу — с двух суток до часа. Жалобы раньше приходили в общий ящик и терялись, теперь они автоматически привязаны к потоку и адресу.
Скрытой ценой были повторные обращения: не дошедший сброс пароля — это тикет в поддержку и клиент, который не вернулся. Сейчас такие сбои видно в метриках доставляемости раньше, чем они превращаются в поток жалоб.
Что делать, если домен уже развёрнут и часть писем отклоняется?
Частичная доставка почти всегда означает не поломку почты, а неполную настройку подписей. DKIM может быть включён только на одном потоке — например, на письмах из CRM, — а регистрационные и счётные уведомления уходят через другой релей вообще без подписи, и именно они попадают в отклонённые. Первый шаг — не менять настройки, а разложить отказы по потокам отправки и посмотреть заголовки Authentication-Results у получателей.
Дальше проверяем выравнивание: домен в поле From должен совпадать с доменом в DKIM-подписи и в SPF-записи. Если подпись стоит с технического поддомена, а письмо отправлено с основного адреса, жёсткая политика DMARC отклонит его даже при валидной подписи. Второе — сама политика: в режиме наблюдения она только собирает отчёты, а в карантинном и запрещающем начинает отсекать всё невыровненное, и это происходит внезапно, если домен уже развёрнут и статистику никто не читал.
Отбои и жалобы на спам — вторая причина частичной доставки. Без их обработки адреса с ошибками остаются в базе, повторные попытки копят отказы, и провайдеры начинают резать весь домен целиком, а не отдельные адреса. Amazon SES отдаёт события отбоя и жалоб отдельным потоком, поэтому база чистится автоматически, а не вручную по логам.
Переход на полную подпись делают без остановки отправки. Сначала подписываем все потоки и настраиваем раздельный поддомен для массовых рассылок, потом несколько недель копим отчёты, и только после этого ужесточаем политику ступенями — от наблюдения к карантину и дальше. На каждом шаге видно, какие источники ещё не выровнены.
Пока политика ужесточается, новые письма идут с полной подписью и вычищенным списком. В итоге доля отклонённых определяется качеством базы, а не настройками домена.
Технические сомнения: репутация, лимиты и разбор отказов
Лимиты в Amazon SES не статичны: суточная квота и скорость отправки растут вместе с репутацией, а на старте они минимальны. Прогрев домена, очередь с повторными попытками и оповещение о приближении к квоте не дают пикам рассылки упираться в отказ.
Репутация держится на трёх показателях: доля отказов, доля жалоб и подлинность писем. Подпись DKIM, выровненный SPF и политика DMARC — не формальность, а условие, при котором крупные почтовые провайдеры принимают письма во «Входящие».
Письма упираются в лимит отправки — что происходит?
Превышение частоты сервис возвращает как ошибку ограничения скорости, исчерпание суточной квоты — как отказ. Очередь с нарастающей задержкой досылает такие письма, а не теряет их; оповещение приходит до того, как рассылка начнёт тормозить.
Как понять, что адрес попал в чёрный список?
Мониторим публичные списки и отчёты о доставке: рост отказов отдельного класса и падение доли открытий видны раньше, чем провайдер начнёт отклонять весь поток. При попадании — заявка на исключение, пауза на проблемном направлении и разбор источника жалоб.
Получатели жалуются на спам — насколько это критично?
Жалоба весит заметно больше обычного отказа. Поэтому подписка только с подтверждением, видимая ссылка на отказ в каждом письме и раздельные потоки для транзакционных и маркетинговых отправлений — жалобы по рассылке не утягивают подтверждающие письма.
Кто поддерживает записи проверки подлинности после сдачи?
Ключи DKIM ротируются, политика DMARC проходит путь от наблюдения к карантину и отклонению, сводные отчёты разбираются — так видно, кто ещё отправляет почту от вашего домена. Передаём схему записей, настройки уведомлений и регламент ротации: команда ведёт это сама или остаётся на сопровождении.
Обсудим задачу: вернёмся с оценкой и планом внедрения
Чтобы вернуться с оценкой работ, а не с общими формулировками, нам достаточно исходных данных по домену и потокам писем. Всё это собирается за один проход по зоне DNS и панели отправки, без остановки текущих рассылок.
- домены и поддомены для отправки, текущие записи в зоне — SPF, DKIM, DMARC и выставленные для них режимы;
- объёмы: писем в сутки и в месяц, пиковые всплески, доля транзакционных и массовых рассылок;
- текущий отправитель и причины переезда — попадание в спам, жалобы, блокировки адресов получателей;
- как сейчас разбираются отказы: кто смотрит жёсткие и мягкие, есть ли журнал доставки и уведомления о событиях;
- требования к согласиям и хранению данных получателей, география аудитории, ограничения по содержанию писем;
- шаблоны, подписи, ссылки отслеживания переходов и правила брендирования в теле письма;
- доступ к аккаунту либо готовность выдать роль с ограниченными правами на время работ.
По этим данным мы собираем план внедрения: последовательность этапов, что требуется с вашей стороны на каждом, и какие проверки подтверждают результат — от подтверждения домена до разбора первых отказов и жалоб. Обсудим задачу с инженерами, которые ведут Amazon SES в рабочей среде: опишите контекст, объёмы и текущие проблемы — вернёмся с оценкой и планом.
