Чому електронні листи затримуються: перелік перевірок

Що означає високий відсоток відкладених електронних листів? Перелік перевірок для виявлення причин затримки доставки

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

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

1. Переконайтеся, що «відкладено» означає затримку, а не відхилення

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

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

Окремо фіксуйте в нотатках про інцидент доставлені та відкладені повідомлення. Відкладене повідомлення ще не надійшло на сервер одержувача, навіть якщо зрештою туди потрапить. Загальні рекомендації щодо репутації відправника та вимог поштових провайдерів дивіться в матеріалі Найкращі практики доставлення електронної пошти · YourTrend.

2. Визначте, які саме повідомлення постраждали, перш ніж щось змінювати

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

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

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

3. Перевірте SMTP-відповідь для кожного відкладеного повідомлення

Відповідь сервера одержувача інформативніша за статус «відкладено». Збережіть і код статусу SMTP, і повний текст відповіді, зокрема назву сервера, якщо вона є в журналах. Щоб зрозуміти, як перевірити помилки SMTP, зіставте код і текст відповіді з історією подій конкретного повідомлення. Тимчасова відповідь із групи 4xx зазвичай означає, що сервер наразі не приймає повідомлення, але сама по собі не вказує на причину.

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

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

4. З’ясуйте, чи затримка локальна, чи поширюється на інші напрямки

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

Складіть коротку хронологію недавніх змін. Зафіксуйте час початку затримок, запуск кампаній, імпорт списків, зміни параметрів автентифікації, збої у провайдера та будь-які зміни обсягу надсилання. Якщо команда маркетингу імпортувала новий список у вівторок, це конкретна зачіпка для перевірки; нечітке пояснення на кшталт «проблеми з доставленням» — ні.

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

5. Захистіть термінові повідомлення, поки тривають повторні спроби

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

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

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

6. Передавайте проблему на розгляд, спираючись на факти, а не припущення

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

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

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

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

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

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

До наступного сповіщення збережіть дані про проблемний період, ідентифікатори повідомлень, IP-адреси та повні відповіді SMTP, перш ніж очищати чергу або запускати надсилання повторно. Ці чотири деталі допоможуть не допустити, щоб затримана група повідомлень перетворилася на другу групу дублікатів.