Доставляемость писем для сайта объявлений для взрослых: почему код подтверждения так и не приходит
Сбой, о котором никто не получает предупреждения
Новый пользователь регистрируется, вводит адрес электронной почты и ждёт шестизначный код, который позволит завершить проверку возраста. Код не приходит в ту минуту, когда должен. Возможно, он появится в папке спам десять минут спустя, когда пользователь уже давно закрыл вкладку. Возможно, принимающий почтовый сервер отклонит его прямо в момент отправки, с сообщением об отказе, которое пролистывается в журнале, который никто не смотрит. В любом случае ничего в этом опыте не сообщает оператору, что что-то пошло не так. Воронка регистрации просто показывает ещё одного посетителя, который ввёл адрес почты и больше не вернулся, неотличимого от того, кто просто передумал.
Эта неопределённость и есть настоящая проблема, важнее любой отдельной технической причины. Большинство сайтов отслеживают, было ли письмо отправлено, зелёная галочка на панели, а не было ли оно действительно показано живому человеку. Это два разных события, и именно в разрыве между ними проблема доставляемости прячется месяцами. Оператор, у которого никогда не было сбоя хостинга или блокировки платёжного процессора, всё равно может терять реальную долю новых регистраций из-за проблемы с почтой, которую он никак не может заметить, потому что нет инцидента, нет тикета в поддержку, нет панели, которая становится красной.
Это другой вид риска, связанного с поставщиком, чем тот, что закрывает аккаунт хостинга уведомлением со ссылкой на пункт договора, который никто не перечитывал со дня подписания. Приостановленный хостинг громкий: сайт гаснет, и оператор узнаёт об этом за минуты, потому что клиенты сообщают об этом, и панель тоже показывает сбой. Проблема доставляемости тиха по своей природе. Аккаунт отправки остаётся открытым, ежемесячный счёт продолжает приходить, и единственный видимый симптом: воронка регистрации, теряющая людей на последнем шаге по причинам, которые со стороны оператора выглядят как обычный отток, а не как исправимая техническая неполадка.
Первопричина при этом остаётся тем же видом категориального трения, что проявляется у хостеров, банков и платёжных процессоров. Почтовые провайдеры и сервисы рассылки оценивают эту категорию как более рискованную, чем большинство других, некоторые прямо и поимённо, и новый домен без истории отправки начинает каждое письмо с изъяном, который не имеет никакого отношения к тому, что письмо на самом деле говорит.
Почему эту категорию фильтруют строже большинства
Спам-фильтры и почтовые сервисы обращаются не со всеми отраслями одинаково, и разницу стоит изучить до регистрации, а не после того, как аккаунт уже пометили. Опубликованная политика SendGrid о запрещённом контенте перечисляет отдельными пунктами «порнографию или сексуально откровенный контент» и, отдельно, «услуги эскорта, поиск невест или супругов по переписке, международные брачные агентства и подобные услуги». Эта вторая категория не о том, что содержит письмо. Она называет сам бизнес причиной для исключения, а значит, обычный текстовый код подтверждения от каталога эскорт-услуг может оказаться вне политики просто из-за категории, независимо от того, насколько нейтрально составлено само сообщение.
Политика допустимого использования Mailgun проводит границу совсем в другом месте. Её раздел о запрещённом контенте ограничен материалами, которые представляют собой или продвигают эксплуатацию детей, зоофилию или действия без согласия, без отдельного пункта, называющего бизнес для взрослых или эскорт-услуги категорией. Это заметно более узкое ограничение, чем у SendGrid, нацеленное на то, что незаконно, а не на то, какая отрасль отправляет письма. Два крупных, универсальных провайдера, доступных через одинаковую форму регистрации, проводят границу в действительно разных местах, и оператор, выбравший одного из них, не читая дальше страницы с тарифами, не может знать, по какую сторону этой границы окажется его аккаунт, пока проверка не выявит это сама.
Это тот же пробел в предварительной проверке, что застаёт операторов врасплох из-за пункта о расторжении договора с хостингом или CDN, который они никогда не читали, только на уровень ниже в стеке. Вопрос, который нужно задать перед выбором почтового провайдера, не в том, разрешает ли он технически отправку почты для такого рода бизнеса в целом. Вопрос в том, называет ли письменная политика провайдера конкретно эту категорию бизнеса, письменно, до того как уйдёт первый код подтверждения, а не после того, как это обнаружит проверка на злоупотребления.
Новый домен отправки усугубляет это независимо от того, что разрешает провайдер. Фильтры сильно учитывают историю и характер объёма домена, и домен, появившийся недавно и сразу начавший рассылать автоматические коды в большом объёме, для фильтра без других сигналов выглядит как шаблон аккаунта, созданного для узкой цели и брошенного после того, как его пометили. Это не суждение о бизнесе; это шаблонное совпадение, которое срабатывает у любого совсем нового домена, будь то объявления для взрослых или нет, и исчезает оно только со временем и при стабильном поведении отправки.
Технический минимум, который теперь требует каждый почтовый провайдер
Даже провайдер, чья политика безоговорочно принимает аккаунт, не может сам по себе доставить письмо во входящие. С 1 февраля 2024 года Google требует от каждого отправителя, посылающего почту на адреса Gmail, независимо от объёма, соответствовать документированному минимуму: как минимум, правильно настроенный SPF или DKIM на домене отправки. SPF перечисляет, каким серверам разрешено отправлять письма от имени домена; DKIM подписывает каждое письмо, чтобы принимающий сервер мог убедиться, что оно не было изменено в пути. Отправители, достигающие 5000 писем в день именно на адреса Gmail, сталкиваются с более высокой планкой: SPF и DKIM вместе, плюс DMARC, опубликованный на домене, как минимум в режиме мониторинга. Сайт объявлений, рассылающий коды проверки возраста, сбросы паролей и квитанции об оплате в реальном масштабе, быстро пересекает этот порог в 5000 писем, поскольку каждое из них засчитывается в общий счёт.
Собственные опубликованные рекомендации Google задают точное число сверх аутентификации: отправители любого размера обязаны удерживать долю жалоб на спам, отображаемую в Postmaster Tools Google, ниже 0,30 процента, а те же рекомендации советуют оставаться ниже 0,10 процента как реальный запас прочности, а не относиться к 0,30 процента как к комфортной цели, к которой можно приближаться. Несоблюдение проявляется в виде двух отдельных, по-разному задокументированных сбоев, а не одного расплывчатого наказания. Письма, не прошедшие SPF, DKIM или DMARC, могут быть помечены как спам или прямо отклонены с ошибкой SMTP 5.7.26. Отправители, превышающие разрешённую Google квоту отправки, упираются в другую стену: ошибку ограничения скорости 4.7.28. Ни один из этих кодов не сообщает «эта отрасль здесь нежеланна». Оба выглядят с панели разработчика как обычная техническая неполадка, и именно поэтому их обычно замечают недели спустя, а не устраняют в день, когда они начинаются.
Yahoo, чья инфраструктура обслуживает и адреса AOL, независимо публикует требование того же рода: SPF и DKIM вместе, политика DMARC минимум p=none, которая должна проходить проверку, и тот же потолок в 0,30 процента по доле жалоб, действующий по тому же графику с февраля 2024 года. Оператор, решивший этот вопрос для Gmail и предполагающий, что Yahoo и AOL последуют тому же пути, обычно прав в механике, поскольку оба провайдера сошлись на почти одинаковых цифрах, но обе системы по-прежнему измеряют и применяют правила раздельно, поэтому домен в хорошем состоянии у одного не находится автоматически в хорошем состоянии у другого.
Одно требование в этом наборе написано намеренно узко. Отписка в один клик через заголовок List-Unsubscribe, по собственной формулировке Google, применяется именно к маркетинговым и подписным сообщениям. Код подтверждения или квитанция об оплате не относятся ни к тем, ни к другим, так что именно этот пункт на них не нацелен. Требования аутентификации и репутации выше по списку (SPF, DKIM, DMARC и потолок жалоб) так не ограничены: они применяются к каждому письму, которое отправляет домен, включая транзакционные.
Ошибка, которая тянет вниз и важную почту
Самый распространённый способ, которым оператор портит собственные письма с подтверждением: отправка маркетинговой почты с того же домена, что и коды подтверждения и квитанции об оплате. Репутация отслеживается в основном на уровне домена и поддомена отправки, поэтому разделение потоков помогает, но изоляция между поддоменами не абсолютна: всплеск жалоб на одном поддомене всё равно может отразиться на родительском домене, особенно если оба потока используют за кулисами одну и ту же подпись DKIM. Рекламное письмо, объявляющее о новой функции или сезонном предложении, отправленное по устаревшему списку, порождает как раз такой всплеск жалоб, который способен обрушить репутацию общего домена, и часть этого ущерба доходит до кода подтверждения, которого прямо сейчас ждёт только что зарегистрировавшийся пользователь, хотя это письмо никак не связано с маркетинговой рассылкой, вызвавшей проблему.
И именно здесь операционная дисциплина, выстроенная вокруг проверки возраста, незаметно переплетается с чисто технической проблемой доставки почты. Процесс проверки, зависящий от того, дойдёт ли код до почтового ящика, надёжен ровно настолько, насколько надёжна репутация домена отправки в тот день, когда этот код уходит, а репутация является ресурсом, общим для всех типов сообщений, использующих связанную инфраструктуру, если только оператор намеренно не держит их порознь.
Решение носит структурный характер, а не является настройкой, которую переключают после того, как всплеск жалоб уже случился. Отправляйте транзакционную почту (коды подтверждения, подтверждения оплаты, сбросы паролей) с выделенного поддомена, не используемого ни для чего другого, например mail.example.com вместо голого домена или общего маркетингового поддомена, и подписывайте её собственным ключом DKIM, а не тем, что используется повторно во всех потоках. Отправляйте маркетинговый или рассылочный контент с полностью отдельного поддомена, например news.example.com, с собственными записями аутентификации и собственной репутацией, способной выдержать неудачную неделю с жалобами, не утягивая за собой почту, которая обязательно должна дойти. Оба потока могут идти через один и тот же аккаунт у провайдера, но с точки зрения принимающего почтового сервера они должны выглядеть, и быть подписаны, как явно разные отправители.
Что действительно стоит проверить на этой неделе
Начните с того, чтобы поднять политику допустимого использования того сервиса, который сейчас отправляет транзакционную почту сайта, и письменно выяснить, называет ли она конкретно категорию бизнеса, точно так же, как ранее сработала проверка договоров с хостингом и CDN для инфраструктурных поставщиков. Провайдер, чья политика уже исключает категорию по имени, не является тем провайдером, на котором стоит строить процесс проверки, каким бы надёжным он ни казался до сих пор, потому что проверка аккаунта может прекратить эту надёжность без всякого предупреждения.
Проверьте, действительно ли SPF, DKIM и DMARC опубликованы и проходят проверку на домене, который прямо сейчас отправляет письма с подтверждением и квитанциями, а не считайте это само собой разумеющимся, потому что кто-то настроил их однажды, много лет назад. DNS-запись, которая была верной в момент создания, может устареть после миграции к другому провайдеру, и домен без аутентификации начинает каждое письмо с реальным шансом на отказ по правилам, которые Google и Yahoo применяют с февраля 2024 года, независимо от содержания письма.
Разделите транзакционную и маркетинговую почту на разные поддомены с разными ключами подписи, если они ещё не разделены, и относитесь к этому как к инфраструктурной работе, а не как к решению отдела маркетинга, поскольку ошибка здесь стоит проваленной проверки личности, а не упущенной продажи.
Следите за реальной долей жалоб через собственные отчёты провайдера или через Postmaster Tools Google по фиксированному графику, и относитесь к любому приближению к 0,10 процента как к моменту, когда нужно разбираться, а не к 0,30 процента, поскольку 0,30 процента ближе к точке, где почту начинают отклонять, чем к точке, где проблема только зарождается. И периодически отправляйте настоящую тестовую регистрацию на личный адрес Gmail и личный адрес Yahoo, засекая, сколько времени требуется коду, чтобы дойти, и куда именно он попадает, потому что панель, сообщающая об успешной отправке, сообщает о том, что покинуло сервер, а не о том, что реально увидел пользователь.
