Помилка електронної пошти «550 rejected»: що це насправді означає і як розблокувати доставку

Що насправді означає «550 rejected» (і чого це не означає)

Коди статусу SMTP — це світу пошти версія «комп’ютер каже ні». 550 — це постійна відмова
на рівні SMTP: сервер отримувача не прийме повідомлення як доставлене. «Постійна» означає, що отримувач говорить
вам «не повторюйте без змін; виправте щось».

Але ось хитрість: 550 — це відро. Сам по собі номер мало інформативний. Важлива частина —
розширений статус-код (наприклад 5.7.1) і, ще більше, текст після нього.
Отримувачі використовують 550 для всього: від «немає такого користувача» до «ваш IP пахне як спам» або «ваш HELO — нісенітниця».

550 проти 450/451: чому «постійний» важливий операційно

Якщо ви бачите 450 або 451, це зазвичай тимчасова відмова: грейлістинг, обмеження швидкості,
тимчасові перевірки політик або проблеми на стороні отримувача. Ваш MTA має повторити спробу.
З 550 повторні спроби зазвичай роблять ситуацію гіршою: ви продовжуєте бити по отримувачу, який вже сказав «ні».

Це не означає «ніколи не повторювати 550». Деякі отримувачі помилково відправляють 550 для тимчасових політик.
Але ставтеся до 550 як до інциденту: призупиніть, проінспектуйте і націлено виправляйте.

Чим 550 не є

• Не обов’язково проблема вашого провайдера пошти. Це часто стосується вашого домену, вашого IP, автентифікації, вмісту або поведінки відправлення.
• Не доказ того, що ви «в чорному списку повсюди». Один отримувач, що відмовив, може зіпсувати вам день, але це рідко універсально.
• Не завжди пов’язано зі спамом. Це може бути «користувач не знайдений», неправильна маршрутизація, поламаний DNS або неправильно налаштований транзит.

Операційне правило: не дозволяйте команді продажів визначати серйозність інциденту на підставі відчуттів.
Серйозність визначається масштабом: які домени відмовляють, які потоки пошти постраждали (транзакційні vs маркетингові),
і чи втрачаєте ви критичну бізнес-пошту.

Цікавинки та трохи історії (бо пошта стара)

• SMTP передує вебу. Базовий стандарт SMTP опублікований у 1982 році. Більшість ваших «сучасних» проблем з поштою — це надбудови.
• Розширені статус-коди (як 5.7.1) були введені пізніше, щоб зробити відмови менш неоднозначними. Багато систем і досі трактують їх як опціональний декор.
• SPF з’явився у відповідь на підробку адрес відправника на початку 2000-х. Він допомагає, але це не система ідентифікації; це підказка «хто дозволений відправляти для цього домену».
• DKIM став загальноприйнятим для захисту цілісності повідомлення і забезпечує стабільний домен підпису навіть при пересиланні.
• DMARC — це політика та звітування, яка каже отримувачам, що робити, коли SPF/DKIM не проходять, і дає вам видимість через звіти.
• Greylisting був трюком проти спаму, який розраховував на те, що спамери не повторюватимуть спробу. Легітимні MTA повторюють; спам-боти часто ні. Дехто досі використовує цю техніку.
• RBL (списки в реальному часі) з’явилися, бо у SMTP немає вбудованої системи репутації. Інтернет віддав «довіру» спискам і зворотному зв’язку.
• IPv6 спочатку ускладнив питання репутації, бо простір адрес величезний; наївне блокування може бути або марним, або руйнівним.
• «Postmaster» і «abuse» поштові скриньки стали де-факто стандартом, бо операторам потрібна була людина, на яку можна покричати, коли сервер поводиться неналежно.

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

Жарт №1: Пошта — єдина система, де 40-річний протокол досі керує глобальною економікою, і ми дивуємось, що він має почуття щодо DNS.

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

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

1. Витягніть точний SMTP-транскрипт або текст повернення. «550 rejected» недостатньо. Вам потрібен розширений код і текст політики.
2. Визначте родину отримувача. Споживчі (Gmail, Microsoft) vs корпоративний шлюз (Proofpoint, Mimecast) vs власний Postfix/Exim. Їхні режими відмов різні.
3. Перевірте масштаб: це один одержувач? один домен? багато доменів? лише нові одержувачі? лише вкладення?

Другий: вирішіть, чи це питання ідентичності, репутації чи маршрутизації

• Ідентичність/автентифікація: помилка SPF, помилка DKIM, провал DMARC, проблеми вирівнювання, відсутній rDNS/PTR, поганий HELO/EHLO, вимоги TLS.
• Репутація/політика: репутація IP або домену, включення в RBL, рівень скарг, обмеження швидкості, фільтрація контенту, репутація URL.
• Маршрутизація/одержувач: користувач не знайдений, relay denied, відправник не дозволений, політика одержувача (зовнішнім відправникам заборонено), неправильний MX, неправильний порт, поламаний DNS.

Третій: оберіть найкоротший шлях до розблокування

1. Якщо це маршрутизація/одержувач: виправте адресацію, MX, relay або політику одержувача; зазвичай це вирішується швидко.
2. Якщо це автентифікація: виправте SPF/DKIM/rDNS/HELO і повторно протестуйте контрольованим способом.
3. Якщо це репутація: припиніть витік (обмежте швидкість, заблокуйте скомпрометовані акаунти, призупиніть маркетинг), потім працюйте над делістингом і розігрівом репутації.

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

Розшифровка відскоку: слова, що мають значення

Поширені розширені статус-коди, які ви побачите з 550

• 550 5.1.1: адреса одержувача відхилена (часто «користувач не знайдений»). Може бути помилка в написанні або видалена скринька.
• 550 5.1.10 (варіюється за постачальником): одержувач не знайдений або недійсний одержувач.
• 550 5.2.0 / 5.2.2: поштовий ящик заповнений або ліміт зберігання/політики (іноді використовується неправильно).
• 550 5.7.1: доставка не авторизована / повідомлення відхилено політикою. Це основний випадок: автентифікація, репутація, вміст або адміністративна політика.
• 550 5.7.26: потрібна автентифікація або відхилення, пов’язане з DMARC (поширено у великих провайдерів).
• 550 5.7.0: загальний статус безпеки/політики.

Шаблони тексту політик і що вони зазвичай означають

• «SPF fail» / «SPF softfail»: ваш відправний IP не авторизований у SPF, або SPF пошкоджений/занадто довгий.
• «DKIM signature invalid»: підпис зламаний (часто через переписування заголовків, невірний селектор або невідповідність ключа).
• «DMARC policy reject»: SPF/DKIM не пройшли вирівнювання відповідно до політики DMARC; отримувач дотримується вашої опублікованої політики (або своєї).
• «blocked using …»: часто RBL або внутрішня репутація. Названий список має значення.
• «reverse DNS required»: відсутній або невідповідний PTR; деякі шлюзи суворі.
• «HELO/EHLO rejected»: ваш MTA представляється фейковим ім’ям хоста або IP-літеральним рядком, який отримувач не любить.
• «Relay access denied»: ви намагаєтеся використати сервер як відкритий ретранслятор, або ваш клієнт не автентифікований/не дозволений.
• «Message content rejected»: репутація URL, тип вкладення або евристика контенту (включно з «занадто багато посилань» або «виглядає як фішинг»).

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

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

Ось перевірки, які я запускаю в першу годину. Кожне завдання містить: команду, що означає вихід, і яке рішення прийняти.
Виконуйте їх з хоста з доступом до DNS і Інтернету (або принаймні до вашого резолвера).

Завдання 1: Витягніть точну SMTP-відмову з логів (Postfix)

cr0x@server:~$ sudo grep -R "status=bounced" /var/log/mail.log | tail -n 3
Jan  3 01:10:12 mx1 postfix/smtp[22103]: 9C2D12A03F: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=5.7.1, status=bounced (host mx.example.net[203.0.113.10] said: 550 5.7.1 Message rejected due to policy restrictions (in reply to end of DATA command))

Значення: У вас розширений код 5.7.1 і відмова політики після DATA. Це зазвичай автентифікація, репутація або вміст.

Рішення: Не гнатися за «користувач не знайдений». Ідіть прямо до перевірок автентифікації/репутації/вмісту.

Завдання 2: Перевірте реальний IP відправлення

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5      2140 Fri Jan  3 01:11:44  alerts@corp.example
                                         user@example.net

-- 1 Kbytes in 1 Request.

Значення: Черга існує; потрібно дізнатись, який транспорт і вихідний IP використовується для відправлення.

Рішення: Підтвердіть NAT виходу або мульті-хомед поведінку; «неправильний» egress IP може порушити SPF і припущення про репутацію.

Завдання 3: Перевірте ваш зовнішній IP з хоста пошти

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

Значення: Це IP, який більшість отримувачів оцінюватимуть для репутації і механізму SPF «ip4».

Рішення: Використайте цей IP при валідації SPF, rDNS і статусу в RBL.

Завдання 4: Перегляньте MX-записи домену-одержувача (перевірка маршрутизації)

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

Значення: Ви знаєте, куди доставляєте. Якщо це порожнo або дивно, можливо, ви надсилаєте не туди.

Рішення: Якщо MX відсутні або вказують на несподівані хости, виправте DNS/очікування одержувача перед тим, як чіпати автентифікацію.

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

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP
EHLO mx.corp.example
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
MAIL FROM:<alerts@corp.example>
250 2.1.0 Ok
RCPT TO:<user@example.net>
550 5.7.1 Recipient address rejected: Access denied

Значення: Відмова на RCPT TO: часто означає політику отримувача, блок-листи, репутацію відправника або «зовнішнім відправникам заборонено».

Рішення: Якщо RCPT не проходить, вміст менш ймовірно винен. Зосередьтеся на політиці, репутації та правилах allow/block одержувача.

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

cr0x@server:~$ dig +short TXT corp.example | grep -i spf
"v=spf1 ip4:198.51.100.25 include:spf.mailvendor.example -all"

Значення: SPF існує і явно дозволяє ваш вихідний IP.

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

Завдання 7: Перевірте оцінку SPF локальним інструментом (швидко і грубо)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 198.51.100.25 -sender alerts@corp.example -helo mx.corp.example
pass

Значення: SPF проходить для цієї комбінації sender/IP/HELO.

Рішення: Якщо результат fail/softfail/permerror, вважайте SPF основним підозрюваним і виправляйте його перш за все.

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

cr0x@server:~$ dig +short TXT selector1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt0..."

Значення: Публічний ключ DKIM опублікований для selector1.

Рішення: Якщо відсутній — отримаєте DKIM=none або fail; опублікуйте запис або виправте відповідність селектора у вашому MTA/ESP.

Завдання 9: Підтвердіть, що ваше вихідне повідомлення фактично підписується DKIM

cr0x@server:~$ sudo apt-get -y install swaks >/dev/null
cr0x@server:~$ swaks --to user@example.net --from alerts@corp.example --server mx1.example.net --data "Subject: test

hello" --quit-after DATA
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<= 220 mx1.example.net ESMTP
=> EHLO mx.corp.example
<= 250-mx1.example.net
<= 250-STARTTLS
=> QUIT

Значення: Цей тест не включав ваш продукційний шлях підписування; swaks корисний для проб, але підпис DKIM залежить від вашого конвеєра відправлення.

Рішення: Відправте реальне повідомлення через ваш MTA і проаналізуйте заголовки (наступне завдання). Не «доказывайте» DKIM тестом, який його обходить.

Завдання 10: Проінспектуйте заголовки Authentication-Results і DKIM у відправленому листі

cr0x@server:~$ sudo grep -R "DKIM-Signature" /var/log/mail.log | tail -n 2
Jan  3 01:14:02 mx1 opendkim[1402]: 9C2D12A03F: DKIM-Signature field added (s=selector1, d=corp.example)

Значення: Ваш MTA додає DKIM-підписи для d=corp.example.

Рішення: Якщо бачите «no signature data» або нічого — виправте інтеграцію opendkim/opendmarc або таблицю підписів.

Завдання 11: Перевірте політику DMARC і очікування вирівнювання

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

Значення: DMARC строгий: як DKIM, так і SPF вирівнювання — «strict» (s). Це може ламати легітимні потоки, як пересилання або сторонні відправники.

Рішення: Якщо вас блокує і ви нещодавно встановили p=reject із строгим вирівнюванням, підтвердіть, що всі потоки вирівнюються; пом’якшуйте вирівнювання тільки якщо розумієте компроміс.

Завдання 12: Перевірте зворотний DNS (PTR) для вашого вихідного IP

cr0x@server:~$ dig +short -x 198.51.100.25
mx.corp.example.

Значення: PTR існує і вказує на mx.corp.example.

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

Завдання 13: Підтвердіть, що форвардний DNS відповідає вашому PTR (не завжди обов’язково, але допомагає)

cr0x@server:~$ dig +short A mx.corp.example
198.51.100.25

Значення: Forward-confirmed reverse DNS (FCrDNS) узгоджено.

Рішення: Якщо A-запис не відповідає IP з PTR, очікуйте підозри. Виправте відповідність імені та IP, де можливо.

Завдання 14: Перевірте, чи HELO/EHLO ім’я реальне

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mx.corp.example
smtp_helo_name = mx.corp.example

Значення: Ви ідентифікуєтесь як mx.corp.example.

Рішення: Якщо HELO — «localhost» або внутрішнє ім’я хоста, виправте це. Деякі отримувачі відхиляють одразу; інші знижують вашу оцінку.

Завдання 15: Перевірте, чи ваш IP у поширених RBL (перевірка через DNS)

cr0x@server:~$ for rbl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
ip=198.51.100.25; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); \
ans=$(dig +short ${rev}.${rbl} A); \
echo "$rbl: ${ans:-not-listed}"; \
done
zen.spamhaus.org: not-listed
bl.spamcop.net: not-listed
b.barracudacentral.org: 127.0.0.2

Значення: Включені в один RBL (приклад: відповідь Barracuda).

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

Завдання 16: Виявлення піків вихідного трафіку (скомпрометований акаунт або скрипт gone feral)

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 20
Postfix log summaries for: Fri Jan  3 2026

Grand Totals
------------
messages processed:                    18432
messages delivered:                    12010
messages deferred:                      5200
messages bounced:                       1222
rejected connections:                    410

Значення: Великий обсяг + багато відкладених/відскочених + відмов: класичний профіль спалаху.

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

Завдання 17: Перевірте використання Postfix SASL (полювання на скомпрометовані облікові)

cr0x@server:~$ sudo grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head
  8420 sasl_username=support@corp.example
  3011 sasl_username=noreply@corp.example
   188 sasl_username=dev@corp.example

Значення: Один акаунт домінує у вихідних автентифікаціях.

Рішення: Якщо верхній відправник несподіваний — оберніть пароль/токен, перевірте IP-джерела і додайте MFA/обмеження для SMTP submission.

Завдання 18: Підтвердіть розділення submission і relay (порт 587 з автентифікацією)

cr0x@server:~$ sudo ss -lntp | grep -E ":25|:587"
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1010,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1010,fd=15))

Значення: Слухають і SMTP (25), і submission (587).

Рішення: Переконайтесь, що порт 25 не дозволяє неавтентифікований ретрансляцію, а 587 вимагає auth/TLS. Неправильні налаштування тут можуть спричинити «550 rejected» далі, після внесення вас у списки.

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

Три корпоративні міні-історії з полі бою

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

Середня компанія мігрувала вихідну пошту зі старої VM на блискучий новий інстанс у хмарі. Те ж ім’я хоста, такий самий конфіг Postfix,
ті ж DKIM-ключі. Зміни зробили в тихий період і відправили святковий «все працює» лист собі. Він прийшов.
Вони закрили зміну.

У понеділок вранці рахунки клієнтам почали відскакувати з 550 5.7.1 rejected. Внутрішньо все «виглядало добре».
Логи показували успішні доставки на особисті акаунти Gmail. Команда припустила, що шлюз клієнта зламався,
тому що, звісно, він зламався. Вони відкрили тикет у IT клієнта і чекали.

Клієнт відповів: «У вас не проходить SPF». Це звучало неможливо — SPF не змінювався. Неправильне припущення було тонким:
вони думали, що вихідний IP — це IP інстансу. Насправді трафік виходив через інший egress IP у хмарній мережі.
SPF все ще авторизував старий IP, а не NAT.

Виправлення зайняло десять хвилин: оновити SPF реальним egress IP і додати другий include для нового шляху реле. Розблокування зайняло більше часу:
клієнт уже тимчасово заблокував, бо повторні спроби виглядали як зловживання.

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

Міні-історія 2: Оптимізація, що обернулась проти

Інша компанія вирішила «оптимізувати доставність», централізувавши всю вихідну пошту через один високопродуктивний MTA.
Логіка була акуратна: одне місце для DKIM, одне місце для налаштування TLS, один IP для розігріву. Навіть купили «преміальний» IP у провайдера.
Хтось зробив слайд. На ньому були стрілочки.

Це працювало — поки маркетинг не запустив кампанію з новим доменом для трекінгу посилань і сильно стиснутим HTML-шаблоном.
Централізований MTA почав нести як транзакційні квитанції, так і розсилку. Рівень скарг піднявся.
Декілька корпоративних одержувачів почали відхиляти через політики 550; потім домени сімейства Microsoft почали власне лімітувати; потім пішли включення в RBL.

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

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

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

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

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

Однієї ночі їхній провайдер DNS мав частковий збій, який не вивів домени з ладу, а лише спричинив переривчасті таймаути TXT-запитів у деяких регіонах.
SPF-запити почали повертати таймаути. Деякі отримувачі трактуали це як permerror і відхиляли з 550 5.7.1.
Інші приймали, але занижували оцінку. Було брудно й непослідовно.

Seed-тести засвітилися за хвилини: DKIM проходив, але SPF флапав. On-call не гадали. Вони порівняли резолвери, підтвердили проблему DNS,
і переключилися на резервного провайдера DNS, який налаштували місяцями раніше, бо хтось наполягав, що це «краща практика».

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

Жарт №2: Найкращий інструмент для доставності пошти — нагадування в календарі: не робіть креативних речей у п’ятницю після обіду.

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

1) «550 5.7.1 rejected» лише для одного великого клієнта

Симптом: Gmail працює, малі домени працюють, один корпоративний відхиляє все.

Корінь: У клієнта політика allowlist/denylist, строгі правила вхідного шлюзу або вимоги TLS/auth alignment; ваш IP/домен може бути локально заблокований.

Виправлення: Отримайте точний текст відмови; попросіть клієнта прислати причину політики; надайте їм ваші IP відправлення, домен envelope-from і DKIM d= домен; налаштуйте rDNS і послідовний HELO; просіть allowlist тільки після виправлення автентифікації.

2) «550 5.1.1 user unknown» після міграції

Симптом: Раніше дійсні адреси тепер відскакують як «не знайдено».

Корінь: Ви доставляєте на неправильний MX (застарілий кеш DNS, неправильний домен або помилка в написанні), або одержувач змінив тенант і ваш старий маршрут мертвий.

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

3) «550 reverse DNS required»

Симптом: Миттєва відмова на ранньому етапі SMTP-розмови.

Корінь: Відсутній PTR-запис, загальний PTR або невідповідність між PTR і A-записом; HELO також не збігається.

Виправлення: Встановіть PTR на стабільне ім’я хоста; переконайтеся, що це ім’я резолвиться назад на той самий IP; налаштуйте HELO/ваш MTA відповідно.

4) «550 relay denied» коли додатки відправляють пошту

Симптом: Додатки не можуть відправляти; люди можуть.

Корінь: Додаток підключається до порту 25 без автентифікації; submission має бути на 587 з SMTP AUTH і STARTTLS; або ваші обмеження ретрансляції правильні, а додаток очікує відкритий ретранслятор (його не повинно бути).

Виправлення: Налаштуйте додатки на порт submission 587, увімкніть автентифікацію, обмежуйте за IP де доречно, і підтвердіть, що додаток використовує коректний envelope-from.

5) «550 5.7.26 DMARC reject» при переадресації

Симптом: Пересилання ламається; пряма доставка працює.

Корінь: SPF не проходить на форвардерах (через зміну IP при пересиланні) і DKIM відсутній або пошкоджений; політика DMARC — reject і вирівнювання не проходить.

Виправлення: Переконайтеся, що DKIM-підпис зберігається при передачі (не переписуйте підписані заголовки); розгляньте ARC для форвардерів під вашим контролем; для сторонніх форвардерів зосередьтеся на вирівнюванні DKIM.

6) «550 message content rejected» після додавання нового трекера посилань

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

Корінь: Репутація URL/домена трекінгу погана, або контент тригерить евристику фішингу; іноді блокують вкладення.

Виправлення: Видаліть або замініть підозрілі URL; переконайтеся, що домен трекінгу має правильний DNS та репутацію; уникайте скорочувачів URL; тримайте HTML простим; розділіть потоки/IP.

7) «550 rejected» почалося відразу після посилення SPF

Симптом: Ви змінили SPF на -all і тепер листи відскакують.

Корінь: Ви забули легітимного відправника (helpdesk, CRM, payroll, принтери, старий app server) або перевищили обмеження DNS-запитів, що спричинило permerror.

Виправлення: Зробіть інвентар відправників, зменшіть використання include, спростіть SPF за потреби і провалідуйте кожен потік. Не використовуйте SPF як зброю проти власної інфраструктури.

8) Случайні 550 з «policy restrictions» у різних отримувачів

Симптом: Не всі листи відхиляються; є шум.

Корінь: Погіршення репутації плюс непослідовне оцінювання отримувачами; або переривчасті DNS/TLS проблеми, через які деякі отримувачі відмовляють.

Виправлення: Перевірте піки обсягів, скомпрометовані акаунти, надійність DNS, помилки TLS-handshake і стан черги; потім стабілізуйте поведінку і розігрівайте репутацію назад.

Мета-помилка в більшості цих випадків: команди трактують відмови як «проблема на боці іншого». Іноді так і є. Але переважно — це ваша проблема, просто висловлена через сервер іншої сторони.

Контрольні списки / покроковий план розблокування

Крок 0: Припиніть погіршувати ситуацію

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

Крок 1: Визначте, який потік не працює

• Це транзакційна пошта (скидання пароля, рахунки) чи масова (розсилки)?
• Один адресу відправника, один домен чи весь вихід?
• Один домен-одержувач чи кілька?

Якщо ви не можете розділити потоки — зробіть це зараз. Це не «приємно мати». Це контроль зони ураження.

Крок 2: Виправте базові ідентичності (те, що треба зробити перед проханням про делістинг)

• Виправіть SPF для реальних egress IP і вендорів.
• Увімкніть DKIM-підписи послідовно для видимого From-домену (або вирівняного піддомену).
• Опублікуйте DMARC з політикою, яку ви можете підтримати (почніть з p=none, якщо сліпі; посилюйте коли вирівняєте).
• Налаштуйте rDNS/PTR і зв’яжіть HELO/EHLO з резольвованим іменем хоста.
• Переконайтеся, що TLS працює; деякі отримувачі вимагають STARTTLS і сучасні шифри.

Крок 3: Переконайтеся, що ваша поведінка не схожа на ботнет

• Тримайте стабільні швидкості відправлення; уникайте раптових стрибків у 10x.
• Використовуйте послідовні envelope-from і From-домени; не змінюйте ідентичності, щоб «обійти блоки». Це виглядає як зловживання.
• Реалізуйте обробку відскоків і пригнічення недійсних адрес.
• Забезпечте роботу unsubscribe для масових розсилок. Так, це впливає на відмови.

Крок 4: Цільові дії для розблокування

• Якщо вас внесли в RBL: з’ясуйте причину (компрометація, відкритий ретранслятор, патерни скарг), виправте корінь, потім просіть делістинг.
• Якщо один корпоративний блок: надайте їхнім адміністраторам ваші IP відправлення, DKIM-домен та приклади; просіть тимчасовий allowlist тільки після виправлень.
• Якщо блокують споживчі провайдери: зосередьтеся на автентифікації, репутації та вмісті; розігрівайте повільно і моніторьте відскоки/скарги.

Крок 5: Доведіть виправлення контрольованим тестуванням

• Відправте мінімальний plain-text лист (без посилань, без вкладень) на проблемний домен. Якщо доставляється — підозра на контент.
• Надішліть один типовий транзакційний шаблон; потім один маркетинговий шаблон.
• Порівняйте заголовки та результати автентифікації між повідомленнями.

Крок 6: Налаштуйте нудний моніторинг, щоб цього не повторилося

• Алертуйте про рівень відскоків, відкладень і відмов по доменах.
• Стежте за проходженням автентифікації SPF/DKIM/DMARC по потоках.
• Ведіть інвентар легітимних відправників і вендорів.
• Репутація не потребує щоденної паніки, але потребує щотижневого догляду.

Одна цитата, щоб тримати вас у тонусі:

«Надія — не стратегія.» — загальний інженерний максимум, часто приписується операційним лідерам (парафраз)

Доставність пошти — це місце, куди надія приходить, щоб її обмежили швидкістю.

FAQ

1) Чи завжди «550 rejected» — це моя вина?

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

2) У чому різниця між 550 5.7.1 і 550 5.1.1?

5.1.1 зазвичай «поганий одержувач» (користувач не знайдений). 5.7.1 — це «політика/безпека».
Перше частіше проблема каталогу/даних. Друге — ідентичність/репутація/контент/політика.

3) Якщо SPF проходить, чи можна ігнорувати DKIM і DMARC?

Ні, якщо вам важлива стабільна доставка. SPF ламається при пересиланні і на деяких ретрансляторах.
DKIM дає стійкий сигнал ідентичності. DMARC пов’язує їх і дає отримувачам чітку політику та вам звітність.

4) Чому це почалося після переходу в нового хмарного провайдера?

Нові IP, нова еґрес/нат-ідентичність, відсутній rDNS і тонкі відмінності в TLS — часті тригери.
Хмарні IP часто мають нейтральну репутацію як максимум. Розігрівайте повільно і тримайте автентифікацію в ідеальному стані.

5) Чи можна просто змінити IP, щоб обійти блок?

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

6) Ми в RBL, але не розсилаємо спам. Що робити?

RBL списки фіксують поведінку, а не ваше уявлення про себе. Можливо, у вас скомпрометований ящик, відкритий порт підпису, вразливий веб-додаток, що відправляє пошту,
або вендор погано використовує ваш домен. Ідентифікуйте джерело відправлення і припиніть його. Потім просіть делістинг.

7) Наші листи відхиляють лише з вкладеннями. Чому?

Вкладення запускають перевірки на шкідливість, політики типів файлів і обмеження розміру. Деякі шлюзи відхиляють певні розширення або захищені паролем архіви.
Тестуйте спочатку простий plain-text лист; потім додавайте вкладення. Якщо вкладення необхідне — використовуйте дозволені формати або надавайте захищені посилання для завантаження (зі шанованими доменами).

8) Чи справді rDNS важливий у 2026?

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

9) Чому ми доставляємось до Gmail, але не до доменів на Microsoft?

Різні моделі оцінювання, різна толерантність до сумнівних сигналів і різні ліміти. Вважайте це підказкою: порівняйте результати автентифікації, TLS і патерни відправлення.
Часто фільтрація Microsoft менш поблажлива до раптових змін обсягів.

10) Скільки часу потрібно відновити репутацію після блоку?

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

Висновок: кроки, які ви можете виконати сьогодні

«550 rejected» — це сигнал від отримувача, що він не довіряє цьому повідомленню, цьому відправнику або цій поведінці. Ваш найшвидший шлях — не хаотичні зміни в налаштуваннях.
Це дисциплінована діагностика і цілеспрямовані виправлення.

1. Захопіть точну відмову (розширений код + текст) і визначте, чи це ідентичність, репутація чи маршрутизація.
2. Перевірте основи: реальний відправний IP, проходження SPF, наявність/коректність DKIM, вирівнювання DMARC, rDNS, HELO, TLS.
3. Зупиніть витік: призупиніть масові відправлення, обмежьте швидкість, знайдіть скомпрометовані акаунти, очистіть списки.
4. Доведіть виправлення контрольованими тестами, які ізолюють контент, політику або проблеми одержувача.
5. Запобігайте повторенню, відокремивши потоки і моніторячи патерни відмов за доменом і результатами автентифікації.

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