Відмови пошти: як читати коди відмов як професіонал і усунути корінну причину

Практична модель: що таке відмова насправді

«Відмова» — це не настрій. Це віддалений SMTP‑сервер (або шлюз перед ним), який повідомляє, що не прийняв ваше повідомлення для доставки. Іноді воно відхиляє одразу під час SMTP‑діалогу. Іноді приймає повідомлення, а пізніше генерує Delivery Status Notification (DSN), коли не може доставити локально.

Для операцій найважливіше розрізняти:

• Жорстка відмова (зазвичай 5xx): постійна помилка. Повторні спроби зазвичай марні і можуть нашкодити вашій репутації.
• М’яка відмова (зазвичай 4xx): тимчасова помилка. Очікується, що система буде повторювати спроби, але багаторазові затримки теж шкодять репутації.

Далі задають наступне питання: чия це проблема?

• Проблема отримувача: поштова скринька не існує, переповнена, політики блокують на їхньому боці.
• Наша проблема: DNS/автентифікація, репутація IP, зламаний TLS, неправильно сформовані повідомлення, пікові обсяги, неправильно спрямовані MX, помилкова конфігурація MTA.
• Мережева проблема: таймаути, збої під час рукопотискання, дивна MTU на шляху, транзитні маршрути.

Більшість команд помиляються, бо ставляться до всіх відмов однаково. Це неправильно. «550 5.1.1 user unknown» — це проблема якості даних. «421 4.7.0 try again later» часто означає проблему обсягу/репутації/тротлінгу. «554 5.7.1» — це широке денне пограбування доставності: вас заблокували.

Факти та історія, які насправді допомагають розбиратися

1. SMTP старший за більшість вашої інфраструктури. Він походить з початку 1980‑х (RFC 821). Багато поведінок такі «бо так працювало в ARPANET», а не тому, що це елегантно.
2. Розширені статус‑коди (на кшталт 5.7.1) з’явилися пізніше, щоб зробити класи помилок зрозумілими для машин (RFC 3463). Не всі сервери використовують їх коректно.
3. «Повідомлення про відмову», яке ви отримуєте, часто генерує ваш власний MTA. Якщо віддалений відхилив під час SMTP, ваш сервер створює DSN, щоб сказати вашому застосунку/користувачу, що сталося.
4. Грейлістинг став популярним у середині 2000‑х як антіспам‑тактика: тимчасово відхиляти перші спроби доставки (часто 4xx) щоб відсіяти недосвідчені спам‑боти.
5. RBL (реальні часові чорні списки) передували появі ролі «інженер доставності». Вони почалися як спільні списки і перетворилися на хаотичну екосистему сигналів репутації.
6. SPF з’явився раніше за DKIM (SPF — на початку 2000‑х; DKIM стандартизували пізніше). SPF аутентифікує IP відправника; DKIM підписує вміст повідомлення.
7. DMARC з’явився пізніше, щоб пов’язати SPF і DKIM політикою та звітністю. Сувора політика DMARC може перетворити «іноді доставлялось» на «послідовно відхиляється».
8. Великі поштові провайдери блокують не лише за вмістом. Вони використовують поведінкові сигнали: рівень скарг, частоту відмов, взаємодію та патерни відправлення. Ось чому «вчора працювало» не є доказом.
9. Текст відповіді SMTP не стандартизований. Числові коди — це контракт; вільний текст — підказка, часто криптична.

Анатомія повідомлення про відмову (поля DSN, які слід читати)

Коли ви отримуєте лист‑відмову (DSN), він зазвичай містить структуровану частину й читабельну для людини частину. Якщо ви читаєте лише тему — ви розбираєтесь всліпу.

Ключові поля DSN

• Final-Recipient: кому намагалися доставити.
• Action: failed, delayed, delivered, relayed (більшість відмов — failed або delayed).
• Status: розширений статус‑код (наприклад 5.1.1, 4.7.0).
• Remote-MTA: ім’я віддаленого сервера (іноді це шлюз, а не остаточна поштова система).
• Diagnostic-Code: часто містить сирий SMTP‑відповідь.
• Reporting-MTA: ваша система, що згенерувала DSN.

Оператори читають ці поля як дамп аварії: спочатку код статусу, потім діагностичний текст, а потім корелюють з логами за ID транзакції SMTP. Якщо ви не можете зв’язати відмови з ID черги й часовими мітками, ви витратите години на суперечки через скриншоти.

Сімейства кодів відмов: 2xx, 4xx, 5xx і їхні наслідки

2xx: успіх (не відмова)

«250 2.0.0 Ok» означає, що повідомлення прийнято. Це не означає, що його прочитали або що воно опинилося у вхідній скриньці. Але SMTP обіцянки виконано — прийнято до доставки.

4xx: тимчасова помилка (м’яка відмова / відкладення)

4xx означає «спробуйте пізніше». Ваш MTA поставить у чергу й повторить спроби. Але потрібно вирішити, чи причина транзенна (віддалений недоступний), чи хронічна (ваша репутація призводить до тротлінгу).

• 421: сервіс недоступний / закриття каналу передачі. Часто тротлінг або тимчасова відмова.
• 450/451/452: поштова скринька недоступна / локальна помилка / нестача сховища. Може бути грейлістинг, політика або їхній брак ресурсів.

5xx: постійна помилка (жорстка відмова)

5xx означає «не повторюйте цю конкретну доставку як є». Ваш MTA може все ще повторювати залежно від конфігурації, але загалом не варто постійно «долбити» 550.

• 550: поштова скринька недоступна, користувач не знайдений, відмова за політикою.
• 552: перевищено ліміт зберігання (скринька повна).
• 553: ім’я скриньки не дозволене (помилка синтаксису адреси або політика отримувача).
• 554: транзакція невдала, часто пов’язано з політикою (спам, блоклісти, вміст).

Правило оператора: ставтеся до 5xx як до проблеми даних або політики, що потребує виправлення. Ставтеся до 4xx як до сигналу про ємність або репутацію, що потребує контролю швидкості та терпіння — якщо воно не триває.

Розширені статус-коди (x.y.z): корисні, погані та оманливі

Розширені статус‑коди дають вам другу площину інформації. Перший розряд все ще 2/4/5. Другий розряд — клас (адресація, поштова скринька, поштова система, мережа, безпека/політика). Третій розряд — конкретний стан.

Високосигнальні розширені коди, які ви зустрінете щодня

• 5.1.1 — неправильна адреса призначення (користувач не знайдений). Зазвичай мертва адреса.
• 5.2.2 — скринька переповнена. Може бути тимчасовою, але більшість систем відправляє 5xx.
• 5.7.1 — доставка не авторизована / повідомлення відхилено (політика). Тут живуть блокування.
• 4.7.0 — тимчасова політика відмови (тротлінг, грейлістинг, обмеження швидкості).
• 4.4.1 — з’єднання вичерпало час очікування (мережеві або віддалені проблеми).
• 5.3.0 — інший стан поштової системи (часто «повідомлення занадто велике» або загальна помилка).

Підступ: деякі провайдери чіпляють «5.7.1» на все, що їм не подобається. Це може означати «спам», «відсутній SPF», «поганий DKIM», «репутація IP», «підозрілий HELO» або «надто швидке відправлення». Все одно потрібні докази.

Парафраз ідеї від Werner Vogels (надійність/операції): «усе ламається, тому проєктуйте з урахуванням відмов». Відмови — це спосіб пошти чесно про це повідомити.

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

Це «ви на виклику і хтось щойно виклав скриншот відмови» вправляння. Мета — знайти вузьке місце за 10 хвилин: адреса, автентифікація, репутація, вміст або віддалена ємність.

Перше: класифікуйте помилку за 30 секунд

1. 4xx чи 5xx? Якщо 5xx: припиніть повтори для цього класу отримувачів; мабуть, це постійна або політична відмова. Якщо 4xx: шукайте тротлінг проти мережевої проблеми.
2. Чи є розширений код? 5.1.1 (адреса), 5.2.2 (квота), 5.7.1 (політика), 4.7.0 (тимчасова політика) — основні.
3. Всі отримувачі чи підмножина? Один домен підозрює політику/репутацію того провайдера; усі домени — ваші проблеми з автентифікацією/DNS або ваш MTA.

Друге: швидко перевірте вашу ідентичність (DNS/автентифікація)

1. Перевірте SPF для MAIL FROM / Return-Path домену.
2. Перевірте, що DKIM підписує і що запис селектора існує.
3. Перевірте політику DMARC і вирівнювання (особливо після змін домену).
4. Підтвердіть, що зворотний DNS (PTR) відповідає очікуванням HELO/EHLO.

Третє: перевірте репутацію і поведінку по швидкості

1. Шукайте «blocked», «blacklist», «spam», «policy», «too many connections» у діагностичному тексті.
2. Перевірте зростання черги відправки і схеми повторів. Зростаюча відкладена черга — попереджувальний сигнал про швидкість/репутацію.
3. Визначте, чи це один IP, весь пул чи конкретний тип трафіку (скидання пароля проти розсилок).

Четверте: ізолюйте проблеми вмісту й транспорту

1. Розмір повідомлення, вкладення та кінцівки рядків.
2. Збої TLS під час рукопотискання та невідповідні шифри.
3. Пошкоджені заголовки (From, Message-ID, Date) або дивні MIME‑межі.

Практичні завдання: команди, очікуваний вивід і що вирішити

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

Завдання 1: Знайти причину відмови в логах Postfix за ID черги

cr0x@server:~$ sudo grep -E "^[A-Z][a-f0-9]{9,12}:" /var/log/mail.log | grep "status=bounced" | tail -n 3
A1B2C3D4E5: to=<user@example.com>, relay=none, delay=0.2, delays=0.1/0/0/0.1, dsn=5.1.1, status=bounced (host mx.example.com[203.0.113.10] said: 550 5.1.1 <user@example.com> User unknown (in reply to RCPT TO command))
F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, delay=12, delays=0.2/0.1/10/1.7, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited (in reply to end of DATA command))
0AA11BB22C: to=<alerts@other.tld>, relay=none, delay=0.1, delays=0.05/0/0/0.05, dsn=5.7.1, status=bounced (host mx.other.tld[192.0.2.55] said: 550 5.7.1 Message rejected as spam (in reply to end of DATA command))

Що це означає: 5.1.1 — мертва адреса; 4.7.0 — повтор/тротлінг; 5.7.1 — політика/вміст/репутація.

Рішення: підтискайте/очищуйте недійсні адреси для 5.1.1; застосуйте обмеження швидкості й backoff для 4.7.0; почніть розслідування автентифікації/репутації/вмісту для 5.7.1.

Завдання 2: Перевірити розмір черги пошти і чи вона заповнена відкладеними

cr0x@server:~$ mailq | tail -n 5
-- 1230 Kbytes in 184 Requests.

Що це означає: сам по собі розмір черги мало що говорить, але раптовий стрибок вказує на віддалені відмови або локальні проблеми.

Рішення: якщо зростання черги корелюється з 4xx відмовами, зменште швидкість відправлення і перевірте репутацію; при локальних помилках перевірте диск і здоров’я MTA.

Завдання 3: Підсумувати коди DSN у логах (що домінує зараз)

cr0x@server:~$ sudo grep -oE "dsn=[245]\.[0-9]\.[0-9]" /var/log/mail.log | sort | uniq -c | sort -nr | head
  412 dsn=4.7.0
  119 dsn=5.7.1
   88 dsn=5.1.1
   41 dsn=4.4.1

Що це означає: домінування 4.7.0 вказує на тротлінг/грейлістинг/політичні тимчасові відмови. 5.7.1 — блокування. 4.4.1 — мережеві таймаути.

Рішення: пріоритет — контроль швидкості й репутація при 4.7.0; перевірка автентифікації/вмісту при 5.7.1; перевірити підключення, якщо зростає 4.4.1.

Завдання 4: Перевірити MX записи домену (чи ви взагалі говорите з потрібними серверами?)

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Що це означає: якщо MX неправильний або вказує на мертві хости, ви побачите таймаути (4.4.1) або помилки з’єднання.

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

Завдання 5: Переконатися, що у вашого IP є зворотний DNS (PTR)

cr0x@server:~$ dig +short -x 198.51.100.10
mailout1.yourdomain.tld.

Що це означає: відсутній або загальний PTR часто спричиняє 5.7.1 політичні відмови, особливо в суворих доменах.

Рішення: якщо PTR відсутній/непогоджений — виправте з провайдером та узгодьте HELO/EHLO з ім’ям, яке резолвиться і відповідає очікуванням політики.

Завдання 6: Перевірити SPF запис для envelope-from домену

cr0x@server:~$ dig +short TXT yourdomain.tld
"v=spf1 ip4:198.51.100.0/24 include:_spf.your-esp.tld -all"

Що це означає: SPF присутній. Кваліфікатор важливий: -all — суворе відхилення; ~all — softfail.

Рішення: якщо ваші IP не включені — додайте їх. Якщо у вас забагато include, ви можете влучити в ліміт DNS‑запитів і спричинити переривчасті помилки.

Завдання 7: Перевірити, чи існує DKIM селектор у DNS

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.tld
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt..."

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

Рішення: опублікуйте селектор або виправте невідповідність домен/селектор у конфігурації MTA/ESP.

Завдання 8: Перевірити політику DMARC (і чи випадково ви не поставили reject)

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.tld
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

Що це означає: суворе вирівнювання (adkim=s, aspf=s) може спричиняти відмови, якщо ваш From домен не вирівнюється зі SPF/DKIM доменами.

Рішення: якщо ви бачите відмови після зміни DMARC — підтвердіть вирівнювання; тимчасово пом’якшіть вирівнювання тільки якщо ви розумієте компроміс щодо підробки.

Завдання 9: Протестувати SMTP сесію вручну, щоб побачити точку відмови

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx.other.tld:25
CONNECTED(00000003)
220 mx.other.tld ESMTP
ehlo mailout1.yourdomain.tld
250-mx.other.tld
250-STARTTLS
250 SIZE 52428800
mail from:<sender@yourdomain.tld>
250 2.1.0 Ok
rcpt to:<alerts@other.tld>
550 5.7.1 Blocked due to policy

Що це означає: відмова на RCPT TO часто стосується рівня отримувача/політики; відмова після DATA більш чутлива до вмісту/репутації.

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

Завдання 10: Підтвердити, що сервер подає правильний сертифікатний ланцюг для SMTP TLS

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_tls_cert_file|smtpd_tls_key_file|smtpd_tls_CAfile"
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Що це означає: ви знаєте, які файли задіяні. Збої TLS можуть проявлятися як 4.4.1 таймаути або помилки рукопотискання в логах.

Рішення: якщо ви нещодавно міняли сертифікати і почалися відмови — перевірте права доступу, повноту ланцюга і налаштування шифрів.

Завдання 11: Визначити топ доменів отримувачів у відкладеній черзі (хто вас тротлить?)

cr0x@server:~$ mailq | awk '/^[A-F0-9]/ {id=$1} /@/ {print $0}' | sed -n 's/.*@//p' | tr -d '>,' | sort | uniq -c | sort -nr | head
  98 gmail.com
  71 corp.tld
  40 outlook.com
  19 yahoo.com

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

Рішення: реалізуйте обмеження по доменах і ліміти з’єднань; подумайте про розподіл типів трафіку по різних IP, якщо ви змішуєте транзакційний і масовий трафік.

Завдання 12: Перевірити «забагато з’єднань» і налаштувати паралелізм

cr0x@server:~$ sudo grep -iE "too many connections|rate limited|throttl" /var/log/mail.log | tail -n 5
Jan 03 10:11:22 mail postfix/smtp[23111]: F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited)
Jan 03 10:11:40 mail postfix/smtp[23112]: 9D8C7B6A5F: to=<ops@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Too many connections)

Що це означає: віддалений бік просить вас пригальмувати.

Рішення: зменшіть паралелізм до цього домену і збільшіть backoff; не намагайтесь «оптимізувати» шляхом відкриття більшої кількості з’єднань. Так ви перетворите тимчасовий тротлінг на блокування.

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

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       40G   37G  1.2G  97% /

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

Рішення: звільніть місце негайно і додайте моніторинг; якщо ви постійно близько до повного, поведінка «поштова система переповнена» виглядатиме як віддалені проблеми.

Завдання 14: Переглянути конкретне повідомлення в черзі (заголовки, розмір і конверт)

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_size:            48213            48159               54               54
sender: sender@yourdomain.tld
*** MESSAGE CONTENTS ***
Received: by mailout1.yourdomain.tld (Postfix, from userid 1001)
Date: Fri, 03 Jan 2026 10:10:05 +0000
From: "Your App" <noreply@yourdomain.tld>
To: user@example.com
Subject: Reset your password
Message-ID: <20260103101005.12345@mailout1.yourdomain.tld>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

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

Рішення: якщо вміст пошкоджено (немає Date/Message-ID, зламаний MIME), виправте генератор; деякі провайдери відхиляють спотворені повідомлення як порушення політики.

Жарт 1: Електронна пошта — єдина система, де ви можете зробити все правильно і все одно почути «спробуйте пізніше» від машини, яка не пояснює причину.

Три корпоративні історії з фронту відмов

Інцидент 1: Неправильне припущення (5.1.1, що не була «помилкою отримувача»)

Одна компанія мігрувала з легендарної CRM на нову платформу клієнтів. Під час перехідного періоду обидві системи працювали паралельно. Команда електронної пошти помітила раптове зростання 550 5.1.1 User unknown відмов для певного домену. Одразу зробили звичне припущення: «наш список застарів».

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

Справжня корінна причина була в нудному місці: нова система правильно переводила в нижній регістр і обрізала пробіли, але проміжний сервіс додавав прихований символ Unicode, скопійований з внутрішнього інструмента адміністратора. Вигляд адреси був ідентичний візуально. SMTP‑сервери не звертають уваги на ваші почуття; вони дивляться на байти. Система отримувача трактувала це як іншу локальну частину і відповіла «user unknown».

Виправлення не було «очистити список». Потрібно було нормалізувати й валідувати адреси при інжекції, логувати сирі байти та додати тести, що порівнюють форми UTF‑8 після нормалізації. Також оновили логіку пригнічення, щоб вимагати повторних помилок і трактувати «знову помилкові адреси» з пересторогою під час міграцій.

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

Інцидент 2: Оптимізація, що відсвистнула назад (більше пропускної здатності — більше блокувань)

Інша організація керувала власним флотом Postfix і відправляла багато легітимних листів: рахунки, квитанції та повідомлення про події. Черга почала накопичуватися в пікові години. Хтось запропонував ідею: «збільшити паралелізм і скоротити інтервали повторів, щоб пошта швидше розчистилася».

Вони підвищили паралельні з’єднання і скоротили backoff. Черга очистилася. Приблизно на день. Потім відмови виросли: 421 4.7.0 відкладень змінилися на 550 5.7.1 блокувань. У діагностичних текстах з’явилося «rate limited», а потім «blocked due to policy».

Класичний сценарій: вони «навчили» отримувача не довіряти їм. Забагато паралельних з’єднань, забагато повідомлень за короткий час і надто мало терпіння. Навіть коректні листи можуть виглядати як зловмисний трафік, якщо ви їх відправляєте як тест на відмовостійкість.

Відкат був болючим, бо «скасувати оптимізацію» не відновило репутацію миттєво. Довелося впроваджувати адаптивний тротлінг по доменах, сегментувати масовий трафік від транзакційного і припинити агресивні повтори на 4xx. З часом блокування послабшали.

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

Інцидент 3: Сумна, але рятівна практика (розділення трафіку та спокійні повтори)

Постачальник SaaS мав нудне правило: транзакційні листи і масові розсилки не повинні ділити IP, домени або політику повторів. Маркетинг ненавидів це через додаткову координацію. Фінанси — через потребу більше IP і постачальників.

Одного дня маркетинг запустив кампанію з несподівано високим рівнем скарг. Природно, пул маркетингових IP почав тротлитися і блокуватися. Але скидання паролів і сповіщення безпеки продовжували надходити. Чому? Розділення репутації IP і строгі ліміти на транзакційному боці.

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

Це не було хитрим. Це було нудно. І воно спрацювало, бо зменшило площу ураження. Це ціль SRE‑дизайну, навіть якщо система «просто пошта».

Жарт 2: Найшвидший спосіб зрозуміти, що у вас немає стратегії доставності — це надіслати лист «підтвердіть свій email», який ніколи не приходить.

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

1) Симптом: Багато 550 5.1.1 «User unknown» одразу після міграції

Корінна причина: баг при трансформації адреси (пробіли, Unicode, обрізання plus‑адресації, опечатка домену) або неправильне зіставлення доменів отримувачів.

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

2) Симптом: 421 4.7.0 «Try again later» протягом кількох годин для великого провайдера

Корінна причина: тротлінг через стрибок швидкості, погану репутацію або неправильний warming для нового IP.

Виправлення: обмеження по доменах, поступове нарощування швидкості, довший backoff на відкладеннях і розділення типів трафіку (транзакційний vs масовий).

3) Симптом: 550 5.7.1 «Blocked» або раптові відмови для багатьох доменів

Корінна причина: збої автентифікації (SPF/DKIM/DMARC), відсутній rDNS або IP у списках через скарги чи скомпрометованого відправника.

Виправлення: перевірити вирівнювання SPF/DKIM/DMARC; підтвердити PTR; переглянути логи відправлення на незвичні піки; обернути креденшелзи; ізолювати трафік; відновлювати репутацію (і припинити масові відправлення).

4) Симптом: 552 5.2.2 бали скриньки переповнені

Корінна причина: перевищено квоту отримувача. Це не ваша інфраструктура, але ваші повтори можуть їх дратувати.

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

5) Симптом: 4.4.1 таймаути і помилки з’єднання до певних доменів

Корінна причина: мережеві шляхи, зламана перевага IPv6, неправильний MX, блоки фаєрволу або віддалені відключення.

Виправлення: протестуйте connect з MTA, перевірте DNS (A/AAAA), перевірте egress фаєрвол і вживайте IPv4, якщо IPv6‑маршрут ненадійний.

6) Симптом: Відмови згадують «TLS» або помилки рукопотискання

Корінна причина: несумісні налаштування TLS, відсутні проміжні сертифікати, зсув часу або зламані SNI очікування у шлюзів.

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

7) Симптом: Тільки HTML‑важкі повідомлення відхиляють як спам; простий текст проходить

Корінна причина: тригери вмісту (патерни URL, невідповідність доменів у видимих посиланнях, трекінгові домени, зламаний MIME або «тихо‑зображення»).

Виправлення: забезпечити коректну MIME‑структуру, додати адекватну текстову частину, вирівняти домени видимих посилань з автентифікованими доменами та зменшити ризикові патерни вмісту.

8) Симптом: «Message size exceeds fixed maximum message size»

Корінна причина: вкладення або кодування (base64) створюють надмірний розмір, що перевищує ліміти віддаленого сервера.

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

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

Чекліст A: Коли відмови стрибають (реакція на інцидент)

1. Зупиніть кровотечу: призупиніть масові розсилки; якщо можливо, збережіть транзакційний трафік у роботі.
2. Класифікуйте: основні DSN (4.7.0 vs 5.7.1 vs 5.1.1) з логів.
3. Охоплення: які домени, які IP, який клас трафіку, яке вікно релізу/зміни.
4. Ідентичність: перевірте SPF/DKIM/DMARC і rDNS. Виправте очевидні порушення першими.
5. Поведіна швидкість: зменште паралелізм; збільшіть backoff; реалізуйте тротлінг по доменах.
6. Санітарність вмісту: підтвердіть заголовки, MIME, розмір повідомлення. Порівняйте «хороший» і «поганий» зразок.
7. Стан черги: моніторте розмір черги і кількість відкладених; переконайтесь у стабільності диска та процесів MTA.
8. Відновлення: очистіть недійсних отримувачів; вимкніть скомпрометованих відправників; сегментуйте трафік.
9. Підтвердьте відновлення: слідкуйте за зниженням DSN‑трендів; підтвердіть, що коефіцієнт прийняття (250) зростає.
10. Постінцидентне укріплення: додайте дашборди для кодів DSN, рівнів відкладень і ефективності тротлінгу по доменах.

Чекліст B: Створення політики обробки відмов (щоб не вчитися знову)

1. Визначте логіку жорстких і м’яких відмов: не трактуйте всі 5xx як постійні без нюансів (квоти особливі), але не повторюйте 5.1.1 вічно.
2. Встановіть пороги пригнічення: негайне пригнічення для 5.1.1; часово‑базоване для 4.7.0; обережно для 5.2.2.
3. Розділіть класи трафіку: транзакційний vs масовий, бажано різні IP і домени.
4. Тротлінг по доменах: різні провайдери — різні ліміти. Побудуйте конфігурацію, яку можна змінити без деплоїв.
5. Зворотний зв’язок: відмови повинні оновлювати дані клієнтів, але з запобіжниками під час міграцій і інцидентів.
6. Аудит стратегії From і Return-Path: забезпечте вирівнювання, що підтримує DMARC.
7. Документуйте все у рунбуку: скриншот відмови повинен транслюватися в передбачувану послідовність перевірок.

Чекліст C: Перед запуском нової інфраструктури відправлення (до виходу в прод)

1. PTR/rDNS встановлено і перевірено.
2. HELO/EHLO hostname резолвиться на IP відправлення.
3. SPF включає всі вихідні IP; не перевищує ліміти DNS‑запитів.
4. DKIM підписування увімкнено; селектори опубліковані; план ротації існує.
5. Політика DMARC обрана свідомо; вирівнювання протестовано.
6. Вихідний TLS налаштовано; сертифікати дійсні; синхронізація часу працює.
7. Моніторинг черг і логів налаштовано; оповіщення про сплески відкладень.
8. Початкові ліміти швидкості та паралелізму консервативні.
9. Розділення трафіку заплановане, а не «пізніше».

FAQ

1) У чому різниця між відмовою і відкладенням?

Відмова — остаточна недоставка (зазвичай 5xx). Відкладення — тимчасова відмова (зазвичай 4xx), яку ваш MTA повторно спробує пізніше.

2) Чи 5xx завжди означає жорстку відмову, яку треба негайно пригнічувати?

Зазвичай так, але не бездумно. 5.1.1 — сильний сигнал для негайного пригнічення. 5.2.2 (скринька переповнена) частіше краще обробляти як «відкладено‑на‑дні», а не видаляти користувача.

3) Чому я бачу 4.7.0 годинами?

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

4) Діагностичний текст каже «spam», але лист легітимний. Що робити?

«Spam» часто є скороченням для політики/репутації. Перевірте автентифікацію (SPF/DKIM/DMARC), rDNS, патерни відправлення і структуру вмісту. Потім зменшіть обсяги і повтори, поки репутація не відновиться.

5) Чи може поганий SPF спричинити відмови?

Так. При жорсткому DMARC невідповідність SPF може перетворитися на 5.7.1 відмову. Навіть без DMARC деякі отримувачі використовують SPF як фактор політики.

6) Чому це працює для деяких отримувачів у провайдера, але не для інших?

Провайдери мають кілька кластерів і шарів політик. Один MX може бути суворішим, або ви можете потрапляти під пер‑отримувацькі чи пер‑доменні ліміти. Саме тому потрібна видимість по доменах і IP.

7) Чи варто «вирішувати» відмови, перемикаючи IP?

Тільки якщо ви знаєте, навіщо перемикаєтесь. Стрибки по IP, щоб уникнути репутації, — швидкий шлях зжерти кілька IP. Виправте причину (автентифікація, якість списку, обсяги), а потім розгляньте контрольований warming.

8) Який найпростіший показник, що передбачає проблеми доставності?

Зростання 4.7.0 відмов і збільшення відкладених черг для великих провайдерів. Це ранній попереджувальний сигнал перед появою 5.7.1 блокувань.

9) Що робити, якщо лист про відмову не містить розширеного статус‑коду?

Покладайтеся на базовий SMTP‑код (4xx/5xx) і діагностичний текст, а потім підтвердіть у логах MTA. Деякі системи обрізають деталі; ваші логи зазвичай мають більше правди, ніж DSN‑лист.

10) Чи потрібні окремі домени для транзакційної і маркетингової пошти?

Це не обов’язково, але робить DMARC‑вирівнювання і ізоляцію репутації простішими. Якщо ви тримаєте один домен, ви приймаєте більшу площу ураження.

Наступні кроки (що змінити в понеділок)

Якщо ви хочете менше інцидентів з відмовами і швидше відновлення, коли вони трапляються, зробіть непривабливу роботу:

1. Побудуйте дашборд DSN, що трендує 4.7.0, 5.7.1, 5.1.1 і 4.4.1 з часом, по доменах отримувачів і по IP відправника.
2. Впровадьте тротлінг по доменах і перестаньте ставитися до віддалених серверів як до безкінечних пляш.
3. Укріпіть ідентичність: SPF має включати всіх відправників, DKIM підписує важливі листи, DMARC відповідає реальності, а PTR/rDNS не є післямовою.
4. Сегментуйте трафік, щоб маркетинг не виводив з ладу скидання паролів.
5. Зробіть правила пригнічення явними: негайно для 5.1.1, за часом для 4xx, обережно для «скринька повна», і зі застереженнями під час міграцій.

Електронна пошта — ненадійний транспорт. Це домовленість між вашим MTA і політиками інших. Читайте коди, підтверджуйте доказами і виправляйте систему — не скриншот.