Довідник помилок / 421 4.7.0 Try again later, closing connection

421 4.7.0 Try again later, closing connection

421 4.7.0 Try again later, closing connection - це тимчасова відмова, найчастіше від серверів Gmail і Google Workspace, зазвичай із командою SMTP, на якій вона сталася, наприклад (EHLO) або (MAIL). Сервер-одержувач завершує розмову, не прийнявши листа, і просить відправника повернутися пізніше. Оскільки це код 4xx, поки нічого не втрачено: правильно налаштований поштовий сервер тримає лист у черзі й повторює спроби протягом наступних годин і днів. Користувачі зазвичай помічають лише затримку або попередження, що доставка ще не вдалася. Справжньою проблемою це стає, коли той самий сервер щоразу отримує ту саму відповідь.

Перевірте свій сайт

>

Через що виникає

У власному списку помилок Google наводить цей текст без однієї причини, бо 4.7.0 - збірний код для тимчасових відмов за політикою, але тригери добре відомі. Імʼя EHLO: сервер, що представляється як localhost, голою IP або імʼям, яке не резолвиться, схожий на неправильно налаштовану чи заражену машину. Зворотний DNS: Google окремо описує 421 4.7.0 для IP-відправника без PTR-запису або з PTR-імʼям, яке не резолвиться назад на ту саму IP. Репутація й швидкість: нова IP, спільна IP з поганими сусідами чи раптовий сплеск зʼєднань потрапляють під обмеження. Автентифікація: Gmail вимагає, щоб кожен відправник проходив SPF або DKIM, а масові відправники мали SPF, DKIM і DMARC, і неавтентифіковану пошту обмежують спорідненими кодами 4.7.x.

Як виправити

  1. Прочитайте повний текст помилки чи рядок журналу. Команда в дужках підказує етап: (EHLO) вказує на ідентичність і репутацію сервера, (MAIL) чи (RCPT) частіше на адресу відправника й автентифікацію. Якщо далі в тексті є «does not have a PTR record» або «very low reputation», Google уже назвав причину.
  2. Запустіть перевірку на цій сторінці для домену з вашої адреси From. Вона показує SPF разом із кількістю запитів, DKIM і DMARC. Gmail вимагає, щоб кожен відправник проходив SPF або DKIM, а масові відправники (близько 5000 листів на день на акаунти Gmail) мали SPF, DKIM і запис DMARC з вирівнюванням домену From. Спершу виправте все, що позначено як відсутнє: неавтентифіковану пошту обмежують, хоч якою гарною була б IP.
  3. Перевірте ідентичність сервера-відправника. Його імʼя EHLO має бути справжнім повним імʼям хоста, наприклад mail.ваш-домен.com, а не localhost. Це імʼя має резолвитися в IP сервера, а PTR-запис IP має вказувати назад на те саме імʼя. Перевірка хостингу на цьому сайті показує PTR сервера і чи резолвиться він назад. На VPS чи виділеному сервері PTR налаштовують у панелі провайдера, на спільному хостингу змінити його може лише хостинг.
  4. Подивіться на обсяги. Якщо сервер відкриває багато паралельних зʼєднань до Gmail або розсилка стартує великим сплеском з нової IP, зменште паралельність і розподіліть надсилання в часі. Нові IP треба прогрівати невеликими обсягами, що поступово зростають. Перевірте IP і в публічних чорних списках перевіркою на цьому сайті: якщо вона там є, проблема з репутацією справжня.
  5. Якщо ви надсилаєте через Google (smtp-relay.gmail.com або smtp.gmail.com), переконайтеся, що клієнт використовує TLS на порту 587 або 465 і автентифікується так, як вимагають налаштування SMTP-ретранслятора в консолі адміністратора Google, а якщо ретрансляція йде за IP, що цю IP там дозволено. Частий випадок - застосунки в Docker-контейнері, що представляються як EHLO localhost: задайте імʼя хоста, яке оголошує застосунок.
  6. Далі дайте черзі зробити свою роботу. Не надсилайте листи повторно вручну й не проганяйте чергу по колу: це лише додає зʼєднань і посилює обмеження. Якщо через добу з нормальною автентифікацією, правильним PTR і звичайними обсягами листи все ще не проходять, перевірте домен та IP в Google Postmaster Tools: там видно репутацію, яку насправді присвоює Gmail, щойно ви надсилаєте достатньо пошти, щоб зʼявилися дані.

Схожі помилки