Чому лист не доставляється

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

Де може зупинитися доставка

Чому лист не доставляється розкладайте на етапи: recipient domain, MX/DNS, SMTP connection, server response, authentication policy та filtering. Прийняте SMTP-повідомлення не гарантує Inbox, а відсутність миттєвого bounce не доводить довгострокову доступність адреси.

Як читати результат перевірки

Розрізняйте temporary 4xx і permanent 5xx SMTP failures, перевіряйте MX та SPF/DKIM/DMARC там, де це доречно. Для діагностики збережіть SMTP code, timestamp і Message-ID. Disposable mailbox додатково створює ризик втрати account recovery.

Контрольний сценарій

Контрольний сценарій: для недоставленого листа збережіть точний SMTP status і перевірте MX домену одержувача. Якщо SMTP прийняв повідомлення, переходьте до headers, SPF/DKIM/DMARC та filtering; якщо connection або recipient відхилено раніше, content analysis не є першим кроком. Не публікуйте повні headers, якщо вони містять приватні адреси чи identifiers.

Конкретні приклади та значення

Використовуйте ці значення як орієнтири під час читання документації та результатів перевірки: SMTP response; MX; SPF; DKIM; DMARC; reputation; temporary vs permanent failure.

SMTP 4xx responses usually request a later retry, while 5xx responses are permanent for that transaction. After acceptance, SPF/DKIM/DMARC alignment, reputation and mailbox filtering can still affect placement, so distinguish transport failure from spam-folder delivery.

Типові причини та помилки

Поширена помилка — вважати один успішний тест доказом справності всього ланцюжка. Доступна IP-адреса не гарантує роботу DNS, відкритий порт не підтверджує правильний протокол застосунку, а високий результат speedtest не виключає затримку, втрати чи перевантаження Wi-Fi. NAT, CGNAT, firewall, CDN, Anycast і кеші також змінюють картину та мають враховуватися залежно від завдання.

Чого результат не доводить

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

Покрокова діагностика

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