Port 25 заблоковано: як усе одно відправляти пошту (без сумнівних хаків)

Ви створюєте нову VM. Розгортаєте додаток. Тригерите лист на скидання пароля. Нічого не приходить.
У логах видно повторні спроби, таймаути і невеселу правду: вихідні TCP/25 заблоковано.

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

Що таке порт 25 (і чому його блокують)

Порт 25 — класичний порт SMTP, який переважно використовується для сервер‑до‑сервера доставки листів:
ваш MTA спілкується з MX‑сервером домену отримувача і передає повідомлення.
Модель «direct‑to‑MX» усе ще існує, але у 2026 році це не найкращий спосіб відправляти пошту з випадкових хостів.

Хмарні провайдери й багато ISP за замовчуванням блокують вихідний 25 з однієї причини: спам.
Нові IP‑діапазони швидко зловживають. Блокування порта 25 зменшує зловживання, захищає репутацію провайдера й тримає їхню адресу поза блоклістами.
Вас не цілеспрямовано підставляють; ви живете в окрузі, де хтось постійно підпалює дивани.

Сучасний підхід: ваш сервер надсилає пошту через автентифікований submission‑endpoint (зазвичай порт 587 з STARTTLS або порт 465 з implicit TLS),
або через API для відправки пошти. Реле‑сервіс тоді вирішує питання доставляння: репутація IP, обмеження швидкості, зворотні сигнали, підписування DKIM тощо.

Цитата, яку варто приклеїти над монітором (парафраз): Gene Kranz: «Будьте жорсткими й компетентними.» Робота над надійністю — це в основному компетентність під тиском.

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

Коли пошта не йде, люди відразу сперечаються про SPF vs DKIM vs «провайдер впав».
Зупиніться. Діагностуйте як SRE: звузьте радіус збитків, потім знайдіть вузьке місце.

Перш за все: підтвердіть, що це саме мережевий блок (а не баг у додатку)

• З хоста, який відправляє пошту, протестуйте TCP‑досяжність до відомого SMTP‑сервера на 25, 587 і 465.
• Перевірте, чи ваш додаток намагається direct‑to‑MX або використовує реле.
• Шукайте «connection timed out» (мережеве блокування) проти «authentication failed» (облікові дані) проти «rejected» (політика/доставляння).

По‑друге: визначте, хто блокує

• Чи провайдер хмари блокує вихідний 25 на рівні гіпервізора?
• Чи ваша VPC/NACL/security group обмежує egress?
• Чи локальний фаєрвол (ufw/iptables/nftables) блокує?

По‑третє: оберіть чисту альтернативу

• Якщо потрібні лише транзакційні листи: використовуйте SMTP submission на 587/465 до надійного реле.
• Якщо потрібний великий обсяг або сильна телеметрія: використовуйте email API (часто все одно за плечима SMTP).
• Якщо це лише внутрішні сповіщення: маршрутуйте до внутрішнього ретранслятора або інструменту співпраці, а не в публічний інтернет.

По‑четверте: перевіряйте доставляння, а не тільки «з’єдналося»

• Переконайтеся, що домен у From автентифікований (SPF/DKIM/DMARC) і вирівняний із відправником.
• Підтвердіть обробку bounce‑ів. Безшумні відмови обходяться найдорожче.

Жарт №1: Порт 25 — як мікрохвильовка в офісі — якщо лишити її без нагляду, хтось поставить рибу і зіпсує всім життя.

Що робити замість порта 25

Варіант A (рекомендовано для більшості): автентифікований SMTP‑реле на порті 587 (STARTTLS)

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

Використовуйте порт 587 з STARTTLS, якщо провайдер явно не просить порт 465. Порт 587 — це стандартний порт submission,
і він добре працює з сучасними політиками безпеки.

Варіант B: SMTP‑реле на порті 465 (implicit TLS)

Порт 465 широко підтримується і на практиці працює добре. Це «SMTPS», де TLS встановлюється відразу.
Якщо ваше середовище фільтрує або псуює STARTTLS, 465 може бути простішим варіантом.

Варіант C: поштовий API провайдера (HTTP)

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

Мінус: ви зв’язуєте логіку додатка з API провайдера. Це нормально, якщо ставитися до нього як до зовнішньої залежності:
timeouts, retries з backoff, circuit breakers і черги.

Варіант D: внутрішній ретранслятор + вихідний шлюз

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

Варіант E: просити розблокувати порт 25 (рідко найкращий перший крок)

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

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

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

Завдання 1: Доведіть, що TCP/25 заблоковано (таймаут vs refuse має значення)

cr0x@server:~$ nc -vz -w 3 gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

Значення: Таймаут зазвичай вказує на мережеву політику блокування (провайдер, фаєрвол або фільтрація egress).
«Refused» означав би, що ви дісталися до хоста, але порт закритий (рідко для публічного MX).

Рішення: Не витрачайте час на налаштування Postfix. Перейдіть на реле на 587/465 або виправте політику egress.

Завдання 2: Перевірте, чи працює 587 (ваш аварійний вихід)

cr0x@server:~$ nc -vz -w 3 smtp.relay.example 587
Connection to smtp.relay.example 587 port [tcp/submission] succeeded!

Значення: Мережевий шлях до submission‑порту існує.

Рішення: Налаштуйте ваш MTA/додаток аутентифікуватися на цьому реле через 587 з TLS.

Завдання 3: Перевірте STARTTLS‑переговори (не припускайте шифрування)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect smtp.relay.example:587 -servername smtp.relay.example < /dev/null
CONNECTED(00000003)
---
250-STARTTLS
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Значення: Сервер рекламує STARTTLS і ви провели сучасний TLS‑звʼязок.

Рішення: Якщо STARTTLS відсутній або TLS не вдається — переходьте на порт 465 або вирішуйте проблеми з TLS‑перехопленням/проксі.

Завдання 4: Перевірте, чи додаток намагається direct‑to‑MX (поганий дефолт)

cr0x@server:~$ grep -R "smtp" -n /etc | head
/etc/postfix/main.cf:relayhost =
/etc/postfix/main.cf:inet_interfaces = loopback-only

Значення: Порожній relayhost означає, що Postfix буде намагатися direct‑to‑MX.

Рішення: Встановіть relayhost на ваш автентифікований smart host, якщо ви не керуєте повноцінним вихідним MTA.

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

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F1A12C0A9     1542 Fri Jan  3 10:41:12  alerts@yourdomain.example
(connect to gmail-smtp-in.l.google.com[142.250.0.27]:25: Connection timed out)
                                         user@gmail.com

-- 1 Kbytes in 1 Request.

Значення: Postfix намагається direct‑to‑MX на 25 і отримує таймаути.

Рішення: Зупиніть кровотечу: налаштуйте relayhost і після підтвердження облікових даних очистіть чергу.

Завдання 6: Визначте, хто блокує egress (перевірка локального фаєрволу)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

Значення: Політика ланцюга output — accept; локальний фаєрвол, ймовірно, не блокує.

Рішення: Якщо ви бачите явні drop для tcp dport 25/587/465 — виправте правила або координуйтеся з командою безпеки.

Завдання 7: Перевірте правила egress хмари (security group / NACL‑еквівалент через інструменти інстансу)

cr0x@server:~$ ip route
default via 10.0.0.1 dev eth0
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.12.34

Значення: Ви в приватній мережі; egress імовірно проходить через NAT або фаєрвол‑пристрої.

Рішення: Перевірте, що NAT/політики безпеки дозволяють 587/465. Не припускайте, що «дефолтний маршрут» означає «інтернет працює для SMTP».

Завдання 8: Налаштуйте Postfix relayhost (основний фікс)

cr0x@server:~$ sudo postconf -e 'relayhost = [smtp.relay.example]:587'
cr0x@server:~$ sudo postconf -e 'smtp_tls_security_level = encrypt'
cr0x@server:~$ sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'

Значення: Квадратні дужки змушують Postfix використовувати хост як є (без MX‑lookup). Вказано порт 587. TLS — обовʼязково.

Рішення: Продовжуйте тільки якщо можете аутентифікуватися (наступне завдання). Інакше ви поміняєте таймаути на помилки аутентифікації.

Завдання 9: Увімкніть SASL‑аутентифікацію для реле

cr0x@server:~$ sudo postconf -e 'smtp_sasl_auth_enable = yes'
cr0x@server:~$ sudo postconf -e 'smtp_sasl_security_options = noanonymous'
cr0x@server:~$ sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'

Значення: Postfix буде аутентифікуватися за обліковими даними, збереженими в /etc/postfix/sasl_passwd.

Рішення: Жорстко обмежте дозволи до файлу пароля. Якщо ви не можете захистити його — не зберігайте SMTP‑логіни на цій машині.

Завдання 10: Створіть мапу облікових даних і перевірте її компіляцію

cr0x@server:~$ sudo bash -c 'printf "[smtp.relay.example]:587 username:app-specific-password\n" > /etc/postfix/sasl_passwd'
cr0x@server:~$ sudo chmod 0600 /etc/postfix/sasl_passwd
cr0x@server:~$ sudo postmap /etc/postfix/sasl_passwd
cr0x@server:~$ ls -l /etc/postfix/sasl_passwd*
-rw------- 1 root root  63 Jan  3 10:52 /etc/postfix/sasl_passwd
-rw------- 1 root root 122 Jan  3 10:52 /etc/postfix/sasl_passwd.db

Значення: Файл .db — скомпільована мапа, яку використовує Postfix. Дозволи — суворі.

Рішення: Якщо postmap видає помилку — виправте формат або інструментарій перед перезапуском Postfix.

Завдання 11: Перезавантажте Postfix і слідкуйте за логами під час тестової відправки

cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo tail -f /var/log/mail.log
Jan  3 10:54:11 server postfix/smtp[22119]: 3F1A12C0A9: to=<user@gmail.com>, relay=smtp.relay.example[203.0.113.10]:587, delay=12, delays=0.1/0.02/2.1/9.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as ABC123)

Значення: Пошта тепер релейиться через smart host на 587 і прийнята (DSN 2.0.0).

Рішення: Очистіть чергу, якщо є накопичення; далі моніторьте рівень bounce‑ів і панель провайдера.

Завдання 12: Очистіть чергу (тільки після виправлення кореневої проблеми)

cr0x@server:~$ sudo postfix flush
cr0x@server:~$ mailq | tail -n 3
Mail queue is empty

Значення: Заблоковані повідомлення намагаються негайно; черга порожня.

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

Завдання 13: Переконайтеся, що ви випадково не відкрили open relay (так, люди й досі це роблять)

cr0x@server:~$ sudo postconf mynetworks smtpd_recipient_restrictions | sed -n '1,3p'
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Значення: Довіряється лише localhost; неаутентифікований зовнішній релей відхиляється. Добре.

Рішення: Якщо ви бачите широкий діапазон (наприклад RFC1918) на інтернет‑фейсі — виправте негайно.

Завдання 14: Перевірте DNS для SPF (базово, але обов’язково)

cr0x@server:~$ dig +short TXT yourdomain.example
"v=spf1 include:spf.relay.example -all"

Значення: SPF існує і делегує право на відправку вашому relay‑провайдеру.

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

Завдання 15: Перевірте політику DMARC (захисні рейки вашого домену)

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

Значення: DMARC існує і примушує вирівнювання (у прикладі — strict).

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

Завдання 16: Переконайтеся, що сервер не намагається використовувати IPv6 і не падає (поширено)

cr0x@server:~$ postconf inet_protocols
inet_protocols = all

Значення: Postfix використовує IPv4 і IPv6. Якщо egress по IPv6 зламаний, ви можете бачити переривчасті SMTP‑помилки.

Рішення: Якщо в логах видно таймаути по IPv6 — виправте маршрутизацію/DNS для IPv6 або тимчасово встановіть inet_protocols = ipv4.

Postfix: приклад налаштування через smart host

Якщо ви запускаєте Postfix на сервері (або ваш додаток передає пошту на localhost), конфігурація через smart host — найчистіше рішення.
Мета проста: ваша машина не має спілкуватися з випадковими MX‑серверами в інтернеті. Вона має говорити з одним реле, якому ви довіряєте.

Розумна мінімальна форма main.cf

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

cr0x@server:~$ sudo postconf -n | egrep '^(relayhost|smtp_tls|smtp_sasl|inet_interfaces|myhostname|myorigin)'
myhostname = server.yourdomain.example
myorigin = /etc/mailname
inet_interfaces = loopback-only
relayhost = [smtp.relay.example]:587
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

Декілька думок, бо вам потрібні рішення:

• Встановіть inet_interfaces = loopback-only на ап‑серверах. Ви не надаєте SMTP‑вхідні послуги у світ. Не вдавайте з себе MTA.
• Використовуйте smtp_tls_security_level = encrypt, щоб не опускатися мовчки до відкритого тексту.
• Оберніть relayhost у дужки, щоб Postfix не робив MX‑lookup. Вам потрібен один явний напрямок.
• Зберігайте облікові дані безпечно. Якщо хост ефемерний — використовуйте секретний менеджер і рендерте мапу при старті.

Не витікайте облікові дані в логи або історію shell

Використовуйте app‑specific паролі або API‑ключі з обмеженим доступом. Ротейтьте їх. Ставтеся до SMTP‑логінів як до базових паролів: вкрали — значить зловживання, зловживання — значить блоклісти.

Відправка з додатка: SMTP vs API

Ви можете відправляти пошту з додатка двома основними шляхами:
SMTP (до реле) або HTTP API (до тих самих провайдерів). Жоден варіант не є абсолютним.
Обирайте залежно від режимів відмов і вашої операційної зрілості.

SMTP з додатків: просто, але слід дивитися за таймаутами та пулінгом

SMTP‑бібліотеки дуже відрізняються в обробці STARTTLS, повторного використання зʼєднань і часткових відмов.
Вам потрібне:

• Явний хост/порт (587 або 465), ніколи не логіка «відправити до MX».
• Розумні connect і read timeouts (не нескінченні).
• Повторні спроби з backoff для тимчасових 4xx відповідей.
• Черга (навіть проста локальна), якщо пошта критична.

Email API: краща видимість, менше крайніх випадків протоколу

З API ви зазвичай отримуєте message IDs, структуровані помилки і вебхуки для bounce/complaint.
Легше реалізувати ідемпотентність («не надсилати дублікати листів про скидання пароля») і простіше інструментувати.

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

Основи доставляння, яких не можна ігнорувати

Блокування порта 25 — це проблема транспорту. Але коли ви виправите транспорт, доставляння стане вашою наступною аварією.
Тут команди часто дивуються: повідомлення «прийняте» (accepted by relay), але люди його не бачать.

Використовуйте реальний envelope sender і обробляйте bounce‑и

Налаштуйте bounce‑домен/адресу, яку ви моніторите. Якщо ігнорувати bounce‑и, ви продовжите слати на мертві адреси,
рівень скарг зросте, і провайдер почне тримати вас у вузді.

SPF, DKIM, DMARC: вирівнювання краще за вірування

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

Операційне правило: домен у From має вирівнюватися з SPF і/або DKIM, а DMARC має виражати явну політику.
Якщо ваш реле підписує DKIM за вас — віддайте селекторні записи, які він дає, і перевірте їхню пропагацію.

Ліміти швидкості існують; це не особисто

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

Жарт №2: SMTP‑коди помилок — єдине місце, де сервер ввічливо каже «я цього не зроблю», одночасно вас осуджуючи.

Корпоративні міні‑історії з практики

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

Середня SaaS‑компанія перенесла навантаження з colo до великої хмари. Додаток надсилав листи реєстрації та скидання паролів через локальний екземпляр Postfix.
У colo у них був статичний IP з нормальною репутацією і вихідний 25 був відкритий. У хмарі команда припустила те саме.

Тиждень запуску настав. Додаток працював, база — теж, трафік зріс — і служба підтримки спалахнула.
Користувачі не могли підтвердити акаунти, не могли скинути паролі, і відтік почався за години.
Інженер on‑call побачив ріст черги Postfix і припустив «recipient MX повільний».

Вони масштабували Postfix. Двічі. Черга росла ще швидше, бо кожен новий інстанс теж був заблокований на 25.
Неправильне припущення було не лише «порт 25 відкритий». Воно було «пошта — це логіка додатка, а не інфраструктури».

Рішення було нудним: налаштувати relayhost на надійне автентифіковане реле на 587, опублікувати SPF/DKIM, очистити чергу і додати інтеграційний тест, який перевіряє SMTP‑submission при деплої.
Постмортем рекомендував ще нудніше: трактувати пошту як зовнішню залежність з явними SLO і алертами по глибині черги.

Міні‑історія 2: Оптимізація, що дала збій

Команда підприємства захотіла зменшити латентність транзакційних листів. Хтось запропонував тримати постійне SMTP‑зʼєднання від кожного ап‑пода до реле,
повторно використовуючи його для сотень повідомлень, щоб зекономити TCP і TLS‑ханшейки. На діаграмі виглядало елегантно.

На практиці це створило новий режим відмов: коли реле ротаціївало сертифікати або застосовувало idle‑тайм‑аут, поди продовжували писати у мертві сокети.
Деякі SMTP‑бібліотеки повідомляли про успіх до фінального flush; інші кидали неінформативні виключення; кілька просто зависали.
Латентність покращилася — аж поки ні, а потім доставка стала невизначеною.

Команда також виявила, що їхня «оптимізація» підсилювала сплески ліміту. Коли запускалася пакетна задача, кожен под вивалював повідомлення максимально швидко по теплому зʼєднанню.
Реле відповіло тимчасовими 4xx відмовами, які їхня логіка ретраїв інтерпретувала як «треба спробувати негайно», породивши свого роду самостійний DDoS.

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

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

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

Одного кварталу DR‑тест провалився: реле приймало листи, але повідомлення приходили без DKIM‑підписів.
Команда простежила це до неправильно обмеженого облікового запису реле в DR: він міг відправляти, але підписування не було привʼязане до цього набору облікових даних.

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

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

Поширені помилки

1) Симптом: черга пошти зростає; логи показують таймаути до recipient MX на порті 25

Коренева причина: вихідний 25 заблоковано; Postfix пробує direct‑to‑MX.

Виправлення: Налаштуйте relayhost на автентифікований smart host на 587/465; вимагайте TLS; очистіть чергу після.

2) Симптом: «SASL authentication failed» або «535 Authentication credentials invalid»

Коренева причина: неправильний логін/пароль, неправильний порт або провайдер вимагає app‑specific пароль.

Виправлення: Перевірте формат облікових даних у /etc/postfix/sasl_passwd, прогоніть postmap, підтвердіть, що використовуєте submission‑endpoint провайдера і вимоги TLS.

3) Симптом: повідомлення приймає реле, але потрапляє до спаму (або взагалі не видно)

Коренева причина: відсутній/неправильний SPF або DKIM, невирівняний From‑домен або відправка з домену без репутації.

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

4) Симптом: переривчасті таймаути; логи показують невдалі IPv6‑адреси

Коренева причина: egress/routing по IPv6 зламаний, але система інколи надає перевагу AAAA.

Виправлення: Відновіть IPv6 шлях або тимчасово встановіть inet_protocols = ipv4.

5) Симптом: помилки TLS‑handshake з STARTTLS

Коренева причина: TLS‑проксі‑інспекція, відсутній CA‑bundle або провайдер вимагає SNI/сучасний TLS.

Виправлення: Перевірте за допомогою openssl s_client; оновіть CA; використовуйте порт 465, якщо STARTTLS ламають; перевірте -servername.

6) Симптом: «Relay access denied» або «unauthorized sender»

Коренева причина: провайдер вимагає верифікацію envelope sender або From‑домена, або ви відправляєте з непідтвердженого домену.

Виправлення: Підтвердіть домен у провайдера; вирівняйте From; налаштуйте myorigin/myhostname розумно; уникайте випадкових From‑адрес.

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

Коренева причина: додаток використовує власні SMTP‑налаштування (direct‑to‑MX, неправильний порт) або політики мережі контейнерів блокують egress.

Виправлення: Уніфікуйте: або додаток надсилає на локальний Postfix, або додаток надсилає напряму на реле на 587/465. Не мішайте це непомітно.

8) Симптом: висока латентність, випадкові дублікати

Коренева причина: логіка повторів без ідемпотентності; повторне використання SMTP‑зʼєднань пішло не так; відсутність черги.

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

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

Покроковий план: від «заблоковано» до «надійно відправляє»

1. Підтвердіть блок: протестуйте TCP до 25/587/465 з хоста, що відправляє.
2. Оберіть модель відправки: SMTP submission (587/465) до реле або API через HTTPS.
3. Зупиніть direct‑to‑MX: налаштуйте Postfix relayhost або хост SMTP в додатку.
4. Вимагайте TLS: STARTTLS на 587 або implicit TLS на 465.
5. Увімкніть автентифікацію: SASL‑облікові дані або API‑ключ.
6. Захистіть: loopback‑only для Postfix; дозволи на файли з обліковими даними; мінімальні привілеї для акаунтів.
7. Надішліть тест: слідкуйте за логами щодо status=sent і ID черги провайдера.
8. Виправте DNS‑автентифікацію: SPF, DKIM, DMARC вирівняні з From‑доменом.
9. Реалізуйте обробку bounce/complaint: поштовий ящик або webhook; алерт при сплесках.
10. Операціоналізуйте: моніторинг глибини черги, кодів помилок, дефередів провайдера і латентності доставляння.

Чек‑лист для on‑call: коли листи знову перестають йти

• Чи доступне реле на 587/465 з уражених хостів?
• Чи дійсні облікові дані (змінено/прострочено)?
• Повертає провайдер 4xx дефери (ліміт) або 5xx відхилення (політика)?
• Чи здорова DNS‑резолюція для endpoint‑у реле і записів вашого домену?
• Чи щось змінилося: фаєрвол, egress‑проксі, CA‑bundle, синхронізація часу?

Чек‑лист безпеки: уникнути перетворення пошти на інцидент

• Зберігайте SMTP‑облікові дані в секретному менеджері; рендерте їх під час запуску; регулярно ротейтьте.
• Не дозволяйте вхідний SMTP з інтернету, якщо ви навмисно не запускаєте MTA.
• Використовуйте відокремлені субдомени для різних потоків пошти (транзакційних vs маркетингових) коли можливо.
• Налаштуйте розумні алерти: раптовий сплеск відправленого обсягу може означати скомпрометовані облікові дані.

Цікаві факти та історичний контекст

• SMTP передує комерційному інтернету: стандарт був закладений на початку 1980‑х, коли довіра між хостами вважалася більшою, ніж сьогодні.
• Порт 587 існує не випадково: це порт для submission, призначений для клієнтів, які подають пошту в MSA зазвичай з автентифікацією.
• Порт 465 має дивну історію: його використовували раніше для implicit TLS, потім декретували, а згодом він фактично «повернувся», бо працює і клієнти його підтримують.
• Блокування порта 25 стало нормою з приходом широкосмугового інтернету: коли масово заражалися машини й виросли обсяги спаму, ISP почали блокувати вихідний 25 з резидентських мереж.
• Хмарні провайдери блокують за замовчуванням, щоб захищати репутацію: один зловмисний підмережа може зіпсувати доставляння для тисяч легітимних орендарів.
• SPF виник через операційний біль: він з’явився на початку 2000‑х, щоб зменшити підробку доменів відправника, але він автентифікує лише шлях конверта, а не цілісність повідомлення.
• Ідея DKIM — криптографічна відповідальність: домен підписує листи, щоб отримувачі могли перевірити цілісність, зменшуючи залежність тільки від IP‑репутації.
• DMARC додав політику і звітування: він каже ресіверам, що робити при невдачі автентифікації і дає зворотні звіти агрегатно.
• Пошта досі одна з останніх глобальних федеративних систем: це відкрита система, де будь‑хто може запустити сервер — добре для стійкості, складно через зловживання.

FAQ

1) Чому порт 25 заблоковано на моїй VM?

Зазвичай тому, що ваш провайдер блокує вихідний SMTP за замовчуванням, щоб запобігти спаму і захистити репутацію IP‑діапазону.
Інколи це ваш власний фаєрвол або політика egress, але у хмарі це частіше виконується нагорі.

2) Чи можна просто попросити розблокувати порт 25?

Іноді так. Але вам все одно доведеться займатися доставлянням: прогрів IP, зворотні адреси, моніторинг блоклістів, обробка зловживань.
Якщо потрібні лише транзакційні листи, relay на 587/465 зазвичай кращий бізнес‑вибір.

3) Яка різниця між портом 25 і портом 587?

Порт 25 традиційно для MTA‑до‑MTA доставки. Порт 587 — для автентифікованої подачі листа від клієнтів/додатків до реле (MSA),
зазвичай з STARTTLS і обліковими даними.

4) Краще використовувати 465 чи 587?

За замовчуванням — 587 з STARTTLS. Використовуйте 465, якщо ваше середовище руйнує STARTTLS або провайдер радить 465.
Головне: у будь‑якому разі використовуйте TLS і автентифікацію.

5) Моє реле приймає пошту, але Gmail кладе в спам. Це все ще проблема порта 25?

Ні. Це вже питання доставляння: відсутність або невірне SPF/DKIM/DMARC, новий домен без репутації, контентні проблеми або високий рівень bounce/complaint.
Порт 25 — транспорт; потрапляння в спам — репутація і автентифікація.

6) Чи безпечно зберігати SMTP‑облікові дані на сервері?

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

7) Чи потрібен мені взагалі Postfix? Чи може додаток відправляти напряму в реле?

Можна й так, і так. Postfix корисний як локальний буфер і політична точка (черги, ретраї, стандартизовані логи).
Пряме додаток‑до‑реле підходить для простіших систем — просто реалізуйте розумні ретраї і таймаути.

8) Що робити, якщо вихідний SMTP заблокований на всіх портах?

Використовуйте email API через HTTPS або маршрутуйте пошту через внутрішній шлюз із дозволеним egress.
Також перевірте, чи мережа вимагає явний проксі для виходу в інтернет.

9) Як зрозуміти, що проблема в DNS?

Якщо ви бачите «host not found» помилки, переривчасті збої по різних цілях або ваші запити SPF/DKIM/DMARC не повертають результати,
ймовірно, є проблеми з резолюцією DNS. Тестуйте за допомогою dig, перевіряйте налаштування резолвера і наявність split‑horizon проблем.

10) Чи можу я запускати власний mail‑сервер і не використовувати реле?

Можна, і деякі так роблять, але це обовʼязок по експлуатації. Потрібна стабільна IP‑репутація, коректний зворотний DNS, обробка зловживань,
моніторинг і постійне тонке налаштування. Якщо пошта — не ваш продукт, не робіть з неї хобі.

Висновок: наступні кроки, які не будуть будити вас о 3 ранку

Коли порт 25 заблоковано, правильний крок — не вигадувати хитрощі. Правильний крок — припинити direct‑to‑MX від ап‑серверів.
Використовуйте автентифіковану подачу на 587/465 або email API, і дозвольте реле вирішувати всю брудну частину публічного SMTP.

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

1. Прогоніть тести підключення, щоб підтвердити, де саме блок (25 vs 587/465).
2. Виберіть реле або API і уніфікуйте підхід у всіх середовищах.
3. Налаштуйте Postfix (або ваш додаток) відправляти лише на це реле з TLS + auth.
4. Опублікуйте і перевірте SPF/DKIM/DMARC для From‑домену.
5. Додайте моніторинг: глибина черги, дефери реле, ставки bounce/complaint.

Пошта — це проблема надійності, замаскована під комунікацію. Трактуйте її як інфраструктуру продакшну — і вона буде поводитися відповідно.