Налаштування 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 у робочому середовищі: опишіть контекст, обсяги та поточні проблеми — повернемося з оцінкою та планом.
