Тестирование писем Amazon SES

Сначала проверьте, находится ли аккаунт в песочнице, поскольку от этого зависит, будет ли все работать. Новый аккаунт SES изначально находится в песочнице в каждом Region. Пока он там, SES доставляет письма только на подтвержденные адреса, в подтвержденные домены и в собственный симулятор почтовых ящиков. Кроме того, действуют ограничения: 200 писем за 24 часа и одно письмо в секунду.

Подтверждение адреса Email Spam Tester не поможет обойти это ограничение. SES подтверждает адрес получателя, отправляя на него письмо со ссылкой. Поскольку наши адреса принимают ровно одно письмо, а затем закрываются, это письмо с подтверждением израсходует адрес. Поэтому на практике вам нужен доступ к рабочему режиму в Region, из которого вы отправляете письма. AWS обещает дать первоначальный ответ на такой запрос в течение 96 часов.

Поскольку статус песочницы задается отдельно для каждого Region, аккаунт, работающий в рабочем режиме в eu-west-1, все еще может находиться в песочнице в us-east-1. Идентификаторы также задаются отдельно для каждого Region, и у каждого из них свои записи DKIM.

Получите адрес и отправьте одно сообщение

Откройте email-spam-tester.com и скопируйте показанный адрес. Для этого не нужны учетная запись или ключ API. Адрес выглядит как test-, затем двадцать символов и домен t.email-spam-tester.com. У вас есть час и одна попытка отправки, поэтому подготовьте команду отправки до получения адреса.

Самый простой способ отправки использует CLI. Команда адаптирована из примера AWS на странице о клиентах SES, но без параметров клиента и набора конфигурации:

aws sesv2 send-email \
  --from-email-address "sender@yourdomain.com" \
  --destination "ToAddresses=test-xxxxxxxxxxxxxxxxxxxx@t.email-spam-tester.com" \
  --content "Simple={Subject={Data='Test Subject',Charset=utf-8},Body={Text={Data='Test email body',Charset=utf-8}}}"

Адрес From должен быть подтвержденным идентификатором даже в производственном режиме. Текстового сообщения без HTML достаточно, чтобы проверить аутентификацию и IP, но оно почти ничего не говорит о содержимом. Для реального результата отправьте именно то сообщение, которое отправляет ваше приложение, включая HTML-часть и заголовки. Используйте тот же программный путь, будь то send_email из boto3, библиотека SMTP или что-либо другое. Если при отправке в производственном режиме используется набор конфигурации, также добавьте здесь --configuration-set-name, чтобы тест выполнялся с теми же настройками.

Тест доставки во входящие подключается к той же команде. Добавьте адреса его ящиков у провайдеров в ToAddresses рядом с тестовым адресом, а его маркер в данные Subject. Один вызов заполнит два отчета. Во втором будет указана папка, в которую попало сообщение в Gmail, Outlook, Yahoo и у других провайдеров. Эти адреса также не подтверждены, поэтому для этого тоже нужен доступ к производственному режиму.

Можно использовать и консоль. Откройте Configuration > Identities, нажмите идентификатор и выберите Send test email. Выберите Raw, если хотите вставить полное сообщение MIME со своими заголовками. AWS описывает консоль как инструмент, который обычно используют только для тестовых писем, а в документации не указаны тестовый префикс или другие изменения сообщения. В песочнице в поле Custom recipient нужно указать подтвержденный адрес, что возвращает вас к описанной выше проблеме.

Как новая конфигурация SES выглядит в отчете

DKIM. Easy DKIM используется по умолчанию для доменных идентификаторов и подписывает каждое сообщение 2048-битным ключом. Для настройки нужны три записи CNAME с именами token._domainkey.yourdomain.com, указывающие на token.dkim.<region>.amazonses.com. Если проверка DKIM не проходит, сначала проверьте два момента: успели ли обновиться данные DNS (AWS допускает до 72 часов) и не добавил ли ваш DNS-провайдер домен к имени, создав token._domainkey.yourdomain.com.yourdomain.com. При использовании BYODKIM вместо этого вы публикуете одну запись TXT со своим селектором. Во время переключения между этими вариантами SES может отправлять сообщения вообще без подписи, что в отчете отмечается как отсутствие DKIM. В инструменте проверки DKIM токен используется как селектор.

SPF и обратный путь. По умолчанию SES использует поддомен amazonses.com в качестве MAIL FROM. SPF проходит проверку, но для amazonses.com, поэтому в отчете SPF отмечается как не выровненный с вашим полем From. Если DKIM выровнен, это почти не влияет на результат: 2 балла по 100-балльной шкале вместо 5, а DMARC по-прежнему проходит проверку благодаря DKIM. Чтобы также выровнять SPF, настройте пользовательский поддомен MAIL FROM ровно с одной записью MX, 10 feedback-smtp.<region>.amazonses.com, и записью TXT v=spf1 include:amazonses.com ~all. Не выбирайте поддомен, который принимает почту, и не добавляйте aspf=s в запись DMARC, поскольку, согласно AWS, выравнивание SPF с SES не работает при строгой политике SPF.

DMARC. SES не публикует эту запись за вас. Пример AWS: v=DMARC1;p=quarantine;rua=mailto:my_dmarc_report@example.com. Если ваши отчеты DMARC пока никто не анализирует, лучше начать с p=none и ужесточить политику позже. Инструмент проверки DMARC показывает текущую конфигурацию, а на странице DMARC fail разобраны распространенные причины ошибок.

List-Unsubscribe. SES добавляет List-Unsubscribe и List-Unsubscribe-Post, только если при отправке вы используете ListManagementOptions, указывающий на список контактов и тему. Даже в этом случае заголовки добавляются только для сообщений с одним получателем и только при использовании Easy DKIM, а SES перезаписывает любые заголовки для отписки, которые вы задали самостоятельно. Все остальные сообщения отправляются вообще без заголовков для отписки. Для рассылки это означает, что проверка List-Unsubscribe и проверка отписки одним нажатием завершатся с ошибкой, если вы не добавите эти заголовки самостоятельно. С марта 2024 года API v2 принимает пользовательские заголовки без необработанного MIME. В адаптированном примере из публикации AWS об отписке одним нажатием эти два заголовка выглядят так:

"Headers": [
  { "Name": "List-Unsubscribe",
    "Value": "<https://yourdomain.com/unsub?address=x&topic=x>, <mailto:unsubscribe@yourdomain.com>" },
  { "Name": "List-Unsubscribe-Post",
    "Value": "List-Unsubscribe=One-Click" }
]

После этого ваша конечная точка должна обработать запрос POST. Сбросы пароля и квитанции без заголовков списков относятся к другому случаю, поэтому для них в отчете группа проверок массового отправителя отмечается как пропущенная. Подробнее о заголовке читайте на нашей странице о List-Unsubscribe.

IP-адреса и блок-листы

Новые учетные записи отправляют письма с IP-адресов, общих с другими пользователями SES. AWS рекомендует использовать их, если объем отправки не является большим и регулярным. Отчет проверяет IP-адрес отправителя по 21 блок-листу. Для общих адресов попадание в блок-лист относится ко всему пулу. Выделенные IP-адреса бывают двух типов: Standard, которые вы прогреваете вручную, и Managed, прогревом которых управляет SES. В случае выделенного IP-адреса попадание в блок-лист связано именно с вашими отправками. Любой IP-адрес, найденный на вкладке Headers, можно сразу проверить с помощью проверки блок-листов.

AWS также следит за вашей учетной записью. В FAQ по применению ограничений указано, что тестировать нужно на реальных адресах, способных принимать почту, или с помощью симулятора, чтобы несуществующие получатели не увеличивали долю возвратов. Учетная запись попадает на проверку при доле возвратов 5% или доле жалоб 0,1%.

В конце приведен план исправлений, включающий до восьми изменений. Для каждого из них, где это применимо, указан DNS-запись для копирования. Баллы рядом с каждым исправлением показывают текущие штрафы за проверки, которых оно касается. Модель выбирает и объясняет исправления, но не оценивает их стоимость. Если название проверки вам ни о чем не говорит, в документации описаны все 42 проверки.