Дебаты между текстом и HTML в письмах не утихают. Специалисты по холодной рассылке в соцсетях выкладывают скриншоты, как чистый текст удвоил им율ет ответов. Маркетинг-платформы отвечают статистикой: HTML письма работают лучше на engagement. Обе стороны отчасти правы, но обе упускают главное: каждое современное письмо должно отправляться как multipart/alternative — с хорошо отформатированной текстовой частью и хорошо отформатированной HTML частью. Это стандарт, и это то, что ожидают фильтры.
HTML-только письма выглядят подозрительно. Обычный текст без HTML выглядит странно от кого угодно, кроме личного аккаунта. Multipart/alternative — обе части есть, обе части говорят одно и то же — это то, что делает каждый настоящий отправитель, и на это настроены фильтры. Отправляйте обе части.
| Аспект | HTML-только | Текст-только | Multipart/alternative |
|---|---|---|---|
| Сигнал для фильтров | Подозрительно (штраф MIME_HTML_ONLY) | Необычно не из личного аккаунта; флажится как массовая рассылка | Стандартное ожидание |
| Доступность | Ломается в текстовых клиентах и скринридерах | Работает везде, но без форматирования | Лучше всего — клиент выбирает |
| Доставка холодной рассылки vs multipart | Ниже (штраф HTML-only) | ~3% ниже в тестах 2025 года | Базовый уровень |
| Совместимость со старыми клиентами | Плохая | Полная | Полная |
| Сложность реализации | Легко | Легко | Легко — большинство ESP делают автоматически |
| Рекомендация | Избегать | Избегать для рассылок | Всегда отправлять |
Что такое multipart/alternative на самом деле
Определено в RFC 2046, multipart/alternative — это MIME-структура, которая содержит две (или больше) версии одного и того же письма. Почтовый клиент получателя выбирает версию, которую он может лучше показать. Клиенты с поддержкой HTML показывают HTML; клиенты без неё (сегодня редко, но некоторые специальные инструменты и старые терминальные клиенты на неё полагаются) показывают текст.
Content-Type: multipart/alternative; boundary="b1"
--b1
Content-Type: text/plain; charset=utf-8
Привет Саша, вот предложение, которое мы обсуждали...
--b1
Content-Type: text/html; charset=utf-8
<html><body><p>Привет Саша, вот предложение, которое мы обсуждали...</p></body></html>
--b1--Это то, что производит каждый корректный почтовый клиент — веб-композер Gmail, Apple Mail, Outlook, Postmark, SendGrid, все трансакционные рассылки, каждое уведомление B2B SaaS, которое вы получали. Это стандартное ожидание.
Почему HTML-только сигнализирует об автоматизации
Письмо, приходящее как text/html без текстовой альтернативы, исторически было признаком массовой рассылки, которой было лень генерировать текстовую версию. Фильтры по-прежнему так на это смотрят. SpamAssassin правило MIME_HTML_ONLYприсваивает небольшой, но стабильный штраф.
Кроме правил, HTML-только письма ломают доступность для скринридеров в текстовых клиентах, ломают вывод на редком клиенте без HTML-поддержки и портят отображение в доступных почтовых ящиках. Стоимость добавления текстовой части — ноль. Нет никаких причин её пропускать.
Почему текст-только тоже подозрителен
Совет из 2018 года был: «отправляй чистый текст, без HTML, будешь выглядеть как личное письмо, лучше дойдёшь». Это работало некоторое время. Фильтры адаптировались.
Обычное текстовое письмо от домена, который иначе отправляет профессиональные multipart письма, выделяется в истории отправителя. Обычное текстовое письмо с новенького домена без других сообщений выглядит как попытка массовой рассылки. Gmail ML не штрафует текст напрямую, но отсутствие HTML-части — это признак в модели engagement — и модель выучила, что массовые холодные отправители непропорционально используют text-only.
В реальном тестировании 2025 года text-only холодная рассылка дала в среднем ~3% ниже доставку в Входящие, чем тот же контент, отправленный как multipart с того же домена. Не катастрофа — но миф, что текст лучше дойдёт, ровно наоборот.
Как писать текстовую часть хорошо
Текстовая часть — не сорняк. Фильтры оценивают текстовую часть независимо. Что может пойти не так:
- Автоматическое преобразование текста из HTML. Большинство ESP плохо убирают HTML — оставляют закрывающие скобки, теряют контекст ссылок, выплёвывают видимые URL трекинг-пикселей в читаемый текст. Всегда проверяйте или пишите текст вручную.
- Несовпадающий контент. Если текстовая часть говорит одно, а HTML часть говорит другое — это фишинг-сигнал. Фильтры сравнивают. Держите их семантически эквивалентными.
- Форматирование URL. Текст не может быть якорной ссылкой. Не оставляйте длинные трекер-URL видимыми — используйте короче, чистые URL в текстовой части, где возможно.
- Пустая текстовая часть. Некоторые ESP отправляют multipart с одноточечной текстовой частью, когда пользователь написал только HTML. Это так же плохо, как пропустить текстовую часть совсем.
HTML правила, которые всё ещё действуют
Современный rendering HTML писем — ограниченный мир. Gmail, Yahoo и Outlook каждый убирают разные вещи. HTML часть должна:
- Использовать inline styles. Большинство CSS в
<head>будет убрано. - Использовать table-based layout для совместимости — современный flexbox/grid неравномерно поддерживается клиентами.
- Избегать JavaScript полностью. Убирается каждым клиентом; присутствие
<script>тегов поднимает спам-оценку. - Избегать
<form>и<iframe>. Убирается или выдаёт предупреждения. - Минимизировать внешний CSS — большинство клиентов его не загружают.
- Отображаться видимо без картинок — многие клиенты блокируют изображения по умолчанию, пока пользователь не разрешит.
Фильтры проверяют, рендерится ли HTML часть примерно в таком же количестве слов, как текстовая часть. Если ваш HTML — 2000 видимых слов, а текстовая часть — «смотрите вложение», это сильный флаг манипуляции. Одинаковый контент, оба формата. Никаких сокращений.
Соотношение длины и размера
Общий размер письма важен меньше, чем думают — современные фильтры спокойно обрабатывают письма до ~100KB без штрафа. Что важно:
- Соотношение текста и HTML. HTML часть должна быть не более ~3-4x размера текстовой части типичного письма. Тяжёлый HTML с соотношением 50:1 выглядит как шаблон для рассылки.
- Соотношение текста и картинок в HTML. Видимый текст должен быть даже когда картинки заблокированы. Смотрите нашу отдельную статью про соотношение картинок и текста.
- Общий размер. Выше ~100KB, Gmail обрезает письмо. Выше ~10MB, большинство провайдеров отказывают. Держите ниже 100KB для холодной рассылки.
Примеры из реальной жизни
Три паттерна отправок и как их принимают:
- Sales-менеджер в Gmail. Gmail автоматически производит multipart/alternative. Текстовая часть авто-выводится, обычно чистая. HTML часть минимального стиля. Это золотой стандарт сигнала, потому что это правда человеческое письмо.
- Маркетинг-автоматизация (HubSpot, Mailchimp, etc.).Multipart с тяжёлым HTML, сложные трекинг-пиксели, большой unsubscribe footer. Фильтры знают эти паттерны и маршрутят в Рассылки. Не спам, но не Входящие.
- Cold-email инструмент (Instantly, Smartlead, etc.).Multipart с минимальным HTML, мимикрирующим личное письмо, минимальный трекинг. Хорошие инструменты производят на MIME уровне неотличимо от Gmail compose. Дешёвые отправляют HTML-only или empty-text-part — и хоронят аккаунты.
Практические рекомендации
- Всегда отправляйте multipart/alternative. Обе части заполнены. Обе части говорят одно и то же.
- Держите HTML простым. Inline styles. Одна колонка. Без фоновых картинок, без JS, без форм.
- Пишите текстовую версию вручную для холодной рассылки. 5 минут работы стоят заметного повышения доставки.
- Проверьте, что производит ваш инструмент. Отправьте письмо себе и посмотрите исходник. Убедитесь, обе части есть и выглядят чисто.
- Перестаньте гоняться за мифом, что «текст лучше дойдёт». Это неправда уже с 2020 года.
Частые вопросы
Мой ESP позволяет только HTML — переходить на другой?
Когда текст-только лучше доходит?
А как Markdown — считается ли он обычным текстом?
Нужен ли отдельный HTML для мобилы?
Создали письмо и готовы его отправить? Используйте бесплатный Inbox Check — проверьте, как оно расположится у 9+ провайдеров: Gmail, Outlook, Mail.ru, Yandex и других. За 2 минуты вы увидите, в какую папку его положат.