Тестування листів Amazon SES

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

Підтвердження адреси Email Spam Tester не допоможе обійти це обмеження. SES підтверджує адресу одержувача, надсилаючи на неї лист із посиланням. Оскільки наші адреси приймають лише одне повідомлення, після чого закриваються, цим єдиним повідомленням буде лист для підтвердження. Тому на практиці вам потрібен production access у регіоні, з якого ви надсилаєте листи. AWS обіцяє надати початкову відповідь на такий запит протягом 96 годин.

Оскільки статус sandbox визначається окремо для кожного регіону, обліковий запис із production access у eu-west-1 усе ще може перебувати в режимі sandbox у us-east-1. Ідентифікатори також належать до окремих регіонів, кожен із власними записами 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 і Return-Path. За замовчуванням 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 не публікує запис DMARC за вас. Приклад від 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-адресу з вкладки Headers можна одразу перевірити за допомогою перевірки списків блокування.

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

План виправлень унизу містить до восьми змін. Для кожної з них, де це доречно, наведено DNS-запис для копіювання, а бали поруч із кожним виправленням відповідають поточним штрафам перевірок, яких воно стосується. Модель вибирає та пояснює виправлення, але не оцінює їхню вартість. Якщо назва перевірки вам нічого не говорить, у документації пояснено кожну з 42 перевірок.