Як не допустити спаму для листів скидання пароля

Переконайтеся, що саме лист для скидання не проходить

Почніть з одного тестового акаунта і одного запиту на скидання. Не здогадуйтеся.

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

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

Ведіть короткий журнал із трьома полями: поштовий сервіс, точний час і папка, куди потрапив лист. Одного рядка на тест достатньо.

Якщо в Gmail усе добре, а Outlook відправляє лист для скидання в спам, у вас уже є зачіпка. Дотримуйтеся фактів, а не відчуттів.

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

Перевірте тему листа для скидання та дані відправника

Тема має звучати так, ніби це справді скидання пароля. Коротко, просто й без вигадливості — саме те, що треба.

Фраза на кшталт «Скинути пароль» зрозуміліша за будь-яку креативність. Це не місце для драматичної терміновості чи заголовка, що нагадує маркетингову розсилку.

Ім’я у полі From має збігатися з назвою продукту, яку впізнають користувачі. Якщо ваш застосунок називається Northstar, а повідомлення одного дня приходить від “Northstar Support Alerts”, а наступного — від “Security Team”, поштові фільтри можуть вважати лист менш надійним.

Використовуйте одну адресу відправника для листів із скиданням пароля й тримайте її видимою. Адреси, що стрибають між no-reply, helpdesk і особистою скринькою, тільки створюють плутанину.

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

Не запихайте в тему одночасно назву акаунта, терміновість і дедлайн. Достатньо однієї причини.

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

Перевірте, чи workflow скидання пароля надсилає листи зі стабільного домену

Подивіться, звідки саме походить лист для скидання пароля. Домен застосунку, піддомен, домен вендора і staging-середовище не повинні змішуватися між собою.

Поширена помилка — надсилати трафік листів для скидання пароля з нового піддомену, поки решта продукту ще використовує старий. Інша — віддати скидання на аутсорс сторонньому сервісу, який використовує інший зворотний шлях, ніж основна транзакційна пошта.

Фільтри помічають зміни. Запит на скидання, який сьогодні приходить із mail.example.com, а завтра з reset.example-mail.net, може виглядати як дві різні системи, що намагаються видавати себе за один продукт.

Якщо ви використовуєте окремі середовища, не надсилайте справжні листи для скидання пароля зі staging помилково. Звучить очевидно. Але таке все одно трапляється.

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

Також перевірте, чи той самий workflow скидання використовує різні API-ключі або SMTP-облікові дані в development і production. Один невірно збережений секрет може пустити весь потік не тим маршрутом.

Перевірте ціль посилання для скидання та формат листа

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

Щоразу використовуйте однаковий шаблон домену. Лист для скидання пароля, який сьогодні веде користувача на один брендований хост, а завтра — на загальний скорочувач посилань, сам просить проблем.

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

Plain text тут також важливий. Додайте його й переконайтеся, що посилання можна прочитати, не копирсаючись у битому HTML.

Будьте уважні до самого URL для скидання. Довгі query string, дивні токени й шляхи, що виглядають випадково, — це нормально з погляду безпеки, але вони все одно мають бути на довіреному хості й без зайвих обхідних маршрутів.

Цей баланс складний. Лист для скидання пароля має виглядати безпечним, але не підозрілим. Обидві речі можуть бути правдою, і це частина того, як зробити так, щоб листи для скидання пароля не потрапляли в спам.

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

Перевірте автентифікацію домену, з якого надсилаються листи для скидання

Перевірте SPF, DKIM і DMARC для точного домену, з якого надсилається лист для скидання пароля. Не маркетингового домену. Не того, що «майже такий самий».

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

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

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

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

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

Протестуйте повідомлення в основних поштових сервісах

Надсилайте контрольні тести на Gmail, Outlook і Yahoo. Трьох сервісів достатньо, щоб побачити закономірності.

Використовуйте однаковий сценарій акаунта, одну й ту саму тему та той самий лінк для скидання в кожному тесті. Потім порівняйте, куди потрапив лист і чи якийсь із сервісів обрізає, переписує або позначає повідомлення.

Gmail може прийняти лист для скидання пароля, а Outlook відправить його в junk. Yahoo може показати його у вхідних один раз, а потім у спамі на наступному тесті. Такий розрив зазвичай вказує на патерн відправника, а не на одну випадкову помилку.

Фіксуйте результати в простій таблиці:

Якщо під час тестування вам потрібен ширший контекст, найкращі практики доставляння листів допоможуть порівняти flow скидання з іншими транзакційними повідомленнями, не перетворюючи це на повну перебудову.

Одна корисна деталь: тестуйте і на нових скриньках, і на тих, що давно використовуються. Новий адрес і старий адрес не завжди отримують однакове ставлення.

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

Налаштуйте простий цикл моніторингу для постійних виправлень

Коли лист для скидання пароля почне поводитися нормально, продовжуйте за ним стежити. Після зміни шаблону, DNS або постачальника проблема зі спамом може повернутися.

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

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

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

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

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

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

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

Для команд, яким потрібен сильніший операційний огляд, найкращі практики обробки bounce допоможуть відокремити тимчасові проблеми доставки від справжньої проблеми на шляху відправлення. Bounce — це шумно; закономірності — ні.

Робіть моніторинг настільки простим, щоб хтось реально перевіряв його в понеділок зранку. Дашборд, який ніхто не відкриває, — це просто декор.

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