Вёрстка писем: почему Outlook ломает то, что работает в браузере

Вы собрали письмо на flex-сетке, проверили в Chrome, отправили — и в Outlook на Windows блоки съехали, отступы исчезли, а фоновая картинка не отрисовалась. Причина не в кривой вёрстке: почтовые клиенты живут по своим правилам, часть из которых застыла где-то в 2007 году. Разбираем, что именно они выкидывают из вашего HTML и CSS, где ломается привычный подход из веба и чем приходится за это платить.

Почему письмо — это не веб-страница

В браузере есть один движок рендеринга на весь документ. В почте движок зависит от клиента, а иногда — от версии клиента и даже от того, открыто письмо в приложении или в вебе. Ключевая боль — Outlook для Windows (версии 2007–2021 и Microsoft 365): он рендерит письма движком Word, а не Internet Explorer или браузером. Word не понимает большую часть современного CSS.

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

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

Что конкретно выкидывают клиенты

• Gmail (веб и приложения) — удаляет тег <style> из <head> в некоторых сценариях (например, при пересылке и в части приложений), не поддерживает вложенные медиазапросы стабильно. Инлайн-стили — надёжнее.
• Outlook Windows (Word-движок) — игнорирует float, flex, grid, position, max-width на многих элементах, фоновые изображения через background-image, скруглённые углы через border-radius на большинстве блоков. Отступы margin работают нестабильно, padding у <div> — тоже.
• Apple Mail — самый лояльный, поддерживает почти всё, включая медиазапросы и часть CSS-анимаций. Опасность обратная: письмо, идеально выглядящее тут, легко оказывается сломанным везде ещё.
• Yandex, Mail.ru — веб-клиенты ближе к Gmail по поведению, поддерживают медиазапросы, но обрезают и переписывают часть стилей.

Где ломается привычный подход из веба

Flex и grid вместо таблиц

Самая частая ошибка — собрать многоколоночный блок на display: flex. В браузере и Apple Mail всё встанет как надо. В Outlook Windows flex просто игнорируется, и колонки складываются вертикально либо накладываются. Двухколоночная сетка «картинка слева, текст справа» в Outlook превратится в две строки одна под другой без отступов.

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

<!-- Двухколоночный блок, работающий в Outlook -->
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0" align="center">
  <tr>
    <td width="280" valign="top" style="padding: 0 10px;">
      <img src="https://example.com/img.png" width="280" style="display:block; width:100%; max-width:280px;" alt="Товар">
    </td>
    <td width="280" valign="top" style="padding: 0 10px; font-family: Arial, sans-serif; font-size: 15px; color: #222222;">
      Текст рядом с картинкой. В Outlook колонки остаются в ряд,
      потому что это ячейки таблицы, а не flex-блоки.
    </td>
  </tr>
</table>

Атрибут role="presentation" нужен, чтобы скринридеры не читали таблицу как таблицу данных — иначе доступность страдает.

Внешние и встроенные стили

В вебе вы выносите CSS в отдельный файл или в <style>. В письме внешний файл невозможен в принципе, а <style> ненадёжен: часть клиентов его вырезает. Базовое оформление (цвета текста, шрифты, отступы ячеек) держат инлайн, прямо в атрибуте style каждого элемента. Блок <style> оставляют для того, что инлайном не задать — прежде всего для медиазапросов адаптива, и относятся к нему как к прогрессивному улучшению, а не как к основе.

Отступы

В браузере вы задаёте margin и padding где угодно. В Outlook надёжно работает только padding у ячеек <td>. Поэтому отступы в письмах делают через padding ячеек или через пустые ячейки-распорки заданной высоты, а не через margin у блоков.

Условные комментарии для Outlook

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

<!--[if mso]>
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0" align="center">
  <tr>
    <td>
<![endif]-->

<!-- Обычный контейнер для остальных клиентов -->
<div style="max-width: 600px; margin: 0 auto;">
  ... содержимое письма ...
</div>

<!--[if mso]>
    </td>
  </tr>
</table>
<![endif]-->

Здесь mso — это Microsoft Office. Всё, что внутри [if mso], видит только Outlook Windows; остальные клиенты воспринимают это как обычный HTML-комментарий и пропускают.

Фоновые изображения

CSS-свойство background-image в Outlook Windows не отрисовывается. Если вам критичен фон под текстом (например, кнопка на градиенте), для Outlook используют VML — векторную разметку Microsoft внутри условного комментария. Это громоздкий приём; проще, где возможно, обойтись сплошной заливкой bgcolor или отдельной картинкой без текста поверх.

Что сравнивать между клиентами

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

Когда какой подход выбирать

• Транзакционные письма (чеки, уведомления, коды) — максимальная совместимость. Таблицы, инлайн-стили, минимум графики. Аудитория тут разнородная, и Outlook в корпоративной среде встречается часто.
• Промо-рассылки на широкую B2C-базу — можно опереться на медиазапросы для адаптива, потому что доля мобильных клиентов (Gmail-приложение, Apple Mail) велика, а они запросы поддерживают. Но базовый вид без запросов всё равно должен оставаться читаемым.
• Письма для дизайнерской аудитории на Apple-технике — редкий случай, когда можно позволить больше CSS. Но проверьте статистику открытий: если 20% аудитории на Outlook, вольности обойдутся дорого.

Что ломается на практике

• Забыли width на изображении — Outlook растянет картинку до реального размера файла, и письмо разъедется. Ширину задают и атрибутом width, и в style.
• Тёмная тема — Gmail и Apple Mail умеют инвертировать цвета в тёмном режиме. Прозрачный PNG-логотип с тёмным контуром на светлом фоне в тёмной теме станет невидимым. Тестируйте оба режима.
• Автоссылки — клиенты сами превращают телефоны, даты и адреса в кликабельные ссылки своим цветом, ломая дизайн. Отключается частично через специальную мета-разметку, но полного контроля нет.
• Обрезка Gmail — если размер HTML превышает ~102 КБ, Gmail обрезает письмо и показывает ссылку «Посмотреть всё сообщение». Держите вес под лимитом.

Что делать дальше

Не проверяйте письма только в браузере — это даёт ложную уверенность. Настройте тестирование в реальных клиентах: заведите почтовые ящики в Gmail, Yandex, Mail.ru и, если есть доступ, откройте письмо в настольном Outlook на Windows. Сервисы вроде Litmus или Email on Acid показывают рендеринг сразу в десятках клиентов — платно, но экономят часы ручной проверки. Следующий шаг после освоения таблиц — научиться писать один блок медиазапросов для мобильной адаптации так, чтобы десктопная версия оставалась рабочей без них. И сверяйтесь с актуальной таблицей поддержки CSS в почтовых клиентах на caniemail.com перед тем, как заложить в письмо новое свойство.