Разработка и вёрстка шаблонов транзакционных email (MJML)

Сделали email-рассылку для интернет-магазина. Вёрстка на таблицах, тестировали в Gmail — всё ок. Но в Outlook 2016 письмо развалилось: кнопка съехала, шрифты пропали, а картинка не загрузилась. Знакомая ситуация — её исправляет MJML.

Проблема в том, что Outlook использует Word для рендеринга HTML, а не Edge или WebKit. MJML решает эту боль: вы пишете компоненты на декларативном языке, а на выходе получаете валидный табличный HTML, проверенный в 90+ почтовых клиентах. Мы используем MJML в связке с Handlebars и Node.js, чтобы шаблоны были не только красивыми, но и легко интегрировались с любым бэкендом.

Почему MJML спасает от Outlook-головной боли?

• Outlook-совместимость. По статистике Litmus, около 9% пользователей открывают письма в Outlook. Если ваш шаблон не адаптирован под Word HTML, письмо может отобразиться некорректно: разъедутся колонки, пропадут background-image, не сработают border-radius. MJML генерирует табличную верстку с VML-кодом, которая корректно рендерится в Outlook. Мы дополнительно тестируем каждый шаблон на 5 версиях Outlook через Litmus.
• Адаптивность для мобильных. Более 50% писем открывают на телефонах. MJML сам создаёт медиа-запросы и fluid-таблицы, чтобы письмо выглядело одинаково хорошо на iPhone 15, Samsung Galaxy и десктопе.
• Скорость разработки. Типовой шаблон на таблицах вручную — 3-4 часа. На MJML — 30–40 минут. Плюс снижается вероятность ошибок: не нужно помнить quirks-режимы каждого клиента.

Как мы это делаем?

Разберём реальный кейс — интернет-магазин электроники. Клиент хотел 4 транзакционных письма: подтверждение заказа, уведомление об отгрузке, сброс пароля и приветствие.

Стек: MJML 4.15, Handlebars 2.0, Node.js 20 с TypeScript, компилятор mjml CLI, тестирование в Litmus.

Мы начали с создания общей базы — mj-attributes для шрифтов, цветов и кнопок. Это обеспечило единый стиль во всех письмах. Затем для каждого письма написали MJML-компонент, разбив интерфейс на секции: header, content, cta, footer. В места вставки динамических данных (имя, номер заказа, товары) добавили Handlebars-переменные.

Пример — письмо подтверждения заказа с таблицей товаров. Использовали <mj-table> для строк, чтобы они корректно отображались в Outlook. Кнопку "Отслеживать заказ" сделали через <mj-button> — он генерирует VML для Outlook.

После компиляции получили HTML-файлы размером ~15 КБ каждый. Интеграция с бэкендом — через Node.js-функцию, которая принимает JSON с данными заказа, подставляет их через Handlebars и возвращает готовый HTML для отправки.

Процесс работы

1. Аналитика — определяем типы писем, согласуем макеты и тексты.
2. Проектирование — создаём прототипы в MJML, показываем клиенту в тестовом окружении.
3. Реализация — верстаем шаблоны, добавляем Handlebars-переменные.
4. Тестирование — прогоняем через Litmus, фиксим баги в Outlook и мобильных клиентах.
5. Деплой — передаём HTML-файлы или код рендеринга на Node.js, пишем документацию по интеграции.

Сроки ориентировочно

Набор из 3-5 транзакционных шаблонов (order, reset password, welcome) — 4-6 рабочих дней. Сложные шаблоны с кастомной анимацией или AMP для email — до 8 дней.

Что входит в работу

• Исходники MJML (компоненты)
• Скомпилированные HTML-файлы
• Handlebars-шаблоны для вашего бэкенда
• Инструкция по интеграции с SendGrid, Amazon SES или любым SMTP
• Отчёт тестирования в Litmus со скриншотами
• Гарантия корректного отображения в Outlook, Gmail, Apple Mail
• Поддержка в течение 14 дней после сдачи

Почему MJML лучше табличной вёрстки?

Как тестировать шаблоны во всех почтовых клиентах?

Используем сервисы Litmus или Email on Acid — они делают скриншоты в реальных клиентах. Для быстрой проверки локально — плагин MJML Preview для VS Code или команда mjml -w для авто-пересборки. Для функционального тестирования — отправка в тестовый inbox через Mailtrap.

Тестируемые клиенты

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

Интеграция email рассылок: почему она часто ломается?

Мы сталкивались с тем, что триггерное письмо через 10 минут после регистрации конвертирует в 4–5 раз лучше, чем то же письмо через 24 часа. Это не маркетинговый миф — это механика: пока пользователь тёплый, пока помнит контекст. Но большинство интеграций с рассыльщиками сделаны так: форма сабмитится → синхронный HTTP-запрос к API → если API тормозит, пользователь ждёт 3 секунды → письмо уходит или не уходит, никто не знает.

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

Провайдеры и их API

Unisender — российский провайдер, популярен в сегменте SMB. REST API, простой. Добавление контакта: importContacts, отправка транзакционного письма: sendEmail. Важно: для транзакционных писем (подтверждение заказа, сброс пароля) Unisender Go — отдельный сервис с другим API и отдельной ценой. Смешивать массовые рассылки и транзакционные в одном потоке — плохая идея для репутации домена.

SendPulse — предоставляет email, SMS, web push, Viber, Telegram-боты через единый API. Для проектов, где нужен омниканал, это удобно. Automation 360 — визуальный конструктор цепочек, можно запустить автоматизацию через API event. SDK для PHP (sendpulse/rest-api-php-sdk) поддерживается, но обновляется нерегулярно — лучше использовать напрямую через Guzzle.

Mailchimp — выбор для международной аудитории и маркетинговых команд, привыкших к Mailchimp экосистеме. Transactional email — через Mandrill (дочерний сервис). Marketing API v3 для управления списками, тегами, кампаниями. Webhook для событий: открытие, клик, отписка, bounce.

SMS. Для России: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всех схожий: метод send, параметры phone, message, sender (имя отправителя — нужно регистрировать отдельно у оператора). Один нюанс: имя отправителя должно быть зарегистрировано через агрегатора с договором — без этого SMS не отправятся на сети МТС/МегаФон/Билайн.

Как построить интеграцию, чтобы не терять письма?

Разделяем транзакционные и маркетинговые потоки

Транзакционные письма (подтверждение заказа, сброс пароля, статус доставки) — через отдельный домен-отправитель или субдомен tx.example.com. Маркетинговые рассылки — через mail.example.com или news.example.com. Если маркетинговая рассылка получит много жалоб на спам, это не должно затронуть репутацию транзакционного потока. Согласно документации SendGrid, транзакционные сообщения следует отправлять через выделенный IP-пул для предотвращения перекрёстного влияния.

Очередь и retry

Любой вызов к email API — через очередь (Laravel Queue, Bull, Celery). Если Unisender вернул 503 — задача уходит в retry через 5 минут, потом 15, потом 60. После 5 неудачных попыток — в dead letter queue с алертом. Пользователь при этом уже получил свой 200 OK и не знает о проблеме. Благодаря этому подходу bounce rate на проектах снижается до 0.5%.

Пример job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 мин
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблоны

Храним шаблоны в коде (Blade, Twig, React Email), не в интерфейсе провайдера. Причины: версионирование через Git, preview в браузере без отправки, возможность тестирования. Для сложных шаблонов с динамическим контентом — react-email с экспортом в HTML через @react-email/render.

Валидация и согласия

Перед добавлением контакта в список — double opt-in (письмо с подтверждением). Хранить факт подтверждения с timestamp в своей БД. При отписке — синхронно отписываем и у провайдера, и в своей базе. Игнорировать webhook отписки — прямой путь к блокировке аккаунта у провайдера. Все процессы соответствуют ФЗ-152 о персональных данных.

Мониторинг доставляемости

Подключаем webhook от провайдера на события bounce (жёсткий и мягкий), spam_complaint, unsubscribe. Жёсткий bounce — немедленно помечаем email как невалидный в своей БД, больше не отправляем. Мягкий bounce 3 раза подряд — то же самое. Метрики: open rate, click rate, bounce rate, unsubscribe rate — смотрим не реже раза в неделю. Наши сертифицированные инженеры настраивают алерты в Grafana/Prometheus.

Почему важно разделять потоки?

Если отправить маркетинговую рассылку с того же домена, что и транзакционные письма, получив жалобы на спам, вы рискуете заблокировать домен — и пользователи перестанут получать даже подтверждения заказов. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) должны быть настроены отдельно для каждого потока. Мы используем субдомены с разными DNS-записями.

Объём работ по интеграции

• Аудит текущих потоков коммуникации и репутации домена (SPF, DKIM, DMARC)
• Выбор провайдера и схемы: транзакционный vs маркетинговый трафик
• Настройка DNS-записей SPF, DKIM, DMARC (Wikipedia DMARC)
• Разработка шаблонов писем (HTML + динамический контент)
• Интеграция с бэкендом через очереди и API
• Настройка webhook для доставляемости и жалоб
• Документация по эксплуатации и обучение команды
• Гарантия доставляемости и поддержка после запуска

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. Мы работаем под ключ: от анализа до мониторинга в продакшене. Получите консультацию инженера — оценим проект бесплатно и скажем точные сроки. Опыт более 7 лет в интеграции почтовых сервисов, реализовано 50+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.