Как стать автором
Обновить

Как делать email-рассылки и не косячить: практические советы

Время на прочтение23 мин
Количество просмотров55K
Всего голосов 62: ↑58 и ↓4+54
Комментарии19

Комментарии 19

Как вы решаете вопрос с форвардингом писем и spf проверкой?
Используете SRS?
В кратце — проблемы с форвардингом обычно решаются с помощью DKIM, SPF даже с SRS нарушается при форвардинге в рамках DMARC. SRS не используем, т.к. SRS по факту в текущих реалиях означает включать пересылаемые письма в репутацию своего домена.
Подробный разбор обоих вопросов есть в этой статье, пункты 13-14.
Спасибо за ссылку.

Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?

Обычный форвардинг на уровне MTA не ломает DKIM, т.к. не меняет содержимое письма. Если он ломает, значит либо DKIM неправильно настроен, например подписываются трекинговые заголовки, либо письмо неправильно формируется, например не формируются обязательные заголовки (Date, From, Message-ID), и они добавляются транзитным сервером уже после DKIM, что «бьет» DKIM подпись. Другие «косяки» с формированием письма, по которым DKIM может биться тоже обсуждаются в статье — слишком длинные строки, неправильные терминаторы, 8-битные символы в заголовках и т.д.

Единственное исключение, которое я знаю это Microsoft Exchange / office365, он при некоторых настройках фактически формирует письмо заново.

В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.

Очень даже можно. Если это не проблема самого ESP, то можно сегментировать разные категории писем по разным поддоменам (в конверте или в From) или DKIM-селекторам, чтобы идентифицировать проблемную категорию пиcем.
Даже если какое-то письмо не дойдет из-за разового сбоя DMARC (например, был недоступен DNS), при reject вы можете понять это по ответу SMTP и переотправить письмо. Но при тех же самых условиях при none ваше письмо с побитым DKIM с очень большой долей вероятности легло в папку «Спам», и ровно так же не будет прочитано пользователем, но об этом вы никогда не узнаете.

Так DKIM цел. От остальных esp приходят отчёты с успехами обработки политик. То есть это именно локальные проблемы и/или некорректные реализации esp.

Несколько процентов сбоев DKIM не бывает без причины. Сбои бывают, но на правильно сформированных письмах это маленькие доли процента (менее 0.1%). Сбои на существенном проценте означают, что часть ваших писем нормализуется получателем, и происходит это, скорей всего, из-за проблем озвученных выше. Если письмо генерируется с нарушением RFC 5322, то поведение на нем не предсказуемое и может быть разным у разных получателей.
Единицы процентов это очень большая доля писем, это значит есть объективная причина.
И ARC, к сожалению, не очень решает проблему с пересылками, т.к. требует доверия к пересылающей стороне и мало чем отличается от любого другого списка известных форвардеров (например по IP или DKIM-подписям).
Проверяем, что Reply-To:
(...)
  • Может быть из любого домена, не обязательно совпадающего с From, однако иногда это пугает пользователей при ответе.

Вот да. 99% писем с Reply-To != From, которые попадались мне (обычному конечному пользователю почтового ящика), — это нигерийские письма, тк адрес из From: в таких письмах по понятным причинам долго на свете не заживается. Какие вообще легальные сценарии использования Reply-To?
Примером нормального сценария может послужить:
From: info@company.com
Reply-To: feedback-1234450-blablabla@crm.company.com

В таком случае по ответу может автоматически создаваться тикет в CRM, в который подтянется вся информация о письме, на которое отвечает пользователь.
Если reply-to не совпадает с адресом домена — является это основанием для попадания писем в спам на mail.ru?
В общем случае нет, это нормальная ситуация.
Использование двух сервисов для подсчета кликов (и перенаправления пользователя) может быть воспринято mail.ru как спам-метод?
Любые ссылки / источники картинок могут влиять на его репутацию, как положительно, если это надежный источник, так и отрицательно, если источник ненадежный. Это касается любых доменов используемых где угодно — в адресах конвертов и заголовков, внешних ссылках, адресах внешних картинок.
Возможно ли использование сервиса dadata на этапе регистрации (помогающего пользователю заполнять поля при регистрации) основанием для блокировки писем?
По конкретным вопросам доставляемости писем лучше задать вопрос на адрес postmaster@corp.mail.ru, тестировщики на них не смогут ответить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий