Леонид Николаев
ДОСТАВКА В INBOX – УРОВЕНЬ «БОГ»!
и другие байки Email-маркетинга
Леонид Николаев
Меня зовут Леонид Николаев. Так получилось, что почти 20 лет я так или иначе связан технологиями вокруг, внутри и около электронной почты. Точно не скажу, но лет пятнадцать я занимаюсь рассылками непосредственно.

Я — это как раз тот случай, когда не я выбрал профессию, а профессия выбрала меня.

В одном из интервью на вопрос: «Что бы вы посоветовали тем, кто хочет стать email-маркетологом?», я честно ответил — ни в коем случае не становиться email-маркетологом и/или специалистом, связанным с массовыми рассылками.


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

Мой отец был одним из известных в СССР (а потом в России) специалистов в области ветеринарии. Его сферой деятельности была эпизоотология. Такое страшное и непонятное слово. Отец много работал и все время был в командировках.

Когда меня спрашивали в детстве взрослые:

— Хочешь ли ты, Лёня, быть как папа?

Мама, не давая мне вставить слово, в ужасе кричала:

— Нет! Только не это! Пусть будет кем-то другим, но вот в это только через мой труп. Пусть хоть ассенизатором!

Если заглянуть в словарь:

Эпизоотология — это наука о причинах возникновения, условиях распространения и угасания заразных болезней животных (т. е. о закономерностях эпизоотического процесса) и методах профилактики и борьбы с ними.
Убрать отсюда слово «животных» и, черт возьми, по сути, это примерно то, чем я занимаюсь — причины и условия попадания писем в спам, методы профилактики и борьба с теми, кто считает, что все это не нужно, и письмо само дойдет.

Однако и мать была права, я как-то написал в анкете в графе «профессия» — IT-ассенизатор, потому что про профилактику никто не думает и приходит только тогда, когда уже надо реально разгребать то, что разгребает ассенизатор «в дикой природе».

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

Как шутейно написать о том, как настроить DKIM, когда нужно еще знать, что такое DNS, что если прописывать DKIM через CNAME запись, то обязательно в конце нужно поставить точку, потому что это каноническая запись?
Мне не представлялось возможным создать такой текст.

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

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

Не могу забыть случай, когда сорокалетний отставной прапорщик огромных пропорций выполнял задание молодого преподавателя (меня) написать небольшой текст в текстовом редакторе «Lexicon».

Вот он старательно, одним указательным пальцем, по буковке на клавиатуре набирает слова. Я стою позади огромного ЭЛТ-монитора.

— Фуф, — вытирает лоб, — набил!

— Давайте сохраним, нажмите F4.

— Ага!

— Где у вас сохранился текст?

— В смысле?

— В прямом. Где вы сохранили текст, который только что набрали?

— Ну там!!! — тычет пальцем в монитор.

— А точнее?

— Ну там!!!

Так происходит несколько раз. Я беру и выдергиваю сзади шнур питания монитора. Монитор гаснет.

— А где теперь?

— Ах, ты [арго]! — вскакивает прапорщик, роняя стул, — я [арго], [арго] его пол дня набирал! Тебе [арго]!

Конфликта не случилось. Я, конечно, рассказал про структуру папок, про диск C:\ …

— Це [арго], комбаин! — ржал прапорщик.

Это к тому, что в теории сложное вполне можно объяснять простым языком.

И вот я решил — напишу техническую книгу, но, когда вы будете ее читать, вам будет казаться (я надеюсь) — что мы сидим рядом, и я вам просто рассказываю про все это без академизма, обычным разговорным языком.

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

Так как я решил, что книга — это живая речь, я буду использовать обычные разговорные слова.

Возможно, это будет бесить кого-то из читателей, но...

Например, я задал вопрос в профессиональном сообществе в ФБ: «как по-вашему написать слово "email" по-русски?». Там было в обсуждении столько всего — от крайней неприязни русской транскрипции до ссылок на корпус русского языка, где русское написание вполне себе норма.

В свое время я был шеф-редактором нескольких журналов, в том числе «Мир Internet». Категорически неприемлемо, тогда говорили корректоры, писать слово «Internet» как-либо по-другому. Мы даже отправили запрос в Институт Русского Языка, и нам ответили, что нужно писать «Internet», а если хотите по-русски, то «МеждуСеть».

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

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

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

По многочисленным требованиям email-маркетологов, email-маркетинг будет написан как надо.

Глава 1.
Законодательные ограничения распространения нежелательной почты
Теперь непосредственно к содержанию: вам предстоит начать с самого скучного, но самого «градообразующего» раздела книги — законодательства.

Законы такая штука, которая должна оградить добросовестное от недобросовестного и последнее наказать в случае, если… Однако на деле — закон есть, но его исполнение в части email-рассылок весьма сомнительное, несмотря на прописанные на бумаге правильные слова.

Но стоит сказать, что в части смс-рассылок «дамоклов меч» наказания продвинулся куда более существенно, чем в части имейл.

Штрафы стали серьезными, и количество «левых» смс разительно сошло на нет.

Мировая практика преследования спама пошла заметно дальше, к сожалению, чем наша судебная система — как исполнительная, так и доказательная.

В мире существуют энтузиасты, которые, подобно мистеру Фреклину из произведения А. Конан Дойля, преследуют спамеров путем частных судебных исков и, надо сказать, зачастую неплохо на этом зарабатывают. Так, например, один из спам-хантеров — Найджел Фитерстон — получил вознаграждение от удовлетворенного судебного иска в размере двухсот пятьдесяти тысяч долларов, только за то, что получал от компании Universal Direct рекламные письма, хоть и призывающие разбогатеть, но нежелательные для истца. К слову, Найджел мог бы требовать гораздо большую сумму, поскольку в штате Вашингтон есть жесткий закон о борьбе со спамом, согласно которому за каждое спамерское письмо отправитель обязан выплатить адресату $500.

Было доказано, что Фитерстон получил 58 тысяч писем, однако сам истец запросил всего 250 тысяч долларов, хотя мог требовать 29 миллионов.

Почитайте, что написано на этих нескольких страницах, или сразу переходите к «Причинам попадания в спам» на странице. Хотя нет, лучше все-таки прочитайте:

Закон о рекламе
Федеральный закон «О рекламе» от 13.03.2006 N 38-ФЗ (последняя редакция)

Статья 18. Реклама, распространяемая по сетям электросвязи

1. Распространение рекламы по сетям электросвязи, в том числе посредством использования телефонной, факсимильной, подвижной радиотелефонной связи, допускается только при условии предварительного согласия абонента или адресата на получение рекламы. При этом реклама признается распространенной без предварительного согласия абонента или адресата, если рекламораспространитель не докажет, что такое согласие было получено. Рекламораспространитель обязан немедленно прекратить распространение рекламы в адрес лица, обратившегося к нему с таким требованием.
http://www.consultant.ru/document/cons_doc_LAW_58968/
Федеральный закон «О персональных данных» от 27.07.2006 N 152-ФЗ (последняя редакция)


Персональные данные – любая информация, относящаяся к прямо или косвенно определенному, или определяемому физическому лицу (субъекту персональных данных).

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

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

Обработка персональных данных – любое действие или совокупность действий, совершаемых с использованием средств автоматизации или без них с персональными данными: сбор, запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передача (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных.



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

  • ссылка на профиль в социальных сетях.
  • ФИО (вместе и даже по отдельности);
  • дата рождения;
  • адрес;
  • телефон;
  • email;
  • фотография;
  • ссылка на персональный сайт;
Одним словом, речь идет о любых данных, по которым можно идентифицировать человека. Следовательно, если вы каким-то образом получаете такие данные в любом сочетании, то являетесь оператором персональных данных. Фактически любой владелец сайта — оператор персональных данных, так как он размещает на своем ресурсе форму обратной связи, форму регистрации и тому подобное, например, форму подписки на рассылку.

Однако Федеральный закон № 152-ФЗ делит операторов на несколько категорий: физлица, ИП, юрлица, муниципальные органы, государственные органы. В зависимости от категории за одно и то же нарушение применяются разные по размеру штрафы. Так, например, для физлиц они заметно ниже, чем для юрлиц.

Это, конечно, здорово, но не очень приятно, когда требование об уплате штрафа придет именно вам, правда?

Каждая категория операторов так или иначе сталкивается с обработкой ПД. Физлица используют ПД клиентов. ИП запрашивают эти данные, нанимая работников, или собирают ПД на сайте, в интернет-магазине. К юрлицам применяется расширенный список требований по оформлению необходимых документов и требование о назначении ответственного за организацию обработки ПД.

Самые жесткие требования предъявляются к государственным и муниципальным органам, которые работают с огромным массивом ПД граждан.

Как вы думаете, если им будет пофиг, накроет ли их гневом Роскомнадзора, если нарушения будут выявлены? Я сомневаюсь. А вот вас, например, если вы небольшой интернет-магазин — вполне.

Избежать гнева Роскомнадзора все-таки можно, если следовать следующему плану
1. Если на сайте есть формы сбора информации о пользователе (подписки в том числе), разместить чекбокс «Даю свое согласие на обработку персональных данных» со ссылкой на Положение об этом на сайте.

2. Само Положение должно описывать условия обработки ПД.

3. Положение должно содержать условия обработки ПД согласно статье 9 Федерального закона № 152-ФЗ:

  • ФИО, адрес субъекта ПД, номер основного документа, удостоверяющего его личность, сведения о дате выдачи указанного документа и выдавшем его органе;
  • наименование или фамилию, имя, отчество и адрес оператора, получающего согласие субъекта ПД;
  • цель обработки ПД;
  • перечень ПД, на обработку которых субъект дает согласие;
  • наименование или ФИО и адрес лица, осуществляющего обработку ПД по поручению оператора, если обработка будет поручена такому лицу;
  • перечень действий с ПД, на совершение которых дается согласие, общее описание используемых оператором способов обработки ПД;
  • срок, в течение которого действует согласие субъекта ПД, а также способ его отзыва (если иное не установлено законом);
  • подпись субъекта ПД.

4. Скорректируйте документ относительно вашей деятельности, задач и потребностей.

5. Следующий документ, который должен присутствовать на сайте — «Политика в отношении обработки персональных данных» (об этом обязательстве оператора прямо говорится в п. 2 ст. 18.1 Федерального закона № 152-ФЗ). В данном случае рекомендации по его составлению дает сам Роскомнадзор (http://rkn.gov.ru/personal-data/p908/).

6. Подайте уведомление об обработке ПД в Роскомнадзор. Вообще, в соответствии с ч. 1 ст. 22 Федерального закона № 152-ФЗ, оператор должен это сделать еще до начала обработки ПД. Но лучше поздно, чем никогда. За задержку с уведомлением вас не оштрафуют, санкции последуют только в том случае, если вами заинтересуется Роскомнадзор. Но, даже если вы высылаете уведомление с опозданием, указывайте дату государственной регистрации как дату начала обработки ПД.

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

Это возможно, когда:

- ПД относятся к субъектам, которых связывают с оператором трудовые отношения;

- ПД получены оператором при заключении договора, но не распространяются и не предоставляются третьим лицам без согласия на то их субъекта, то есть используются оператором исключительно для исполнения договора;

- являются общедоступными ПД (это самая что ни на есть формулировка-с-двойным-дном. В свое время спамеры именно так прикрывали свою спамерскую сущность — «ваш адрес был найден в открытых источниках». Но у них ничего не вышло);

- включают только ФИО субъектов ПД;

- нужны для однократного пропуска субъекта ПД на территорию, на которой находится оператор, или в иных аналогичных целях;

- включены в федеральные автоматизированные информационные системы ПД, государственные информационные системы ПД, созданные в целях защиты безопасности государства и общественного порядка;

- обрабатываются без использования средств автоматизации в соответствии с федеральными законами или иными нормативными правовыми актами.

Есть еще «вишенка на торте», когда для обработки персональных данных не нужно согласие субъекта персональных данных :)

Согласно ч. 2 ст. 6 Федерального закона от 27.07.2006 № 152-ФЗ согласие субъекта персональных данных не требуется в случаях, когда обработка персональных данных:
Это возможно, когда:

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

- необходима в связи с реализацией международных договоров Российской Федерации о реадмиссии (Реадмиссия — это такая штуковина в виде согласия государства на прием обратно на территорию своих граждан, а также в некоторых случаях иностранцев, прежде находившихся или проживавших в этом государстве, которые подлежат депортации из другого государства);

- осуществляется в целях исполнения договора, одной из сторон которого является субъект персональных данных;

- осуществляется для статистических или иных научных целей (при условии обязательного обезличивания персональных данных);

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

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

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

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

Ну а теперь вкратце, чтобы переварить все вышесказанное:
Персональными данными является любая информация о физическом лице, в том числе:

- Адрес электронной почты, содержащий в себе фамилию и/или название компании;

- Номер банковской карты, а также, в определенных случаях, код CVC;

- В некоторых случаях номер мобильного телефона (так называемые «конфиденциальные персональные данные»).

Например:

- Электронный адрес: sergey.ivanov@mail.com – является персональными данными;

- Электронный адрес: sergey@mail.com – не является персональными данными.

http://www.consultant.ru/document/cons_doc_LAW_61801/

В том числе данный раздел подготовлен с использованием материалов размещенных на сайте СКБ Контур. (https://kontur.ru/articles/4816)

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

Пользовательское соглашение и антиспам политика
Еще раз для укрепления материала (это на самом деле очень важно).

Перечень документов, которые помогут вам правильно организовать подписку на сайте:

  • «Пользовательское соглашение». При регистрации или подписке на сайте посетитель должен отметить, что согласен на обработку персональных данных, которая регламентируется Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных «Политикой конфиденциальности»;
  • Исходя из предыдущего пункта, ссылка на документ «Политика конфиденциальности» должна быть рядом со ссылкой на «Пользовательское соглашение»;
  • Не помешает ссылка и еще на один документ — «Политика в отношении обработки персональных данных»;
  • «Форма отписки». Достаточно, если она располагается в конце сообщения, главное здесь — понятная форма без дополнительных действий. Наиболее удобный вариант — автоматическая отписка при переходе по соответствующей ссылке из письма.
Ответственность за ненадлежащее исполнение правил и норм по организации e-mail и SMS-рассылок

Согласно части 1 статьи 14.3 КоАП РФ за несоблюдение законодательства возможно наложение административных штрафов:

1. на граждан от 2 000 р. до 2 500 р.;

2. на должностные лица от 4 000 р. до 20 000 р.;

3. на юридические лица от 100 000 р. до 500 000 р.

Так же, как и email-рассылка, SMS-рассылка возможна только при предварительном согласии (ст 18 ФЗ о Рекламе).

Согласно части 1 статьи 14.3 КоАП РФ за несоблюдение законодательства возможно наложение административных штрафов:

1. на граждан от 2 000 р. до 2 500 р.;

2. на должностные лица от 4 000 р. до 20 000 р.;

3. на юридические лица от 100 000 р. до 500 000 р.

Так же, как и email-рассылка, SMS-рассылка возможна только при предварительном согласии (ст 18 ФЗ о Рекламе).

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

- устное согласие абонента, рекомендации знакомых и т.д.;

- информация из открытых источников;

- технический сбой или ошибка оператора (неправильно записали данные).

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

- назначить приказом ответственное лицо;

- выработать регламент формирования и ведения клиентской базы;

- вести запись при получении согласия на рекламную рассылку по телефону;

- регулярно проводить проверку клиентской базы на основе статистической выборки;

- при работе с брендами получать согласие именно на бренд, а не просто заключать соглашение с юрлицом-владельцем бренда.

Порядок обращения граждан в ФАС

http://fas.gov.ru/citizens/treatment/


Роскомнадзор

http://rsoc.ru/treatments/ask-question/
http://rkn.gov.ru/treatments/ask-question/
It is necessary to choose a visual aid that is appropriate for the material and audience.
С 01 июля 2017 года в закон № 54-ФЗ от 22.05.2003 г. были внесены существенные изменения законом № 290-ФЗ от 03.07.2016 г., которые затронули все продажи через интернет. В соответствии с этими изменения в законе было введено новое понятие «электронные средства платежа», под которое подпадают любые платежи, осуществленные в сети Интернет физическими лицами (банковские карты, «Яндекс.деньги», «Вебмани» и т.д.). В соответствии с вышеуказанными изменениями продавец обязан в момент совершения покупки электронными средствами платежа предоставить клиенту кассовый чек, а также отправить данные о продаже в налоговую инспекцию. Некоторые платежные агрегаторы предоставляют функцию аренды кассовой техники и отправки электронного чека клиенту и в налоговую инспекцию, но далеко не все. При работе, например, с платежным агрегатором «Яндекс.деньги» продавец вынужден самостоятельно приобретать контрольно-кассовую технику (ККТ), подключать ее и интегрировать с платежной системой.
Штрафы:

Ст.14.5 КОАП РФ

  1. Неприменение контрольно-кассовой техники в установленных законодательством Российской Федерации о применении контрольно-кассовой техники случаях — влечет наложение административного штрафа на должностных лиц в размере от одной четвертой до одной второй размера суммы расчета, осуществленного без применения контрольно-кассовой техники, но не менее десяти тысяч рублей; на юридических лиц — от трех четвертых до одного размера суммы расчета, осуществленного с использованием наличных денежных средств и (или) электронных средств платежа без применения контрольно-кассовой техники, но не менее тридцати тысяч рублей.
  2. Повторное совершение административного правонарушения, предусмотренного частью 2 настоящей статьи в случае, если сумма расчетов, осуществленных без применения контрольно-кассовой техники, составила, в том числе в совокупности, один миллион рублей и более, — влечет в отношении должностных лиц дисквалификацию на срок от одного года до двух лет; в отношении индивидуальных предпринимателей и юридических лиц — административное приостановление деятельности на срок до девяноста суток.
  3. Применение контрольно-кассовой техники, которая не соответствует установленным требованиям, либо применение контрольно-кассовой техники с нарушением установленных законодательством Российской Федерации о применении контрольно-кассовой техники порядка регистрации контрольно-кассовой техники, порядка, сроков и условий ее перерегистрации, порядка и условий ее применения — влечет предупреждение или наложение административного штрафа на должностных лиц в размере от полутора тысяч до трех тысяч рублей; на юридических лиц — предупреждение или наложение административного штрафа в размере от пяти тысяч до десяти тысяч рублей.

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

— Как у тебя с письмами?

— Все в спаме… — Хм… [В разговорной речи обычно иное междометие].
Каким Сервисом пользуешься?

— «имя_сервиса».

— Х… сервис, меняй.
90% людей, которые так или иначе пытаются работать с массовыми рассылками, действительно уверены, что виноват именно Сервис рассылок. Более того, я видел «грозные-письма-подам-на-васв-суд» и обвинения, что именно Сервис рассылок еще и губит базу, которую за большие деньги (или по знакомству) достали, чтобы продать на волне ажиотажа спиннер, летающую фею, биткоины или наклейку-скручивалку на счетчик электроэнергии. «Главное зло, естественно, почтовая система, но Сервис рассылок ведь как раз для того и создан, чтобы «обходить» эти спам-фильтры?» — думают они. Маркетологи с серьезными лицами со сцены обсуждают сотые доли процента открытий писем, оценивают рекламные кампании по скриншоту макета неотправленного письма в PowerPoint… К чему все эти труды, если письмо никуда не придет или придет в папку спам? Однажды я готовил скучный технический доклад и из любопытства решил оценить количество запросов (и вопросов) в поисковых системах, на форумах и сообществах в социальных сетях относительно проблем доставки писем. Их десятки тысяч!
Среднестатистически это выглядит так. Вопрос: «Почему мои рассылки попадают в спам в [название почтового сервиса]?» Ответ: «Потому что [название почтового сервиса] — содомиты!»
Все вопросы, связанные с доставкой, условно можно разделить на четыре части: технические, законодательные, административные и условно-контекстные (этот термин используется мной для простоты и не является общепринятым). Внутри это можно подробить на такие факторы, влияющие на доставку:
  • Рассылки не нарушают закон;
  • Выполняются административные регламенты почтовых сервисов;
  • Поддерживается чистота и качество базы подписчиков;
  • Количество жалоб пользователей на письма отправителя находится в пределах норм, установленных почтовыми сервисами;
  • Технические настройки писем отправителя правильные.
В этой книге мы рассмотрим все эти вопросы наиболее подробно, каждый технический термин и технология будут рассмотрены досконально, но для того, чтобы к более техническим деталям вы подобрались уже подкованными, рассмотрим процесс, как почтовая система видит письма в тот момент, когда какой-либо сервер решил отправить письмо. В момент установления диалога между отправляющим сервером и принимающим принимающий сервер (в данном случае ISP) должен принять решение, куда письмо должно в конечном итоге попасть. По сути, это довольно сложная система, строящаяся на самообучаемых алгоритмах, а также обращающаяся к существующим базам данных, в которых содержатся хорошие и плохие образцы информации (сигнатуры). У каждого публичного почтового провайдера есть собственная система оценки и хранения данных об отправителе (репутация). И, как вершина этого айсберга, последняя миля — система принятия решения. В простом виде, всю схему можно изобразить так:
У каждого письма есть технический заголовок, так называемый RFC, в котором содержится зачастую гораздо больше информации, чем самом письме. Вот вам в качестве примера полное содержание письма вместе с техническим заголовком:
В данном случае все содержание письма — это 7 последних строк.

Пока на эту картинку нужно просто посмотреть, оценить объем, так сказать. Все, что тут может быть написано и как читать это, подробно рассмотрим чуть позже.

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

Существуют внешние репутационные данные: информация, которой делятся с почтовой системой публичные black-листы, независимые антиспам-системы, общественные сервисы оценки репутации (такие, как WOT https://www.mywot.com) и тому подобные. Зачем это нужно, и почему обмен такой информацией — безусловная польза для всего рынка?

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

Внешние репутационные данные в большинстве случаев касаются: IP-адресов, доменов, с которых рассылается спам, спам-слов («Enlarge your dick, Dude!»), адресов и телефонов, связанных с мошенниками.

Образно — вы постучались в дверь почтовика с «черного» IP-адреса, а вам даже не открыли дверь (сразу отвергли сообщение, не читая). Или рассылка идет с домена, который кто-то уже уличил в рассылке спама: в «лучшем» случае, все письма сразу пойдут в папку «спам», в худшем — не попадут внутрь почтовой системы вообще.

Разумеется «лучший» и худший случай — для отправителя, для почтового провайдера оба варианта лучшие без всяких кавычек: спам не попал в папку входящие, пользователи не увидели спам — все довольны.


«Как мои рассылки могут быть отправлены с плохих IP-адресов?»

Совершенно разумный вопрос, но и ответ на него достаточно прост: вы можете этого и не знать — сюрприз! Решили вы создать интернет-магазин и скачали какой-то скрипт, который его реализует в вебе, купили хостинг (естественно, дешевый) и все так или иначе настроили — с виду работает. Вроде и посетители есть, и заказы вы видите в админке. Покупок нет.
Почему оно не приходит? — задаете вы вопрос админу (если он у вас есть). — Как мы эти письма отправляем?
— <?php
mail("zakazchik@milliondeneg.com", "Подтвердите ваш заказ на миллион", "Дядь, вот содержание твоего заказа... Оплати, мы привезем");

?>

Пример тривиальный, и пусть простят меня знающие функцию mail(), там, конечно, можно задать и правильные заголовки и все, что необходимо, но ясно одно — вы отправите письмо с IP-адресов вашего хостинг провайдера. Вы отправите хорошее письмо, которое ждет ваш покупатель. В это время Я, условный спамер, почти за бесценок покупаю у этого же хостера несколько таких же, как у вас, «тарифных планов» и физически на том же сервере разворачиваю систему, чтобы конкретно рассылать спам. Почтовая система видит, что спам-писем с этого IP-адреса идет гораздо больше, чем нормальных, и блокирует IP. Ваш покупатель ждет письмо, вы ждете покупателя… а спамер давно ушел в другой хостинг и портит IP-адреса там. Кстати, такая же проблема может возникнуть, если вы, как интернет-магазин, используете SAASсервис в качестве платформы и даже если ведете рассылку через Сервис рассылок. Массовый Сервис рассылок в некотором смысле — заложник ситуации. На рынке существует огромная конкуренция, массовым Сервисам необходимо искать маркетинговые ходы привлечения клиентов. Клиент сейчас довольно требовательный, ему все нужно бесплатно и с наилучшим набором услуг. Сервисы же, служа на благо клиента и в надежде на бурный рост и будущую прибыль зачастую (да что уж греха таить, всегда) имеют в своем арсенале бесплатные тарифы на месяц, бесплатные тарифы навсегда, если база не превышает N подписчиков или писем не больше N*Х в месяц, и так далее. И действительно — регистрации идут, клиенты множатся, красивые цифры можно написать в презентации, чтобы очаровать успехами инвесторов. Однако теневая закулиса драйверов нежелательной почты скрупулезно отслеживает все волшебные предложения Сервисов рассылок и использует их в своих коварных целях. Все спамеры это знают, все Сервисы это знают. Все борются друг с другом с переменным успехом. Самый простой вариант со стороны Сервиса — использовать для новых и условно-бесплатных клиентов какую-то отдельную технологическую часть, которая бы не влияла очень сильно на самый вкусный кусок пирога — рассылки больших и проверенных клиентов. Поэтому если вы «с улицы» зарегистрировались в Сервисе рассылок, выбрали условно-бесплатный и/или минимальный тариф обслуживания, ожидайте, что, возможно, даже письмо подтверждения вашей регистрации придет вам же в папку спам. Причем это как раз может не означать, что Сервис рассылок плохой, просто у него есть некий буфер (начальная часть сервиса), призванный как раз выловить спамеров на начальном этапе. Естественно, IP-адреса у вас скорее всего будут от «так себе» до «лучше вообще об этом не думать». Решение этой проблемы (если вы используете Сервис) — сразу запросить для себя отдельный, выделенный IP-адрес, с которого, кроме вас, никто не будет рассылать. Либо использовать свои собственные IP-адреса.
Книга о рассылках, предполагаю, что у читателя база есть.

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

Email-маркетинг — такой же канал привлечения (обслуживания, удержания, дополнительных конверсий) клиентов, как и другие виды рекламной и коммерческой активности в сети. Эффективность этого канала может быть больше или меньше в сравнении с другими, но рассылки — это самый зависимый от чистоты и качества пользовательской базы источник.

К примеру, трафик посетителей, привлекаемый через дисплей или smm, может быть разной степени качества и «чистоты». В конечном итоге это отражается только на крайне низкой конверсии, в то время как сомнительная база подписчиков может нанести компании серьезные репутационные риски от попадания в различные черные списки до полной блокировки отправки почты с домена.

Поэтому так называемая «гигиена» базы подписчиков — одна из важнейших, первостепенных задач email-маркетолога.

На дворе XXI век, однако запросы типа «где скачать базу для рассылки» популярны настолько, что, вероятно, даже в обозримом будущем ни спрос, ни предложения не сойдут на нет. Учитывая почти нулевой по затратам уровень вхождения в рынок email-рассылок новичков коммерции и, к сожалению, даже крупных игроков, спам привлекает условной возможностью быстро и почти бесплатно получить прибыль, не выходя из дома / коворкинга / смузи-бара/ барбешопа, был бы интернет под рукой.

Характерно то, что такие примеры в истории есть.

Вот вам песенку про Спам принес (https://youtu.be/cFrtpT1mKy8 ). Она 1969 года. Если лень перепечатывать ссылку, можете поискать в Youtube «Летающий цирк Монти Пайтона "песня про Спам"», уже тогда общественность так задолбала острая ветчина SPAM, производимая компанией «Хормел Фудс», что появился такой скетч от известных комиков того времени. Ветчину рекламировали на билбордах, фасадах домов, по радио и деться от нее было совершенно некуда. Так безобидная с виду ветчина (и довольно вкусная, кстати) стала синонимом нежелательных сообщений прежде всего в электронной почте.

Ветчина живет и здравствует до сих пор (если так можно выразиться, говоря про консервы).

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

Итак — «Центр американского английского» — самый известный отечественный спамер всех времен и народов.

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

«Центр Американского Английского» вызывал такую ненависть, что в Интернете был проведен литературный конкурс «Убей "Центр Американского Английского Языка"!»

На компанию подавали в суд и Антимонопольный комитет, но компетентные органы не нашли в действиях «Центра Американского Английского» ничего противозаконного.

В 2005 году Вардан Кушнир, основатель «Центра Американского Английского» и главный спамер Рунета, был убит. Насколько его смерть связана с ненавистью пользователей интернета следствие не установило, но спам прекратился.

Убийство вызвало широкий резонанс как в прессе, так и в среде сетевого общения. Многие обитатели российского сегмента Интернета откровенно радовались смерти Кушнира, некоторые даже предлагали объявить 24 июля «Днём борьбы со спамом». Хотя Кушнир не был единственным российским спамером, в глазах многих он был символом российского спама.

Но тут появились «Пластиковые окна»…

Несмотря на несовершенство нашего законодательства, теперь у государства есть законные рычаги воздействия на спамеров [Читайте «Законодательные ограничения распространения нежелательной почты»].

Если коротко, в России рассылки по электронной почте, носящие массовый и/или рекламный характер регулируются «Законом о рекламе» (в частности, статьей 18 «Реклама, распространяемая по сетям электросвязи») и Федеральным законом «О персональных данных» (№152-ФЗ), которые обязывают отправителя иметь предварительное и явное согласие пользователя на получение информации отправителя.

На практике это называется «Double Opt-In» (двойное согласие, DOI), когда пользователь не только оставил вам адрес электронной почты для получения рассылки (регистрация), но и подтвердил свое согласие, перейдя по специальной ссылке из подтверждающего регистрацию письма, которое вы должны отправить сразу же после того, как подписчик сообщил вам свой адрес.

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

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

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

Распространенный миф — DOI снижает конверсию и «убивает» базу

Нежеланием реализовывать DOI в своей email-активности наиболее славятся представители онлайн-ритейла, в то время как именно рассылки интернет-магазинов (eCommerce в целом) составляют наиболее существенный процент из числа всех рассылок, которые приходят пользователям.

Рассылки ритейла — привлекательный сегмент для Сервисов рассылок и Сервисов, которые оказывают различные услуги он-лайн бизнесам для повышения конверсии и, в том числе, рассылают ситуационные письма, например, «брошенная корзина», «вы были у нас на сайте», «вы что-то забыли» и так далее. Если такой Сервис не имеет собственного транспорта доставки писем, они используют сторонние решения. Достаточно часто у Транспорта возникает вопросы, откуда клиенты Сервиса берут адреса и/или целые базы для рассылок маркетинговых писем, есть ли DOI и так далее.

Неудивительно, что ответ на такие вопросы колеблется между «нет» и «не знаем».

Иногда бывает так: Сервис утверждает, что все подписчики Клиента дали свое согласие на рассылку.

— На чем основывается ваше утверждение?

— Мы с ними подписали договор, у нас там указан пункт такой.

— Это не является подтверждением.

— Они клянутся, что есть!

— … [смайлик рука-лицо]

— Как мы можем это проверить? Это невозможно!

Повышение квалификации сотрудников email-агентств начинается прямо сейчас, итак:

Первое — люди врут! (какая неожиданность)

Второе — все люди врут! (Доктор Хаус)

Третье — проверить — нет ничего проще!

Зайдите на сайт клиента и подпишитесь одним из своих ящиков, ну, тех самых, «для спама». Кстати, тоже самое сделают сотрудники почтовой системы в случае подозрения на рассылку спама. Пришло письмо подтверждения? Отлично. Ничего не делайте. Подождите от нескольких минут до 1-2 дней. Что-то вам стало приходить в почту? Клиент врет. Не пришло письмо подтверждения — клиент врет. Не подтвердили подписку — письма не приходят? Умница и лапочка, с ним можно перейти на следующую ступень заключения договора. То есть проверить все остальное, такие ли они молодцы, как кажутся. Но наличие DOI у ритейла (и вообще у всех) — это уже полдороги к победе.

Был один случай (не один, конечно) в моей практике: клиент загрузил явно левую базу в десять тысяч адресов. Мы ее заблокировали (признаков там было более, чем достаточно). И тут он звонит в офис:

— Почему вы заблокировали мою базу?

— Ваша база не имеет подтверждения от подписчиков.

— Это все мои клиенты и друзья! Я вчера их лично обзвонил каждого! Они мне дали согласие лично!

— Чувак, — говорю, — К черту email-маркетинг! Если ты физически можешь один обзвонить 10 тысяч человек за «вчера», мы станем с тобой миллионерами! Давай откроем call-центр?

Он повесил трубку, а зря — такая бизнес идея сорвалась! В сутках 1440 минут, один звонок, учитывая набор и разговор, минимум минута. За смену оператор call-центра сделает максимум 90 звонков (норматив — примерно 1000 звонков в рабочий день, на 11 операторов), а тут 10 тысяч на одного!!!

Такой бизнес не случился. Жалею…

Как я уже говорил, до сих пор существует порочная практика покупки сторонних баз и/или использования в своей деятельности базы, которые собирались другими компаниями или для других целей (аренда базы). В зону риска также входит привлечение подписчиков на подрядной основе (например, агентствами, CPA-сетями и т.д.).

Рассмотрим несколько примеров типичных проблем в работе с базами, опять же, для электронной коммерции.
Техническая: Большинство платформ для интернет-магазинов не имеют инструментов для рассылки писем подтверждения, и/или технические специалисты не задумываются об интеграции с каким-либо сервисом рассылок, где такие инструменты реализованы.

Для небольших самописных магазинов и многих SAAS — это бич. Разработчики уверены, что поставить чекбокс «Хочу получать рассылку» в карточке заказа или при регистрации — это достаточная процедура (и даже излишняя). Настройки отправки транзакционных писем обычно заключаются в том, что нужно указать адрес smtp-сервера почтовой системы, логин и пароль (письма, по сути, будут просто отправляться от вашего ящика в публичном почтовике) — и это фундаментальная проблема всех небольших интернет-магазинов. Безусловно, письма так или иначе (правдами или неправдами) будут ходить, но! Плох тот рядовой, который не хочет стать генералом — количество заказов вырастет, Saas станет тесным, придет осознание, что письма нужно рассылать от своего домена… А у вас на руках — приличная база неподтвержденных адресов, ни разу не валидированная, никакого DOI нет, и что с этой базой делать — непонятно.

А тут еще директор говорит: «Разошли-ка наши скидки всем, кто заходил к нам за последние три года»…

Однажды на большой конференции прямо с утра к нам подошла девушка и говорит:

— У меня есть база подписчиков, мы их по визиткам собирали. Разослали через Сервис Х, нас там заблокировали.

— У вас есть DOI?

— Я не знаю, что это такое.

— Вы получали согласие от людей, чтобы присылать рассылки?

— А зачем? У нас же есть их визитки! Директор говорит, что нужно срочно отправлять рассылки и приглашать на наши семинары. Там всего-то 7 тысяч адресов. А вот Сервис Х нас заблокировал. Мы эту базу три года собирали.

— Нет, — говорю, — Не надо ничего им рассылать.



В тот день у меня были частные консультации в кулуарах, записывается эта девушка ко мне.

— Леонид, — говорит, — У нас база 7 тысяч адресов и директор говорит, что по ней нужно разослать, а нас заблокировал Сервис.

Я объяснил ей все обстоятельно еще раз.

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

— У нас есть база, я вчера все рассказала директору, что вы мне говорили, но директор требует, чтобы мы разослали рассылку, что мне сделать?

— Девушка, — говорю, — Лучшее противозачаточное средство, это слово «НЕТ». Так и передайте директору. И в целом, стоит задуматься о политике ведения бизнеса в организации. Ведь, вероятнее всего, если под давлением требований директора вы все-таки начнете рассылать спам — а по-другому это не назвать — то у компании будут проблемы, возможно, даже существенные, с блокировкой домена, «пасьянсом и танцовщицами из кабаре». И именно вы, как исполняющий обязанности email-маркетолога в компании, будете в этом виноваты! Вот, например, в компаниях, где главный бухгалтер не согласен с каким-либо финансовым решением руководящего органа, учитывая, что ответственность лежит на нем, может взять с директора письменное уведомление, что он принимает на себя весь груз ответственности и снимает его с бухгалтерии. Это может являться гарантией того, что в случае «маски-шоу» главбух останется на свободе. Потребуйте от своего директора письменный отказ от претензий и рассылайте, если ему так хочется послать спам, и он понимает, что делает.

Тут мы плавно подходим ко второй части проблемы баз подписчиков — организационной.

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

Во-вторых, любые рассылки на адреса без DOI чреваты проблемами с доставкой писем в папку инбокс, а также высоким уровнем жалоб получателей на несанкционированную рассылку (спам) и, как следствие, ухудшением почтовой репутации отправителя.

И проблема могла бы быть сведена почти к нулю, если бы в момент, когда вы получили данные пользователя, вы бы отправили ему письмо подтверждения и сразу бы узнали, что адрес невалидный, если это так. Тогда, связываясь с клиентом по телефону (мессенджеру), адрес можно было бы и уточнить.

Всем — профит!

Офф-лайновый сбор адресов — это боль. Магазины считают, что если в договоре поставки покупатель оставил свой имейл — он подписал себя на все, что вы заходите ему отправить. Это не так — хоть на какой бумажке напишет вам адрес ваш покупатель — вы обязаны получить DOI. Иначе, в случае возникновения проблем с доставкой, вам любая почтовая система скажет, что «непрокоцаный тикет за отмазку не катит».

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

Я понимаю, что у кассы не подтвердишь подписку через имейл, НО я абсолютно убежден, что технически отправить письмо с подтверждением максимально быстро, как только я написал свой адрес в договоре в строке «хочу получать рассылку», можно! И тогда я приду домой и буду помнить, что я это действительно делал, найду / увижу письмо и совершу адекватное действие.

Если же письмо мне придет через полгода, то мое действие может быть неадекватным (с точки зрения владельца рассылки).

Потом все они хором исполняют «Плач Ярославны в Путивле на стене»: «Почему мои подписчики отправляют письма подтверждения DOI сразу в спам?».

Ну, теперь вы точно знаете почему — с глаз долой, из сердца вон.

Но не только екоммерц страдает опасной болезнью «первое письмо через полгода».

Мой фаворит — компании, которые собирают базу на мероприятиях и выставках. Особенно непосредственно организаторы этих мероприятий.

Они собирают визитки, после мероприятия визитки лежат где-то в коробках, потом они отдают их подрядчику на автоматическое распознавание (что само по себе уже прекрасно — каких только креативных визиток сейчас нет, я иногда глазами прочитать не могу, не то, что автоматически), после распознавания это как-то импортируется в базу, обрабатывается, а потом составляются списки мейлов, которым перед следующим мероприятием (обычно через год) без всякого предупреждения приходит письмо: «Эй, чувак, давай участвуй!». Приходит, кстати, скорее всего в папку спам…

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

У меня есть адрес xpert@домен — на слух его практически никто не может записать правильно с первого раза, даже когда я диктую его по буквам. Даже когда его интерпретирует замечательный алфавит для [политкорректно убрал определение социальной группы] — «"h" как стульчик» и все остальное.

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

Не люблю средние показатели по больнице, но при офф-лайновом сборе баз количество невалидных адресов может составлять 25% и больше.

Стоит помнить, что, например, в почте Mail.Ru пороговое значение на количество несуществующих адресов в рассылке всего 5%.

Выводы:

  • Получение DOI обязательно вне зависимости от канала получения адреса электронной почты.
  • Базу (особенно собранную офф-лайновым способом) необходимо проверить перед отправкой [читайте раздел про сервисы проверки списков подписчиков].
Проблема вторая — сбор базы и неиспользование ее для рассылок сразу
Это тоже мое любимое — у компании скопилась большая база email-адресов, но по ним никогда не осуществлялись рассылки (либо осуществлялись неудачно), или источник получения всей или части такой базы неизвестен.

Так бывает достаточно часто в трех случаях:

  • Ранее компания не занималась email-маркетингом в принципе и адреса в базы попадали разными путями (регистрации, заказы, из 1С и т.д.), а работа с ними не велась;
  • С базой данных работали разные менеджеры, которые привносили в нее списки «своих клиентов» с предыдущих мест работы (об этом я обязательно расскажу подробнее);
  • Базы были приобретены или скачаны из интернета.

Вот случай из жизни.

К настоящему моменту конференция Mailing Day проходит уже 7 лет подряд и несколько раз в год. На одной из первых конференций, где я выступал в качестве докладчика, с вопросом из зала встал мужчина, он взял микрофон и говорит:

— Вот у меня есть база, мы собирали ее на сайте 3 года, но ни разу не делали рассылок. Как нам ее реанимировать, так сказать, с чего начать?

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

— Нет, ну как же! Мы ее собирали три года?!

— Поймите, сейчас такое количество информации приходит к людям в почту, через уведомления, социальные сети и прочее. Человек забывает через неделю, где он оставлял свой почтовый ящик. Три года — это могила! Шанс, что вас вспомнят практически нулевой.

Человек сел на место, и мы перешли к другим вопросам.



Проходит год. Конференция. Встает человек из зала.

— Вот у меня есть база, мы собирали ее на сайте 4 года, но ни разу не делали рассылок. Как нам ее реанимировать, так сказать, с чего начать?..

Этот преданный участник конференции посетил, по-моему, все мероприятия и в Санкт-Петербурге, и в Москве.

Уже работая над книгой я стал пересматривать свое выступление, которое делал, когда конференция проходила в рамках Ecom в Сокольниках в 2017 году. И тут встает этот мужчина и говорит:

— У нас есть база, ей 10 лет!

— Дальше не продолжайте, умоляю вас!

Безусловно я дал ему полный ответ (в десятый раз), а заключается он в следующем:

Начинать рассылку надо сразу же, как только у вас появился первый подписчик. Не нужно ждать красивых цифр — 100 подписчиков или миллион. Первое письмо (подтверждение подписки) человек должен получить так скоро, как это возможно, в идеале — сразу же! Любой Сервис рассылок обрабатывает это событие и даже предоставит вам форму подписки, которую вы поставите на свой сайт.

Более того, как только пусть даже единственный подписчик подтвердил свое согласие, начинайте рассылать ему письма согласно графику так, как бы вы рассылали рассылку, будь у вас база размером в десятки тысяч имейлов.

В этом огромное количество плюсов:

- Вы сразу же имеете провалидированную базу (высылая приглашение к подписке, вы сразу узнаете, существующий ли ящик вам оставил пользователь или нет);

- Вы сразу получите DOI (когда получатель приглашения подтвердит подписку, перейдя по ссылке из письма), и у вас в будущем не будет проблем реактивации, переподписки и прочего шаманства, когда база есть, а DOI нет, и есть проблемы с доставкой;

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

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

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

Как же оценить качество базы?
Проблема третья — оценка качества базы подписчиков ДО рассылки
В любой, даже самой хорошей базе, со временем появляются невалидные адреса, дубликаты, известные алиасы почтовых систем, адреса, которые случайно были записаны неверно (ошибки в доменах), адреса «временной почты».

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

Очень часто, когда вы выгружаете свою базу из Сервиса, чтобы перенести ее в другой — вы выгружаете ее в первоначальном виде.

Важно попросить Сервис отдать вам отдельно списки всех невалидных адресов, которые обнаружились в процессе ваших рассылок, и списки адресов, которые жаловались на спам.

Также неплохо выгружать базы по сегментам активности (те, кто открывал рассылки, переходил по ссылкам, совершал конверсии) и начинать рассылки в новом Сервисе именно с этих активных сегментов.

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

  1. Проверазличные сервисы проверок, узнать, не было ли попытки отправки на этот адрес у других рассыльщиков или крупных отправителей. Тот, кто аккумулирует у себя наибольшее количество информации о статистике отправки, точнее покажет совпадение, например, по несуществующим ящикам. Примерно 70-80% всех активных адресов электронной почты подписаны на одну или более рассылки, и им хотя бы раз была осуществлена попытка отправки почты через тот или иной канал.
  2. Ни один сервис проверки баз подписчиков не даст релевантных результатов, если база данных была составлена путем генерации случайных адресов в надежде «угадать» ящик реального пользователя. Во-первых, такая механика нелегальна (попросту спам). Во-вторых, вероятность, что кто-либо до этого совершал отправку по такой же базе, крайне низкая и, как следствие, результат проверки покажет такие ящики «условно хорошими». Однако, Сервис mailvalidator.ru с высокой степенью достоверности (98-99%) может проверить даже заведомо ложные адреса в базе.
  3. Использование зарубежных сервисов проверок баз подписчиков (например datavalidation.com, briteverify.com, xverify.com и др.), как правило, показывают крайне низкое качество проверки адресов в русскоязычном сегменте в силу того, что они основываются на фактических результатах работы иностранных сервисов рассылок, а в глобальном масштабе у таких сервисов не очень много русских клиентов. Использовать зарубежные сервисы рекомендуется в случае, если компания вела свои рассылки в каком-либо западном сервисе (mailchimp.com, elasticmail.com и т.д.) и решила перенести свою базу в российский сервис рассылок или осуществлять отправку самостоятельно.
  4. Не все сервисы проверки показывают результаты (даже в виде информации) бесплатно. Обычно, даже чтобы посмотреть среднюю картину о качестве базы, придется оплатить стоимость полной проверки, зачастую это довольно внушительная сумма.
Важно: если сервис проверки отметил какие-либо адреса как несуществующие или нежелательные для отправки рассылки, например, адреса, с которых осуществляются жалобы, не пытаться делать даже реактивационных писем в их адрес. Сервис имеет множество проверенных причин поместить тот или иной адрес в различные стоп-листы, и именно это позволяет влиять на почтовую репутацию в положительную сторону.
Проблема четвертая: чем грозит некачественная база рассылки
Проблема четвертая: чем грозит некачественная база

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

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

Рассылка по некачественным базам, особенно, если это значимый канал продвижения и продаж внутри вашей компании — это сильный удар по бизнесу компании. Заблокированные рассылки и/или письма, приходящие в папку спам — потеря реальных денег и времени.

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

Условно, вы делаете рассылку раз в день, она приносит выручку в несколько сотен тысяч рублей. Рассылка заблокирована на неделю — нетрудно подсчитать убытки.

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

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

Например, некоторое время назад в Правилах ведения почтовых рассылок Google явным образом указал, что:

Партнерские маркетинговые программы

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

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

Ответственность за действия аффилированных лиц и обязанность пресекать рассылку спама возлагается на создателя программы.

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

Сейчас наблюдается новая волна, когда в email-маркетинг приходят случайные люди. Компании ищут новые пути продвижения (или только начинают свой бизнес), стоимость рекламных интернет-носителей слишком высокая, а окружающие утверждают, что рассылки — это очень дешево и приносит быстрый «возврат вложенных средств».

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

Один из самых популярных запросов в поисковых системах: «скачать базу для рассылки». Результатов поиска тоже неимоверное количество — и «сегментированные», и с описанием, откуда базы сказали, и за деньги, и бесплатно. Все это создает ложное впечатление, что бизнес с использованием рассылок действительно простой, и достаточно только скачать базу.

Как примерно выглядят базы, которые скачивают из интернета, мы знаем благодаря нашему сервису www.mailvalidator.ru , их туда загружают, и у нас появляются вот такие записи в базе — и это настоящее название файла :)

Ребят_вот_кусочек_базы_в_ЛЯМ_адресов_по_которой_сам_работал_она_копеечная_но_конфертит_коненчо.txt

Стоит ли говорить, что данная база в 450 тысяч адресов не только на этапе экспресс-проверки показывает количество невалидных адресов больше 35%, так если по ней действительно сделать рассылку — погубит любой домен (и даже не один).

Уверен, что кто-то купил или скачал эту базу в надежде «поконфертить» немного легких денег. Но это вряд ли удастся.

Клиенты с некачественными базами наносят существенный вред и сервисам рассылок в том числе. В любом сервисе с общедоступной регистрацией и возможностью условно сразу приступить к рассылке существенный процент новых клиентов — спамеры (умышленные или «по незнанию»), которые пришли в сервис с единственной целью — «попробовать доставить по этой базе свое коммерческое предложение». Многие из спамеров «по незнанию» убеждены, что, если они заплатили деньги за какой-либо тариф в Сервисе рассылок, сервис обязан (!) отправить и доставить до папки «Входящие». Когда сервис или почтовая система блокирует таких клиентов, они скандалят и требуют возврата денежных средств.

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

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

Люди жалуются. В принципе, в той или иной мере это происходило всегда, правда, теперь люди стали жаловаться еще и в социальных сетях, а иногда они жалуются, даже находясь один на один со своим почтовым ящиком, нажимая на кнопку «Спам». И ожидают, что где-то незримый контролер возьмет их гнев в свои надежные руки и накажет нерадивого отправителя по всей строгости «Правил ведения почтовых рассылок».

Удивительно, но даже те, кто дал согласие получать вашу рассылку, могут целенаправленно пожаловаться.

Вам, как автору рассылки, кажется, что она прекрасная, замечательная и самая-самая, а читатель, получая письмо, думает: «О, Боже! Опять! На тебе!».

В таком случае:

  • Хороший вариант для вас, когда получатель найдет ссылку «Отписаться» и отпишется.
  • Более-менее нормальный вариант, когда он нажмет на ссылку «Отписаться», используя интерфейс почтовой системы (это, кстати, будет работать в большинстве случаев только если фактический отправитель сделал для этого необходимые настройки).
  • Плохой вариант, когда получатель нажал на вашу ссылку «Отписаться», а попал на ваш сайт, и ему предложили ввести логин/пароль. Его действие в таком случае — возврат в почтовую систему и нажатие на «Это спам» и/или — найти/выделить все письма отправителя (ваши письма), и нажать на «Это спам» на все сразу.
  • Самый ужасные вариант, когда получатель отписался от рассылки, а вы его не отписали и продолжаете присылать письма.

Наличие большого количества жалоб не звоночек, а колокол, в который бьют фильтры почтовой системы — «Это нежелательная рассылка!».

Лавинообразно растут жалобы как раз у спам-писем, так как их никто не ожидает получить, никто не стесняется жаловаться и делает это сразу же (зачастую не открывая письма). Поэтому уровень жалоб — последнее, что повлияет на то, куда попало письмо, даже если с техническими настройками все прекрасно, база «чистая», а в письме нет нежелательных артефактов.

Для рассылок, которые выпускались, и у них было все хорошо и вдруг!.., такое бывает в нескольких случаях:

  • Что-то случилось на стороне отправителя письма — рассылка задублировалась, и подписчики получили по несколько одинаковых писем;
  • В рассылку влили» новую базу «неизвестного происхождения»;
  • Маркетолог «поиграл» с темой письма, она показалась получателям неуместной, оскорбительной и т.д.;
  • Маркетолог «заигрался» в тесты и, например, поменял отправителя письма в поле «фром» — подписчики, которые уже жаловались на ваши письма, вновь получили их во входящие;
  • Вы действительно послали нежелательное письмо, например, его содержание неприятно удивило того, кто письмо открыл. Еще вчера вы рассылали новинки книжного рынка, а сегодня я узнал, что письмо о септиках для дачного туалета;
  • Вы воспользовались заманчивыми предложением и монетизировали рассылку партнерскими предложениями.

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

Кстати, помимо «самого ужасного варианта», есть, по моему мнению, вообще подрасстрельный — я отписался от рассылки, а мне говорят что-то в таком духе: «Уважаемый подписчик, мы вас отписали, но вы получите еще 1-2-3 письма, так как они уже загружены в систему, и удалить их невозможно».

Тысяча чертей! — я буду ждать ваши письма как никогда ранее! С таким наслаждением я буду нажимать на «Спам», что сравнить это почти ни с чем невозможно.

Ну и вишенка на торте — письмо после отписки с картинкой в стиле «Я убью эту собачку, если вы не вернетесь», или «Вот этот милый котик будет по вам скучать». За собачку вы ответите на Страшном суде, а на котика мне может быть и плевать, вдруг у меня аллергия?

Кстати, о дубликатах писем и сообщений. Помню, году в 2007-м мы даже не придавали этому значение, пока не произошло несколько курьезных случаев — рассылки после перестройки сендера (МТА) перестали обрабатывать ответы от почтовых серверов, и в системе каждое письмо не могло завершиться ни с каким статусом. Естественно, сендер, не получая результатов отправки, считал, что он ничего не отправил и делал попытку заново через заданный интервал. Постмастеров тогда еще не существовало и, по большому счету, узнать о происходящем можно было как раз только по жалобам пользователя, но — «теплым и ламповым» жалобам — по телефону! Нам оборвали все линии и буквально кричали в трубку: «Прекратите слать письма, они сыпятся сотнями в ящик, мы устали их удалять!».

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

Терпеливые сотрудники нашей службы поддержки устало говорили в трубку:

— Да, случилась проблема… Да, на стороне оператора… Решить можно выключением аппарата более, чем на сутки, истечет срок хранения смс на стороне оператора, они не будут приходить.

По возможности, избегайте этого.

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

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

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

Об обязательных технических настройках будет подробно рассказано в данном разделе.

Request for Comments (RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» еще можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения».

Когда волосатые дяди и умные тети начали строить интернет в разных частях нашей маленькой планеты, они довольно быстро осознали, что иногда придумывают велосипед, потому что то, что делал один, уже сделано другим и чуть раньше (хороший пример не про интернет — Попов и Белл).

И тогда мировая техническая общественность стала собирать свод правил всего, что так или иначе влияет на интернет и технологии в целом — свод стандартов отрасли. До сих пор в него добавляется все, что появляется в технологическом океане.

Вся электронная почта должна соответствовать стандартам RFC (например, SMTP 5321; MIME 2045, 2046, 2047, 2048, 2049);

SMTP 5321 (http://tools.ietf.org/rfc/rfc5321.txt );

MIME 2045, 2046, 2047, 2048, 2049.

http://tools.ietf.org/rfc/rfc2045.txt

http://tools.ietf.org/rfc/rfc2046.txt

http://tools.ietf.org/rfc/rfc2047.txt

http://tools.ietf.org/rfc/rfc2048.txt

http://tools.ietf.org/rfc/rfc2049.txt

Описание RFC на русском языке легко гуглится, но можно набрать эту коротенькую ссылочку: http://rfc.com.ru

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

Здесь будет уместным сравнение RFC с «самой читаемой книгой в мире», пожалуй, за исключением только того, что RFC продолжают писать.

Все почтовые серверы, осуществляющие подключения к почтовым серверам, должны иметь валидные (соответствующие действительности), осмысленные, не автоматически сгенерированные обратные DNS записи (rDNS, PTR-записи).

Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера. Практически все почтовые серверы отвергнут прием сообщения еще на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удаленным почтовым сервером, скорее всего, будет указана такой:

550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."

или:

550-There's no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто:

550 Your IP has no PTR Record.

Число «550» во всех трех случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими, и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS), и, в случае ее отсутствия, сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

Что-нибудь стало понятно? Из описания, догадываюсь, не очень

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

Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило, этим владельцем оказывается провайдер, владеющий собственной автономной системой.

Оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своем личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS, и настроить поддержку зоны вида «3.2.1.in-addr.arpa» на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса и имени хоста.

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

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

В любом случае имя IP-адресу почтового сервера (а особенно корпоративного почтового сервера) следует давать осмысленно.

Примеры хороших имен для сервера почты:

mail.domain.ru mta.domain.ru mx.domain.ru

Примеры плохих имен:

host-192-168-0-1.domain.ru

customer192-168-0-1.domain.ru

vpn-dailup-xdsl-clients.domain.ru

и подобные.


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

Проверка: http://remote.12dt.com

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

Представьте ситуацию — хостера «сломали» и от лица его IP шлют спам. Почтовая служба или блэк-лист, куда поступают жалобы, хочет хостеру сообщить о проблеме и ищет, как это сделать через «WHOIS» адреса и/или домена. Но информации не находит. Естественная реакция — просто заблокировать такие адреса (и/или домены).

Ну и, конечно:
  • IP-адреса, с которых идут рассылки, не должны находиться в black-листах;
  • Желательно использовать выделенные IP-адреса.

Про то, насколько важно следить за репутацией IP-адресов, я подробно рассказал в разделе [Причины попадания писем в спам].

Очень важно знать, что новые IP-адреса, которые вы собираетесь использовать для рассылок, требуют прогрева. Прогрев — это нарастающая отправка почты с каждого IP-адреса от малого к большему, постепенно наращивая объемы. Обычно Сервисы рассылок предоставляют своим клиентам на выбор автоматический план прогрева для выделенных IP-адресов (когда Сервис сам устанавливает лимиты отправок для каждого IP) или «ручной». В каждом Сервисе есть собственные рекомендации по «ручному» прогреву, но, в целом, они примерно схожие. Прогрев обычно рекомендуется на срок не менее 30 дней и начинается с 50-100 писем в первый день, 200-300 во второй, 500-800 в третий, 1000 в четвертый и так далее.

Уточните у вашего Сервиса, какие они дают рекомендации по прогреву адресов (или почитайте документацию), и четко следуйте инструкциям.

PTR — «обратная запись». В ней в обратном порядке записывается IP-адрес хоста, с которого в нашем случае рассылается почта. По этой записи почтовики распознают имя хоста по его IP.

Предположим, что IP вашего почтового сервера 78.56.158.23. В NS-записи сервера (или, что чаще, в настройках провайдера сервера или хостера) необходимо добавить следующую DNS запись (IP при этом «разворачиваем»):

23.158.56.78.in-addr.arpa IN PTR mail.mydomain.ru.

Проверка: http://centralops.net/co/DomainDossier.aspx

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

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

Проверка сервера на open relay: http://tests.nettools.ru

Открытые тексты и утилиты для проверки сервера на открытый proxy:

http://www.corpit.ru/mjt/proxycheck.html

DomainKey Identified Mail (DKIM)— метод, позволяющий убедиться, что почта отправлена тем, кто имеет на это право. Это протокол цифровой подписи письма.

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

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

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

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

Пару ключей можно сгенерировать с помощью онлайн-сервисов, например, этого: http://dkimcore.org/tools/keys.html

Безусловно, все описано на сайте самого стандарта (http://www.dkim.org), однако, есть много материалов по самостоятельной настройке DKIM на русском языке. Посмотрите, например, тут: https://habr.com/post/322616/

Как пример:

используем OpenSSL:

openssl.exe genrsa -out tstpriv.pem 1024 — генерируем секретный ключ длиной 1024 бит;

openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного.

Примером записей является:

mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=<публичный ключ>",

где «mail» — селектор. Можно указать несколько записей с разными селекторами, где в каждой записи будет свой ключ. Применяется, когда задействовано несколько серверов (на каждый сервер свой ключ).

Это самый частый вопрос: сколько записей DKIM может быть в DNS домена?

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

v — версия DKIM, всегда принимает значение "v=DKIM1" (обязательный аргумент);

k — тип ключа, всегда "k=rsa" (по крайней мере, на текущий момент);

p — публичный ключ, кодированный в base64 (обязательный аргумент);

t — флаги:

"t=y" — режим тестирования (отличаются от неподписанных и нужны лишь для отслеживания результатов);

"t=s" — означает, что запись будет использована только для домена, к которому относится запись, не рекомендуется, если используются домены третьего уровня.

Возможные:

h — предпочитаемый hash-алгоритм, может принимать значения «h=sha1» и «h=sha256»;

s — тип сервиса, использующего DKIM, принимает значения «s=email» (электронная почта) и «s=*» (все сервисы), по-умолчанию "*";

; — разделитель.

Есть вариант прописать ADSP запись, которая позволяет понять, обязательно должно быть подписано письмо или нет.

_adsp._domainkey.example.com. TXT "dkim=all"

Значений может быть три:

all — все письма должны быть подписаны;

discardable — не принимать письма без подписи;

unknown — неизвестно (что, по сути, аналогично отсутствию записи).

Некоторое время назад основные почтовые сервисы приняли решение запретить массовые рассылки от почтовых ящиков фри-мейлеров, когда, например, в поле отправителя стоит вася@домен_фримейлера.ru. Поэтому, если вы будете пытаться отправить рассылки, где в поле «фром» стоит такой ящик — авторизация по DKIM не пройдет и, в лучшем случае, почтовик выдаст предупреждение, что не может идентифицировать отправителя, в среднем — положит письмо в спам, в худшем — не примет вообще.

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

dkim=pass header.i=@get-n-post.ru;

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=get-n-post.ru; s=out;

h=Date:Message-Id:Subject:From:To:List-Unsubscribe:MIME-Version:Content-Type; bh=Z7HmzmQ4g….=;b=g7oRC+h3nKY99cnWepbAvdVMh/cqRKFtKDCYAj7Dr9UCeBoe3TZIr0/20E…=;

Помощь в настройке Dkim: http://www.port25.com/support/domainkeysdkim-wizard/
SPF — Sender Policy Framework — запись, которая указывает, с каких адресов (доменов и/или IP) следует ожидать почту, и как интерпретировать ошибку в случае несоответствия. По сути, это всего лишь рекомендация отправителя по проверке, но сейчас все почтовые системы обязывают отправителя иметь данную запись в DNS и, скорее всего, письма без SPF и/или выдающие ошибку проверки при приеме почтой либо отвергаются почтовым сервисом, либо помещаются в папку спам, либо будут иметь предупреждение для получателя о возможной угрозе нежелательности данного письма.

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

Технические детали

Для размещения данных используется поле TXT в DNS.

Так IANA (функция управления пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета. Исполняется компанией Public Technical Identifiers, которая находится под контролем ICANN) назначила DNS поле с кодом 99 для SPF.

Формат SPF поля идентичен TXT.

Некоторые системные администраторы прописывают SPF-запись как поле типа SPF и, в принципе, это правильно, но не всякий DNS сервер и клиент понимает такой тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие. Но лучше, если запись будет в формате ТХТ, а когда почтовые сервисы перейдут на новый тип записи — я уверен — они оповестят всех заблаговременно.

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

Например:

example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»

example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»

Если установлена запись SPF, то TXT записи должны быть проигнорированы.

Механизм взаимодействия

Почтовый обмен с использованием SPF происходит по следующему алгоритму:

- Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net.

В DNS записи example.com содержатся такие строки:

mx.example.com. IN A 208.77.188.166

example.com. IN MX 10 mx.example.com.

example.com. IN TXT «v=spf1 +mx -all»

- mx.example.com устанавливает соединение с SMTP example.net и получает от него, например:

>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC

- затем mx.example.com представляется через HELO/EHLO:

<< HELO mx.example.com

- В зависимости от настроек принимающей стороны после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это необязательно:

>> 250 example.net Hello mx.example.com., pleased to meet you

<< MAIL From:<user@example.com>

- После выдачи отправителем "MAIL FROM" должна последовать обязательная проверка, интерпретация результата и реакция на него.

- В данный момент модуль, отвечающий за проверку SPF, делает следующие вещи:

Осуществляет запрос к DNS;

Запрашивают SPF и TXT поля;

Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие.

В нашем примере это правило «v=spf1 +mx -all».

- Согласно правилам проверяются MX-записи и проводится сверка указанных в записях IP-адресов, полученных из представления DNS-имени и IP-адреса подключившегося отправителя.

В данном случае все совпадает, управление возвращается почтовому серверу, и он начинает прием сообщения.

Если фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовому серверу, что входящее сообщение невалидно, и, вероятно, его не стоит принимать или на крайний случай отмаркировать отдельно (например, «Спам»).

Формат записи

Запись SPF выглядит примерно так:

example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»

Эта запись содержит следующую информацию:

  • Версия «SPF1» (кстати, пока единственная используемая);
  • Письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com;
  • Письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28;
  • Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.

Вообще, в условии есть 2 части — определитель и механизм.

Определители могут быть: «+» (Pass), «-» (Fail), «~» (SoftFail), «?» (Neutral);

Механизмы: «all», «include», «A», «MX», «PTR», «IP4», «IP6», «exists».

Результатами проверки условий могут являться следующие определенные результаты:

  • None — означает, что-либо в домене нет записей, либо вообще не удается проверить домен;
  • Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить, разрешен ли IP. Этот результат должен обрабатываться так же, как и «None»;
  • Pass — означает, что все ОК, и получатель может принять письмо;
  • Fail — явно указывает на то, что письмо принимать не следует;
  • SoftFail — находится где-то между «Fail» и «Neutral». Принимающая сторона не должна отбрасывать письмо на основании только этого результата;
  • TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть;
  • PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.

Проблема пересылки

Достаточно часто подписчики могут переслать из своего почтового клиента ваше письмо другому получателю, в этом случае SPF не пройдет проверку и письмо придет с ошибкой в RFC-заголовках (например, «SoftFail»).

В дополнение к SPF некоторые почтовые серверы поддерживают SRS (Sender Rewriting Scheme — схема перезаписи отправителя) — механизм перезаписи адреса отправителя перенаправляемых сообщений так, чтобы они могли пройти проверку SPF. SRS помогает обеспечить доставку сообщений при использовании SPF, чтобы запись была валидной (прошла проверку легитимности).

Технология спорная. Публичные почтовые системы официально ее не поддерживают.

FeedBack Lookup (FBL) — это стандарт выдачи информации о жалобах на спам от провайдера услуг электронной почты отправителю писем.

Поддержка почтовым сервером FBL означает, что любой отправитель писем (например, веб-сервис) может получать в реальном времени информацию о том, что конкретный пользователь пожаловался (нажал кнопку «Это спам») на конкретное письмо, пришедшее от этого сервиса.

После нажатия кнопки «Спам» сервис формирует отчет в специальном формате ARF (Abuse Report Format), который содержит исходное письмо и электронный адрес пользователя; также отчет может содержать дополнительную мета-информацию.

Формат письма ARF состоит из нескольких частей:

  • Текстовая версия. Предназначена для отображения пользователю, который может читать этот отчет. Может содержать некоторую подробную информацию (о чем этот отчет и почему был сгенерирован).
  • Служебная информация об этом отчете (Content-Type: message/feedback-report). Содержит информацию о типе отчета (abuse — для отчетов по жалобам на письма), а также может содержать разного рода дополнительную информацию.
  • Исходное письмо, на которое пожаловались, в виде вложения.

Пример ARF-отчета:

From: <abusedesk@example.com>

Date: Thu, 8 Mar 2005 17:40:36 EDT

Subject: FW: Earn money

To: <abuse@example.net>

MIME-Version: 1.0

Content-Type: multipart/report; report-type=feedback-report;

boundary=part1_13d.2e68ed54_boundary

--part1_13d.2e68ed54_boundary

Content-Type: text/plain; charset=US-ASCII

Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP

10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information

about this format please see http://www.mipassoc.org/arf/.

--part1_13d.2e68ed54_boundary

Content-Type: message/feedback-report

Feedback-Type: abuse

User-Agent: SomeGenerator/1.0

Version: 0.1

Original-Mail-From: <somespammer@example.net>

Original-Rcpt-To: <user@example.com>

Received-Date: Thu, 8 Mar 2005 14:00:00 EDT

Source-IP: 10.67.41.167

Authentication-Results: mail.example.com

smtp.mail=somespammer@example.com;

spf=fail

Reported-Domain: example.net

Reported-Uri: http://example.net/earn_money.html

Reported-Uri: mailto:user@example.com

Removal-Recipient: user@example.com

--part1_13d.2e68ed54_boundary

Content-Type: message/rfc822

Content-Disposition: inline

From: <somespammer@example.net>

Received: from mailserver.example.net (mailserver.example.net

[10.67.41.167]) by example.com with ESMTP id M63d4137594e46;

Thu, 8 Mar 2005 14:00:00 -0400

To: <Undisclosed Recipients>

Subject: Earn money

MIME-Version: 1.0

Content-type: text/plain

Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net

Date: Thu, 2 Sep 2004 12:31:03 -0500

Spam Spam Spam

--part1_13d.2e68ed54_boundary--

FBL поддерживает большинство крупных мировых email-провайдеров, таких, как «Hotmail», «Yahoo» и «AOL». Для использования FBL обычно надо указать и подтвердить электронный адрес с того же домена (на него будут приходить отчеты), и подтвердить диапазон IP-адресов, с которых вы отправляете почту. В случае с «Hotmail», например, необходимо еще заключить специальный договор.

«Gmail» предоставляет FBL только проверенным (прошедшим «отбор») Сервисам рассылок. В данном случае «Gmail» считает, что этот инструмент позволяет Сервисам отследить недобросовестных клиентов, у которых доля жалоб достаточно высока.

Так, Сервисам, подключенным к программе получения FBL предлагается добавить заголовок Feedback-ID, состоящий из параметров, уникально идентифицирующих кампанию (" "). Идентификаторы с повышенной вероятностью попадания в спам и идентификаторы, из-за которых могут возникать проблемы с доставкой, будут отображаться на панели FBL в "Postmaster Tools".

Формат заголовка при этом рекомендуется такой:

Feedback-ID: a:b:c:SenderId,

где Feedback-ID – это имя внедряемого заголовка;

a, b, c – необязательные поля, в которые отправитель может вставить 3 идентификатора (название компании, клиента или другой параметр);.

SenderId – выбранный отправителем обязательный уникальный идентификатор (5–15 знаков, например, название Сервиса рассылок; должен быть одинаковым во всех письмах).

В RFC-заголовке письма в записи «List-Unsubscribe» настраивается адрес электронной почты для отправки письма-отписки или URL для быстрой отмены подписки:

List-Unsubscribe: mailto:unsubscribe@youdomain.ru

Или:

List-Unsubscribe: http://my.get-n-post.ru/list/unsubscribe/484/nza1sMUvhCCUpL82ZGP8lF5g7S0nzCXU1Uo0TpuK79A3jtms+RQm2Ym6/SaMmW/T

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

Наличие данного заголовка со стороны Сервиса рассылок — это проявление лояльности к пользователям почтовых сервисов, даже несмотря на то, что отписка через «List-Unsubscribe» у некоторых почтовиков засчитывается как жалоба на спам.

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

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

SSL поддерживает 3 типа аутентификации:

  • аутентификация обеих сторон (клиент — сервер);
  • аутентификация сервера с неаутентифицированным клиентом,
  • полная анонимность.

Открытый протокол OpenSSL:

http://ru.wikipedia.org/wiki/OpenSSL

Если домен, с которого происходит отправка рассылок, защищен SSL — это дополнительное преимущество для отправителя, повышающее доверие к корреспонденции, которая приходит от данного домена.

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

Несмотря на технические настройки, позволяющие обезопасить отправителя от подделок, а получателя от спама, злоумышленники пытаются подделывать DKIM, использовать распространенные сервисы не требующих подтверждения доменов для обеспечения валидности SPF-записи, или просто подставлять в поле «фром» ваш домен.

Cтандарты DMARC.org помогают владельцам доменов устанавливать правила, предписывающие (!) почтовым сервисам, участвующим в программе, как поступать с сообщениями, отправленными из домена соответствующего владельца, но не прошедшими аутентификацию. Это способствует борьбе c фишингом, а также помогает защитить пользователей и репутацию компаний.

Одним словом, вы сами указываете, что нужно сделать почтовой системе с письмом, если оно пришло с «битыми» техническими записями. Это очень полезный стандарт, поскольку, даже если никто не пытается отправлять почту от вашего домена, вы можете использовать DMARC как систему контроля ваших технических настроек (особенно, если для рассылок вы используете несколько Сервисов одновременно). Например, вы указали, что письма, которые не проходят проверку, должны быть отправлены в папку «Спам». В «Постмастере» вы увидели при очередной рассылке, что часть писем попадает в спам — это повод сразу же посмотреть отчеты DMARC и определить, не случились ли технические сбои на стороне вашего Сервиса (например, не проходит проверку DKIM или SPF).

Запись DMARC добавляется в TXT записи и должна иметь название: «_dmarc.vash_domen.ru», где «vash_domen.ru» необходимо заменить именем реального домена.

Примеры записей

Ниже приведены примеры записей TXT для проверки DMARC: (_dmarc.vash_domen.ru IN TXT), которые можно изменить в соответствии с потребностями. При этом не забудьте заменить строки «vash_domen.ru» и «postmaster@vash_domen.ru» реальным названием домена и адресом электронной почты.

В приведенном ниже примере записи TXT для сообщения, которое якобы исходит из вашего домена, но не проходит проверку DMARC, не выполняется никаких действий. Все такие сообщения включаются в ежедневный сводный отчет, отправляемый на адрес postmaster@vash_domen.ru:

"v=DMARC1; p=none; rua=mailto:postmaster@vash_domen.ru"

В следующем примере 5% сообщений, которые якобы исходят из вашего домена, но не проходят проверку DMARC, помещаются в карантин.

Соответствующие ежедневные сводные отчеты отправляются на адрес postmaster@vash_domen.ru.

"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@vash_domen.ru"

При такой записи все сообщения, которые якобы исходят из вашего домена, но не проходят проверку DMARC, отклоняются. Соответствующие ежедневные сводные отчеты отправляются на адреса postmaster@vash_domen.ru и dmarc@vash_domen.ru.

"v=DMARC1; p=reject; rua=mailto:postmaster@vash_domen.ru mailto:dmarc@vash_domen."

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

Полный реестр тегов DMARC:

http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags

Технические заголовки писем в разных сервисах могут иметь разное местонахождение в интерфейсе и называться по-своему:

«GMAIL» — «Показать оригинал»;

«MAIL.RU» — «Служебные заголовки»;

«YANDEX» — «Свойства письма».

На следующих трех скриншотах показано, как их найти в веб-интерфейсе:

Gmail.com
Mail.ru
Mail.Yandex.ru
Каждая почтовая система добавляет в технические заголовки собственные уникальные записи, которые обеспечивают идентификацию писем и их свойства внутри почты, но общий вид технических заголовков стандартизирован.

Умение читать технические заголовки — один из первостепенных навыков, которыми должен овладеть специалист по имейл рассылкам. В заголовках столько интересных данных, что их по праву можно назвать кладезем информации о письме в целом: от кого оно, каким сервисом разослано, какие системы отправки (МТА) и сервисы используют, какой диапазон IP-адресов используют, и где он зарегистрирован, и еще много-много интересного.
Вот полный технический заголовок письма из моего почтового ящика в сервисе «mail.ru»:

Delivered-To: x#####@mail.ru

Return-path: <postmaster@youdrive.today>

Received-SPF: pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) client-ip=213.109.77.56; envelope-from=postmaster@youdrive.today; helo=mx25.sendpulse.io;

Received: from mx25.sendpulse.io ([213.109.77.56]:40624)

by mx188.mail.ru with esmtp (envelope-from <postmaster@youdrive.today>)

id 1fCloh-0004qp-LA

for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300

Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)

by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)

(envelope-from <lab@youdrive.today>)

id 1fCloa-0000LF-8g

for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200

Content-Type: multipart/alternative;

boundary="===============9125649223522575729=="

MIME-Version: 1.0

From: =?utf-8?q?YouDrive_Lab?= <lab@youdrive.today>

Precedence: bulk

Feedback-ID: 6481889:1702492:540306:409974

List-ID: 1702492@sendpulse.io

Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=

Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)

Sender: lab@youdrive.today

X-Mailru-Msgtype: task6481889

X-Authenticated-User: ab63cdd6c739cbf7406197d84b3d159e@youdrive.today

Errors-To: postmaster@sendpulse.io

X-Complaints-To: abuse@sendpulse.io

To: x#####@mail.ru

List-Unsubscribe: <http://s540306.stat-pulse.com/unsubscribes/ru/NjQ4MTg4OQ==/bdb75dad240c2b58c5db91a6d057a13d/h/9dae6d62c816560a842268bde2cd317d>

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=youdrive.today;

i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :

To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;

b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF

E5ErKAU06Hkb5jNDE4337RUM7yLp9hPPMIddals/JXiLJKdOwACjybQpssk3D1j1j2QUe/bz

/N3rNvcwUnLLlCTIKoF1tWaGuwQ+Y=

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;

i=@sendpulse.io;

q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;

bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=;

b=RjKvm4wLcrPoxEfgLIxtfFyns3gwwekAWSeLflou7uDmiWTZLPqtxO95fJfIPtWDCOolZN

HcQU1B/pFSkQBRPMtAH1Fgl3s5DnbYei1w6aytJSkBzWaI+FFTvBTIo6S2lttptBJl7bJaJ8

nFfWOnvAOYwY/nKquzjuD+bsQOYG0=

Message-Id: <1fCloa-0000LF-8g@mx25.sendpulse.io>

X-DMARC-Policy: none

X-DMARC-Result: pass

X-Mailru-Dmarc-Auth: dmarc=pass header.from=lab@youdrive.today

X-Mras: OK

X-Spam: undefined

Authentication-Results: mxs.mail.ru; spf=pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) smtp.mailfrom=postmaster@youdrive.today smtp.helo=mx25.sendpulse.io;

dkim=pass header.d=youdrive.today;

dkim=pass header.d=sendpulse.io; dmarc=pass header.from=lab@youdrive.today

Разберем данный заголовок по частям:

Delivered-To: x#####@mail.ru

Return-path: <postmaster@youdrive.today>

Письмо доставлено на адрес x#####@mail.ru.

Если ящик, на который письмо было отправлено, принял письмо с ошибкой, или ящик не существует, то почтовая система отправит outloop-отчет на ящик, указанный в поле «Return-path». Такие отчеты в среде специалистов Сервисов рассылок называют «отлупами», с одной стороны, это калька с английского термина, с другой — четко доносит смысл: почтовик отлупил ваше письмо, идите, разбирайтесь, что с ним (или с получателем) не так.

В данном случает отправитель самостоятельно будет обрабатывать ошибки, в то время как обычно в «Return-path» находится специальный ящик Сервиса рассылок.

Received-SPF: pass (mx188.mail.ru: domain of youdrive.today designates 213.109.77.56 as permitted sender) client-ip=213.109.77.56; envelope-from=postmaster@youdrive.today; helo=mx25.sendpulse.io;

Received: from mx25.sendpulse.io ([213.109.77.56]:40624)

«SPF: pass» говорит о том, что письмо было аутентифицировано, SPF прошел проверку. В DNS домена youdrive.today прописаны необходимые записи Сервиса рассылок. В данном случае это «Sendpulse», в чем можно убедиться, если проверить IP-адрес 213.109.77.56, с которого пришло письмо.

Проверим его через «whois» — запись соответствует действительности, и данные владельца открыты, что правильно.
inetnum: 213.109.76.0 - 213.109.77.255

netname: SendPulse

organisation: ORG-SI172-RIPE

org-name: SendPulse Inc

org-type: OTHER

address: 19 Hill S Bernardsvill, NJ 07924, USA

abuse-c: ACRO2989-RIPE

mnt-ref: MNT-SENDPULSE

mnt-by: MNT-SENDPULSE

Далее:

id 1fCloh-0004qp-LA

for x####@mail.ru; Sun, 29 Apr 2018 15:52:35 +0300

Received: from [127.0.0.1] (helo=mailer02.sendpulse.io)

by sendpulse.io with esmtp (Exim 4.88_29-9c63814-XX)

(envelope-from <lab@youdrive.today>)

id 1fCloa-0000LF-8g

for x#####@mail.ru; Sun, 29 Apr 2018 14:52:28 +0200

Мы видим уникальный ID письма, по которому его можно найти в логах Сервиса рассылок, и дату/время, когда письмо было отправлено с серверов.
Precedence: bulk

Feedback-ID: 6481889:1702492:540306:409974

List-ID: 1702492@sendpulse.io

Subject: =?utf-8?b?0KPRh9GR0L3Ri9C1INC90LAg0LrQsNC90LjQutGD0LvQsNGF?=

Date: Sun, 29 Apr 2018 12:52:28 +0000 (CET)

Sender: lab@youdrive.today

X-Mailru-Msgtype: task6481889

To: x#####@mail.ru

«Presedence: bulk» говорит почтовому сервису, что письмо надо отнести к массовым рассылкам (во многих почтовиках это требование обязательно, массовость рассылки надо явно указать).

«X-Mailru-Msgtype: task6481889» специальный тег, по которому группу писем и/или письмо можно будет найти в «Постмастере.Mail.Ru» — это важно, в случае если письмо попадет в папку Спам, поскольку в этом случае отправитель не получит «отлуп» на ящик, указанный в "Return-path".

Запись «To: x#####@mail.ru» — говорит о том, кому предназначалось письмо. Важно помнить, что ящики в «To:» и в «Delivered-To:» могут отличаться, если у получателя настроена переадресация.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=youdrive.today;

i=@youdrive.today; q=dns/txt; s=sign; t=1525006348; h=Subject : From :

To; bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=; b=Y2mcnCeafYBQmAo+vh3Ngxe77IZWr3Pd+39No0AdO+9kCGN+AmkZtrp7GiE+HJQUlSVqlF.........

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendpulse.io;

i=@sendpulse.io;

q=dns/txt; s=sign; t=1525006348; h=Subject : From : To;

bh=58M7Vv5E9jF+R+0H1HpRrcOAXVTuez9xckKy2h2QFk4=........

Далее следуют записи ключей DKIM отправителя и Сервиса рассылок.

Не так давно почтовые сервисы стали поддерживать множественные записи DKIM в заголовках и правильно их обрабатывать. Множественная запись дает преимущество — и отправитель рассылки, и Сервис, который фактически отправку сделал, могут видеть результаты доставки в «Постмастере». Более того, почтовый сервис отслеживает, кто именно (фактически) производит отправки тех или иных рассылок, и может помочь Сервису решить некоторые проблемы в случае возникновения проблем с доставкой.

Записи

dkim=pass header.d=youdrive.today;

dkim=pass header.d=sendpulse.io

говорят, что оба DKIM валидные.

Но, очевидно, есть, что улучшить в письме

X-DMARC-Policy: none

X-DMARC-Result: pass

X-Mailru-Dmarc-Auth: dmarc=pass

Запись DMARC в DNS отправителя присутствует и валидная, но она прописана с ключом «none» — не предпринимать никаких действий. Это говорит о том, что в случае, если злоумышленник попробует подделать письма от домена отправителя, какая-то часть (в зависимости от репутации доменов) может попасть в инбокс получателям.

Рекомендуется прописывать политики DMARC как «quarantine» или «reject».

Какие проблемы можно обнаружить в заголовках

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

• IP-адрес в Black-листе (dnsbl.info), как рассылающий спам
X-DMARC-Policy: no
X-Mailru-Noreply: yes
X-Mras: OK X-Spam: undefined
X-UBL: Black


• Проблема с DKIM записью
X-DKIM-FAIL: DKIM test failed: invalid (address=sender@get-n-post.ru domain=v####o.su reason=pubkey_syntax).
X-DMARC-Result: fail X-Mailru-Dmarc-Auth: dmarc=fail header.from=ad@v####o.su
X-Mras: OK
X-Spam: undefined
Authentication-Results: mxs.mail.ru; spf=pass (mx178.mail.ru: domain of get-n-post.ru designates 212.24.39.198 as permitted sender) smtp.mailfrom=sender@get-n-post.ru smtp.helo=out5.get-n-post.ru;
dkim=pass header.d=get-n-post.ru;
dkim=invalid reason=pubkey_syntax header.d=v####o.su; dmarc=fail header.from=ad@v###o.su


• Публичный ключ в DNS домене отправителя записан с ошибкой.

• Срабатывание или ошибка DMARC
В этом случае технические настройки в письме неверны, DMARC не прошел аутентификацию, и почтовая система отправила письмо в папку «Спам», как подозрительное.
X-DMARC-Result: fail
X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419 X-Mailru-Dmarc-Auth: dmarc=fail header.from=ras###@email2.#####ir.ru
X-Mras: PROBABLE_SPAM
X-Spam: undefined

Кстати, так сказать, «хозяйке на заметку» строка «X-Magic: D7426F4F725623B9A9F6DBBE852452D0140F2EFE3225FE7459A0A3EE30C7B419» очень пригодится вам, если ваши письма стали попадать в папку «Спам» в сервисе «Mail.ru». Именно это значение попросит вас предоставить Служба поддержки при обращении. По данному идентификатору они смогут проследить историю и причины.

• Проблема с SPF

Received-SPF: fail (mx144.mail.ru: domain of r####a.su does not designate 000.88.00.100 as permitted sender) client-ip=000.88.00.100; envelope-from=hello@r####a.su; helo=forward100p.mail.yandex.net; Received: from forward100p.mail.yandex.net ([000.88.00.100]:46112)
В данном случае письмо отправлено с IP-адреса 000.88.00.100, который не прописан в DNS домена r####a.su.
Глава 4. Административные требования почтовых сервисов (ISP — inbox service provider)
В целом административные требования всех почтовых сервисов (ISP) очень схожи — ISP стараются придерживаться единого мнения, какими должны быть массовые рассылки, чтобы почтовые фильтры не считали их спамом.
Из практики я знаю, что при возникновении проблем с доставкой («Все пропало! Все в спаме!») спрашиваешь у отправителя, придерживался ли он требований к рассылкам, и обычно начинаются возмущенные вопросы: — А что, они еще что-то требуют? На каком основании? Это мои клиенты! Мы не нарушали закон, а, значит, и требовать с нас что-то отдельно никто не имеет права! И так далее.
Я всегда вспоминаю, что в юном возрасте в каком-то из журналов я прочитал о системе стандартизации производства в Японии. Надо отметить, что на тот момент в СССР существовала система государственного стандарта (ГОСТ) и предприятия должны были «дотянуть» качество своей продукции до ГОСТа (впоследствии хотя бы придерживаться ТУ — технических условий). Так вот, в Японии, как гласила статья, государственные стандарты тоже существовали, но как нижняя планка вывода продукта на рынок, и в каждой компании стандарты были существенно выше и более требовательные, нежели государственные. Возьмем за правило, что почтовый сервис — это отдельное государство, зачастую с огромной численностью «граждан» — пользователей сервиса. Почтовый сервис заботится о своих пользователях как о «священной корове» и предпринимает все попытки их обезопасить, сохранить, приумножить и сделать счастливыми. Поэтому правила и требования почтовых сервисов куда более жесткие, нежели статьи закона. Как я говорил, требования достаточно схожие, поэтому рассмотрим основные из них на примере почтового сервиса «Mail.ru».
  • Рассылка должна осуществляться исключительно по явному и прямому требованию или согласию получателя (opt-in);
  • Все рассылки, отправляемые по подписке, должны иметь в тексте каждого сообщения валидную неэлектронную контактную информацию об организации, осуществляющей рассылку, включая телефонный номер и физический адрес;
  • Массовые рассылки должны иметь простой и очевидный механизм отписки. Процесс отписки не должен требовать от пользователя сложных действий, таких как ввод или восстановление пароля, регистрация и т.п. Мы рекомендуем в качестве механизма отписки добавлять в каждое письмо хорошо заметную ссылку с возможностью отписаться одним переходом по ней. Пользователи не должны авторизовываться на сайте, чтобы отписаться от рассылки;
  • Рассыльщики не должны осуществлять действий по сокрытию, подделке или искажению отправителя сообщения и источника отправки;
  • Информация о подписке, включая то, как был получен электронный адрес получателя, дата и время подписки, а также IP-адрес, откуда пользователь осуществил подписку, должны быть доступны по запросу пользователя;
  • В рассылках должна быть указана информация о том, откуда был взят адрес пользователя и его согласие на получение рассылки. Например, «Вы получили это письмо, потому что подписались на рассылку на нашем сайте …»;
  • Сервисы, осуществляющие рассылки на основе подписки, должны безусловно удалять из базы подписчиков или принимать меры по приостановке рассылок на адреса, которые генерируют ошибку протокола "SMTP: 550 user not found" (отслеживание валидности базы получателей — необходимое условие для поддержания положительной репутации рассыльщика).
Некоторые различия, которые присущи разным почтовым системам, заключаются в следующем: Все почтовые системы сообщают о невалидных адресах посредством «отлупов» на ящик, указанный в поле «Return-path», однако, если вы не обрабатываете отчеты своего ESP, то получить список невалидных адресов вряд ли сможете. В свое время только «postoffice.yandex.ru» давал возможность выгрузить списки несуществующих адресов. Напротив, в прямом виде получить адреса тех, кто пожаловался на рассылку, вы сможете только в «Mail.ru», указав в «Postmaster.Mail.ru» ящик в вашем домене, куда их надо присылать. В других почтовых сервисах вы сможете получить эти адреса только через отчеты вашего ESP (кстати, в «GMAIL» только в том случае, если сам Сервис допущен к FBL программе «GOOGLE»).
Получатели в явной форме выразили свое желание в получении информации до начала рассылки Убедитесь, что вы отправляете письма пользователям, которые в однозначной форме выразили согласие их получать:

• вручную установив галочку «Подписаться на рассылку...» в форме регистрации или подписки (настоятельно не рекомендуется ставить галочку подписки по умолчанию);
• отправив по e-mail сообщение с запросом на подписку на специальный адрес;
• кликнув на ссылку подтверждения подписки в письме.

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

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

В рассуждениях о том, нужен DOI или нет, сломано столько копий в дискуссиях в профессиональных сообществах и прочая, что, даже отстояв свое мнение о необходимости DOI, я часто сталкиваюсь с тем, что клиент продолжает твердить «упадет конверсия», «как они могут проверить», «все это ерунда вот "Мейлчимп" отказался…».

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

• DOI не только дает вам подтвержденное согласие на рассылку, но и проверяет оставленный ящик на валидность (это важно);
• Если у вас нет DOI, вероятность попадания почтовых ловушек в ваш список равна примерно 100%;
• Надо быть очень наивным, чтобы предполагать, что внутри одной почтовой системы сотрудники не могут отследить, было ли от вас письмо DOI до того, как вы отправили коммерческую рассылку (и какая была реакция пользователя на него — переходил он по ссылке или нет);
• DOI спасает вас от жалоб (это правда), поскольку человек менее охотно жалуется на спам, если давал согласие на рассылку, он скорее отпишется в случае чего;
• При возникновении проблем с доставкой первый вопрос, который вам зададут в Службе поддержки — «Есть ли DOI?» — если нет, то скорее всего — «До свидания!».
Важно! Помимо получения двойного согласия нужно сохранить всю существенную информацию о пользователе в момент, когда он оставил вам адрес почты и когда подтвердил свое согласие, а именно:

• Дату и время;
• IP-адреса, с которых происходили эти события;
• URL, где пользователь оставил адрес;
• Ссылку, которая была в письме-подтверждении.
Используйте аутентификацию на технологии Domain Keys Identified Mail (DKIM). Этот механизм может обеспечить вам непротиворечивую репутацию в рамках вашего домена, без привязки к IP-адресам, с которых вы производите рассылку.

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

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

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

С прискорбием нужно отметить, что существуют умники, которые до сих пор считают, что, если подписчик нажал на ссылку «Отписаться», он будет рад получить еще одно-два-три письма от вас.

Хочу огорчить всех, кто так считает — НЕТ!

В следующий раз он нажмет на кнопку «Спам», даже несмотря на то, что давал вам согласие на рассылку. Поэтому уловки прошлого века, типа — «Мы вас отписали, но вы получите еще 3 письма, потому что они уже в очереди, и мы не можем вас оттуда удалить» — надо искоренить сразу и на корню!

Еще одна пагубная практика — требовать авторизации для отписки и/или заполнения перед отпиской огромных форм с объяснениями «почему вы отписываетесь». Вишенка на торте — это когда я заполнил форму, а мне показывают страницу: «Ой, у нас произошел сбой, и что-то пошло не так, мы не можем вас сейчас отписать» — для таких отдельный котел уже разогрет до приличной температуры. Но иногда отписка на стороне Сервиса рассылок бывает максимально честная: помню форму, где, после перехода по ссылке, было написано: «Мы отписали вас от рассылки, и вы большее ее не получите, но ответьте на один вопрос — почему?». И там был выпадающий список причин, где среди прочего была строка «Я на эту х@#ню не подписывался!». Как говорится, аплодирую стоя!

В каждом письме из рассылки рекомендуется использовать служебный заголовок «List-Unsubscribe», позволяющий мгновенно отписаться от рассылки. Процесс отписки должен завершаться сразу же после перехода по указанному в нем URL или получению письма на указанный в нем адрес. В этом случае от пользователя не должно требоваться дополнительных действий.
Многие рассыльщики блокируются именно из-за жалоб пользователей на спам, вследствие того, что пользователям трудно отписаться и удалиться из списка получателей рассылки, и поэтому они сообщают о спаме.

Рекомендуется сохранять всю информацию о том, когда пользователь подписался на рассылку (IPадрес; время и дату осуществления подписки; браузер и пр.) — это поможет вам в спорных ситуациях доказать, что ваши действия были правомерными, и вы не рассылали письма без согласия на то пользователя.
Большое количество некорректных получателей вредят вашей репутации. Вы можете сократить количество таких получателей в вашей рассылке, если будете использовать двойную (подтвержденную) процедуру подписки на рассылку. Даже если в вашем листе будет несколько невалидных адресов, ваша репутация не испортится.

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

Наличие в рассылках более 5% невалидных адресов может привести к попаданию писем, отправленных с вашего домена, в папку «Спам» или даже к полной их блокировке.
Обозначьте ваше письмо так, чтобы пользователь не ошибся и случайно не принял ваше письмо за спам. Убедитесь, что поле «От кого» явным образом указывает, от кого получено это письмо, и пользователь не спутает вас ни с кем другим — используйте свой домен в адресе отправителя. Включите название вашей компании или же бренда в тему письма. Даже если пользователи соглашались на получение вашего письма, они могут с первого взгляда не определить его происхождение. Тема письма вида «Наша ежедневная рассылка от Фирмы» или «Ваше ежемесячное обновление `Название продукта`» помогут пользователям сразу узнать ваше письмо.

Даже если у вас предусмотрена двойная (подтвержденная) подписка на рассылку (confirmed opt-in), пользователи могут не узнать рассылку, на которую они подписывались с темой, например, «Купи две, получи третью БЕСПЛАТНО!», и сообщить о спаме.
Не рассылайте массовые (рекламные) письма с того же IP-адреса, что вы используете для обычной или деловой переписки, сообщений с важной (технической или финансовой) информацией и пр. Разделяя ваши IP-адреса для того или иного типа задач, вы способствуете тому, чтобы ваши письма доставлялись надежным образом до адресатов.
В целях защиты от спама почтовый провайдер рассматривает новых отправителей (компании, отправляющие письма с ранее неизвестного IP-адреса или домена) как подозрительных. У них нет репутации, провайдер не знает о реакции пользователей на их рассылки. Поэтому хорошей практикой при вводе в эксплуатацию нового домена или IP является их прогрев.

Прогрев — это постепенное увеличение объема писем, отправляемых с IP/домена с целью формирования хорошей репутации отправителя. Не существует готовой формулы для прогрева нового домена или IP-адреса отправителя. Скорость наращивания объемов может зависеть от того, насколько давно вы собираете и используете базу подписчиков, от активности и лояльности получателей и многих других факторов. Например, если ваша текущая репутация оставляет желать лучшего, то смена или добавление IP/домена лишь усугубит ситуацию. Также не рекомендуется одновременно менять IP и домен при наличии такой возможности.
Репутация — это интегрированный показатель «добросовестности» рассыльщика, рассчитываемый в «Mail.ru» на основании большого количества факторов, основные из которых — это количество жалоб на спам, количество несуществующих адресов, количество попаданий писем отправителя в ящики-ловушки и других.

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

Репутация используется фильтрами для вынесения решения о том, является ли письмо спамом или нет. В случае плохой репутации ваши рассылки могут быть целиком или частично заблокированы или приходить пользователям в папку «Спам».

Значения количества жалоб, которые не следует превышать (меньшие значения — лучше):
Жалобы пользователей, отправка на несуществующие адреса получателей (в том числе, на существовавшие ранее, но удаленные), невозможность получения отправителем отчетов о недоставке, попадание сообщений в спам-ловушки «Mail.ru» влияют на репутацию отправителя. Для любого отправителя с негативной репутацией доставка сообщений на «Mail.ru» может быть заблокирована. Серия нарушений от одного автора рассыльщика может привести к частичному или полному блокированию его IP-адресов в «Mail.ru».
Как было сказано выше, одним из обязательных требований проведения легальных массовых рассылок является наличие в базе DOI (Double Opt-In). Конечно, на стороне почтовых систем (ISP) нет возможности точно проверить его наличие в каждой базе, по которой идет рассылка в автоматическом режиме. Поэтому «на вооружении» ISP есть ящики-роботы, так называемые спамловушки (trap mail). Внешне они ничем не отличаются от обычного адреса человека, но функционируют по определенным алгоритмам и анализируют всю входящую почту. С такого ящика невозможно получить подтверждение подписки (DOI), поэтому в случае если на ящик-ловушку приходит коммерческая рассылка, это сигнал для антиспам служб ISP, что в данной базе (во всей или ее части) нет DOI.

К таким рассылкам обычно применяются санкции вплоть до полной блокировки доставки почты в почтовые ящики ISP.

Ловушки бываю двух видов:
  • Специально созданные;
  • Преобразованные.
Преобразованные ящики-ловушки — это заброшенные пользователями адреса электронной почты, которые не пользовались ими на протяжении значительного промежутка времени (более года), и они были заблокированы ISP, и со стороны пользователя не были зафиксированы попытки восстановления доступа.

Конечно, когда-то бывшие владельцы ящиков (которые впоследствии были преобразованы в ловушки) могли давать свое согласие на получение рассылок. Но если, несмотря на большой период бездействия ящика, в него продолжают поступать коммерческие рассылки, это сигнал для ISP, что данные авторы рассылок не ведут должные работы со своей базой и не занимаются ее гигиеной. Вероятно, для таких рассылок тоже будут применены санкции, скорее всего, они будут приходить в папку «Спам».

Это одна из самых трудных для вычисления проблем с доставкой тем. Если в содержании письма можно достаточно быстро найти артефакты (типа заблокированных ссылок), то «чисто» в оформлении письма найти причину очень и очень трудно.

При использовании HTML в ваших сообщениях убедитесь, что соблюдена валидная структура HTMLдокумента. Запрещено использовать потенциально опасные объекты, такие как ActiveX, JavaScript, VBScript, Java-апплеты, Frames и IFrames, подключаемые с внешних сайтов CSS, Meta Refresh и т.п. (использование таких элементов может привести к блокировке ваших рассылок).

С точки зрения почтовой системы все просто — внутри интерфейса почты есть место, куда вставляется html вашего письма. Вы хотите, чтобы оно было красивым (интерактивным / самым запоминающимся / оформленным с использованием последних достижений науки и техники), а почтовая система хочет, чтобы не развалилась страница, куда вставлен код, чтобы не были заблокированы элементы интерфейса, чтобы верстку не «разорвало», чтобы пользователь не «поделился» со злоумышленниками своими данными и так далее.

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

Попытка использовать сторонние сервисы (редиректоры, «укоротители ссылок») для сокрытия информации о настоящей целевой странице любой из веб-ссылок в письме могут привести к тому, что рассылка будет заблокирована.

У меня был случай из практики: большой отправитель, не имеющий проблем с доставкой, но имеющий приложения для iOS и Android и дизайнера с чувством прекрасного внутри кода, решил, что ссылки в письме на AppStore и Google Play на собственные приложения не очень красивые, и завернул их в укорачиватель. Надо понимать простую механику — в укорачиватели ссылки заворачивают сто процентов спамеров из ста. Делается это для того, чтобы скрыть истинное назначение перехода из письма (на какой-нибудь заблоченный ресурс, или цепь спам-редиректов). Когда получатели видят спам-письмо, они обычно жалуются. Фильтры почтовых систем анализируют письма, на которые поступают жалобы и содержание этих писем, в том числе и ссылки. Всем понятно, что известные домены-укорачиватели — рекордсмены по количеству ссылок в письмах, на которые жалуются.

Клиент с чувством прекрасного в коде обнаружил, что с «сего дня» все его письма идут прямиком в папку «Спам» и причина неочевидна (хотя вот она, на поверхности).

Недопустимо использование в письмах в качестве ссылок IP-адресов и доменных имен в кодировке URL-encode.



Глава 5. Коды возвращаемых ошибок
Спросите любого антиспам-специалиста любого Сервиса рассылок, и он вам скажет, что «Отлупы» — наше все! Никто больше не расскажет нам в автоматическом режиме о проблемах, чем возвращаемые почтовыми серверами ошибки доставки.

Спросите любого антиспам-специалиста любого Сервиса рассылок, и он вам скажет, что «Отлупы» — наше все! Никто больше не расскажет нам в автоматическом режиме о проблемах, чем возвращаемые почтовыми серверами ошибки доставки.

Самые часто встречающиеся коды ошибок:
Стоит иметь в виду, что все коды, начинающиеся на 4** или 5**, говорят о том, что ваше письмо не доставлено адресату.

Если ответ состоит из нескольких строк, то каждая из них начинается числовым кодом. Помимо числовых кодов каждая строчка содержит дополнительные разъяснения для более точной интерпретации ошибки.

  • Пользователь не найден (ящик не существует): host mxs.Mail.ru [94.100.180.150]: 550 Message was not accepted -- invalid mailbox. Local mailbox fhnnbff@Mail.ru is unavailable: user not found
  • Письмо отвергнуто как спам почтовыми фильтрами: host mxs.Mail.ru [94.100.180.150]: 550 spam message rejected. Please visit http://help.Mail.ru/notspam-support/id?c=KjnbOllQA~ or report details to abuse@corp.Mail.ru. Error code: 3ADB392ABA035059ABCEC6DEE1971AF2DB14FE14
  • Письмо отвергнуто антиспам фильтрами (по содержанию): host mxs.Mail.ru [217.69.139.150]: 550 spam message discarded. Please visit http://help.Mail.ru/notspam-support/id?c=TYUG7ZSh8cdd_eqMHU65HtH32V….~~ or report details to abuse@corp.Mail.ru. Error code: ED06854DC7F1A1948CEAFD5D1EB94E1D58D9F7D129AE90A486.

Дополнительные сведения о кодах ошибок SMTP: http://help.raspadskaya.com/mail/bad_smtp/Pages/default.aspx

host mx.example.ru [93.158.134.89]: 552 5.2.2 Mailbox size limit exceeded 1485862577- fqepEeOBU9-aH9qo6Kf
Обычно почтовый ящик неограничен, но из этого правила бывают исключения для неактивных пользователей, которые не осуществляют входы через веб-, мобильную версию почты или IMAP/POP3-протоколы в почтовый ящик на протяжении более 3 месяцев.

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

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

Рекомендую воспользоваться сервисами проверки почтовых настроек:

- http://www.allaboutspam.com/email-server-test/

Отправляем любое письмо на адрес test@allaboutspam.com и через несколько минут получаем «отлуп», в котором будет ссылка, перейдя по которой получим результаты теста.

- Или http://www.brandonchecketts.com/emailtest.php

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

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

Проверка на присутствие домена и/или IP-адресов в black-листах

http://mxtoolbox.com/blacklists.aspx

http://whatismyipaddress.com/blacklist-check

http://www.dnsbl.info

http://www.barracudacentral.org/rbl

http://www.spamcop.net

http://www.spamhaus.org

Проверка писем на корректность верстки, отображение в почтовых клиентах, а также на чувствительность спам-фильтров

https://www.emailonacid.com

https://litmus.com

http://www.mail-tester.com

Сервисы проверки списков подписчиков

http://www.briteverify.com

http://xverify.com

http://www.datavalidation.com

https://www.emailready.com

http://bounceless.io

https://mailvalidator.ru

Почти все сервисы проверки баз подписчиков работают по принципу проверки списка по существующим (в распоряжении сервиса) стоп-листам адресов, чья почтовая история уже известна (невалидный, возвращает ошибку доставки, жалуется и т.д.), а также просто пингуют без отправки письма smtp-зону принимающего домена. Зачастую качество таких проверок оставляет желать лучшего — многие почтовые домены просто отвечают всегда «ОК» на попытку запроса возможности доставки письма на ящик в домене, или можно попасть на так называемые «всеядные домены» (Catchual domain), которые принимают письма вне зависимости от того, что стоит перед @. И только после фактической отправки возвращают ошибку, а, значит, вы получите массу невалидов после того, как сервис проверки выдаст вам список «хороших» имейлов.
Рассмотрим процессы регистрации и проверки базы в самых популярных сервисах.

www.briteverify.com

Шаг 1. Заполните форму регистрации

Для регистрации в сервисе Вам надо указать:

- Full Name — ФИО

- Email Address — адрес электронной почты

- Password — пароль. Пароль должен: состоять не менее чем из 8-ми символов, иметь в своем составе как минимум 1 заглавную букву, 1 спецсимвол, 1 цифру, 1 строчную букву.

Шаг 2. Подтвердите личность.

Для подтверждения личности Вам потребуется аккаунт linkedin или, как альтернативу (для тех, кто не имеет доступа к этой сети) Вам предложат пообщаться в чате со службой поддержки. Внимание! Общение идет на английском языке.

www.xverify.com

Шаг 1. Заполните форму регистрации.
Данные для регистрации:

- First & Last Name — ФИО

- Company Name — Название компании

- Email Address — адрес электронной почты

- Phone Number — действующий номер телефона

- Username — логин

- Password — Пароль. Пароль должен состоять не менее чем из 6 символов и содержать не менее 1 буквы, 1 цифры и 1 спецзнака.

Вам предложат на выбор несколько сервисов:

- Email Verification

- Phone Verification

- Address Verification

- Phone Confirm

Шаг 2. Заполните данные вашей кредитной карты.
www.datavalidation.com
Шаг 1. Укажите адрес электронной почты.
Шаг 2. Заполните форму или авторизуйтесь с использованием аккаунтов hubspot, mailup или mailchimp
Шаг 3. Подтвердите регистрацию, перейдя по ссылке в письме.
Шаг 4. Укажите пароль.
Шаг 5. Загрузите базу для проверки.
Загрузка доступна с компьютера, Evernote, Google Drive, по URL или FTP.
Шаг 6. Дождитесь проверки списка. Список около 5 000 проверялся 20-25 минут.
www.emailready.com
Шаг 1. Заполните форму регистрации.

- Full Name — ФИО

- Email Address — адрес электронной почты

- Company/Business/Trading Name — Название компании

- Mobile Number — существующий номер телефона в международном формате

- How many verifications per month? — Укажите, какое количество адресов в месяц вы планируете проверять.
Шаг 2. Дождитесь звонка от представителя компании. Внимание! Общение происходит на английском языке.
www.bounceless.io
www.bounceless.io

Шаг 1. Заполните форму регистрации.

- Full Name — ФИО

- Email — адрес электронной почты

- Password — Пароль
Шаг 2. Загрузите базу.
Загрузка доступна с компьютера, Evernote, Google Drive, по URL, FTP или Amazon Cloud Drive.
Шаг 3. Закажите проверку базы «Start Verifying».
Итог:
www.mailvalidator.ru
Шаг 1. Заполните форму регистрации.
Шаг 2. Укажите номер телефона и подтвердите его, введя код из СМС.
Шаг 3. Дождитесь письма на адрес, указанный при регистрации и подтвердите регистрацию, перейдя по ссылке из письма.
Шаг 4. Нажмите на кнопку «Загрузить список».
Шаг 5. Загрузите базу. Размер базы должен быть не менее 150 адресов.
Шаг 6. Дождитесь полной проверки базы.
«Mailvalidator.ru» — единственный сервис, который независимо от сайта полноценно работает через мессенджер («Телеграм») и поддерживает все функции от регистрации, проверки, оплаты до получения развернутой статистики и некоторых дополнительных функций для аналитики данных.

Телеграм-бот Сервиса доступен по адресу

http://t.me/mailvalidator_bot

или

@mailvalidator_bot,

если вы уже находитесь в «Телеграм».

Шаг 1. Нажмите кнопку «Start».

Шаг 2. Выберите действие. Для регистрации в сервисе «/register».
Шаг 3. Укажите адрес электронной почты.
Шаг 4. Укажите номер телефона.
Шаг 5. Подтвердите номер телефона.
Присланный логин и пароль вы можете использовать в т.ч. и в веб версии сервиса.
Шаг 6. Для проверки базы введите команду «/check_db».
Шаг 7. Для загрузки базы используйте кнопку «Send file».
Шаг 8. Дождитесь проверки базы.
Итог:
Глава 7.
Сервисы контроля доставки рассылок
Для подключения ко всем Постмастерам необходимо быть авторизованным в почте (в соответствии с выбранным сервисом). Далее необходимо добавить домен, который необходимо отслеживать. После этого домен надо будет подтвердить одним из двух или трех способов: HTML-файл в корне вашего сайта, meta-тег в заголовке страницы index или DNS-проверка (в том числе CNAME-запись). При успешной проверке прав статистика по данному домену станет доступна.

Статистика в большинстве Постмастеров будет отображаться только в том случае, если в DNS домена прописан валидный ключ DKIM.

Postmaster.Mail.ru

Подключение к Сервису

Шаг 1. Укажите домен.

Шаг 2. Подтвердите домен одним из предложенных способов.
Для подтверждения прав на управление доменом нужно выполнить одно из трех действий:

- Разместить HTML-файл

· Создайте HTML-файл с именем mailru-verification6d779e6def0d52e9.html и содержимым mailru-verification: 6d779e6def0d52e9

· Загрузите его в корневой каталог вашего веб-сервера

· Убедитесь, что загруженный файл открывается по адресу http://neskuchniyspam.ru/mailru-verification6d779e6def0d52e9.html

· Нажмите кнопку «Подтвердить».

- Мета-теги

· Добавьте в раздел header главной страницы вашего сайта следующий код:

<meta name="mailru-verification" content="6d779e6def0d52e9" />

· Нажмите кнопку «Подтвердить».

- DNS-проверка

Обратите внимание, что использовать данный метод стоит только в том случае, если вы уверены в том, что делаете

· Для добавления TXT-записи вы должны иметь доступ к редактированию DNS-записей домена. Обычно это делается через веб-интерфейс хостинг-провайдера или регистратора доменного имени.

· Добавьте DNS-запись со следующими значениями:

· Имя домена/поддомена: @

· Тип записи: TXT

· Значение (все, выделенное жирным): mailru-verification: 6d779e6def0d52e9

· Нажмите кнопку «Подтвердить».

· Иногда интерфейс управления DNS не позволяет использовать символ @ как имя домена/поддомена. В этом случае используйте имя вашего домена с точкой на конце, например: "neskuchniyspam.ru.".

«Постмастер.Mail.ru» предоставляет доступ к статистике рассылок, группируя ее по дням, неделям или месяцам.

Среди предлагаемых параметров:

Письма — количество отправленных писем;

Жалоб — количество нажатий на кнопку «Спам»;

Репутация, % — средний процент жалоб за 30 дней. Она рассчитывается как отношение количества жалоб за 30 дней к общему количеству отправок за этот промежуток времени и выражается в процентах;

Тенденция, % — изменение процента жалоб за 7 дней по отношению к проценту за 30 дней;

Прочит. — количество открытых писем;

Удал. прочит. — количество писем, удаленных после прочтения;

Удал. непрочит. — количество писем, удаленных до прочтения;

Доставлено, % — процентное соотношение следующих типов писем;

Доставлено — количество писем, доставленных в папку «Входящие»;

Возможно, спам — количество писем, доставленных в папку «Спам»;

Точно спам — количество писем, которые не были приняты серверами «Mail.ru». В ответ на такие письма всегда приходит письмо с ошибкой «550 spam message discarded».

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

Помимо группировки по дням, есть возможность увидеть общую статистику по отдельным сообщениям. Сделать это можно на вкладке «Письма». Статистика по отдельным письмам предоставляется только в том случае, если в заголовках отправляемых писем прописан тег «X-Postmaster-Msgtype: reg864177842702997», где «reg864177842702997» — произвольный код внутри вашей системы рассылок.

«Постмастер.Mail.ru» поддерживает технологию FeedBack Loop. Для подключения FBL необходимо указать email-адрес, на который начнут приходить отчеты (адрес должен быть в домене, который привязан к постмастеру и с которого идут отправки). Сделать это можно на странице настроек. Ящик для получения FBL должен быть в том же домене, с которого происходят отправки.

Postoffice.Yandex.ru

Подключение к сервису:

Шаг 1. Введите имя домена.

Шаг 2. Подтвердите домен.
Подтвердите владение доменом:

- Загрузите в корневой каталог вашего сайта файл с именем yandex_9a484c4747880cf3.html. Файл должен содержать следующее:

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

</head>

<body>Verification: 9a484c4747880cf3</body>

</html>

- Дождитесь, пожалуйста, результатов проверки.

Для настройки FBL необходимо указывать только пул IP-адресов, с которых отправляются рассылки, на ящик для FBL жалоб «Yandex.ru» ничего не отправляет.

«Постофис» предоставляет доступ к подробной статистике рассылок.

На странице статистики домена группировка идет по темам сообщений с сортировкой в хронологическом порядке (в отличие от вкладки «Тема», на которой письма отсортированы по алфавиту).

По нажатию на письмо открывается подробная статистика в виде графика.

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

Также можно скачать всю статистику по письму в виде pdf-файла с большим количеством различных графиков. У «Постофиса.Yandex» есть API. С помощью него можно автоматизировать выгрузку отчетов по рассылкам.

Postmaster.Google.com

Подключение к сервису:

Шаг 1. Укажите домен.

Шаг 2. Подтвердите домен.
Добавьте запись TXT в конфигурацию DNS для neskuchniyspam.ru.

Запись TXT:

google-site-verification=7201KT_3wuIkNYfNmHk1z4Zh8yHIHrsB7NPArodkMrw

«Постмастер.Gmail» позволяет получить менее подробную информацию о ваших рассылках. Среди доступного:

- доля попадания в спам;

- репутация IP и домена;

- информация об аутентификации (прохождении проверок DKIM, SPF и DMARC);

- информация о шифровании трафика (доля TLS);

- информация о сбоях доставки;

- также доступен механизм FBL.

Все отчеты в «Постмастере.Gmail» формируются в виде графиков и таблиц с выборкой данных за промежуток от 7 до 120 дней.

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

«Постмастер.Gmail» — не самый удобный инструмент для анализа рассылок, однако наглядно показывает динамику репутации домена и IP и статистику по прохождению SPF, DKIM и DMARC.
Если ваши рассылки отправляются на большое количество зарубежных адресов, то вам стоит узнать о следующих сервисах, предоставляемых наиболее популярными инструментами для работы в зарубежном сегменте:

AOL – http://postmaster.info.aol.com/

ATT – http://www.att.com/esupport/postmaster/

BellSouth – http://www.att.com/esupport/postmaster/

Charter – http://www.charter.com/customers/support.aspx

Comcast – http://postmaster.comcast.net/

Cox – http://postmaster.cox.net/

Facebook – http://postmaster.facebook.com/

Frontier – http://postmaster.frontier.net/

Gmail – https://mail.google.com/support/bin/answer.py

Hotmail – http://postmaster.msn.com/

RoadRunner – http://postmaster.rr.com/

United Online – http://unitedonline.net/postmaster/

USA.NET – http://postmaster.usa.net/

Yahoo! – http://postmaster.yahoo.com/

Вместо послесловия
Разногласия в книге, которых на самом деле нет

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

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

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

Мир изменчив

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

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

Книга не лишена недостатков, но представляет собой некую структуру для осмысления проблемы доставки рассылок и подхода «куда копать», если возникают проблемы.

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

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

Но некоторые бесплатные почтовые сервисы все же были.

Однажды мне нужно было зайти на сайт американского Белого дома, но вместо государственного домена .gov, я набрал whitehouse.com — это оказался сайт с отменным таким порно-контентом!

Помимо прочего всем желающим предлагалось зарегистрировать там адрес электронной почты. Это был год, когда всем известный скандал вокруг Клинтона и Моники Левински уже утих, но обе персоны были у всех на слуху.

Удивительно, но адрес Monica.Lewinsky@whitehouse.com был свободен :)

С этим надо было что-то делать. Мы работали в редакции одного очень крупного Издательского дома, и редакция была довольно веселая. Учитывая, что мы делали множество переводных изданий и плотно общались с другими Издательскими домами, в том числе и американскими, мы придумали «Международный конгресс Книгоиздателей, проходящий под эгидой Правительства США непосредственно в Белом доме». Мы написали чудесное письмо-приглашение, один из лучших переводчиков перевел его на американский английский, и мы со свежезарегистрированного ящика отправили его нашему издателю Григорию. Но подписали это замечательное деловое письмо «Lovely Monica».

Григорий на подсознании почувствовал подвох, но собрал технических специалистов для расследования. В те времена смотреть технические заголовки письма была работа Системного Администратора!

Системный администратор Филипп долго исследовал заголовки и вынес заключение — письмо подлинное, пришло из Америки, домен Whitehouse, все так. Издатель распечатал письмо (а мы его сделали с логотипом администрации Президента США, на бланке, все, как полагается) и стал собираться в дорогу…

Интернет тогда был драгоценностью, около сотни сотрудников редакции были подключены к сети через один модем 48 Кбит/сек, картинки в браузерах были отключены по умолчанию, поэтому никому даже в голову не пришло зайти на сайт и посмотреть, что там, и чем содержание сайта в домене .gov отличается от того, что показывают в домене .com.

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

Сегодня все «топят» за технологическую составляющую бизнеса, в том числе и рассылочного: автоматизация, автоворонки, искусственный интеллект и прочая. Технологии в бизнесе стали решать многое настолько, что люди перестали контролировать, что там «нарешали технологии», даже прочитать (посмотреть) рассылку перед выпуском у маркетолога нет времени/желания/возможности. Мы это проходили без малого лет 15 назад.

Самым первым сервисом рассылок был «Томкотик». Позднее он был переименован в «Городского кота», который стал родоначальником Сервиса «Subscribe». «Городской кот» производил полезный контент в нескольких рубриках, на которые подписывались люди. Одним из видов подписок была (и остается по сей день) телепрограмма.

В те давние времена не существовало сторонних API и сервисов, где можно было бы на партнерских условиях получать контент из первых рук в удобной форме, поэтому технологически сервис был устроен следующим образом: самой первой газетой с программой, которая появлялась в продаже была, по-моему, газета «Радио и Телевидение». Она выходила во вторник или в среду с полной программой на следующую неделю. Создатель сервиса, Паша, утром ехал на работу и покупал газету в киоске. В офисе ее сканировали и отправляли на автоматическое распознавание текста (OCR). Далее текст упаковывался в письмо, и оно уходило подписчикам. Все было автоматизировано настолько, насколько это было возможно в той ситуации.

Газета «Радио и Телевидение» печаталась на самой дешевой бумаге самым дешевым офсетным способом, качество ее оставляло желать лучшего: буквы сливались, не пропечатывались и т.д., что приводило к различным ошибкам после распознавания текста. Но на ошибки забивали, главное — первым прислать программу, тогда подписчик будет доволен.

В один из таких замечательных дней в программе спортивного канала была трансляция соревнования «ГРЕБЛЯ НА БАЙДАРКАХ И КАНОЭ — 12.45». Сканер вместе с OCR то ли не заметили, то ли пропустили, но в рассылку ушел замечательный анонс мероприятия без букв «ГР» в первом слове. Ситуация, честно сказать, пошла только на пользу рассылке, подписка выросла в разы (так об ошибке и узнали — по аномальному росту подписчиков, ее просто пересылали всем друзьям), но, в целом, необходимо взять за правило — всегда проверять тексты перед отправкой.

Проверьте все трижды, а лучше семь раз, как в известной пословице. И не только тексты, но и другие составляющие эффективной доставки (смотри раздел «Чек-лист»), и будет вам счастье и вашим подписчикам тоже :)

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

Моя персональная страница: http://leonidnikolaev.ru

Моя страница в ФБ: https://www.facebook.com/leonid.nikolaev

Мой Телеграм: @Leonid_Nikolaev (https://t.me/Leonid_Nikolaev)

Про тех, без кого эта книга
не получилась бы в такой короткий срок

Юлия Любимская (генеральный директор интернет-агентства «Artrix.ru») и Вячеслав Федоров (директор по развитию «e-moneynews.ru») — именно они придумали этот интересный челлендж «написать книгу за месяц».

Александр Носач (организатор конференций «MailingDay.ru», основатель «EmailFactory.pro» и других проектов в области email-маркетинга) — подхватил проект и взял на себя техническую часть по обеспечению печати книги и распространению ее в бумажном и электронном виде.

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

Марина Пешикова (специалист по работе с клиентами компании «GET-N-POST») — помогала в сборе материалов и документировала наш опыт, который лег в основу подавляющего большинства практических аспектов применения методологии доставки описанной в этой книге.

Даша Иванова (email-маркетолог в «Банде умников») — взяла на себя редактуру материала и задавала много вопросов для того, чтобы текст получился таким понятным и читаемым.

Коллектив сервиса «eSputnik.com» во главе с Дмитрием Кудренко, который всячески поддерживал наше безумное начинание и помог с освещением вопросов про GDPR.

Все без исключения сотрудники компании «GET-N-POST», которые героически выдержали этот месяц и слышали на любой вопрос в сторону меня: «Секундочку, сейчас допишу и отвечу». Секундочки иногда длились довольно долго :)