Дизайн email-рассылок: шаблоны, адаптивная вёрстка, тёмная тема

Представьте: вы запускаете промо-кампанию, письмо уходит в 50 000 подписчиков — а в Outlook оно отображается белым прямоугольником. Или в Gmail обрезается после первого экрана. Это типичная ситуация, когда email-шаблон свёрстан без учёта ограничений почтовых клиентов. Правильно свёрстанное письмо даёт конверсию в 2–3 раза выше, чем шаблон, созданный без тестирования. За 5 лет мы разработали более 100 шаблонов писем для интернет-магазинов, новостных изданий и SaaS-продуктов — и знаем, как обойти подводные камни каждого клиента.

Дизайн email-рассылки — это инженерия с жёсткими ограничениями. Outlook рендерит через Word rendering engine, Gmail лимитирует 102 КБ, Apple Mail поддерживает prefers-color-scheme, а остальные — нет. Наш опыт показывает: корректно свёрстанное письмо открывается на любом устройстве. Чтобы избежать проблем с отображением, обратитесь к нам на этапе проектирования. Закажите разработку шаблона — и мы подготовим макет, который не потеряется в папке «Спам».

Недавно мы делали шаблон для интернет-магазина электроники: после замены табличной вёрстки на адаптивную открываемость выросла на 25%, а число переходов по CTA — на 40%.

Какие проблемы решаем?

• Outlook: Word rendering engine ломает позиционирование, игнорирует многие CSS-свойства. Решение — табличная вёрстка с инлайн-стилями, основа Outlook-вёрстки. Таблица в 2-3 раза надёжнее flexbox в почтовых клиентах.
• Gmail: лимит 102 КБ на необработанное письмо. Оптимизируем изображения через CDN, исключаем base64, минифицируем код. Экономия трафика — до 30%.
• Тёмная тема: Apple Mail корректно перекрашивает фон и текст, Gmail — нет. Без явных правил дизайн может инвертироваться в негатив.
• Адаптивность: мобильная версия должна читаться без зума. Используем fluid таблицы и медиа-запросы.

Как обеспечить совместимость с Outlook?

Базовая структура письма — табличная вёрстка с шириной 600px, инлайн-стилями для каждого элемента. Безопасные CSS-свойства: font-family, font-size, color, background-color, padding, margin, border, width. Flexbox, grid, position: absolute не работают в большинстве клиентов, поэтому их избегаем.

Сравнение почтовых клиентов

Какие CSS-свойства безопасны?

Почему тёмная тема критична?

Более 30% пользователей включают тёмный режим на устройствах. Без медиа-запроса @media (prefers-color-scheme: dark) клиент автоматически инвертирует цвета, и ваш логотип становится невидимым. Мы добавляем явные правила:

@media (prefers-color-scheme: dark) {
  .email-bg { background-color: #1a1a2e !important; }
  .email-text { color: #e0e0e0 !important; }
}

Подробнее о prefers-color-scheme на MDN

Preheader — скрытый текст, повышающий открываемость

Preheader — скрытый текст, который отображается в списке писем рядом с темой. Он увеличивает открываемость на 15–20%. Задаётся через display:none в самом начале body.

Состав работ

• Дизайн шаблона письма в Figma (десктоп и мобильный превью)
• Адаптивная вёрстка HTML-кода email (таблицы, инлайн-стили)
• Тестирование в 10+ почтовых клиентах (Outlook, Gmail, Apple Mail, Яндекс, Mail.ru, Rambler и др.)
• Настройка тёмной темы
• Preheader, CTA-кнопка, footer с отпиской
• Документация по использованию шаблона (как вставлять изображения, менять текст)
• Исходники Figma и готовый HTML-файл

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

1. Анализ: определяем тип рассылки (транзакционная, новостная, промо) и целевую аудиторию.
2. Дизайн: создаём 1–2 прототипа в Figma, согласовываем.
3. Вёрстка: табличный макет с инлайн-стилями, оптимизация изображений.
4. Тестирование: проверяем в Litmus или Email on Acid, фиксим баги.
5. Деплой: передаём готовый шаблон и документацию.

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

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

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

Интеграция 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+ проектов. Закажите бесплатный аудит текущей интеграции — получите отчёт с рекомендациями.