Amazon SES диагностика

1. С чего начать диагностику Amazon SES

В консоли SES (Configuration -> Account dashboard) проверьте статус аккаунта (Healthy или Paused) и метрики bounce rate и complaint rate, в Configuration -> Identities - статус домена, DKIM и MAIL FROM. Это дает первичную картину: где падают письма и не приостановлена ли отправка из-за жалоб или отказов.

В Postmaster Tools получателей (Google Postmaster Tools, Mail.ru Postmaster) смотрите долю жалоб и доставку за последние 7-14 дней: резкое ухудшение обычно совпадает с изменением DNS, потоком или доменом MAIL FROM.

Если у вас уже подключен PostmastersTool, откройте карточку домена: там видно доли SPF/DKIM/DMARC, долю жалоб и факт соответствия требованиям Google. Это позволяет за 2 минуты понять, касается ли проблема именно аутентификации.

2. Аутентификация: SPF, DKIM, DMARC для SES

Без Custom MAIL FROM домен MAIL FROM (Return-Path) у писем через SES - это поддомен amazonses.com, и SPF по нему проходит за счет собственной записи Amazon: никакой SPF-записи на вашем домене для этого не нужно. Проблема в том, что домен из Return-Path не совпадает с доменом в From, поэтому SPF-выравнивание для DMARC не проходит. Именно ради выравнивания и подключают Custom MAIL FROM (раздел 3).

DKIM Amazon SES подписывает сам (Easy DKIM), но ключ нужно опубликовать в вашей DNS-зоне: SES выдает три CNAME-записи вида xxxxx._domainkey.example.com, и без них статус DKIM в Identities останется Pending, а затем Failed, и письма будут уходить без подписи.

В Configuration -> Identities откройте домен и вкладку Authentication: там статус самого домена (Verified/Pending), статус DKIM (Success/Pending/Failed) и статус Custom MAIL FROM, если он настроен. После добавления CNAME в DNS изменениям может понадобиться до 72 часов на распространение и проверку - это официальный ориентир SES, не TTL в минутах.

Начинайте DMARC с p=none и тегом rua=mailto:адрес_для_отчетов, чтобы не терять письма и видеть, что реально проходит выравнивание. К quarantine и тем более reject переходите только после того, как отчеты покажут стабильный проход SPF или DKIM (для DMARC достаточно, чтобы прошел один из двух механизмов). Проверить запись можно через dig TXT _dmarc.example.com или любой онлайн-анализатор DMARC.

3. Custom MAIL FROM и поддомен

Custom MAIL FROM заменяет технический домен Return-Path с поддомена amazonses.com на ваш собственный, например mail.example.com. Для этого домена нужны ровно две записи: MX с приоритетом 10 на feedback-smtp.<регион>.amazonses.com и TXT-запись SPF v=spf1 include:amazonses.com ~all - обе публикуются на самом поддомене mail.example.com, а не на корневом домене или домене From.

Если MX-запись SES не находит, поведение зависит от настройки Behavior on MX failure: вариант Use default MAIL FROM domain откатывает отправку на amazonses.com (без выравнивания, но без остановки отправки), вариант Reject message возвращает ошибку MailFromDomainNotVerified и блокирует отправку с этого домена. Типовая ошибка - MX опубликован в другом регионе, чем регион отправки SES, тогда SES не находит нужную запись и статус Custom MAIL FROM остается Failed.

После настройки поддомен для Custom MAIL FROM не имеет истории отправки у получателей: наращивайте объем постепенно и следите за долей жалоб на каждом шаге, а не только на старте. Подробный план прогрева - в отдельном материале, ссылка ниже.

4. Suppression list, bounce и жалобы

Account-level suppression list в SES ведется по двум причинам - Bounce и Complaint - варианта "Manual" в списке причин нет: даже адрес, добавленный вручную через API, помечается одной из этих двух причин. Автоматически в список попадают только адреса с постоянным отказом (hard bounce); временные отказы SES не подавляет.

Bounce-события SES бывают двух типов: Permanent (постоянный отказ, соответствует ответам SMTP 5xx - адрес не существует) и Transient (временный отказ, ответы 4xx - переполнен ящик, сервер временно недоступен). Оба типа приходят в уведомлениях с полями bounceType, bounceSubType и diagnostic code, поэтому "все отказы - это 5xx" не так: временные тоже фиксируются и информативны для диагностики.

AWS ориентируется на следующие пороги: bounce rate стоит держать ниже 2%; при 5% и выше аккаунт переводится в статус under review, при 10% и выше отправку могут приостановить (sending paused). Для жалоб ориентир ниже 0,1%; при 0,1% и выше - under review, при 0,5% и выше - возможна приостановка. Текущий статус виден в Account dashboard (Healthy или Paused); восстановление отправки - через обращение в AWS Support Center с описанием того, что исправлено.

Важная особенность: Gmail не передает данные о жалобах в SES через feedback loop, поэтому complaint rate в самой консоли SES не отражает жалобы получателей на Gmail. Для потоков с заметной долей Gmail ориентируйтесь на долю жалоб из Google Postmaster Tools, а не только на метрику SES.

У Mail.ru свой порог жалоб, отдельный от порогов SES и Gmail, и зависит он от объема рассылки в месяц: до 10 000 писем - 1,1%, до 500 000 - 1%, до 10 000 000 - 0,8%, до 50 000 000 - 0,5%, свыше 50 000 000 - 0,3%. Смотреть его нужно в Mail.ru Postmaster, а не в консоли SES.

5. Дерево диагностики: что именно проверить

6. Как отделить проблему SES от проблемы списка и контента

Проведите A/B: 1000 адресов на текущей базе против 1000 свежих double opt-in адресов через тот же SES и тот же домен. Если первая группа сыпется, а вторая проходит - проблема в базе и жалобах, а не в SES.

Проверьте заголовок письма в анализаторе: видно Authentication-Results, фактические значения SPF, DKIM, DMARC, IP отправки и наличие List-Unsubscribe. Это дает независимый взгляд: что именно видит получатель.

Контент редко виноват сам по себе, если аутентификация в порядке и база согласна на рассылку. Но если в письме только изображения, нет текстовой версии или много ссылок на короткие URL - фильтры получателя растят спам-score. Сверяйтесь с отдельным материалом про контент и ссылки.

7. Проверка результата и оповещения

После правок в DNS новым данным нужно время: Google Postmaster Tools обычно обновляется в течение суток, но может задержаться дольше; Custom MAIL FROM и верификация DKIM в самой SES - до 72 часов. В PostmastersTool включите уведомления в Telegram или на почту при превышении порогов жалоб и при падении долей аутентификации - так вы узнаете о регрессе не из тикета, а до того, как рассылка встанет.

Регулярно сверяйте: статус DKIM и Custom MAIL FROM в SES, набор CNAME и MX в DNS (не удалил ли их регистратор при обновлении), suppression list и динамику жалоб в Postmaster. Отдельно проверьте домен по черным спискам, ссылка в сервисах ниже.

Если после всех правок метрики не восстанавливаются заметное время, это повод пересмотреть выбор домена или потока: возможно, нужен отдельный поддомен под текущую рассылку с собственным прогревом.