Електронна пошта: автентифікований ретранслятор проти прямої відправки — виберіть підхід, який не заблокує вас

Рішення: пряма відправка проти автентифікованого ретранслятора

Пряма відправка (ваш MTA доставляє прямо до MX отримувача)

У моделі прямої відправки ваш сервер запускає MTA (Postfix/Exim тощо) і підключається до поштових обмінників (MX) отримувачів в Інтернеті. Ви контролюєте повну SMTP-сесію, чергу, повторні спроби, політику TLS і пропускну здатність. Ви також успадковуєте повний тягар репутації та інженерії доставляння.

Використовуйте пряму відправку, коли:

• Ви готові вести пошту як production-сервіс (моніторинг, обробка зловживань, управління репутацією).
• Потрібний високий контроль над маршрутизацією, повторними спробами, кастомними політиками та налаштуванням для окремих доменів.
• Обсяг відправлень стабільний, і ви можете правильно «розігріти» IP.
• Ви можете призначити чистий, виділений IP (або ретельно керований пул) з правильним rDNS.

Уникайте прямої відправки, коли:

• Ви на хмарних інстансах з часто змінними IP.
• Ви не контролюєте rDNS/PTR записи (поширено в споживчих VPS-планах та деяких внутрішніх мережах).
• Ви відправляєте невеликі обсяги, але потребуєте високої доставності (репутація ніколи не «стабілізується»).
• У вас немає плану для скарг на спам, bounce’ів та feedback loop.

Автентифікований ретранслятор (ваш сервер надсилає пошту провайдеру)

У моделі автентифікованого ретранслятора ваші системи відправляють пошту на smarthost по SMTP submission (зазвичай порт 587, іноді 465) з автентифікацією (SASL) та TLS. Провайдер ретранслю потім займається доставкою до MX отримувачів. Цим провайдером може бути ESP (сервіс транзакційної пошти), корпоративний пакет (Microsoft 365 / Google Workspace) або внутрішній рівень ретрансляції.

Використовуйте автентифікований ретранслятор, коли:

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

Уникайте автентифікованого ретранслятора, коли:

• Ви не можете терпіти залежність від інфраструктури стороннього провайдера.
• Є суворі вимоги щодо резидентності даних, і ретранслятор не відповідає їм.
• Вам потрібні певні SMTP-поведінки, які ретранслятор не дозволяє (рідко, але трапляється).

Мій операційний ухил

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

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

Факти та історія, що важливі й у 2026 році

• SMTP передував спаму як промисловій проблемі. Ранній SMTP припускав взаємну співпрацю; сучасні фільтри припускають, що вам можна не довіряти, поки не доведено зворотне.
• Блокування вихідного порту 25 стало поширеним, коли провайдери боролися з ботнетами. Багато мереж досі блокують вихід 25; submission-порти (587/465) — практичний шлях.
• SPF з’явився, бо підробити envelope sender було просто. Це DNS-заплатка, яка досі важлива, оскільки отримувачі використовують її для моделювання наміру та відповідальності.
• DKIM створили, щоб захистити заголовки від підміни і довести відповідальність домену. Це не шифрування; це підпис, що іноді переживає пересилання.
• DMARC з’явився, бо SPF і DKIM самі по собі були недостатні. Вирівнювання і політика дозволяють доменам сказати «відхилити, якщо це не справді ми».
• Поштові масові відправники зірвали розвиток складних систем репутації. Ідея «IP хороша/погана» еволюціонувала в репутацію домену, репутацію контенту, сигнали взаємодії та рівень скарг.
• rDNS/PTR залишається грубим, але ефективним фільтром. Відсутність PTR не завжди блокує вас, але часто понижує довіру і збільшує ймовірність потрапляння в спам.
• TLS став очікуванням, а потім сигналом. Опортуністичний STARTTLS — базова вимога; деякі отримувачі зараз оцінюють вас за сучасними шифрами та стабільною поведінкою TLS.
• Greylisting навчив MTА правильно повторювати спроби. Нерозбірлива поведінка повторних спроб досі видає інфраструктуру низької якості і може нашкодити доставлянню.

Моделі доставки і де кожна з них ламається

Модель A: App → local MTA → direct to recipient MX

Класика. Ваш додаток говорить SMTP до localhost, Postfix ставить в чергу, Postfix робить DNS-запити для MX і потім доставляє назовні. Точки відмов: DNS, вихідні з’єднання, репутація, rDNS, TLS-узгодження та обмеження швидкості на боці отримувача.

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

Модель B: App → local MTA → автентифікований smarthost ретранслятор

Додаток усе ще говорить SMTP локально, але Postfix ретранслює все провайдеру з AUTH і TLS. Точки відмов переміщуються з «чи можемо ми дістатися до кожного MX у світі?» до «чи можемо ми автентифікуватися, відповідати лімітам провайдера і вирівняти ідентичність?»

Підступна відмова: пошта прийнята ретранслятором, але ніколи не доходить. Тут треба розуміти, що «accepted» не означає «delivered». Це означає «поставлено в чергу десь ще». Потрібні ID повідомлень і спосіб корелювати події.

Модель C: App → provider API (HTTP) → provider delivers

Не основна тема статті, але важлива, бо команди часто переходять на неї. Надсилання через API прибирає локальний MTA, але збільшує прив’язку до вендора. Це може бути відмінно. І також може неочікувано зламатися, коли ваш додаток розгорне новий шаблон, який тригерить фільтри контенту.

Гібридна реальність

Більшість компаній мають гібрид:

• Транзакційна пошта через автентифікований ретранслятор (скидання пароля, чеки).
• Внутрішні оповіщення через пряму відправку до корпоративних MX (або внутрішнього ретранслятора).
• Маркетингова пошта через виділений ESP-пайплайн.

Такий поділ корисний. Це також означає, що ви повинні явно вказати, яким шляхом йде кожне повідомлення. Інакше випадково спрямуватимете скидання паролів через маркетинговий пул IP і дізнаєтеся нові значення слова «інцидент».

Ідентичність: SPF, DKIM, DMARC, вирівнювання і чому «pass» може все одно не допомогти

SPF: авторизація для envelope sender

SPF перевіряє, чи IP-відправник уповноважений відправляти від імені домену в RFC5321.MailFrom (envelope-from). Оцінюється через TXT-записи в DNS.

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

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

DKIM: підпис для заголовків/тіла повідомлення

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

Типова операційна підстава: проміжна система модифікує повідомлення (додає футер, змінює обгортку рядків, конвертує MIME), ламаючи DKIM-підпис. Отримувач бачить «DKIM fail», і історія вирівнювання DMARC стає неприємною.

DMARC: вирівнювання та політика

DMARC питає: чи домен у видимому заголовку From вирівнюється з SPF або DKIM (або обома), і що робити, якщо ні? Політика виражається як none/quarantine/reject.

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

Автентифікований ретранслятор змінює, хто «володіє» відправним IP

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

Цитата для липкої нотатки

«Надія — не стратегія.» — General Gordon R. Sullivan

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

Реальність інфраструктури: репутація IP, rDNS, TLS, черги, обмеження швидкості

Репутація IP — це не моральна оцінка, а статистична модель

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

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

Reverse DNS (PTR) — базова гігієна

Багато отримувачів очікують, що IP має PTR-запис, який співпадає з прямим DNS-записом (A/AAAA) і виглядає розсудливо. Не потрібно бути поетичним — важлива консистентність і контроль.

TLS: вам не потрібна досконалість, потрібна послідовність

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

Черги і повторні спроби — частина доставки

MTA, який правильно повторює спроби й інтелектуально робить backoff, виглядає як легітимна інфраструктура. MTA, який агресивно повторює, виглядає як ботнет. Одному — доставляють, іншому — блокують.

Обмеження швидкості — це не особисто

Великі провайдери обмежують швидкість нових або низько-репутаційних відправників. Ваше завдання — не «боротися» з лимітами; а проектувати під них:

• Чергуйте й повторюйте делікатно.
• Надсилайте критичні листи першими (скидання пароля, оповіщення про вхід).
• Розігрівайте IP і домени замість «зливу» обсягу відразу.

Короткий жарт #1: Доставляння пошти схоже на знайомства — якщо з’явилися несподівано з підозрілого адреса, не дивуйтеся, коли вас ігнорують.

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

Міні-історія 1: Інцидент, спричинений хибним припущенням

Команда запустила невеликий флот application-серверів і вирішила «спростити»: Postfix на кожному вузлі, пряма відправка в Інтернет, однакова конфігурація всюди. Вони використовували стандартні вихідні IP хмарного провайдера. Ніхто не володів rDNS. Ніхто не відповідав за репутацію. Але листи зі staging приходили, і перший тиждень production-пошти теж, тож здавалося, що все гаразд.

Потім незалежна подія зі скейлінгом замінила частину вузлів. Заміни мали різні IP. Ночі сталися так: листи для скидання паролів почали відскакувати у великих поштових провайдерів з неясними 4xx деферами та іноді 5xx відмовами. Підтримка побачила сплеск: користувачі не могли увійти, не могли скинути пароль і звинувачували «додаток». Додаток був невинний. Шлях пошти — ні.

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

Виправлення було операційним, не героїчним. Вони перейшли на автентифікований ретранслятор зі стабільними відправними IP, додали SPF-авторизацію для ретранслятора, увімкнули DKIM-підписання, вирівняне з From-доменом, і припинили вдавати, що хмарний autoscaling сумісний з DIY-доставлянням за замовчуванням. Пряма відправка могла б спрацювати, але потребувала б виділених egress-IP, контролю rDNS, розігріву, моніторингу і відповідальної людини. Їх цього не було, тому обирати таку модель не варто було.

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

Інша компанія використовувала автентифікований ретранслятор, але хотіла зменшити латентність у пайплайні нотифікацій. Хтось помітив, що кожен app-сервер часто встановлював нові TLS-сесії до ретранслятора. Тож «оптимізували»: збільшили повторне використання з’єднань, підняли concurrency і пакували більше листів на з’єднання.

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

Повернення стало класичним: оптимізація мікролатентності без розуміння макроконтракту системи. SMTP submission — це не low-latency RPC. Це store-and-forward пайплайн з політикою та контролем репутації. Перетюнінг поведінки з’єднань змінив підпис відправника і тригернув запобіжні механізми.

Відновлення включало зниження concurrency до рекомендованих провайдером значень, додавання коректної семантики повторних спроб (не повторювати, якщо ви вже отримали 250 + queue ID), і впровадження ідемпотентності на рівні додатка, щоб те саме подія не породжувало кілька листів під час тимчасового тротлінгу.

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

Фінансова організація надсилала рахунки і повідомлення акаунтів. Вони використовували автентифікований ретранслятор для вихідної пошти, але також тримали невеликий внутрішній Postfix як шлюз submission для застосунків. Шлюз робив одну нудну річ надзвичайно добре: ставив у кожен лист correlation header і логував відповідність між request ID додатка, SMTP queue ID і provider message ID.

Одного вівторка великий поштовий провайдер почав дефертити пошту з shared pool їхнього ретранслятора через локалізовану проблему репутації, що зачепила багатьох клієнтів. Це не була вина організації, і вони не могли це виправити. Але вони могли це пояснити. За кілька хвилин on-call витягнув список затронутих message ID, добув SMTP-коди відповіді і підготував статус для клієнтів з деталізацією: «Повідомлення, надіслані між часом A і часом B, затримуються через 4xx дефери; втрат даних немає; повторні спроби в процесі.»

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

Короткий жарт #2: Нічого не будує довіру так, як добре промаркована черга — без неї ви просто кричите в SMTP-пустку.

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

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

Завдання 1: Підтвердити, яким шляхом ви йдете (прямо чи через ретранслятор)

cr0x@server:~$ postconf -n | egrep '^(relayhost|smtp_sasl_auth_enable|myhostname|myorigin|mydestination)'
relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
myhostname = app-01.prod.example.net
myorigin = /etc/mailname
mydestination = localhost

Значення: relayhost вказано на submission endpoint на 587 і SASL автентифікація увімкнена. Ви ретранслюєте, а не доставляєте прямо.

Рішення: Трушіть throttling/auth/TLS на стороні провайдера і вирівнювання ідентичності, а не вихідний порт 25 до довільних MX.

Завдання 2: Якщо пряма відправка — підтвердити, що порт 25 не заблокований

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

Значення: Мережа дозволяє вихідний TCP/25 принаймні до одного великого MX.

Рішення: Якщо доставка усе ще провалюється, переходьте до репутації/TLS/rDNS/контенту, а не базової підключності.

Завдання 3: Тест submission до ретранслятора з STARTTLS і AUTH

cr0x@server:~$ openssl s_client -starttls smtp -connect smtp.relay.example:587 -servername smtp.relay.example -crlf
...
250-smtp.relay.example
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN
250 HELP

Значення: Ретранслятор підтримує STARTTLS і методи AUTH. Добрий базис.

Рішення: Якщо Postfix не може автентифікуватися, ймовірно, проблема з обліковими даними/SASL, а не з недоступністю ретранслятора.

Завдання 4: Перевірити DNS для SPF на From-домені

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.relay.example -all"
"google-site-verification=..."

Значення: SPF авторизує ретранслятора через include і використовує -all (жорсткий фейл для неавторизованих IP).

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

Завдання 5: Перевірити наявність DKIM публічного ключа

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

Значення: DKIM-селектор s1 опублікований.

Рішення: Якщо отримувачі показують DKIM=fail, перевірте, чи підписувач використовує той самий селектор і домен, і чи проміжне ПЗ не змінює повідомлення.

Завдання 6: Інспектувати DMARC-політику та режим вирівнювання

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=r; pct=100"

Значення: DMARC встановлено в quarantine. DKIM-вирівнювання — strict (adkim=s), SPF-вирівнювання — relaxed (aspf=r).

Рішення: Строге DKIM-вирівнювання означає, що DKIM d= має точно співпадати з From-доменом. Якщо ваш ретранслятор підписує з іншим d=, ви впадете по DMARC.

Завдання 7: Перевірити reverse DNS (PTR) вашого відправного IP (шлях прямої відправки)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout-01.example.net.

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

Рішення: Підтвердьте прямий DNS цього hostname, що повертає той самий IP; якщо ні — виправте невідповідність або очікуйте штрафів на доставлянні.

Завдання 8: Перевірити, що forward DNS збігається з PTR (базова санітарка)

cr0x@server:~$ dig +short mailout-01.example.net A
203.0.113.10

Значення: Forward-confirmed reverse DNS (FCrDNS) пройшов.

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

Завдання 9: Перевірити, чи вказаний ваш IP у загальних DNS-блоклистах (сигнал, не євангеліє)

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

Значення: Жоден A-запис не повернувся, тож станом на запит IP не в списках цих трьох.

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

Завдання 10: Переглянути глибину черги Postfix (застрягло локально?)

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     1823 Mon Jan  4 09:12:10  alerts@example.com
                                         user@gmail.com
                                         (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Значення: Пошта поставлена в локальну чергу через таймаути з’єднань до MX отримувача.

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

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

cr0x@server:~$ grep -R "A1B2C3D4E5" /var/log/mail.log | tail -n 5
Jan  4 09:12:10 app-01 postfix/qmgr[1187]: A1B2C3D4E5: from=<alerts@example.com>, size=1823, nrcpt=1 (queue active)
Jan  4 09:12:12 app-01 postfix/smtp[2214]: A1B2C3D4E5: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.1/0/2/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Значення: DSN 4.4.1 вказує на тимчасовий мережевий збій; Postfix повторюватиме спроби.

Рішення: Якщо DSN 5.x.x (постійний), припиніть повтори і виправляйте identity/content/reputation. Якщо 4.x.x — виправте підключення або зачекайте, залежно від тексту повідомлення.

Завдання 12: Підтвердити, що Postfix використовує ретранслятор і не «тече» пряма відправка

cr0x@server:~$ grep -E "relay=" /var/log/mail.log | tail -n 3
Jan  4 10:02:41 app-01 postfix/smtp[4021]: 9F8E7D6C5B: to=<user@outlook.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=1.2, dsn=2.0.0, status=sent (250 2.0.0 queued as 7c9f1a2b-1234-5678-9012-acdeffedcba0)
Jan  4 10:02:42 app-01 postfix/smtp[4021]: 1A2B3C4D5E: to=<user@gmail.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=0.9, dsn=2.0.0, status=sent (250 2.0.0 queued as 0d1e2f3a-aaaa-bbbb-cccc-112233445566)

Значення: Повідомлення йдуть через relayhost на 587 і ставляться в чергу провайдером (у вас є provider queue IDs).

Рішення: Якщо деякі рядки показують relay=recipient-mx:25, у вас змішаний шлях. Виправте transport maps або relay restrictions, перш ніж дебажити доставляння — ви не зможете одночасно дебажити дві системи.

Завдання 13: Перевірити TLS-полісію і чи ви падаєте під TLS-узгодження

cr0x@server:~$ postconf -n | egrep '^(smtp_tls_security_level|smtp_tls_CAfile|smtp_tls_loglevel|smtp_tls_policy_maps)'
smtp_tls_security_level = may
smtp_tls_loglevel = 1

Значення: Опортуністичний TLS увімкнений (may). Рівень логування низький, але присутній.

Рішення: Якщо бачите TLS-помилки в логах — тимчасово підвищте smtp_tls_loglevel для дебагу. Якщо вимагаєте TLS (encrypt), встановіть security_level=encrypt лише якщо знаєте, що отримувачі це підтримують або маєте policy maps.

Завдання 14: Доведіть, як повідомлення виглядало «на дроті» (заголовки)

cr0x@server:~$ sed -n '1,60p' /var/spool/postfix/deferred/A/A1B2C3D4E5
From: "Example Alerts" <alerts@example.com>
To: user@gmail.com
Subject: Your login code
Date: Mon, 04 Jan 2026 09:12:09 +0000
Message-ID: <20260104091209.12345@app-01.prod.example.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Значення: Показує збережені заголовки повідомлення (не кінцеві заголовки отримувача). Корисно для перевірки From-домену, Message-ID домену і типу контенту.

Рішення: Якщо DMARC-вирівнювання суворе і ви бачите From: один домен, але DKIM підписує інший (або Message-ID домен плутає отримувачів), уніфікуйте домени в заголовках.

Завдання 15: Підтвердити, що додаток не обходить MTA і не використовує випадкові SMTP-бібліотеки напряму

cr0x@server:~$ ss -tpn | egrep ':25 |:587 ' | head
ESTAB 0 0 10.0.1.10:49822 198.51.100.20:587 users:(("master",pid=1123,fd=24))
ESTAB 0 0 10.0.1.10:50112 142.250.102.27:25 users:(("python3",pid=9981,fd=8))

Значення: Postfix використовує ретранслятор на 587, але python-процес підключається напряму до MX отримувача на 25.

Рішення: Вирахуйте цей процес. Встановіть єдиний egress-шлях. «Частково прямо, частково через ретранслятор» — це шлях до того, що половина репутації вашого домену приклеїться до хаосу.

Завдання 16: Перевірити системний час (DKIM та TLS можуть погано поводитися при зсуві годин)

cr0x@server:~$ timedatectl
               Local time: Mon 2026-01-04 10:15:22 UTC
           Universal time: Mon 2026-01-04 10:15:22 UTC
                 RTC time: Mon 2026-01-04 10:15:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований; добре.

Рішення: Якщо не синхронізований — виправте NTP. Деякі отримувачі поблажливі; інші трактують зсув часу як підозрілий для підписів і TLS-сесій.

Швидкий план діагностики

Це послідовність «зупиніться з дерганням». Виконайте її в порядку. Ви намагаєтесь знайти вузьке місце: додаток, локальний MTA, провайдер ретранслятора, отримувач чи DNS/автентифікація.

Перше: визначте, де закінчується «sent»

1. Додаток передає пошту комусь? Шукайте логи додатка з message ID або SMTP-кодами відповіді. Якщо додаток ніколи не передавав — це баг у додатку, а не проблеми доставляння.
2. Чи зростає черга Postfix? mailq. Якщо локальна черга росте — ваша система не може передати (мережа, auth, DNS, outage ретранслятора).
3. Чи є в логах 250 queued на ретрансляторі? Якщо так — проблема перемістилася вниз по ланцюжку. Припиніть звинувачувати Postfix.

Друге: перевірте ідентичність і вирівнювання, не лише «pass»

1. SPF існує і авторизує систему відправлення (ваш IP або ретранслятор).
2. DKIM присутній і перевіряється; селектор опублікований у DNS.
3. Політика DMARC не відкидає вас; вирівнювання збігається з From-доменом.

Третє: перевірте репутацію та базові сигнали довіри

1. Якщо прямо: PTR існує і співпадає з A-записом (FCrDNS).
2. Якщо прямо: перевірте blocklist-сигнали і чи IP новий/ротаційний.
3. Якщо ретранслятор: перевірте статус провайдера, ліміти і чи не перевищені квоти.

Четверте: верифікуйте зворотний зв’язок від отримувача (bounce’и, дефери, розміщення в спамі)

1. Парсуйте SMTP-коди відповіді з логів або подій провайдера.
2. Шукайте шаблони за доменом отримувача (gmail vs outlook vs yahoo).
3. Визначте, це відмова (5xx), деферт (4xx) чи потрапляння в спам (accepted, але не в inbox).

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

1) «Працює в staging, падає у production»

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

Корінна причина: Production відправляє з інших IP (autoscaling, NAT, різні egress-шляхи) з холодною/поганою репутацією і відсутнім PTR.

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

2) «SMTP каже 250 OK, але користувачі не бачать листи»

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

Корінна причина: Прийнято в чергу провайдера; потім відкинуто/тротлиться; або доставлено в спам/карантин через контент/DMARC-невідповідність.

Виправлення: Корелюйте provider queue IDs, перегляньте події провайдера і підтвердіть SPF/DKIM/DMARC вирівнювання. Впровадьте обробку bounce’ів і моніторинг скарг.

3) «Раптовий сплеск bounce’ів після деплою»

Симптом: Відмови з’явилися відразу після зміни шаблону.

Корінна причина: Тригери фільтрів контенту (патерни URL, зломаний MIME, відсутній List-Unsubscribe для масових розсилок, дивна енкодінг). Або DKIM ламається, бо middleware змінює тіло.

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

4) «Деякі отримувачі отримують, інші — ні»

Симптом: Gmail нормально, Outlook блокує (або навпаки).

Корінна причина: Провайдер-специфічні системи оцінювання; TLS/cipher mismatch; неконсистентні SPF include; проблеми з IPv6-путем.

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

5) «DMARC-звіти показують невдачі, але ми ж налаштували SPF і DKIM»

Симптом: Агреговані звіти показують високий відсоток DMARC-fail.

Корінна причина: Несумісність вирівнювання: From-домен відрізняється від DKIM d= або SPF MailFrom домену. Або треті сторони надсилають від вашого імені без авторизації.

Виправлення: Вирівняйте From з доменом DKIM-підпису; використайте виділений субдомен для сторонніх відправників; оновіть SPF include; підвищуйте DMARC-політику лише після впевненості в легітимних відправниках.

6) «Додали більше серверів для швидшої відправки і доставка погіршилася»

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

Корінна причина: Сплески обсягу і зміни concurrency змінили «відбиток» відправника; репутація по IP розмилася; рівень скарг зріс через швидкість і відсутність обмежень.

Виправлення: Централізуйте відправку через автентифікований ретранслятор або контрольований direct-send tier; застосуйте ліміти; розігрівайте IP; пріоритезуйте повідомлення.

7) «Високі bounce’и, а підтримка каже, що адреси валідні»

Симптом: Сплески 550 user unknown.

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

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

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

Чеклист A: Якщо ви обираєте автентифікований ретранслятор (рекомендовано для більшості команд)

1. Виберіть відправну ідентичність: Визначте From-домен і чи будете використовувати субдомен (наприклад, mail.example.com) для операційного розділення.
2. Опублікуйте SPF: Авторизуйте провайдера ретрансляції (include або явні IP-диапазони). Тримайте під 10 DNS-запитів.
3. Увімкніть DKIM з вашим доменом: Бажано підписувати як ваш From-домен або вирівняний субдомен. Періодично ротируйте ключі.
4. Опублікуйте DMARC: Почніть з p=none для збору звітів, потім переходьте до quarantine/reject, коли усунете неавторизовані відправлення.
5. Налаштуйте Postfix submission до ретранслятора: 587 з STARTTLS і SASL auth. Використовуйте стабільні креденшіали і управління секретами.
6. Визначте чіткі межі повторних спроб: Якщо ретранслятор повернув 250 queued, не повторюйте на рівні додатка.
7. Впровадьте обробку bounce’ів: Парсьте DSN і події провайдера; автоматично приглушуйте постійні bounce’и.
8. Моніторте сигнали доставляння: Рівні дефертів, скарги на спам, домен-специфічні відмови.

Чеклист B: Якщо ви обираєте пряму відправку (ви тепер оперуєте поштовою системою)

1. Стабільні egress-IP: Без ротації IP. Без автоскейлінгу, що ламає очікування. Виділені IP за можливості.
2. Контроль rDNS/PTR: PTR існує, forward співпадає, hostname адекватний.
3. SPF авторизує ваші IP: Тримайте запис жорстким; не ховайтеся за «~all» назавжди.
4. DKIM-підписання для всього вихідного трафіку: Переконайтесь, що проміжні системи не ламають підписи.
5. Політика DMARC: Вирівняйте From з SPF/DKIM і поступово рухайтеся до впровадження.
6. Тюнінг черг і ліміти: Обмеження concurrency по доменах, розумний backoff, уникнення сплесків.
7. Обробка зловживань: Скарги, відписки, suppression list і реальна людська процедура.
8. Моніторинг: Глибина черги, деферти по доменах, коди bounce’ів, перевірка блоклистів, TLS-помилки.
9. План розігріву: Поступово збільшуйте обсяг; починайте з активних одержувачів і критичних транзакцій.

Покроково: міграція з прямої відправки на автентифікований ретранслятор без хаосу

1. Інвентаризація відправників: Знайдіть усі системи, що надсилають пошту (додатки, cron jobs, принтери, старі сервери). Так, принтери теж.
2. Централізуйте submission: Змушуйте всі відправники субмітити на локальний MTA або шлюз ретранслятора.
3. Налаштуйте relayhost: Оновіть Postfix relayhost і SASL-налаштування; тестуйте на одному малоризиковому потоці пошти.
4. Оновіть SPF/DKIM: Авторизуйте ретранслятор і забезпечте вирівнювання DKIM з видимим From.
5. Увімкніть звітування DMARC: Спостерігайте, хто ще надсилає прямо або підроблює ваш домен.
6. Переключайте по класам повідомлень: Спочатку скидання паролів, потім нотифікації, потім масові. Не перемикайте все одразу, якщо вам не подобається адреналін.
7. Приберіть прямий egress: Заблокуйте вихідний 25 з мереж додатків, щоб запобігти обходам.
8. Трасування message ID наскрізь: Корелюйте app request ID → локальний queue ID → provider queue ID.

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

1) Якщо я використовую автентифікований ретранслятор, чи потрібні мені SPF/DKIM/DMARC?

Так. Ретранслятор вирішує транспорт і репутацію інфраструктури, а не ідентичність. Отримувачі все одно оцінюють автентикацію вашого домену та вирівнювання. Без цього ви потрапите в спам або отримаєте відмови в жорстких DMARC-екосистемах.

2) Чи пряма відправка завжди гірша для доставляння?

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

3) Чому мої повідомлення приймають (250), але вони ніколи не з’являються?

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

4) Чи відправляти транзакційну та маркетингову пошту з того самого домену/IP?

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

5) Чи IPv6 допомагає чи шкодить?

Може допомогти, якщо налаштовано правильно (стабільний IPv6, коректний rDNS, SPF include і послідовні відправлення). Може нашкодити, якщо ви випадково почали відправляти з невірного або непідігрітого IPv6-адресу. Якщо сумніваєтесь — відключіть IPv6 для SMTP, поки не перевірите.

6) Чи можна пропустити rDNS, якщо я використовую ретранслятор?

Зазвичай так, бо отримувач бачить IP ретранслятора і його rDNS, а не ваш. Але локальному оточенню все одно потрібен пристойний DNS для свого hostname і TLS; не працюйте з поламаним DNS і не очікуйте стабільності.

7) З якої DMARC-політики почати?

Почніть з p=none, щоб збирати звіти і виявити, хто надсилає від вашого домену. Перейдіть на quarantine, а потім на reject, коли ви вирішите легітимних відправників і усунете неавторизованих.

8) Яка найпростіша конфігурація «не бути заблокованим» для невеликого production-додатка?

Автентифікований ретранслятор на 587 з TLS і AUTH, SPF, що авторизує ретранслятор, DKIM-підписування вирівняне з From-доменом і DMARC-запис. Додайте suppression для bounce’ів. Тримайте From-домен стабільним і не змінюйте його щотижня.

9) Як зрозуміти, чи мене тротлять або блокують?

Дивіться SMTP-коди відповіді. Деферти зазвичай 4xx з текстом про тротлінг або тимчасове лімітування. Блокування часто 5xx з підказками про політику або репутацію. У будь-якому разі — логгування і тренди по домену отримувача.

10) Чи корисно запускати Postfix локально, якщо я використовую ретранслятор?

Так. Локальний MTA дає буферизацію, повтори і чистий інтерфейс submission для додатків. Також — ваші логи. Просто тримайте його простим: ретранслюйте все; не дозволяйте додаткам «йти в обхід».

Висновок: що робити далі у виробничих термінах

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

Наступні кроки, що дають швидкий ефект:

1. Виберіть один egress-шлях для кожного класу пошти (транзакційна, масова, внутрішня) і дотримуйтесь його.
2. Зробіть ідентичність когерентною: SPF авторизує відправника, DKIM підписує як From-домен (або вирівняний субдомен), DMARC-політика відповідає вашому ризику.
3. Додайте трасування: корелюйте message ID через app → MTA → провайдера, щоб «де мій лист?» став питанням, а не сеансом ворожби.
4. Моніторьте правильні метрики: деферти, відмови за доменом, глибина черги і коди bounce’ів. Не «відправлено листів».
5. Перестаньте оптимізувати невірний шар: не боріться зі SMTP через application retries. Поважайте чергу.

Можете ускладнювати пізніше. Спочатку — доставити.