Найпопулярніші помилки у поштовій хмарній інфраструктурі та як їх уникнути

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звуть Андрій і я DevSecOps, з досвідом у IT понад 25 років. Займаюся як хмарною інфраструктурою, так і bare metal.

Сьогодні мені не було чого робити і я вирішив створити науковий експеримент про те, як легко потрапити в блокування AWS SES і наскільки важко з нього вийти. Якщо щось — це сервіс для розсилки поштових повідомлень з різними прикольними прибабахами.

Сенс

Навіщо ця штука взагалі потрібна для типового айтішника? Особисто я торік у пошуку роботи запускав її на мільйон компаній, отримав перші відгуки десь на 300k, так що вона ефективніша, ніж відгуки по сайтах з погляду витрати людино годин (мене покусали менеджери, вибачте).

Але є ще неочевидні фактори, які зможуть заблокувати ваше розсилання або зробити його неефективним. Хочу показати приклад як можна «влетіти» на розсилці та що потрібно зробити, щоб виправити негативні наслідки.

Базові налаштування SES

Для тих, хто тільки збирається запускати розсилку через AWS SES і ще жодного разу не робив цього, короткий гайд.
Перше, що вас зустріне після реєстрації в SES — sandbox режим. Це така пісочниця, в якій ви можете надсилати листи тільки на заздалегідь підтверджені адреси. Звучить як знущання, але насправді це розумно — AWS просто хоче переконатися, що ви розумієте як працює цей сервіс. Щоб вийти з sandbox, потрібно подати заявку на підтримку і пояснити, що ви збираєтеся робити, кому надіслати і скільки листів на день. Обов’язково вказуйте, що типи листів — транзакцинні, а не маркетингові. Тому що це не впливає на відправлення, а от крові може попити неабияк. Можна також згенерувати приклади листів на скидання пароля, наприклад. Зазвичай схвалюють за добу-дві, якщо AI вам не нагенерувало щось зовсім дивне.
Далі починається рутина — DNS записи. Їхні три штуки і кожна робить свою справу.
SPF — це запис, який говорить поштовим серверам світу: ось список серверів яким дозволено надсилати листи від імені мого домену.

DKIM — для перевірки, що лист дійсно від вас.

DMARC — це політика, яка говорить, що робити з листами, які не пройшли перевірку.

Після того як все налаштовано та пройшло перевірку, ще треба перевірити відправку через mail-tester.com.

І останнє — налаштуйте обробку bounce і complaint повідомлень до того, як почнете надсилати листи, а не після того, як отримаєте лист щастя від AWS. У консолі SES йдете в Configuration Sets, створюєте новий, додаєте event destination — SNS topic. Далі цей topic підключаєте Lambda або SQS та обробляєте події. Логіка проста: прилетів bounce — адреса в стоп-лист, прилетіла скарга — адреса у стоп-лист, більше ніколи не надсилати. Звучить як багато роботи але насправді це пара годин якщо робити перший раз та хвилин тридцять якщо вже знаєш куди натискати.

Збір даних

Як уникнути проблем із розсилкою? Зібрати ідеальну аудиторію під неї. Але у разі аутрича (холодних розсилок) усієї інформації часто не вистачає. Наприклад, я розсилав IT-компаніям, які мали сторінку з кар’єрою та списком вакансій. Але я не шукав саме під свою позицію і це спрацювало. Перший оффер я отримав від компанії, яка тільки планувала оренду DevOps, але ще не опублікувала вакансію на сайті. Тож доводиться ризикувати.

Ризики — це bounce rate вище 10% і ще скарги, відправлення спам, і купа інших сигналів. Тут треба дивитися як на панель AWS так і на репутацію домену Postmaster Tools.

Коли щось іде не так

Одного ранку прилітає лист від Amazon SES. Не рекламне, не зі спаму — справжнє, офіційне: обліковий запис під перевіркою, bounce rate критичний, якщо не виправити — тимчасово заблокують. І дають ліміт: наступні ~44 000 листів, щоб все полагодити. Звучить як багато, але при активному розсиланні це не так вже й довго.

Перша реакція — очікувано, я цього й домагався. Друга — читати, що вони взагалі хочуть. Виявляється, AWS хочуть почути три речі: що сталося, що ви вже зробили, і чому це не повториться. Ключове слово — вже. Чи не «плануємо», не «збираємося», не «розглядаємо можливість». Лише те, що реально зроблено. Обіцянки вони не ухвалюють, перевірено особисто.

Штучний інтелектМаркетолог, якому я довіряв

Доки я розбирався з bounce rate, AWS надіслали друге зауваження. Виявляється, вони переглядали мої листи вручну і знайшли там два чудові артефакти творчості мого AI.

Перший — посилання на buymeacoffee.com у листі, який надсилався з outreach.college. З точки зору AWS це виглядає як фішинг або, як мінімум, підозріла невідповідність брендингу. Другий — футер з текстом «You received this letter because your email was found in open sources.» Ось тут я мало не впав зі стільця, тому що це прямим текстом каже AWS: так, ми збираємо бази з відкритих джерел без згоди людей. Що є грубим порушенням їхньої політики та взагалі здорового глузду.

AI додав це до шаблону «для краси». Мабуть, надивився туторіалів по холодних розсилках і скопіював чужий шаблон не думаючи. Мораль проста — читайте, що саме йде людям, перш ніж натиснути відправити. Бажано очима, а не просто «ну там все нормально». Такий кейс я навіть не планував, хотів просто вивести bounce rate максимум, а потім вирішити цей челендж.

Як я вибрався із цієї ситуації

Насамперед я зупинив відправку по всьому проблемному сегменту та прогнав базу через сервіс що перевіряє існування адреси та обчислює тимчасові пошти та інше сміття.

За шаблонами прибрав усі сторонні посилання, виправив футер. Тепер хоч одна жива людина читає лист очима одержувача, перш ніж він піде. Здавалося б очевидно — але знадобився цілий review від AWS щоб до цього дійти.

Окремий важливий момент, коли відповідаєте AWS — давайте технічні деталі. Не «у нас налаштована обробка bounces», саме: SNS topic → Lambda function → DynamoDB suppression, ось ARN, ось endpoint. Коли вони бачать реальну архітектуру — розуміють, що ви не просто відписуєтеся, а реально знаєтеся на ситуації. Це сильно змінює тон листування.

І ще одна річ, яку я зрозумів у процесі: якщо щось у їх претензії незрозуміло чи здається несправедливим — просіть зразок листа з повними заголовками. Мені це допомогло коли вони заявили про цей злощасний футер. Попросив — надіслали — розібралися.

Це ще не все

Зняття санкцій AWS — це не гарантія доставки повідомлення! Як то кажуть — я вистрілив, проблема на вашому боці.

Є ще списки блок-аркушів, куди ваш IP легко потрапляє. Для цього потрібно створити в AWS Managed Dedicated IP pool, а якщо вже був створений, видалити і створити новий.

Крім того, є ще неочевидні обмеження серед поштових систем, такі як тіньові, сірі та чорні списки, куди краще не потрапляти.

Розв’язка

Після кількох ітерацій листування — AWS кілька разів повертали листа з уточнювальними питаннями, це нормально і не треба панікувати — надійшла фінальна відповідь: «We’ve ended this review period.»

Все. Обліковий запис розблоковано. Науковий експеримент завершено, гіпотеза підтверджена: влетіти легко, вибиратися довше, але реально.

AWS просто хочуть переконатися, що ви розумієте, що робите і контролюєте свою інфраструктуру. Покажіть це конкретними діями та конкретними деталями — і все буде добре. А посилання на buymeacoffee цього разу я вставляти не став. Усі зрозуміли чому ☕