CRM-аналитика
Как настроить one-click unsubscribe и проверить его без ручной отписки из формы
Время чтения: 4 мин
Уровень материала: Для экспертов
Содержание
Внизу письма есть ссылка «Отписаться», но почтовый сервис сообщает, что one-click unsubscribe не настроен. Причина проста: видимая ссылка в теле и техническая отписка из интерфейса почты — два разных механизма.
One-click unsubscribe по RFC 8058 позволяет почтовой системе передать запрос на отписку без входа в аккаунт и заполнения формы. Механизм использует служебные заголовки письма и HTTPS-запрос POST. Его нужно проверять на реальном письме после обработки платформой, а не только в HTML-шаблоне — коде разметки письма.[1]
Что должно быть в доставленном сообщении
Нужны заголовок List-Unsubscribe с HTTPS-адресом обработчика и List-Unsubscribe-Post со значением List-Unsubscribe=One-Click. Обе записи должны входить в область действительной DKIM-подписи. Почтовая система отправляет POST на указанный адрес; обработчик не должен требовать авторизацию, cookies или дополнительное подтверждение и не должен отвечать перенаправлением.[1]
Видимая ссылка в теле письма сохраняется отдельно. Google требует поддержку one-click для маркетинговых и подписных сообщений от отправителей, подпадающих под его требования к массовой отправке на личные Gmail-адреса, а также понятный способ отписки в самом письме.[2]
Не превращайте эту статью в инструкцию «вставьте два заголовка вручную». В большинстве ESP, платформ отправки рассылок, механизм настраивается на уровне отправителя или проекта; важно убедиться, что конкретная кампания пользуется правильной конфигурацией.
Определите, от чего отписывает действие
Технический запрос должен однозначно указывать подписку и контакт. До реализации согласуйте область: конкретный список, рубрика или рекламные email бренда. Получатель не должен столкнуться с неожиданным сохранением тех же сообщений под другим названием.
Не включайте открытый email и дополнительные сведения о клиенте в публичный адрес без необходимости. Используйте непрозрачный проверяемый токен, ограниченный действием отписки. Его получение не должно давать доступ к заказам или всему профилю.
Обычный GET-запрос к адресу может выполнять проверяющая система безопасности. Он не должен сам менять подписку: именно разделение GET и POST помогает не отписывать людей из-за автоматической проверки ссылок.[1]
Проведите техническую проверку без реальных подписчиков
Создайте тестовый контакт с активной рекламной подпиской и отправьте ему обычную кампанию через рабочий маршрут. Сохраните исходник. Инженер проверяет заголовки, подпись и обращается к обработчику так, как это сделал бы почтовый сервис.
| Проверка | Ожидаемое поведение |
|---|---|
| GET по адресу | Подписка не изменяется автоматически |
| Корректный POST | Исполняется предусмотренная отписка |
| Повтор того же POST | Запрет сохраняется, новых побочных действий нет |
| Неверный токен | Чужая подписка не изменяется |
| Нет браузерной сессии | Отписка всё равно выполняется |
| Рассылка после запроса | Рекламное сообщение в соответствующей области блокируется |
Точный HTTP-ответ согласуют с реализацией протокола и платформы. Для CRM-приёмки важно дополнительно подтвердить изменение разрешения и запрет отправки. Красивый ответ 200 от обработчика, который только записал строку в лог, недостаточен.
Условный пример: редирект сломал отписку
В заголовок добавили ссылку, проходящую через маркетинговый трекер. Трекер отвечает перенаправлением на страницу настроек, а та требует вход. Человек может вручную пройти этот путь, но технический механизм не соответствует ожидаемому процессу.
Исправление — отдельный HTTPS-обработчик нужного действия без промежуточного маршрута. Его адрес подставляется в служебный заголовок, а видимая ссылка на центр предпочтений остаётся в теле письма как другой элемент. После изменения повторно проверяют исходник: ESP может переписывать ссылки или подписывать не все необходимые поля.
Свяжите обработчик с общим запретом
После принятого запроса прекращение рассылок должно работать во всех системах, отправляющих сообщения в этой области. Локальная отписка в одной ESP не остановит резервный сервис, если туда уходит независимая выгрузка.
Запрос получает идентификатор события и прослеживается до актуального состояния разрешений. Повтор должен быть идемпотентным: одинаковое действие не создаёт конфликтующих обновлений и не снимает запрет. При временном сбое обработка требует наблюдаемого восстановления, а не молчаливой потери.
Новый импорт профиля не должен отменять уже выполненное решение. Этот случай обязательно включают в проверку отписки во всех каналах, если интерфейс обещает соответствующий объём отказа.
Что передать верстальщику и разработчику
Верстальщику — понятную видимую ссылку и текст её действия. Команде платформы — настройки заголовков, подписи, обработчика и область запрета. Интегратору — передачу решения и отмену ещё не исполненных отправок. Аналитику — журнал успешных и неуспешных исполнений.
В акте приёмки сохраните исходное письмо, результаты запросов и проверку последующей кампании. Появление кнопки в интерфейсе конкретного почтового сервиса может зависеть от его собственных условий; исправная реализация протокола проверяется независимо от наличия этой кнопки на одном экране.
Источники
[1] J. Levine, T. Herkula. Signaling One-Click Functionality for List Email Headers. RFC 8058, январь 2017. Проверено 22.09.2026.
[2] Google. Email sender guidelines. Справка Gmail; требования и рекомендации для отправителей на личные адреса Gmail. Проверено 22.09.2026.