Текст книги "INBOX. Полное руководство по доставляемости ваших писем"

INBOX. Полное руководство по доставляемости ваших писем
Максим Тимощенко

© Максим Тимощенко, 2023

ISBN 978-5-4496-7897-3

Создано в интеллектуальной издательской системе Ridero

ПРИЕВЕТСТВЕННОЕ СЛОВО

Всем привет, меня зовут Тимощенко Максим, я являюсь руководителем направления e-mail-маркетинга в Газпром Медиа Холдинг. В этой книге я хочу рассказать о доставляемости в email-маркетинге, ориентируясь как на базовый уровень, так и на тех людей, которые уже хоть немного, но что-то делают в email-маркетинге или, может быть, даже работают с крупными базами, поэтому мы пойдем не только по верхам!

Я начну с глобального блока – доставляемости писем, который мучает многих клиентов: «А что же делать? А как же быть?». И могу сказать, что у многих крупных брендов не настроен до сих пор даже параметр DMARC, которого требуют многие email-провайдеры.

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

Некоторые части книги будут полезны руководителям отделов маркетинга, некоторые моменты из книги будут полезны вашим системным администраторам, разработчикам, некоторые непосредственно email-маркетологам, так как им необходимо будет настраивать техническую составляющую. Есть вещи, которые интересны на ESP (email server provider) – платформах. Их техническая часть, как правило, реализована самой платформой, но всегда стоит помнить, что качественные показатели относятся напрямую к маркетологу, к тому, кто будет отправлять письма.

Смысл доставляемости

Давайте подумаем, что такое спам. Спам – это массовая рассылка коммерческих писем тем, кто не выражал яркого желания их получать. Когда вы шлете тем людям, которые не ждут ваших писем, вам нужно получать явное согласие, чтобы не слать спам, причем оно должно быть выражено не ранее, чем за 12 месяцев. Практика показывает, что люди, подписавшиеся более 12 месяцев назад, могут забыть про вас. Важно постоянно чистить базу. Год – это долгий срок. Вы можете поставить себя на место таких людей и подумать: если год назад вы подписались на какой-либо сервис, вспомните ли вы его сейчас, если вы в течение года с ним не контактировали? Думаю, ответ очевиден.

Второй момент: когда вы получаете данные в рамках офлайн-конференций, обязательно надо предупреждать, что будете отправлять письма. В свое время я пересекался с «Инфобизнесменом» на какой-то из конференций, мы обменялись визитками, после этого мне пришла рассылка. Иначе говоря, я был удивлен, каким образом мой рабочий email попал в рассылку от него? На мой взгляд, это было не очень корректно.

При этом, даже если у вас есть согласие на получение рассылок, контент должен обязательно соответствовать ожиданиям подписчика, то есть, если человек подписывается на туризм, нельзя ему отправлять рассылки о инфобизнесе. Если человек подписывается на маркетинг, не надо ему отправлять письма про игрушки. Это вызывает негатив, и подписчики с большой долей вероятностью нажмут «ЭТО СПАМ».

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

Нельзя отправлять письма, если нет явного согласия: скрытые пункты, вписанные в политику обработки персональных данных или в политику пользования сервисом, – это не очень корректные моменты, из-за которых вы получите больше негатива, чем релевантных клиентов.

Также негатив возникает, когда вы пытаетесь спрятать то, что письма приходят от вас, то есть изменяете имя отправителя или домен. Это все не очень правильно. В США, Европе, Канаде есть законодательно закрепленные штрафы за спам-рассылку, и в законе четко указано, что в каждом письме должны быть физические контакты отправителя, чтобы имелась возможность выйти с отправителями на связь.

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

При этом доставляемость делится на два типа: техническая и качественная, они различаются кардинально.

Техническая – это, то сколько сообщений вообще попало в почтовые ящики пользователей – без разницы, в какую из папок. Показатель технической доставляемости ESP сообщают в графе «Доставлено писем», и, как правило, он составляет 99,95%.

Качественная доставляемость – это то, сколько писем попало в inbox, то есть не было отфильтровано в спам. И это то, чего мы пытаемся добиться в email-маркетинге.

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

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

Также нужно четко понимать то, что технические составляющие – это первичная база, которая обязательно должна быть. То есть, если у вас будет отличная стратегия, ее будут любить ваши пользователи, но, если у вас нет попросту настроенных параметров, ваши письма никто не увидит. Таким образом, базовые параметры SPF, DKIM, политику DMARC нужно настраивать изначально.

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

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

Немного подробнее поговорим про выделенные IP-адреса: сначала о разделении отправляющих IP-адресов, а затем о том, как происходит отправка писем. Предположим, у вас есть почтовый сервер (SMTP Server), который, как правило, привязан к вашей форме рассылок, то есть форма подписки у вас, получается, не привязана к платформе, потому что вы сами настраивали почтовый сервер. У почтового сервера есть параметры отправки: домен отправителя и IP-адреса, с которых уходит почта. Это то, что находится на вашей стороне, и вы их контролируете, вы можете их менять. Почему это важно? Например, возьмем сервис GetResponse – это платформа, ориентированная на средних и мелких клиентов. Соответственно, выделять под каждого клиента пул IP-адресов не имеет смысла, это неоправданное использование ресурсов со стороны платформы. Поэтому GetResponse, так же как «Юнисендер», MailChimp и другие ESP – все платформы такого уровня, используют общие IP-адреса для большого количества своих клиентов, это означает, что репутация IP-адресов распределяется по каждому из отправителей и формируется также суммарно из репутации каждого отправителя.

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

Не все платформы предоставляют выделенные IP, но у тех, кто нацелен на хороший уровень работы, они есть. И не всегда выделенные IP даются бесплатно. Так что выделенные IP-адреса, с одной стороны, – хорошо, потому что вы сами формируете репутацию, с другой стороны – это проблема, потому что, если у вас случайно пошел какой-то плохой трафик, то вы сами себя топите. Соответственно, с выделенными IP все зависит от вас с точки зрения репутации.

Давайте поговорим, почему имеет смысл разделять новостные и транзакционные письма с разных IP-адресов и с разных доменов.

Транзакционные сообщения – это восстановление пароля, сопровождение заказа, подтверждение регистрации, это те письма, которые обязательно должны быть доставлены пользователям.

Маркетинговые сообщения – промо-акции, распродажи и т. д. – это письма, которые приносят вам прибыль, но, если они не придут, вы потеряете только прибыль.

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

Как это делается? Для промо используется домен типа promo.<domain>.com, а для транзакций – order.<domain>.com. Соответственно, репутация разделяется по этим доменам, и в случае если ваши массовые рассылки попадут в спам, письма восстановления пароля все равно будут приходить.

Базовый принцип – это разделение вашего основного корпоративного домена и домена, использующегося в массовых рассылках. Аналогичная тактика применяется для разделения разных типов писем.

Может также использоваться замена доменов, смена IP в зависимости от страны, в которую вы отправляете, то есть, например, если вы шлете в Россию, Украину, Белоруссию, там можно использовать одни и те же IP. А если вы еще отправляете письма условно в Америку или Китай, тогда имеет смысл брать другие домены, другие IP-адреса. В отношении Китая – там все очень строго: нужно иметь сервер, который физически находится на территории КНР.

Технические требования к рассылкам
SPF-запись

ru.wikipedia.org/wiki/Sender_Policy_Framework

SPF (sender policy framework) – это подпись, содержащая информацию о серверах, которые могут отправлять почту с вашего домена. Наличие SPF снижает вероятность попадания вашего письма в спам.

Важно помнить, что SPF-запись может быть только одна для одного домена. В рамках одной SPF может быть несколько записей (например, если письма отправляются с нескольких ESP – маловероятно, но все же чуть позже будет пример). Для поддоменов нужны свои записи.

Пример записи SPF

SPF запись определяет, от имени каких IP-адресов вы можете отправлять письма, то есть это та запись, которую проверяет почтовый провайдер mail.ru, yandex.ru, gmail.ru и другие, они смотрят на соответствие IP-адреса, с которого фактически пришло письмо, и IP-адреса с которого вы разрешили отправлять. SPF-запись публикуется в открытом доступе в форме DNS. Вы можете посмотреть SPF-запись любого домена, просто воспользовавшись нужным сервисом.

Приведем пример Lamoda. У них запись выглядит следующим образом:

lamoda.ru. TXT «v=spf1 include:_spf.lamoda.ru include:_spf.google.com include:ofsys.com -all»

Из этой записи мы видим, что у них есть разрешение отправлять с IP, указанных по адресу spf.lamoda.ru, с IP Google (видимо, у них там почта находится) и с IP-платформы. Соответственно, все остальные IP-адреса исключаются. Это означает, что с других IP-адресов письма будут отправляться в спам. Как это проверять? Я назову вам несколько сервисов, которыми пользуюсь лично сам:

• dsnwatch.info / type = TXT

• mxtoolbox.com / SPF-check

• Google.com: SPF checker

DKIM (domain keys identified mail)

ru.wikipedia.org/wiki/DomainKeys_Identified_Mail

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

Проверка DKIM происходит автоматически на стороне получателя. Если домен в письме не авторизован для отправки сообщений, то письмо может быть помечено подозрительным или помещено в спам – в зависимости от политики получателя.

Записей DKIM может быть несколько – например, если вы пользуетесь одновременно сервисом GetResponse и при этом отправляете письма через Gmail, у вас будет 2 записи DKIM с разными селекторами:

Синтаксис DKIM

Обязательные элементы синтаксиса DKIM:

 
«v» – версия DKIM, всегда принимает значение v=DKIM1;
«k» – тип ключа, всегда k=rsa;
«p» – публичный ключ, кодированный в base64.
 

Ключ DKIM – это, по сути, подпись письма, он прописывается двумя частями, одна из которых выложена так же, как и SPF, в публичном доступе для всего Интернета в формате DNS-записи. Она записывается в каждое отправляемое письмо в формате служебных заголовков, то есть, когда письмо уходит с вашей платформы, у нее есть видимая часть (это контент) и есть служебная часть, которую обычный получатель не видит, но при необходимости до нее можно добраться, и там прописаны как раз все технические нюансы отправки сообщения. Ключ DKIM публикуется как раз в этих служебных заголовках, и его проверяет в момент получения почтовый провайдер. Когда письмо прилетает на принимающий сервер, он проверяет DNS-записи, у него указан один ключ, в письме приходит другая часть ключ, и, если они совпадают, являются частью одной пары, письмо проходит во входящие; если они не совпадают, то письма будут отправлены в спам.

DMARC

https://www.dmarcanalyzer.com/dmarc/

– это то, что работает на основе SPF и DKIM, то есть надстройка. Появился этот протокол в конце 2011 года, активно использоваться начал с 2013-го, в его разработке участвовали Yahoo!, LinkedIn и другие крупные компании.

Как это работает? Запись DMARC публикуется аналогично DKIM и SPF в формате DNS-записи, то есть она публично доступна всем, ее также можно проверять. При этом в момент отправки уходит сообщение, оно формируется в платформе, затем сигнал об отправке уходит на управляющий сервер на стороне платформы и на стороне вашей инфраструктуры, в него добавляется DKIM, и, соответствует или не соответствует SPF, – письмо уходит. В тот момент, когда письмо попадает на сервер получателя Mail.ru, «Яндекс» и т. д., они проверяют, естественно, все стандартные механизмы по репутации, SPF, по черным спискам, и если все хорошо, то письмо отправляется в проверку политики DMARC, если нет, то, соответственно, письмо блокируется еще на этом этапе.

Что делает политика DMARC? Она указывает, каким образом почтовый сервер получателя должен обрабатывать письмо, если у этого письма сломана SPF или ключ DKIM. Письмо пришло с других IP-адресов, что делать с этим письмом? На этот вопрос отвечает DMARC.

Почему DMARC так важен? Потому что это ваше решение, каким образом почтовику обрабатывать письма. Не сам почтовик решает, а вы ему четко указываете, что делать с вашими письмами. Например, SPF проходит, а DKIM не проходит – письмо все равно хорошее, его надо отправить в inbox, или если SPF сломан, но DKIM хороший, тогда письмо отправлять в блокировку.

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

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

Политика DMARC формируется в формате DNS-записи, то есть у нее есть определенный синтаксис вида DMARC.сайт.com, и сама DNS-запись, точнее, значение DNS-записи – это название поддомена, под которым висит политика DMARC, а значение этой политики формируется по определенным правилам, и есть сервисы, которые помогают генерировать эту запись. Ключевые параметры, которые в ней есть, – это сама политика. Когда вы собираете отчеты, смотрите, что происходит. Карантин-письма отправляются в спам, reject-письма блокируются. Блок-отчет об ошибках отправляется на указанный вами email-адрес, который вы указываете в DNS-записи. Все письма с сообщениями об ошибках стандартны и доступны для парсинга в автоматическом режиме, вам не нужно самому заходить туда и каждый отчет открывать руками. В них также указывается частота отправки отчетов, можно в секундах задать, как часто вам нужно отправлять отчет о мониторинге, обычно – по опыту – указывают сутки. Соответственно, делается запись, в которой прописываются все параметры в момент получения.

В случае если политика DMARC стоит «карантин» или «reject» и получился инцидент, то формируется второе письмо по каждому инциденту, и оно уходит на второй emai-адрес, вы можете его обрабатывать. Отчет содержит информацию о количестве отправленных сообщений, об IP-адресах, с которых были отправлены письма, и о статусе проверки SPF и DKIM. Вы настроили политику DMARC на мониторинг, чтобы понять, какие письма идут от вашего имени, потому что в случае с большими компаниями почта уходит от имени компании из нескольких разных точек – это может быть корпоративная почта, в которой вы общаетесь, это могут быть промо-рассылки с одной платформы, это может быть HelpDesk, который использует третью платформу, и это может быть какой-то еще сервер «Гугла», где у вас находится почта. Получается несколько разных блоков IP-адресов, все эти блоки надо первоначально идентифицировать и затем прописать в политику SPF, чтобы случайно не заблокировать свою собственную почту.

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

Есть сервисы, которые генерируют отчет в формате xml, где в тегах указаны параметры, чтобы его привести в нужный вид, есть сервисы, которые его просят и разбивают по IP-адресам, по статусам и т. д.

Если рассматривать платформы среднего уровня, которые ориентированы на небольших клиентов, то, как правило, отправка писем с них идет с домена, принадлежащего платформе, то есть вы просто прописываете там email отправителя, но по факту письма уходят с их домена, а не с вашего. И получается, что репутация зависит от их домена. При этом SPF и DKIM настроен на их собственный домен, поэтому вам не нужно заморачиваться. Надо зарегистрировать аккаунт в платформе, создать письмо оттуда, верифицировать email, с которого отправляете письма, и рассылка уйдет. Когда вы будете использовать какие-то платформы более высокого уровня – тот же самый Emarsys, ExpertSender, – потребуются первоначальные настройки аккаунта: SPF и DKIM, а также техническая составляющая. Потому что отправка пойдет от имени вашего домена, соответственно, на ваш домен нужно все это настроить, чтобы письма не попадали в спам, но при этом платформа помогает это сделать: присылает инструкции и все сама за вас генерирует.

Далее. Требования к качеству рассылок – это то что, относится к маркетологу, который делает рассылки, создает контент. Большая часть этих требований обусловлена качеством общения с вашими получателями.

Double Opt-In – это подписка с подтверждением, когда человек сначала регистрируется на сайте, ему приходит письмо «подтвердите, пожалуйста, подписку», он кликает на ссылку в письме, только после этого он попадает в лист получателей ваших маркетинговых сообщений; без этого клика он вообще не будет ничего получать от вас. Есть, естественно, много соблазнов: «А что это у меня так мало людей подтверждают письма, давайте-ка я их все равно включу в открытую базу, они же у меня там подписывались». Так нельзя делать, потому что подписка с подтверждением нужна как раз для того, чтобы верифицировать email-адреса, на которые к вам приходят сообщения, и понять, кто из ваших получателей действительно хочет получать рассылки, а кто нет.

Также есть и отрицательные стороны: база растет не так быстро, потому что не все будут подтверждать подписку; люди могут вести неверный email, могут забыть пароль от почтового ящика, могут намеренно ввести «левый» email, только бы получить доступ к сервису, а подписываться на рассылки они не хотят, им надо ввести хоть что-то. Это минус, так как база не будет расти, порядка 40% регистрантов у вас может отвалиться на этапе подтверждения подписки, и это нормально, потому что те, кто подтверждают рассылки, – это лояльные к вам пользователи, которым было не в лом тратить свои полторы минуты времени, зайти в соседнюю вкладку в браузере и перейти по этой ссылке для подтверждения. Соответственно, вы приобретаете, во-первых, первичную лояльность, а также вы плюс к доставляемости, потому что вы получаете, с точки зрения почтового провайдера, позитивные взаимодействия с вашими рассылками, с вашим доменом. Вы уже ведете общение с пользователем, и при этом вы получаете людей, которые знают ваш дизайн, ваше имя отправителя, и в дальнейшем вам будет проще с ними работать. Напомню, подписка с подтверждением – это обязательное требование почтовых провайдеров, то есть в правилах Mail.ru четко указано, что она должна быть. Эти правила опубликованы на Mail.ru в разделе Help.

Один из часто задаваемых вопросов у новичков в email-маркетинге: «Как они проверяют, подтвердил ли человек регистрацию, откуда Mail.ru знает, что он есть в этой базе?»

Смотрите, Mail.ru этого не знает в момент отправки рассылок, но они могут это узнать, если ваши письма попадут в спам и вы напишете в Mail.ru: «Почему мои письма в спаме?». А они ответят: «Подписка не была подтверждена». И нечего будет возразить.