Електронна пошта: зовнішня репутація впала — що припинити робити негайно (і як виправити)

Припиніть робити це негайно

1) Перестаньте «тестувати», розсилаючи всім одночасно

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

Замініть масове тестування контрольними вибірками: перевірений seed-лист і невеликий піднабір найбільш залучених одержувачів (останні відкриття/клацання/відповіді). Якщо ви не можете виміряти залученість, це не причина продовжувати масову розсилку; це причина сповільнитися.

2) Перестаньте надсилати з нових доменів «щоб виправити» проблему

«Просто надсилаймо з іншого домену» — це борг з доставлюваності з відсотками. Провайдери корелюють інфраструктуру, URL, контент і поведінку. Крім того, ви втрачаєте весь позитивний рейтинг, який мали. Виправляйте проблему, а не перейменовуйте її.

3) Перестаньте ігнорувати відмови і нескінченно повторювати спроби

Ваш MTA охоче повторює 4xx-відповіді. Це правильно для тимчасових помилок, але якщо ви отримуєте тимчасові відмови через тротлінг або модель репутації, потрібні контролювання швидкості та стратегія придушення, а не нескінченний оптимізм.

4) Перестаньте надсилати пошту без автентифікації (або «майже» автентифіковану)

SPF pass з DKIM fail — це не «гаразд». DMARC pass без вирівнювання — теж не «гаразд». У 2026 році основні провайдери жорсткіше ставляться до автентифікованих, вирівняних листів. Вам не потрібна ідеальність, але припиніть відправляти неавтентифіковану або неправильно вирівняну пошту, як у 2009 році.

5) Перестаньте надсилати маркетингову і транзакційну пошту під одним і тим же ідентифікатором

Змішування щотижневого розсилання з повідомленнями про скидання пароля під тим самим доменом і IP — це спосіб випадково навчити Gmail, що «ваші коди для входу мають той самий стиль, що й розпродаж». Розділяйте потоки: субдомени, різні DKIM-селектори, окремі пулі IP, якщо ви достатньо великі.

6) Перестаньте змінювати п’ять змінних одночасно

Коли ви в один день правите SPF, ротируєте DKIM, змінюєте From-домен, переходите на іншого ESP і змінюєте шаблони, ви втрачаєте можливість відстежити причину. Ставтеся до доставлюваності як до інциденту: одна зміна, вимірюваний вплив, опція відкату.

Короткий жарт #1: Репутація в пошті — як кредитний рейтинг: її можна зіпсувати швидко, а оскарження клавіатурним хапанням не допоможе.

Швидкий план діагностики (перший/другий/третій)

Це шлях «отримати сигнал за 30 хвилин». Він не вирішить усе, але швидко виявить вузьке місце і убере здогадки.

Перший крок: визначте режим відмови (доставляння vs розміщення vs приймання)

• Помилка доставляння: відмови, відкладення, блокування, зростання черги, помилки SMTP.
• Проблема розміщення: прийнято (250 OK), але лист потрапляє в спам/розсилки/карантин.
• Прийнято, але не бачать: правила користувача, корпоративний карантин, журналювання або проблеми маршрутизації.

Швидкий тест: візьміть 10 останніх повідомлень, зберіть логи SMTP-транзакцій і класифікуйте. Не покладайтеся на «користувач каже, що не отримав». Користувачі також кажуть «я нічого не змінював».

Другий крок: перевірте автентифікацію й вирівнювання (SPF/DKIM/DMARC)

• Чи вирівняний домен у полі From: з SPF (MAIL FROM / Return-Path) або з DKIM d= доменом?
• Чи присутні DKIM-підписи і чи перевіряються вони?
• Чи існує політика DMARC і чи бачите ви невдачі?

Більшість раптових падінь репутації пов’язані з регресіями автентифікації після переходу постачальника, зміни DNS або зміни ланцюжка шаблонів.

Третій крок: подивіться на профіль відмов і скарг

• Hard bounces: невідомий користувач, недійсний домен. Їх слід швидко пригнічувати.
• Soft bounces / тротлінг: обмеження швидкості, «спробуйте пізніше», тимчасові відмови через репутацію.
• Скарги: користувачі натискають «спам». Якщо ви не отримуєте фідбек зі свого ESP, скарги все одно є — просто ви не отримали повідомлення.

Четвертий крок: ізолюйте потоки і зменшіть обсяг

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

П’ятий крок: перевірте ідентичність інфраструктури (rDNS, HELO, TLS)

Багато блокувань виникають від сигналів «це виглядає як інфраструктура шкідливого ПЗ»: відсутні PTR записи, загальний HELO або поламані TLS. Це легкі перемоги.

Як репутація насправді працює (те, що забувають)

Репутація багатовимірна, а не один показник

Поштові провайдери не зберігають одне чарівне число для вас. Вони відстежують репутацію за кількома вимірами:

• Репутація домену (домена в From:, який бачить користувач)
• Репутація субдомену (news.example.com проти example.com)
• Репутація IP (особливо для виділених IP)
• Репутація URL (куди ведуть ваші посилання, включно з редиректами)
• Репутація контенту та поведінки (шаблони, рядки теми, патерни взаємодії)
• Репутація на рівні одержувача (як ваша пошта поводиться для конкретного провайдера)

Тому коли хтось каже «наш домен згорів», перше питання: який домен, який потік, який провайдер і який часовий інтервал?

Провайдери оптимізують під користувацький досвід, а не під налаштування відправника

Мета фільтрації — «користувачі не дратуються і не піддаються фішингу». Ваша мета — «мій бізнес-листи бачать». Ці цілі збігаються лише якщо ви поводитеся добре. Якщо якість списку падає, жодна магія з DNS не врятує повністю.

Автентифікація — базова вимога; вирівнювання — головна гра

SPF і DKIM — механізми автентифікації. DMARC — рівень політики та звітності, який вводить вирівнювання: домен, видимий користувачеві, має відповідати автентифікованому домену. Багато відправників «проходять SPF» через домен ESP для bounce-ів, але провалюють DMARC, бо From: домен не вирівняний.

Відновлення репутації — як формування трафіку після аварії

Якщо вас обмежили по швидкості, ви не доводите свою доброчесність відправленням більше листів. Ви доводите її, відправляючи послідовно, людям, які хочуть вашу пошту, з низьким рівнем відмов і скарг. Warm-up — це дисципліна операцій, а не маркетинговий оптимізм.

Цитата (парафразована): Gene Kim часто підкреслює, що надійні системи виникають завдяки дисциплінованим, повторюваним практикам, а не героїзму. Те саме стосується доставлюваності.

Цікаві факти та історичний контекст (те, що пояснює сучасні правила)

1. SMTP з’явився раніше за спам. Початковий поштовий протокол передбачав дружню мережу; механізми автентифікації та контролю зловживань були додані пізніше.
2. SPF і DKIM з’явилися через різні проблеми. SPF стосувався валідації IP-відправника; DKIM — цілісності повідомлення й відповідальності домену.
3. DMARC зробив «вирівнювання» мейнстримом. До DMARC «pass чогось» було достатньо; DMARC зробив видимий домен підзвітним.
4. Системи репутації — відповідь на масштаб. Коли провайдери почали обробляти мільярди повідомлень, ручні whitelist-и померли, а статистична фільтрація взяла верх.
5. Грейлістинг колись був модним. Тимчасові відмови, щоб змусити повторити, використовувалися для відсіювання спаму. Сьогодні це більше карає погано налаштованих відправників і вразливі MTA.
6. Листи тільки зображеннями стали спам-трюком. Шпамери використовували зображення, щоб уникнути ключових слів; провайдери відповіли кращим OCR і евристичною перевіркою.
7. Спільні IP створили ризик «сусідів». Зростання ESP зробив спільну інфраструктуру нормою, і один поганий актор може підкосити цілий пул.
8. Великі провайдери все частіше вимагають вирівнювання для масових відправників. З часом планка піднялася від «якась автентифікація» до «вирівняна автентифікація плюс адекватні правила списків».
9. Відмови — це сигнал репутації, а не лише помилка доставляння. Високий рівень unknown-user виглядає як збір списків або застарілі дані, і фільтри реагують відповідно.

Практичні завдання: команди, виводи, рішення (12+)

Це перевірки, які ви можете виконати сьогодні. Кожне завдання містить: команду, реалістичний приклад виводу, що це означає, і рішення, яке ви приймаєте.

Завдання 1: Перевірте, чи черга пошти вибухає (Postfix)

cr0x@server:~$ mailq | tail -n 20
-- 2150 Kbytes in 124 Requests.
AB12CD34EF     2190 Thu Jan  4 10:11:12  sender@example.com
                                         (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later (in reply to end of DATA command))
                                         user@gmail.com

Сенс: Багато відкладеної пошти з 421 тимчасовими відмовами. Зазвичай це тротлінг, питання репутації або обмеження на боці провайдера.

Рішення: Припиніть масові відправлення, втіліть обмеження швидкості і зосередьтесь на репутації/автентифікації, перш ніж черга стане вашим новим інструментом моніторингу.

Завдання 2: Проаналізуйте останні SMTP-статуси на предмет шаблонів

cr0x@server:~$ sudo grep -E "status=(bounced|deferred)" /var/log/mail.log | tail -n 15
Jan  4 10:11:12 mx1 postfix/smtp[22107]: AB12CD34EF: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.200.26]:25, delay=12, delays=0.2/0/2/9.8, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later)
Jan  4 10:11:18 mx1 postfix/smtp[22111]: CD34EF56GH: to=<user@outlook.com>, relay=outlook-com.mail.protection.outlook.com[52.101.68.9]:25, delay=3.2, delays=0.1/0/0.7/2.4, dsn=5.7.1, status=bounced (host outlook-com.mail.protection.outlook.com[52.101.68.9] said: 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.)

Сенс: Gmail тимчасово відмовляє; Microsoft робить жорсткий блок з 5.7.1 і відмовляє за IP.

Рішення: Роздільне усунення для кожного провайдера. Для Microsoft потрібні поліпшення репутації IP/домену і, ймовірно, процес делістингу; для Gmail — зменшення обсягу і виправлення автентифікації/якості списку.

Завдання 3: Підтвердьте свій вихідний IP (що бачить світ)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Сенс: Це публічний IP, який поштові провайдери асоціюють з вашими SMTP-з’єднаннями.

Рішення: Використайте цей IP для перевірки PTR, блоклистів і будь-яких ескалацій з вашим ISP/ESP.

Завдання 4: Підтвердіть зворотний DNS (PTR) і відповідність вашій ідентичності пошти

cr0x@server:~$ dig +short -x 203.0.113.10
mx1.mail.example.com.

Сенс: PTR існує. Далі переконайтеся у forward-confirmed reverse DNS (FCrDNS): хостнейм повинен знову вирішуватися в той самий IP.

Рішення: Якщо PTR відсутній або загальний (наприклад, ім’я інстансу в хмарі), виправте це через вашого провайдера. Відсутній PTR швидко підвищує оцінку «підозрілий хост».

Завдання 5: Перевірте форвардний DNS для PTR-хостнейма

cr0x@server:~$ dig +short mx1.mail.example.com A
203.0.113.10

Сенс: FCrDNS пройшов. Добре.

Рішення: Якщо не збігається, виправте DNS так, щоб PTR і A записи були консистентні.

Завдання 6: Перевірте HELO/EHLO, яке ваш MTA представляє

cr0x@server:~$ sudo postconf -n | grep -E "myhostname|smtpd_banner|smtp_helo_name"
myhostname = mx1.mail.example.com
smtp_helo_name = mx1.mail.example.com
smtpd_banner = $myhostname ESMTP

Сенс: HELO відповідає реальному, резольвному хостнейму. Це зменшує «ботнетні» враження.

Рішення: Якщо бачите «localhost» або випадкове хмарне ім’я, виправте це. Це важить більше, ніж багато хто вважає.

Завдання 7: Перевірте, що SPF запис існує і не є пасткою

cr0x@server:~$ dig +short TXT example.com | sed -n '1,5p'
"v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Сенс: SPF авторизує ваш IP і Microsoft 365, закінчується на -all (жорсткий фейл). Це нормально, якщо запис точний.

Рішення: Якщо SPF відсутній або закінчується ~all під час спроби застосувати DMARC — посиліть його. Якщо включає занадто багато постачальників, яких ви більше не використовуєте — видаліть їх.

Завдання 8: Перевірте кількість DNS-запитів SPF (тиха помилка)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null 2>&1 || true
cr0x@server:~$ spfquery -ip 203.0.113.10 -sender bounce@example.com -helo mx1.mail.example.com -debug | tail -n 8
policy result: pass
mechanism: ip4:203.0.113.10
explanation: (none)
received-spf: pass (example.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender)

Сенс: SPF оцінюється як pass для цього відправного IP і envelope sender.

Рішення: Якщо бачите permerror або «too many DNS lookups», спростьте SPF (згладьте includes, видаліть старі сервіси). SPF permerror на практиці часто трактують як фейл.

Завдання 9: Підтвердіть, що публічний ключ DKIM опублікований для селектора, який ви використовуєте

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtY..."

Сенс: Ключ існує в DNS. Далі переконайтеся, що ваша вихідна пошта фактично підписана цим селектором і що підписи перевіряються.

Рішення: Якщо запис відсутній — опублікуйте його. Якщо ви ротували ключі, забезпечте, щоб старі селектори залишалися, поки всі системи не перестануть ними користуватися.

Завдання 10: Перевірте DMARC запис і політику

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; fo=1"

Сенс: DMARC існує, зі строгим вирівнюванням для SPF і DKIM. Це жорстка позиція.

Рішення: Якщо ви провалюєте вирівнювання через інструменти постачальника, або виправте інструменти, або тимчасово послабте вирівнювання. Строге вирівнювання при неправильному налаштуванні — це самосаботаж під виглядом безпеки.

Завдання 11: Перегляньте Authentication-Results у реальному повідомленні (з заголовків)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|From:" -n sample.eml | head -n 30
12:From: "Example Support" <support@example.com>
45:DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed;
88:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@bounce.example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@bounce.example.com;
       dkim=pass header.i=@example.com header.s=s1;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Сенс: SPF і DKIM проходять окремо, але DMARC — не проходить. Чому? SPF автентифікує bounce.example.com (envelope domain), який не вирівнюється з example.com. DKIM проходить і вирівняний (d=example.com), отже DMARC має проходити — якщо підпис охоплює заголовок From правильно, або якщо провайдер не побачив інакший результат.

Рішення: Повторно зніміть заголовки з поштової скриньки одержувача, підтвердіть вирівнювання DKIM і переконайтеся, що жодна проміжна система не змінює повідомлення (додавання футерів, перезаписування) після підпису. Якщо у вас є конектор M365 або шлюз, що додає дисклеймери, це може ламати DKIM.

Завдання 12: Перевірте, чи шлюз або дисклеймер не ламають DKIM

cr0x@server:~$ sudo grep -R "disclaimer\|footer\|append" /etc/postfix /etc/opendkim /etc/mail 2>/dev/null | head
/etc/opendkim.conf:# OversignHeaders From

Сенс: На місці не знайдено багато вказівок. Це натякає, що модифікація може відбуватися вище за ланцюгом (наприклад, корпоративний шлюз, трекер ESP або захисний пристрій одержувача).

Рішення: Прослідкуйте шлях листа. Якщо щось змінює тіло або заголовки після підпису DKIM, змініть порядок (підписуйте останнім) або налаштуйте «oversigning» коректно. Або перемістіть модифікації на стадію до підпису.

Завдання 13: Заміряйте рівень відмов за причиною (вибірка логів)

cr0x@server:~$ sudo awk '/status=bounced/ {print $0}' /var/log/mail.log | tail -n 500 | \
awk -F'said: ' '{print $2}' | sed 's/[()]//g' | cut -c1-80 | sort | uniq -c | sort -nr | head
  88 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.
  41 550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown
  19 554 5.7.1 Message rejected due to content restrictions

Сенс: Топ-помилка — блокування репутації/IP у Microsoft, а не проблема контенту. Друга — невідомі користувачі (гігієна списків). Третя — відхилення через обмеження контенту.

Рішення: Пріоритезуйте: (1) відновлення репутації з Microsoft, (2) негайне пригнічення невідомих користувачів, (3) перевірка контенту і URL лише після того, як ви припините «кровотечу».

Завдання 14: Перевірте підтримку TLS на вихідному з’єднанні (сигнал легітимності)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.mail.example.com
Verification: OK

Сенс: STARTTLS працює і сертифікат валідний. Це допомагає з деякими оцінками провайдерів і запобігає дивним зниженням захищеності.

Рішення: Якщо TLS не працює — виправте. Дивовижна кількість «ми виглядаємо підозріло» походить від поламаного TLS і невідповідності імен.

Завдання 15: Переконайтеся, що ви не є відкритим реле (так, це ще трапляється)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_recipient_restrictions|mynetworks|smtpd_client_restrictions"
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/8
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Сенс: Ви відхиляєте неавторизовані переправлення на не-локальні домени. Добре.

Рішення: Якщо бачите permit правила перед reject_unauth_destination або надто широкі mynetworks, виправте негайно. Відкрите реле знищить вашу репутацію швидше, ніж встигнете сказати «incident review».

Завдання 16: Обмежте швидкість вихідних відправлень, щоб знизити тимчасові відмови і тротлінг

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf default_destination_rate_delay smtp_destination_concurrency_limit
default_destination_rate_delay = 1s
smtp_destination_concurrency_limit = 5

Сенс: Ви уповільнюєте доставляння на кожного одержувача/ціль, що зменшує тротлінг провайдерів і уникає спайкового поведінки.

Рішення: Тримайте це консервативно під час відновлення. Якщо затримка транзакційної пошти стає неприйнятною, виділіть окремий потік (окремий IP/субдомен) замість того, щоб «накручувати» налаштування.

Три корпоративні міні-історії (анонімізовані, правдоподібні та болісно знайомі)

Міні-історія 1: Інцидент через неправильне припущення

Вони мігрували від одного ESP до іншого за вихідні. План проекту був простим: додати нового провайдера в SPF, опублікувати нові DKIM-ключі, переключити API відправлення — і готово. У понеділок вранці листи зі скидання пароля почали зникати. Не відмовлятися. Просто… не доходити.

Неправильне припущення було в тому, що «SPF pass — це доставлюваність». Новий ESP використовував інший return-path домен для bounce-ів, і хоча SPF для цього домену проходив, DMARC вирівнювання не виконувалося для видимого From-домену. У старому ESP DKIM був вирівняний і стабільний. У новому налаштуванні проміжний шлюз додав футер після підпису ESP, що ламало DKIM при доставці.

Тому користувачі бачили «support@example.com», але ні SPF-алігнменти, ні DKIM не відповідали вимогам DMARC. Деякі провайдери класифікували в карантин; інші тихо відправляли в спам. Команда ганялася за шаблонами і темами, бо маркетинг міг змінити це швидко. Насправді ж потрібно було: змінити поведінку шлюзу (не змінювати після підпису), підписувати на останньому хопі і перевіряти вирівнювання в реальних заголовках з поштових скриньок одержувачів.

Постмортем-дія, яка мала значення: кожна зміна шляху листа мала тест, який підтверджує DMARC pass з вирівнюванням для кожного великого провайдера, а не просто «віддалений прийняв повідомлення». Вони почали ставитися до пошти як до продакшн-трафіку, а не як до магічної служби, що «просто працює».

Міні-історія 2: Оптимізація, що дала зворотний ефект

Growth-команда захотіла швидше доставляти кампанії. Вони були переконані, що їхній MTA «занадто повільний», бо часи відправлення розтягувалися на години. Інженер підвищив ліміти паралелізму і прибрав затримки.

Листи полетіли як конфетті.

Приблизно 30 хвилин це виглядало чудово. Потім почалися відкладення: 421 тимчасові відмови, «спробуйте пізніше», а потім відверті блокування від великого провайдера. Черга роздулася. Виникли retry-шторм і чергові повтори. Поштова система провела наступний день, товчучи ті ж самі провайдери, постійно доводячи, що вона не вміє ввічливо поводитись.

У розборі інциденту оптимізацію перекваліфікували як «агресивне формування трафіку в неправильному напрямку». Провайдери не відхиляли тому, що контент став гіршим; вони відхиляли, бо поведінка відправника виглядала як ботнет: спайкова, безжальна і без реакції на зворотний тиск.

Виправлення були нудними: знизити паралелізм, впровадити ліміти за напрямком і розбити кампанії. Але реальне виправлення було організаційним: припиніть ставитись до доставлюваності як до пропускної здатності. Пошта — це не проста передача великих даних; це протокол довіри з SMTP як транспортом.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Середня SaaS-компанія відокремила транзакційну і маркетингову пошту роками тому. Не через кризу — а тому що один SRE наполіг: «blast radius існує». Транзакційна пошта виходила з mail.example.com на невеликому пулі виділених IP, зі строгим DMARC і закритим pipeline шаблонів. Маркетинг ішов з news.example.com через спільний пул ESP.

Колись маркетинг купив партнерський список (нібито opt-in). Рівень скарг підскочив. Пул ESP почав хитатися. Деякі домени тротлили. Доставлюваність маркетингу просіла. Нездорово, але прийнятно.

Важливе: листи зі скидання паролів, рахунки і алерти продовжували доставлятися. Метрики транзакційного потоку залишалися чистими: низькі відмови, стабільний обсяг, передбачувані одержувачі. Провайдери й далі довіряли, бо потік поводився передбачувано і користувачі з ним взаємодіяли.

Момент «врятував день» настав під час розсилки рахунків. Якби рахунки потрапили в спам — це було б інцидентом по доходу. Вони уникли цього, бо наперед зробили нудну архітектуру: сегрегацію, вирівнювання і продуманий план підігрівання під час змін. Виробництво любить нудне.

Короткий жарт #2: Якщо ваш план покращення доставлюваності — «надсилати агресивніше», вітаю — ви винайшли retry-шторм, але для маркетингу.

Поширені помилки: симптоми → корінна причина → виправлення

1) Симптом: Gmail приймає (250 OK), але користувачі скаржаться на папку спаму

• Корінна причина: Низька залученість та/або застарілий список; контент виглядає рекламним; сплески обсягу; відсутні сигнали вирівнювання.
• Виправлення: Зменште обсяг, надсилайте лише активним користувачам, видаліть неактивних, забезпечте вирівнювання DKIM і тримайте стабільний ритм 2–4 тижні.

2) Симптом: Microsoft відкидає з 550 5.7.1 та згадує ваш IP

• Корінна причина: Пошкодження репутації IP (сусід по спільному пулу або ваша власна поведінка з відмов/скарг). Іноді також відсутній PTR або слабкий TLS.
• Виправлення: Підтвердіть PTR/HELO/TLS, зменшіть швидкість, виправте гігієну списків і домагайтеся ремедіації через вашого провайдера. Якщо на спільному IP — вимагайте інший пул або виділений IP з підігріванням.

3) Симптом: DMARC невдачі різко зросли після зміни DNS або постачальника

• Корінна причина: Невирівнювання між From-доменом та автентифікаційними доменами; неправильний DKIM-селектор; шлюз модифікує листи після підпису; SPF permerror через ліміт запитів.
• Виправлення: Перевірте реальними заголовками, переконайтеся, що DKIM підписує з d= доменом, вирівняним з From, виправте SPF і приберіть модифікації після підпису.

4) Симптом: Різке збільшення «User unknown» hard bounces

• Корінна причина: Застарілий список, імпортовані контакти, помилки в доменах, або поломана верифікація при реєстрації.
• Виправлення: Негайне пригнічення hard bounces; впровадження валідації адрес при зборі; карантин старих сегментів; повторне запитування дозволу лише для відомо залучених користувачів.

5) Симптом: Черга пошти росте, і час доставки транзакційної пошти стає хвилинами/годинами

• Корінна причина: Спільна черга для масової і транзакційної пошти; тротлінг провайдера викликає глобальний беклог; надто багато повторів, що насичують з’єднання.
• Виправлення: Розділіть потоки (окремі MTA або транспорти), запровадьте обмеження по напрямках, пріоритезуйте транзакційні черги і тимчасово припиніть масові розсилки.

6) Симптом: Все «проходить», але конкретний корпоративний отримувач ніколи не отримує листи

• Корінна причина: Карантин на боці отримувача, власна фільтрація або блокування домену/URL внутрішньо; іноді їхній шлюз мовчить про відмови.
• Виправлення: Попросіть їхнього адміністратора пошти надати логи за message ID і часовою міткою. Надайте свої SMTP-логи. За потреби змініть URL (tracking domains) і забезпечте консистентні ідентифікатори.

7) Симптом: DKIM іноді не проходить, не завжди

• Корінна причина: Модифікації через кілька хопів; різні ключі підпису на серверах; система шаблонів додає динамічні пробіли/завивки рядків після підпису; кілька DKIM-підписів, і одна ламається.
• Виправлення: Підписуйте на фінальному хопі, стандартизуйте конфіг підписування, використовуйте canonicalization relaxed/relaxed і тестуйте з повними заголовками через різні провайдери.

8) Симптом: Доставлюваність у нормі, поки ви не запустите кампанію — і тоді все стає гірше

• Корінна причина: Спільна ідентичність між маркетингом і транзакційною поштою; сплески обсягу навчають фільтри не довіряти вашому потоку.
• Виправлення: Розділіть домени/субдомени, різні DKIM-селектори і використовуйте окремі IP, якщо можливо. Принаймні розділіть envelope domains і патерни трафіку.

Чеклісти / покроковий план

Фаза 0 (сьогодні): Стабілізація і припинення кровотечі

1. Призупиніть масові розсилки. Заморозьте маркетингові відправлення, які не є критичними для операцій.
2. Захистіть транзакційні листи. Якщо не можете відразу розділити, принаймні пріоритезуйте транзакції в черзі і зменшіть обсяг масових розсилок до майже нуля.
3. Увімкніть жорстке пригнічення. Hard bounces пригнічуйте негайно; повторні soft bounces пригнічуйте після розумного порогу.
4. Зменште паралелізм і додайте паузи. Поводьтеся ввічливо; приймайте зворотний тиск.
5. Виберіть одну контрольну вибірку. Невелика група залучених користувачів плюс seed-лист по основних провайдерах.

Фаза 1 (24–72 години): Діагностика на підставі даних, а не відчуттів

1. Класифікуйте режим відмови. Відмови vs accept-but-spam vs accept-and-missing.
2. Зберіть реальні заголовки. Підтвердіть SPF/DKIM/DMARC, як бачить їх одержувач.
3. Перевірте базові ідентифікатори. PTR, HELO, сертифікат TLS, стабільні вихідні IP.
4. Квантифікуйте відмови. Топ SMTP-коди та їх розподіл за провайдерами/доменами.
5. Знайдіть точку перелому. Що змінилося навколо моменту, коли репутація впала? DNS, провайдер, pipeline шаблонів, придбання списку, налаштування паралелізму.

Фаза 2 (1–3 тижні): Відновлення довіри контрольованим підігріванням

1. Сегментуйте за залученістю. Почніть з тих, хто недавно взаємодіяв. Якщо ви не відстежуєте залученість, почніть робити це і прийміть, що відновлення займе більше часу.
2. Підігрівайте поступово. Збільшуйте обсяг повільно, тримайте стабільний ритм і стежте за відкладеннями/скаргами, як за CPU бази даних.
3. Тримайте контент стабільним. Не тестуйте A/B під час інциденту з репутацією.
4. Стабілізуйте URL-адреси. Уникайте ротації коротших посилань або доменів під час відновлення. Підозрілі ланцюги редиректів — ваш ворог.
5. Розділіть потоки назавжди. Транзакційна vs маркетингова пошта, ідеально ще й повідомлення продукту як третій потік.

Фаза 3 (постійно): Запобігайте наступному падінню

1. SLO для доставлюваності. Відстежуйте рівень відмов, відкладень, проксі-скарг і індикатори потрапляння в папку «Вхідні» за провайдером.
2. Управління змінами. Зміни DNS і pipeline пошти потребують тестування і відкату, як будь-яка продакшн-конфігурація.
3. Гівернанс списків. Визначте дозволені джерела адрес. Жодних «партнерських списків» без контролю якості і правил пригнічення.
4. Дріли інцидентів. Практикуйте швидкий план діагностики щоквартально. Ваше майбутнє «я» буде вдячне.

Питання та відповіді

1) Скільки часу займає відновлення репутації відправника?

Від кількох днів до кількох тижнів, залежно від того, наскільки сильно ви її пошкодили і чи виправите базову поведінку. Виправлення автентифікації може допомогти відразу, але поліпшення залученості та якості списків потребує часу.

2) Чи слід переходити на інший ESP, щоб виправити доставлюваність?

Тільки якщо ваш поточний провайдер не дає контролю або видимості (або ви застрягли на отруєному спільному пулі). Перехід без виправлення гігієни списків і автентифікації просто переносить проблему й додає ризик міграції.

3) Чи вирішує проблему виділений IP?

Він усуває ризик «сусідів», але не ваш власний ризик. Якщо ваш список поганий, виділений IP дає приватне місце для «випалювання» репутації. Вам все одно потрібен warm-up і гігієна.

4) Чи слід ставити DMARC p=reject, щоб довести легітимність?

Не під час конфігураційного безпорядку. Запроваджуйте жорстку політику DMARC, коли ви впевнені, що всі легітимні відправники проходять вирівнювання. Інакше ви відкинете власну пошту під приводом «безпеки».

5) Чому ми бачимо 421 тимчасові відмови замість жорстких bounce-ів?

Провайдери часто тротлять замість негайного блокування, особливо якщо думають, що ви можете бути легітимним, але тимчасово ризиковим. Сприймайте це як зворотний тиск і зменшіть швидкість; не тисніть сильніше.

6) Яка найпоширеніша причина «раптового погіршення»?

Непомічені зміни: оновлення DNS, зміни маршруту ESP або шлюзи, що починають переписувати повідомлення і ламати DKIM. Друга — імпорт списків, що збільшує unknown users і скарги.

7) Чи шкодить трекінг посилань доставлюваності?

Так. Спільні домени трекінгу можуть успадковувати проблеми з репутацією, ланцюги редиректів виглядають фішинговими, а невідповідні домени знижують довіру. Тримайте домени трекінгу стабільними і вирівняними з брендом, уникайте підозрілих коротких посилань.

8) Чому транзакційна пошта страждає, коли маркетинг запускає кампанію?

Бо ви пов’язали їх: один From-домен, той самий IP, одна DKIM-ідентичність, спільні черги. Розділіть потоки, щоб одна команда не могла випадково DDoS-нути довіру провайдерів.

9) Наші листи «приймають». Чому користувачі їх не бачать?

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

10) Які метрики слід ставити на алерти?

Зростання розміру черги, відсоток відкладень за провайдером, рівень hard bounces, частка unknown-user, і показники невдач автентифікації (DMARC aggregate reports корисні). Аларміть по трендам, а не лише за абсолютними порогами.

Наступні кроки, які ви можете виконати цього тижня

1. Заморозьте масові розсилки на 48 годин поки збираєте докази: SMTP-коди за провайдерами, поведінку черги і реальні заголовки від одержувачів.
2. Підтвердіть правильність ідентичності: PTR/FCrDNS, HELO, TLS, стабільні вихідні IP. Виправте «дешеві» сигнали першими.
3. Домогайтесь проходження DMARC з вирівнюванням для вашого основного From-домену. Валідовуйте знімками заголовків з Gmail і Microsoft.
4. Запровадьте жорстке пригнічення негайно і помістіть під карантин сумнівні сегменти. Відмови unknown-user — це репутаційний податок з відсотками.
5. Розділіть транзакції і маркетинг (щонайменше субдомени і DKIM-селектори). Ставтесь до цього як до контролю blast-radius.
6. Підігрівайте свідомо: стабільний щоденний обсяг, спочатку залучені одержувачі, повільні нарощення і уважний моніторинг відкладень і скарг.

Якщо ви зробите лише одну річ: припиніть сплески обсягу і не надсилайте тим, хто не просив. Автентифікація відкриває двері; поведінка вирішує, чи вам дозволять залишитися.