One-click unsubscribe: заголовки и границы применения

Однокликовая отписка, или one-click unsubscribe, — это машинный механизм, с помощью которого почтовый сервис может отправить запрос на исключение адресата из списка рассылки. Получателю не нужно переходить на сайт, авторизовываться, выбирать причину отказа или подтверждать решение на отдельной странице.

Механизм предназначен прежде всего для подписных, маркетинговых и рекламных сообщений. Его не следует автоматически добавлять ко всей исходящей почте: уведомление о скидке можно прекратить по желанию адресата, а одноразовый пароль или чек по уже совершённой покупке отправляются в связи с конкретным действием и обычно относятся к транзакционной переписке.

Техническая основа one-click unsubscribe описана в RFC 8058 и связана с заголовком List-Unsubscribe, определённым ранее в RFC 2369. Для корректной реализации недостаточно разместить в подвале письма кнопку «Отписаться»: почтовый клиент должен получить специальные заголовки и иметь возможность выполнить HTTPS POST без дополнительного взаимодействия с пользователем.

Зачем нужна однокликовая отписка

Обычная ссылка в письме рассчитана на человека. Он открывает сообщение, находит ссылку, переходит по ней и выполняет предусмотренные отправителем действия. One-click unsubscribe предназначен для взаимодействия двух систем: почтового сервиса получателя и инфраструктуры рассылки.

При поддержке механизма почтовый интерфейс может показать собственную команду отписки рядом с именем отправителя или в другом стандартном месте. После выбора этой команды сервис получателя отправляет запрос на указанный отправителем HTTPS-адрес. Сервер рассылки определяет подписчика и список по данным URL, фиксирует отказ и прекращает соответствующие отправления.

Такой подход решает несколько задач:

• получателю не приходится искать мелкую ссылку в длинном письме;
• отписка не зависит от дизайна, скриптов и корректного отображения посадочной страницы;
• почтовый сервис понимает, что запрос можно выполнить автоматически;
• у получателя появляется удобная альтернатива кнопке «Спам»;
• отправитель быстрее исключает незаинтересованные адреса и снижает число жалоб.

One-click unsubscribe не подтверждает законность сбора адресов и не заменяет согласие на рассылку. Это только технический способ прекратить дальнейшие подписные сообщения. Требования к согласию, хранению персональных данных и содержанию рекламы зависят от применимого законодательства и должны рассматриваться отдельно.

Из каких заголовков состоит механизм

Для реализации по RFC 8058 письмо содержит два связанных заголовка:

List-Unsubscribe: <https://unsubscribe.example/u/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

List-Unsubscribe сообщает адрес, по которому обрабатывается отказ. Для one-click в нём должен присутствовать HTTPS URI. List-Unsubscribe-Post указывает, что этот адрес поддерживает автоматическую отписку посредством POST-запроса.

Значение второго заголовка фиксировано:

List-Unsubscribe=One-Click

Его не следует заменять произвольными параметрами, названием списка, адресом подписчика или собственной командой. Информация, необходимая для определения получателя и подписки, передаётся в HTTPS URI, обычно внутри непрозрачного токена.

Роль заголовка List-Unsubscribe

Сам по себе List-Unsubscribe старше механизма one-click. Он может содержать один или несколько способов отказа, например HTTPS URI и адрес с методом mailto:. Если указано несколько вариантов, они перечисляются через запятую в угловых скобках.

List-Unsubscribe: <https://unsubscribe.example/u/opaque-token>,
 <mailto:unsubscribe@example.test?subject=unsubscribe>

Наличие mailto: может быть полезно для совместимости, но отправка письма на служебный адрес не соответствует требованию one-click по RFC 8058. Аналогично обычный URL, который открывает страницу настроек, сам по себе не становится однокликовым механизмом.

Для автоматической операции почтовому сервису нужны и HTTPS URI в List-Unsubscribe, и отдельное объявление List-Unsubscribe-Post. Если второго заголовка нет, получатель не должен предполагать, что POST по указанному адресу безопасно и достаточно выполнить без дополнительных шагов.

Как выглядит запрос

После согласия пользователя почтовый сервис выполняет HTTPS POST на URI из заголовка. В теле запроса передаётся стандартная пара параметров:

POST /u/opaque-token HTTP/1.1
Host: unsubscribe.example
Content-Type: application/x-www-form-urlencoded

List-Unsubscribe=One-Click

На этом взаимодействие должно завершаться. Endpoint не должен требовать входа в аккаунт, CAPTCHA, ввода адреса, выбора причины, повторного нажатия кнопки или подтверждения через ещё одно письмо. Если без этих действий подписка не прекращается, механизм перестаёт быть one-click.

RFC допускает отправку данных как application/x-www-form-urlencoded и предусматривает вариант multipart/form-data. Обработчику разумно корректно принимать оба представления, если используемая почтовая инфраструктура может их отправлять.

Требования к HTTPS endpoint

Адрес из List-Unsubscribe — не обычная публичная страница управления профилем, а интерфейс для автоматического запроса. Его поведение должно соответствовать назначению механизма.

Запрос не должен зависеть от пользовательской сессии

Почтовый сервис не передаёт cookies, данные HTTP-аутентификации или контекст предыдущего посещения сайта. Сервер должен распознать подписчика и список только по защищённым данным в URI. Следовательно, endpoint нельзя строить по схеме «если пользователь уже вошёл в личный кабинет, покажем его подписки».

Открыто помещать email в URL нежелательно. Помимо попадания адреса в журналы и системы мониторинга, предсказуемые параметры упрощают подделку запросов. Обычно в URI включают непрозрачный, трудно подбираемый идентификатор, который связывает конкретного получателя с конкретным списком. Сервер проверяет подлинность и срок действия такого значения, не полагаясь на cookies.

Токен не должен давать доступ к профилю, истории заказов или другим операциям. Его полномочия следует ограничить одной задачей: прекратить определённую категорию рассылки для связанного с ним адреса.

Нельзя отвечать перенаправлением

Endpoint для one-click не должен возвращать HTTPS redirect на другой адрес. Перенаправления POST обрабатываются неодинаково: промежуточный компонент может изменить метод на GET или потерять тело запроса. Поэтому рабочий URI должен принимать операцию непосредственно.

Это не запрещает после ручного перехода по ссылке показывать человеку информационную страницу. Важно разделять сценарии: автоматический POST должен завершать отписку без редиректа и дополнительных действий, а GET может использоваться для понятного интерфейса, если он действительно нужен.

Повторный запрос должен быть безопасным

Отписка должна быть идемпотентной: повторная отправка того же запроса не создаёт ошибку состояния и не возвращает адрес в список. Если подписчик уже исключён, сервер может считать операцию успешно выполненной.

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

Отказ нужно применить к правильному списку

One-click unsubscribe не обязательно означает полный запрет любой почты от домена. URI должен однозначно определять подписку, связанную с конкретным сообщением. Например, отказ от еженедельных акций не обязан выключать уведомления о состоянии заказов или сообщения безопасности.

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

Почему важна DKIM-подпись заголовков

RFC 8058 требует валидной DKIM-подписи сообщения. В область подписи должны входить как List-Unsubscribe, так и List-Unsubscribe-Post. Иначе принимающая сторона не может надёжно связать адрес endpoint с подтверждённым отправителем и может не показывать собственный элемент быстрой отписки.

В поле h= заголовка DKIM-Signature должны быть перечислены оба имени. Упрощённо соответствующая часть может выглядеть так:

h=from:to:subject:date:list-unsubscribe:list-unsubscribe-post;

Это не готовая DKIM-подпись: остальные параметры и криптографическое значение формирует почтовая система. Пример показывает только принцип — оба служебных заголовка должны быть защищены от изменения после подписания.

Порядок обработки имеет практическое значение. Если приложение добавило поля отписки после того, как MTA подписал письмо, они не попадут под DKIM. Если промежуточный сервис переписал заголовки после подписания, проверка также может завершиться неудачно. Поэтому поля следует формировать до создания окончательной DKIM-подписи, а готовое письмо — проверять на стороне реального получателя. Подробнее о проверке аутентификации и заголовков письма читайте в статье о SPF, DKIM, DMARC и анализе SMTP-логов.

One-click и ссылка в теле письма — не одно и то же

Эти способы не конкурируют, а дополняют друг друга. Заголовки обслуживают машинный сценарий, а ссылка в теле — пользовательский. Почтовый сервис может не показать собственную кнопку даже при технически корректных заголовках, поэтому видимая возможность отказаться от рассылки всё равно необходима.

Для маркетинговых и подписных сообщений крупных отправителей Gmail требует одновременно поддерживать one-click unsubscribe и размещать ясно заметную ссылку отписки в теле. Нельзя выполнить это условие только кнопкой в подвале или, наоборот, только служебными заголовками.

Различия удобно сформулировать так:

• служебные заголовки читаются почтовой системой и позволяют ей отправить автоматический POST;
• ссылка в теле видна человеку и открывается как обычная веб-страница;
• страница предпочтений может предложить выбрать темы и частоту, но не заменяет автоматический отказ;
• mailto-отписка остаётся дополнительным способом, но сама по себе не соответствует one-click по RFC 8058.

Ссылка в содержимом не обязана работать строго в один запрос. Она может вести в центр управления подписками, где пользователь отключает отдельные темы, меняет частоту или прекращает все маркетинговые рассылки. Но такой интерфейс не следует подставлять вместо HTTPS endpoint в расчёте на то, что почтовый сервис разберётся с формой самостоятельно.

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

Для каких писем требуется one-click unsubscribe

В политике Gmail обязательное требование относится к маркетинговым и подписным сообщениям крупных отправителей, направляемым на личные аккаунты Gmail. Крупным считается отправитель, который передаёт около 5000 или более сообщений на такие аккаунты за 24 часа. При подсчёте объединяется почта с одного основного домена, включая его поддомены. После присвоения статуса крупного отправителя он не снимается простым уменьшением объёма.

К сообщениям, для которых применим механизм, обычно относятся:

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

Стандарт RFC 8058 описывает технический механизм, но сам по себе не устанавливает универсальное правило, что каждое письмо в интернете обязано его использовать. Обязательность возникает из политики принимающего сервиса, условий платформы рассылок или применимых норм. Поэтому отправителю нужно учитывать не только формат заголовков, но и состав аудитории, объём отправки и назначение сообщений.

Даже если текущий объём ниже порога конкретного почтового провайдера, поддержка механизма может быть полезна для регулярной массовой рассылки. Она упрощает отказ и помогает не доводить получателя до жалобы. Однако добровольная установка заголовков не отменяет необходимости правильно классифицировать поток.

Когда требование не относится к транзакционным сообщениям

Транзакционное письмо отправляется в связи с конкретным запросом пользователя, операцией, договорным или обязательным уведомлением. Его основная задача — не продвигать продукт и не поддерживать регулярную подписку, а передать информацию, без которой нельзя корректно завершить или проконтролировать действие.

К типичным примерам относятся:

• сброс и восстановление пароля;
• одноразовый код подтверждения;
• чек или квитанция по покупке;
• подтверждение бронирования;
• подтверждение отправки формы или заявки;
• уведомление о статусе уже оформленного заказа;
• сообщение безопасности о входе или изменении важных настроек.

Для таких писем one-click unsubscribe по требованиям Gmail к маркетинговым сообщениям не обязателен. Более того, бездумное добавление отписки способно создать неверное ожидание: пользователь решит, что после нажатия перестанет получать одноразовые коды или обязательные сведения о текущем заказе.

Исключение не означает, что любое письмо с меткой «транзакционное» автоматически становится таким. Оценивается реальное содержание и ожидание получателя. Если подтверждение покупки наполовину состоит из рекламной подборки, скидочных баннеров и призывов оформить новый заказ, граница размывается. Gmail отдельно рекомендует не смешивать разные типы контента в одном сообщении.

Пограничные уведомления

Не все уведомления однозначно транзакционные. Например, сообщение о новом комментарии может быть частью отключаемой подписки, а предупреждение о подозрительном входе — необходимым элементом безопасности. Критерий «это уведомление, а не реклама» недостаточен.

Полезно проверить несколько признаков:

1. Письмо вызвано конкретным недавним действием адресата или отправляется регулярно по расписанию?
2. Может ли пользователь разумно отказаться от всей категории, не нарушив работу основной услуги?
3. Содержимое преимущественно информирует о совершённой операции или побуждает к новой покупке?
4. Адресат ожидает письмо независимо от маркетинговых настроек?
5. Категория оформлена как управляемая подписка в личном кабинете?

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

Почему нельзя смешивать рекламу и транзакционные данные

Разделение потоков упрощает и техническую настройку, и ожидания получателей. Маркетинговые письма можно снабжать one-click unsubscribe, видимой ссылкой и идентификатором списка. Транзакционные — отправлять только по событию, не создавая впечатления регулярной рекламной подписки.

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

Особенно рискованна попытка обойти отписку путём объявления рекламного потока «сервисными уведомлениями». Если адресат получает периодические предложения без явной связи с его действиями, название шаблона или технический тип в API не изменят восприятие сообщения. Получатель всё равно может отметить письмо как спам, а высокая доля жалоб влияет на доставляемость остальных сообщений домена.

Как должна обрабатываться отписка

Корректные заголовки бесполезны, если запрос не меняет состояние базы. После успешного POST адрес должен попасть в список подавления или получить признак отказа от соответствующей подписки. Все очереди, сегменты и повторные кампании обязаны учитывать это состояние.

Gmail указывает срок обработки запросов до 48 часов. Это предельное окно, а не рекомендуемая искусственная задержка. Если система способна применить отказ немедленно, лучше сделать это сразу. Отложенная синхронизация создаёт риск, что за двое суток адресат получит ещё несколько писем и отправит жалобу.

В инфраструктуре с несколькими системами важно определить единый источник состояния. Например, запрос принимает сервис рассылки, а аудиторию формирует CRM. Если отписка записалась только в одном компоненте, следующая выгрузка может снова активировать адрес. Список подавления должен иметь приоритет над импортом, сегментацией и автоматическими сценариями.

Следует различать:

• отказ от конкретной тематической рассылки;
• отказ от всех маркетинговых сообщений бренда;
• временную приостановку доставки;
• невозможность доставки из-за постоянной ошибки;
• транзакционные сообщения, которые продолжают отправляться по событиям.

Область действия команды должна быть понятной и стабильной. Если токен относится к еженедельному дайджесту, запрос выключает именно этот список. Дополнительная ссылка в теле может вести в центр предпочтений, где доступен более широкий выбор, включая полный отказ от маркетинга.

Если endpoint, обработчик токенов и список подавления размещаются в собственной инфраструктуре, для изолированной почтовой системы может подойти VPS-сервер. Такой вариант требует самостоятельной настройки защиты, журналирования, резервного копирования и контроля доступности обработчика.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Типичные ошибки реализации

В письме есть только ссылка в подвале

Даже заметная кнопка не создаёт заголовки автоматически. Почтовая система не обязана анализировать HTML, угадывать назначение URL и отправлять по нему POST. Для one-click нужны оба служебных поля.

Добавлен только List-Unsubscribe

Этот заголовок сообщает варианты отказа, но без List-Unsubscribe-Post не объявляет поддержку операции RFC 8058. Наличие HTTPS URI или mailto: отдельно не выполняет требование.

Endpoint открывает страницу подтверждения

Если POST лишь создаёт предварительный запрос, после которого пользователь должен перейти на страницу и нажать кнопку, автоматическая отписка не завершена. Страница предпочтений допустима для ссылки в теле, но не как обязательное продолжение машинного сценария.

Сервер требует cookies или авторизацию

Запрос приходит не из браузерной сессии пользователя. Любая зависимость от личного кабинета, cookie-файла или HTTP-аутентификации приведёт к отказу обработки.

URI перенаправляет POST

Редирект может изменить метод или потерять тело. Следует указывать конечный HTTPS endpoint и обрабатывать запрос непосредственно на нём.

Токен не определяет список

One-click не предоставляет отдельного диалога для выбора адреса или категории. Если URI позволяет определить только пользователя, сервер не узнает, от какой подписки его нужно отключить. Контекст списка необходимо безопасно включить в токен или связанное с ним серверное состояние.

Заголовки не входят в DKIM-подпись

Письмо может пройти общую DKIM-проверку, но поля отписки останутся неподписанными. Нужно проверять не только результат DKIM, но и перечень заголовков в параметре h=.

Отписка применяется только в одном сервисе

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

Отсутствие кнопки Gmail считается доказательством ошибки

Почтовый интерфейс может не показать команду рядом с отправителем, даже если заголовки присутствуют. Отображение зависит от автоматических проверок и общей оценки отправителя. Проверять нужно исходный код письма, DKIM-подпись, доступность endpoint и реальное изменение подписки, а не только внешний вид интерфейса.

Что проверить перед массовой отправкой

Хотя материал посвящён принципам, а не конкретной платформе, минимальная проверка реализации должна охватывать всю цепочку:

1. Маркетинговый шаблон содержит List-Unsubscribe с персонализированным HTTPS URI.
2. В письмо добавлен List-Unsubscribe-Post: List-Unsubscribe=One-Click.
3. Оба поля входят в валидную DKIM-подпись итогового сообщения.
4. POST обрабатывается без cookies, авторизации, CAPTCHA и ручного подтверждения.
5. Endpoint не отвечает перенаправлением.
6. Токен нельзя легко подобрать или изменить для отключения чужого адреса.
7. Повторный запрос не вызывает ошибочного состояния.
8. Отказ блокирует последующие отправки из нужного списка во всех связанных системах.
9. В теле письма остаётся видимая и понятная ссылка отписки.
10. Транзакционные и подписные потоки используют отдельные правила и по возможности разные адреса отправителя.

Тест лучше проводить на письме, прошедшем тот же путь, что и реальная кампания. Просмотр шаблона внутри редактора не выявит заголовки, добавленные или удалённые на уровне API, SMTP-реле и DKIM-подписания. Нужно получить сообщение во внешнем ящике, открыть его исходный код и проверить конечный вариант.

Затем следует отправить POST с тем же типом содержимого, который ожидается от почтового сервиса, и убедиться, что адрес действительно исключён. После этого полезно попытаться повторно включить его обычным импортом или запуском автоматического сценария: список подавления должен предотвратить случайное возвращение.

Помимо заголовков отписки проверьте базовые DNS-записи почтового домена: MX, SPF, DKIM, DMARC и TXT. Их назначение и взаимосвязь разобраны в практическом руководстве по DNS и SMTP.

Главное о границах применения

One-click unsubscribe — это не декоративная ссылка и не универсальный заголовок для любой исходящей почты. Это стандартизированный машинный способ отказаться от конкретной подписной рассылки. Он строится на паре List-Unsubscribe и List-Unsubscribe-Post, HTTPS POST, защищённом идентификаторе и DKIM-подписи соответствующих полей.

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

Транзакционные письма, вызванные конкретным действием или необходимые для выполнения операции, исключаются из требования Gmail к однокликовой отписке. Однако решающим остаётся назначение сообщения, а не название шаблона. Разделение рекламных и сервисных потоков помогает правильно применять заголовки, не отключать важные уведомления и не маскировать маркетинг под обязательную переписку.