Блокування електронної пошти «550 5.7.1» — реалістичний шлях виправлення

Що насправді означає 550 5.7.1 (і чому воно навмисно неясне)

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

Ключова деталь: «політика» — це рішення віддаленої сторони. Воно може бути викликане вашою автентичністю
(SPF/DKIM/DMARC), репутацією IP чи домену, зворотним DNS та ідентичністю HELO/EHLO, TLS-параметрами,
вмістом повідомлення, шаблонами відправлення або внутрішніми правилами одержувача. Іноді це комбінація.

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

Практичний зсув в мисленні: перестаньте думати «пошта впала». Думайте «доставленість не працює».
Це не педантизм. Доступність — це ваш сервер онлайн. Доставленість — це те, чи довіряють вам інші.
Інструменти інші. Виправлення інші. Термінологія інша.

Швидкий план діагностики (швидко знайдіть вузьке місце)

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

Спочатку: класифікуйте відхилення

• Де воно відхиляється? Під час діалогу SMTP (RCPT TO / DATA) чи після прийняття (повернення пізніше)?
• Чи це для всіх одержувачів чи для одного домену? «Тільки до Microsoft» відрізняється від «до всіх».
• Чи це від усіх відправників чи від одного домену From? Невідповідність DMARC часто виглядає як «деякі бренди падають».

По-друге: перевірте ідентичність та вирівнювання (легкі перемоги)

• SPF: авторизовані вихідні IP(и) і include-ланцюги без розривів.
• DKIM: дійсний підпис, правильний селектор, не прострочені ключі, підписуються потрібні заголовки.
• DMARC: вирівнювання між видимим From і ідентичностями SPF/DKIM.

По-третє: перевірте сигнали репутації (повагається час)

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

По-четверте: перевірте презентацію SMTP (rDNS/HELO/TLS)

• Зворотний DNS існує і відповідає оголошеній назві хоста (або принаймні виглядає навмисним).
• HELO/EHLO — це реальний FQDN з відповідним прямим DNS.
• TLS коректний; сертифікати не прострочені; ви не рекламуєте дивні шифри.

По-п’яте: вміст і маршрутизація

• Тригери контенту: URL-сервіси скорочення, пошкоджений MIME, відсутній List-Unsubscribe для розсилок, підозрілі типи вкладень.
• Маршрутизація: чи не реле ви несподівано використовуєте смарт-хост або cloud NAT, що змінив вихідний IP?

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

Цікаві факти та історичний контекст (щоб дивність стала зрозумілішою)

1. SMTP передував спаму на десятиліття. Початкова модель припускала переважно кооперативних партнерів; автентифікація не була пріоритетною вимогою.
2. Розширені коди стану (на кшталт 5.7.1) були стандартизовані пізніше щоб надати більше нюансів, ніж «550», але провайдери й далі їх перевантажують.
3. SPF почався як ідея «хто може відправляти для цього домену» через широку підробку відправників; це ніколи не було повним рішенням проти фішингу.
4. DKIM з’явився як підписування на рівні домену щоб краще переживати пересилки, ніж SPF; він усе ще крихкий, коли проміжні вузли переписують вміст.
5. Справжня сила DMARC — в вирівнюванні та політиці. Вона дозволяє власнику домену заявити «якщо це не автентифікується як я — відхилити або карантинувати».
6. Зворотний DNS став соціальним контрактом. Це не сувора протоколна вимога, але багато одержувачів трактують відсутність PTR як «ймовірний ботнет».
7. Чорні списки існували ще до сучасних систем репутації. Ранні опертори ділилися списками, бо це було швидше, ніж сперечатися з кожним спамером окремо.
8. Великі провайдери використовують пропрієтарні рухи репутації. Ви можете пройти SPF/DKIM/DMARC і все одно бути заблоковані, якщо ваш трафік виглядає зловмисним.
9. «Політика» також означає локальні рішення відповідності. Деякі організації відхиляють пошту з адрес із діапазонів для домашніх користувачів, певних геозон або з низьким TLS-профілем незалежно від автентифікації.

Збирайте докази перш ніж «виправляти» щось

Коли пошта ламається, люди починають «пробувати щось». Ось як у вас з’являються три напівналаштовані DKIM-селектори,
SPF-запис, що перевищує ліміт DNS-запитів, і проблема з репутацією, яку ви не можете пояснити, бо змінили п’ять змінних одночасно.

Зберіть невеликий пакет доказів. Це не бюрократія; це те, як уникнути повторних відмов.

• Одне повне повідомлення про відмову включно з заголовками та транскриптом SMTP (не скріншот).
• Логи Postfix/Exim навколо відмови з ідентифікатором черги та відповіддю віддаленого сервера.
• Вихідний IP і ім’я хоста як вони спостерігаються зовні (не те, що ви думаєте).
• Поточні DNS-записи для SPF, DKIM-селекторів, DMARC, MX, A/AAAA, PTR.
• Останні зміни в відправленні: нова маркетингова кампанія, новий IP, нове реле, розгортання додатка, зміна NAT або відновлення після компрометації акаунту.

Жарт №1: Якщо ваше «виправлення» — це редагування DNS із пам’яті о 2-й ночі, вітаю — ви винайшли рулетку з меншим вмістом алкоголю.

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

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

Завдання 1: Знайдіть точний текст відмови та стадію (Postfix)

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred|5\.7\.1|policy" /var/log/mail.log | tail -n 8
Jan 04 10:11:22 mx1 postfix/smtp[18422]: 9C2E91A2C4: to=<user@recipient.example>, relay=mx.recipient.example[203.0.113.9]:25, delay=2.1, delays=0.1/0.02/0.6/1.4, dsn=5.7.1, status=bounced (host mx.recipient.example[203.0.113.9] said: 550 5.7.1 Message rejected due to policy (in reply to end of DATA command))
Jan 04 10:11:23 mx1 postfix/qmgr[913]: 9C2E91A2C4: removed

Значення: Відмова в кінці DATA означає, що віддалений прийняв обгортку (envelope), але не сподобався вміст або результати сканування автентифікації.
Якщо б відмовили на RCPT TO, швидше за все це репутація IP, RBL або політика одержувача.

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

Завдання 2: Безпечно перегляньте повідомлення в черзі (Postfix)

cr0x@server:~$ sudo postcat -q 9C2E91A2C4 | sed -n '1,120p'
*** ENVELOPE RECORDS ***
message_size: 48231            1980             1               0               0
message_arrival_time: Sat Jan  4 10:11:20 2026
create_time: Sat Jan  4 10:11:20 2026
named_attribute: log_ident=mx1
sender: noreply@brand.example
*** MESSAGE CONTENTS ***
Received: from app1.internal (app1.internal [10.0.2.15])
        by mx1.brand.example (Postfix) with ESMTPSA id 9C2E91A2C4
        for <user@recipient.example>; Sat, 04 Jan 2026 10:11:20 +0000 (UTC)
From: "Brand Support" <noreply@brand.example>
To: <user@recipient.example>
Subject: Password reset
Date: Sat, 04 Jan 2026 10:11:20 +0000
Message-ID: <20260104101120.12345@app1.internal>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Значення: Це підтверджує видимий домен From, шлях подачі (ESMTPSA від внутрішнього додатка)
і чи виглядають заголовки «нормально». Message-ID на внутрішньому домені може бути незначним сигналом недовіри для деяких фільтрів.

Рішення: Якщо Message-ID або інші заголовки виглядають дивно, виправте політику заголовків у додатку/MTA (домен Message-ID, Date, MIME). Потім повторно перевірте перед зміною DNS.

Завдання 3: Визначте, з якого IP ви фактично відправляєте (surprises з NAT реальні)

cr0x@server:~$ ip route get 8.8.8.8 | sed -n '1p'
8.8.8.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000

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

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

Завдання 4: Перевірте прямий DNS для вашого поштового хоста (A/AAAA)

cr0x@server:~$ dig +short A mx1.brand.example
192.0.2.10

Значення: Ім’я хоста резольвиться. Багато приймачів штрафують HELO-імена, що не резольвяться.

Рішення: Якщо пусто — виправіть DNS. Якщо воно резольвиться в неправильний IP — виправте це перед будь-якими іншими діями.

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

cr0x@server:~$ dig +short -x 192.0.2.10
mx1.brand.example.

Значення: PTR існує і виглядає навмисним.

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

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

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|smtp_helo_name'
mydomain = brand.example
myhostname = mx1.brand.example
smtp_helo_name = $myhostname

Значення: Ви представляєте стабільний FQDN. Добре.

Рішення: Якщо smtp_helo_name встановлено як некваліфіковане (наприклад «mail») або внутрішнє, виправте і перезапустіть Postfix.

Завдання 7: Перевірте SPF-запис і виявлення DNS-перевантаження

cr0x@server:~$ dig +short TXT brand.example | sed -n '1,3p'
"v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all"

Значення: SPF присутній. Але це не каже, чи включення перевищують ліміт у 10 DNS-запитів.

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

Завдання 8: Оцініть SPF зовні за допомогою локального інструменту (симуляція результатів автентифікації)

cr0x@server:~$ python3 - <<'PY'
import sys, dns.resolver
domain="brand.example"
answers=dns.resolver.resolve(domain,'TXT')
for r in answers:
    for s in r.strings:
        t=s.decode()
        if t.startswith("v=spf1"):
            print(t)
PY
v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all

Значення: Підтверджує рядок SPF, який ви публікуєте. Це все ще не повна оцінка SPF, але швидко ловить «кілька SPF-записів» і очевидні форматні помилки.

Рішення: Якщо бачите більше одного v=spf1-запису, виправте негайно. Приймачі можуть трактувати це як SPF permerror.

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

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

Значення: У вас суворе вирівнювання (adkim=s, aspf=s) і політика reject.
Чудово для протидії фішингу. Також безжально, якщо ваші системи не ідеально вирівняні.

Рішення: Якщо після ввімкнення суворого DMARC ви отримали політичні блокування від великих провайдерів, підтвердіть, що всі легітимні відправники підписують DKIM з d=brand.example або що SPF вирівнюється з доменом From.

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

cr0x@server:~$ dig +short TXT s2024._domainkey.brand.example | head -n 2
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt..."

Значення: Селектор існує. Відсутній селектор — дуже поширена причина простою після ротації ключів з забутим DNS.

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

Завдання 11: Підтвердіть конфігурацію підписування DKIM (OpenDKIM + Postfix приклад)

cr0x@server:~$ sudo egrep -n 'Domain|Selector|KeyFile|Socket' /etc/opendkim.conf | head
14:Domain                 brand.example
15:Selector               s2024
16:KeyFile                /etc/opendkim/keys/brand.example/s2024.private
23:Socket                 inet:8891@localhost

Значення: Показує, який домен DKIM і селектор ви налаштовані використовувати.

Рішення: Якщо Domain/Selector не відповідають DNS — виправте конфіг. Якщо шлях KeyFile неправильний або права зламані, DKIM-підписування тихо не працює і приймачі вирішують, що ви підозрілий.

Завдання 12: Перевірте Authentication-Results на доставленому повідомленні (джерело правди)

cr0x@server:~$ grep -i "Authentication-Results" -n /var/mail/test-inbox | tail -n 3
120:Authentication-Results: mx.google.example; spf=pass (google.example: domain of noreply@brand.example designates 192.0.2.10 as permitted sender) smtp.mailfrom=noreply@brand.example; dkim=pass header.i=@brand.example header.s=s2024; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand.example

Значення: Це вердикт приймача. Якщо там написано SPF pass, DKIM pass, DMARC pass — можете перестати гадати і перейти до репутації/вмісту/лімітів.

Рішення: Якщо SPF/DKIM/DMARC тут падають — виправте вирівнювання перед будь-якими іншими діями. Локальний успіх не має значення; важлива оцінка приймача.

Завдання 13: Перевірте, чи ваш IP потрапив до загальних DNSBL (швидкий сигнал, не є Євангелієм)

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

Значення: Порожній вивід свідчить «не в списку» для цих. Якщо ви отримаєте IP у відповіді — ви в списку.

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

Завдання 14: Перевірте TLS-позицію зовні (STARTTLS, ланцюг сертифікатів)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.brand.example:25 -servername mx1.brand.example /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mx1.brand.example
issuer=CN = R3, O = Let's Encrypt, C = US
notBefore=Dec 15 00:00:00 2025 GMT
notAfter=Mar 14 00:00:00 2026 GMT

Значення: Сертифікат дійсний і не прострочений.

Рішення: Якщо прострочений або не відповідає — виправте сертифікати. Деякі організації застосовують «політичні» блокування через відсутність TLS або зламаний TLS, особливо для B2B-пошти.

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

cr0x@server:~$ swaks --server mx1.brand.example --to victim@external.example --from attacker@external.example --data "Subject: test

hello"
=== Trying mx1.brand.example:25...
=== Connected to mx1.brand.example.
<-  220 mx1.brand.example ESMTP Postfix
 -> EHLO server
<-  250-mx1.brand.example
 -> MAIL FROM:<attacker@external.example>
<-  554 5.7.1 Relay access denied

Значення: Реле відхилено для неавтентифікованого зовнішнього відправника. Добре.

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

Завдання 16: Перевірте зростання вихідної черги та поведінку повторних спроб

cr0x@server:~$ mailq | tail -n 5
-- 2 Kbytes in 1 Request.

Значення: Низька черга — добре. Під час інциденту ви можете бачити сотні/тисячі повідомлень у черзі з повторними відкладеннями.

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

Звідки беруться політичні блокування: реальні режими відмов

1) Автентифікація проходить… але не вирівняна

Це найдратівливіший варіант, бо ваші логи гордо показують «SPF=pass» і «DKIM=pass» десь,
але DMARC падає і приймач трактує вас як підробника. Вирівнювання — це різниця між
«домен автентифіковано» і «видимий домен From автентифіковано».

Типові причини:

• Ваш додаток надсилає From: brand.example, але конвертний відправник — bounce@mailer.vendor.example, і лише він проходить SPF.
• DKIM підписує з d=vendor.example замість d=brand.example.
• DMARC встановлено на суворе вирівнювання, тоді як легітимні піддомени надсилають пошту, що не збігається точно.

2) Спіраль смерті репутації (обсяги та відмови)

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

Відновлення можливе, але повільне і нудне. Це добре: означає, що злочинці теж не можуть миттєво «скинути» репутацію.

3) Невідповідність ідентичності інфраструктури (rDNS, HELO, динамічний IP)

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

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

4) Блокування політикою на основі вмісту (так, ваша нешкідлива пошта може виглядати зловмисною)

Фільтри безжальні щодо патернів, що корелюють зі зловживанням:
зіпсовані MIME-границі, HTML-листи тільки з крихітним текстом і гігантськими посиланнями, скорочені URL, невідповідність видимого тексту і реальної URL,
вкладення з макросами та «новий домен + терміновість + посилання для входу».

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

5) Переспрямування і розсилки ламають SPF (а іноді DKIM)

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

Якщо ваша аудиторія включає університети, розсилки, тикетингові системи та шлюзи безпеки,
це може бути значною частиною «випадкових» відмов 5.7.1.

6) Провайдер-специфічне обмеження та політичні шлюзи

Великі провайдери та корпоративні шлюзи впроваджують власні бар’єри: ліміти по IP, кешування по домену, контроль сплесків і підозру до «нових відправників».
Іноді вони відповідають 4xx відкладеннями. Іноді — 5xx політичними блокуваннями, що фактично означають «поверніться, коли репутація покращиться».

Тут оператори марнують дні, сперечаючись з протоколом. Це не проблема протоколу. Це система боротьби зі зловживанням, що виконує свою роботу.

Одна цитата, що тримає команди чесними

Перефразована ідея від Річарда Кука (безпека і надійність): «успіх приходить від постійних налаштувань; невдача — коли ці налаштування не встигають за подіями».

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

Міні-історія №1: Інцидент через хибне припущення (NAT, що вкрав пошту)

Середня SaaS-компанія використовувала Postfix на парі віртуальних машин. У них були SPF, DKIM, DMARC — всі зелені у власних тестах.
Але частина транзакційної пошти до великого поштового провайдера почала відхилятися з 550 5.7.1.
Команда припустила «DKIM зламався», бо це типовий винуватець після деплою.

Вони ротували DKIM-ключі. Вони підправляли вирівнювання DMARC. Додавали ще один include у SPF.
Відмова тривала. Черга злітала. Підтримка ставала голоснішою.

Справжня причина була буденною: мережна команда перемістила поштові VM за інший еgress NAT під час робіт з міжмережевим екраном.
Вихідна пошта тепер виходила з IP, якого немає в SPF і без сконфігурованого rDNS.
Їхні внутрішні тести потрапляли до більш поблажливого тестового провайдера; великий провайдер таким не був.

Коли вони визначили справжній egress IP (перевіривши маршрутизацію і порівнявши з логами отримувача),
виправлення було простим: оновити SPF для нового IP, задати коректний PTR і стабілізувати HELO.
Урок запам’ятався: в пошті питання «з якого IP ми відправляємо?» — це не філософське питання. Це головний рядок судово-медичного висновку.

Міні-історія №2: Оптимізація, що дала зворотний ефект (тонке налаштування черги vs репутація)

Команда підприємства вирішила, що їхня вихідна пропускна здатність «занадто повільна». Маркетинг хотів швидших запусків.
Хтось підняв конкорренцію та швидкість з’єднань у Postfix. Графіки виглядали чудово. Затримка знизилася.
MTA поводився, наче випив три еспресо і знайшов нову мету в житті.

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

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

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

Міні-історія №3: Нудна, але правильна практика, що врятувала день (DMARC-звіти як ранній дим)

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

Одного тижня вони помітили нове джерело, що надсилало пошту від імені їхнього домену, провалюючи вирівнювання, з випадкового хостинг-провайдера.
Це не була їхня інфраструктура. Не був авторизований вендор. Це було або підроблення, або скомпрометована третя сторона.
Жоден клієнт ще не скаржився. Чорні списки ще не торкнулися їх. Але дим був видимий.

Вони посилили SPF, перевірили DKIM-селектори для всіх вендорів і звернулися до хостинг-провайдера з доказами.
Також вони превентивно переконались, що їхні легітимні потоки пошти ідеально вирівняні і підписані, щоб не потрапити в зону ураження.

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

Жарт №2: Доставленість електронної пошти — єдина сфера, де робити все правильно все одно відчувається, ніби тебе оцінює кіт.

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

1) Симптом: 550 5.7.1 з’являється тільки для одного великого провайдера

Корінна причина: Провайдер-специфічна оцінка репутації, обмеження або евристика контенту; іноді відсутній rDNS/TLS, що менші провайдери ігнорують.

Виправлення: Перевірте Authentication-Results від цього провайдера, підтвердіть egress IP, виправте rDNS/HELO/TLS, потім знизьте швидкість відправлення і очистіть відмови. Очікуйте часу на відновлення.

2) Симптом: SPF «pass», але DMARC падає

Корінна причина: SPF проходить для іншого домену (envelope sender), ніж видимий домен From; вирівнювання DMARC не проходить.

Виправлення: Переконайтесь, що домен конверта узгоджується з From (або налаштуйте DKIM з d=brand.example і вирівняйте DMARC). Уникайте суворого вирівнювання поки не впевнені, що всі джерела відповідають.

3) Симптом: Все працює, поки ви не ротуєте DKIM-ключі

Корінна причина: Новий селектор не опубліковано в DNS, затримка TTL або неправильні права на файл ключа, що викликає тиху відмову підписування.

Виправлення: Опублікуйте селектор спочатку, зачекайте TTL, валідируйте за допомогою dig, потім переключайте підписування. Моніторте логи на помилки DKIM.

4) Симптом: Раптовий сплеск відмов, а потім політичні блокування

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

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

5) Симптом: Політичні блокування почалися після переходу у новий регіон хмари

Корінна причина: Новий діапазон IP має холодну/погану репутацію; відсутній rDNS; невідповідність між HELO і PTR; деякі провайдери недовіряють певним діапазонам.

Виправлення: Налаштуйте PTR і прямий DNS правильно, поступово розігрівайте IP і розгляньте використання авторитетного реле під час розігріву для критичної пошти.

6) Симптом: Тільки переспрямовані одержувачі відмовляються (університети, розсилки, тикети)

Корінна причина: SPF ламається при пересиланні; DKIM ламається, якщо тіло змінюють; DMARC падає і приймачі застосовують політику.

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

7) Симптом: «Relay access denied» внутрішні користувачі кажуть, що це 5.7.1 політика

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

Виправлення: Налаштуйте подачу на 587 з автентифікацією, перевірте smtpd_recipient_restrictions і переконайтесь, що клієнти використовують STARTTLS + auth.

8) Симптом: Відмова відбувається в кінці DATA для листів з великою кількістю HTML

Корінна причина: Оцінювання вмісту: репутація URL, пошкоджений MIME, домени відстеження, невідповідність From/відображуваного імені, відсутня частина text/plain.

Виправлення: Перевірте MIME, додайте multipart/alternative з text/plain, видаліть ризикові URL-патерни, виправте зламаний HTML, уникайте скорочувачів і вирівняйте домени відстеження з вашим брендом.

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

Покроково: стабілізація інциденту (перші 2 години)

1. Перестаньте погіршувати ситуацію. Призупиніть масові потоки і підозрілі відправники. Якщо можете ізолювати — тримайте скидання паролів і чеки в роботі.
2. Виберіть один домен-одержувач і один зразок повідомлення. Не налагоджуйте десять одночасно.
3. Захопіть транскрипт відмови та ідентифікатор черги, плюс віддалену відповідь і стадію (RCPT vs DATA).
4. Підтвердіть egress IP і перевірте узгодженість PTR + HELO + A-запис.
5. Перевірте SPF/DKIM/DMARC з перспективи приймача за допомогою Authentication-Results з тестової скриньки.
6. Перевірте очевидні прапорці репутації: наявність у DNSBL і чи є IP новим/холодним.
7. Робіть одну зміну за раз, документуйте її і повторно тестуйте. DNS-зміни — це «повільні зміни».

Покроково: виправлення ідентичності й вирівнювання (цей же день)

1. SPF: один запис, правильні авторизовані IP, уникайте надмірних include, використовуйте -all лише коли впевнені.
2. DKIM: підписуйте всі вихідні потоки пошти з вирівняним d= під видимим доменом From. Ротуйте ключі з перекриттям.
3. DMARC: під час розгортання почніть з p=none, якщо є невідомі джерела; переходьте до quarantine і reject коли показники стабільні.
4. Конвертний відправник: переконайтесь, що домен для bounce під вашим контролем і вирівнюється, якщо SPF — ваш основний шлях.
5. Заголовки: виправте домен Message-ID, Date, структуру MIME і впевніться, що не генеруєте пошкоджений вміст.

Покроково: відновлення репутації (дні–тижні)

1. Зменште обсяги і згладьте сплески. Провайдери недовірують до «рвонутих» відправників.
2. Очистіть списки і приглушіть відмови. Високий рівень жорстких відмов — самостворена шкода.
3. Сегментуйте потоки пошти. Транзакційна пошта не повинна ділити репутацію з маркетингом.
4. Розігрівайте нові IP повільно. Починайте з зацікавлених одержувачів і поступово збільшуйте обсяги.
5. Моніторьте скарги та сигнали взаємодії там, де це доступно (feedback loops, звіти користувачів).
6. Не «виправляйте» репутацію щотижневими стрибками IP. Це нагадує ухилення. Деякі системи пам’ятають.

Операційний контрольний список: що тримати постійно

• Документована діаграма потоку пошти: додатки → submission → MTA → реле (якщо є) → вихідні egress IP.
• DNS-фрагменти під версіонним контролем або інфраструктура як код для SPF/DKIM/DMARC.
• Рунабук ротації ключів: опублікувати селектор, валідувати DNS, переключити підписування, тримати старий селектор у вікні перекриття.
• Обмеження вихідної швидкості по домену/провайдеру і розумні значення конкорренції за замовчуванням.
• Роздільні IP/домени для транзакційної та маркетингової пошти, коли бізнес залежить від проходження чеків.
• Алерти на сплески відмов, зростання черги і раптові помилки автентифікації.

Поширені запитання

1) Чи завжди «550 5.7.1» — це проблема SPF/DKIM/DMARC?

Ні. Часто це корелює з проблемами автентифікації, але це може бути репутація, rDNS/HELO-невідповідність, політика TLS або фільтрація вмісту.
Стадія SMTP важлива: відмова на RCPT частіше вказує на IP/репутацію; відмова в кінці DATA частіше вказує на вміст/автентифікацію після сканування.

2) Ми проходимо SPF, DKIM і DMARC, але все одно отримуємо 550 5.7.1. Що далі?

Припускайте репутацію або вміст. Підтвердіть, що ви відправляєте з очікуваного IP, перевірте PTR/HELO на узгодженість,
перегляньте рівні відмов/скарг і шукайте тригери вмісту (URL, вкладення, пошкоджений MIME, агресивне відстеження).
Також переконайтесь, що ви не робите сплесків трафіку, що запускає політичні шлюзи.

3) Чи можна виправити це зміною IP?

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

4) У чому різниця між SPF fail і SPF permerror?

Fail означає, що IP не авторизований політикою SPF домену. Permerror означає, що запис зламаний (часто через надто багато DNS-запитів або кілька SPF-записів).
Permerror особливо болісний, бо це самостійно створена проблема і може спричинити помилку DMARC навіть для легітимної пошти.

5) Чому пересилання ламає речі?

SPF оцінюється щодо підключного IP. Коли пересильник надсилає вашу пошту далі, підключний IP стає IP пересильника, а не ваш — тому SPF часто падає.
DKIM може пережити пересилання, але ламається, якщо пересильник змінює тіло або підписані заголовки. DMARC падає, якщо ні вирівняний SPF, ні вирівняний DKIM не проходять.

6) Чи слід нам ставити DMARC на p=reject, щоб зупинити підробку?

З часом — так. Але робіть це як SRE, а не як гравець. Перевірте всі легітимні відправники, зробіть DKIM послідовним,
почніть з p=none для спостереження, потім рухайтесь до quarantine і нарешті до reject.
Інакше ви заблокуєте власну ділову пошту і назвете це «безпекою».

7) Як тримати транзакційну пошту, коли маркетинг нас блокує?

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

8) Чи може лише вміст спричинити «політичне блокування» при ідеальній автентифікації?

Так. Автентифікація відповідає «хто ви», а не «чи бажані ви тут». Якщо ваше повідомлення виглядає як доставка шкідливого ПЗ, фішинг або спамна партнерська активність,
деякі приймачі блокуватимуть в кінці DATA. Виправте коректність MIME, видаліть підозрілі URL і уникайте ризикових типів вкладень.

9) Яка найшвидша «саніті-перевірка» під час інциденту?

Витягніть один транскрипт відмови, підтвердіть egress IP і PTR, і отримайте заголовок Authentication-Results з посіяної скриньки.
Це трикутник ідентичності vs репутації vs вмісту швидше за будь-яку дискусію в Slack.

Висновок: наступні кроки, що реально зменшують кількість 550

«550 5.7.1 policy block» — це не одна баг. Це вердикт з іншого кінця інтернету, зазвичай підкріплений купою сигналів, які ви повністю не бачите.
Ваше завдання — зробити вашу ідентичність однозначною, інфраструктуру послідовною та поведінку відправлень нудною.
Нудність — це добре. Нудність доставляється.

Практичні наступні кроки:

1. Побудуйте відтворюваний пакет доказів: транскрипт відмови, ідентифікатор черги, стадія, egress IP і поточні DNS-записи.
2. Зробіть вирівнювання безкомпромісним: DKIM з вирівняним d= для вашого From-домену, SPF, що відповідає фактичному IP відправлення, DMARC, що відображає реальність.
3. Укріпіть SMTP-ідентичність: rDNS, HELO, прямий DNS і дійсні TLS-сертифікати.
4. Контролюйте поведінку: обмеження швидкості, сегментація потоків і запобігання сплескам, що стають інцидентами репутації.
5. Інституціоналізуйте нудну практику: моніторинг результатів автентифікації і сплесків відмов до того, як вони стануть простоєм.

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