Как email выглядит в разных клиентах: тестирование рендеринга
You design an email. It looks sharp in the preview. Then you open it in Outlook - and the layout is broken. Gmail stripped your styles. Yahoo shifted the margins. Apple Mail rendered it perfectly, but in dark mode your logo disappeared into the background. This is not a bug in your code. This is how email clients work.
Why the same HTML looks different everywhere
Web browsers share rendering standards. Chrome, Firefox, Safari - they all follow the same CSS spec, give or take minor edge cases. Email clients do not. There is no shared standard for how email HTML should be rendered. Each client applies its own rules, its own restrictions, and its own modifications to your markup before the user ever sees it.
Outlook on Windows uses Microsoft Word's rendering engine to display HTML emails. Not a browser engine. Word. That means no support for flexbox, no grid, limited background images, and unpredictable margin behavior. Gmail strips the entire <style> block from <head> if the HTML exceeds 102 KB, and rewrites class names even when it keeps them. Apple Mail supports nearly all modern CSS but aggressively auto-inverts colors in dark mode. Yandex.Mail and Mail.ru each have their own quirks with max-width, positioning, and image handling.
The result: a single email can look four different ways in four different inboxes. And if you only tested in one client before sending, three out of four recipients saw something you never intended.
What breaks where: a field guide
Outlook (Windows). The Word engine does not understand border-radius, so rounded buttons become rectangles. Background images require VML markup. Padding on <div> elements is often ignored - use table cells instead. Line-height calculations differ from every other client, which shifts vertical spacing. Conditional comments <!--[if mso]> are the standard workaround: they inject Outlook-specific HTML that other clients ignore.
Gmail. All class names get prefixed, so if your CSS relies on descendant selectors or complex specificity, it may break. Media queries work in most Gmail interfaces now, but not reliably in the Android app for non-IMAP accounts. The 102 KB limit on HTML size is a hard boundary - exceed it, and Gmail clips the message with a "View entire message" link. Most recipients will not click that link.
Apple Mail. The most forgiving client. Supports web fonts, media queries, CSS animations, and prefers-color-scheme. The catch: dark mode. Apple Mail automatically inverts light backgrounds to dark, and dark text to light. If your design uses mid-range colors or images with transparent backgrounds against assumed-white, the automatic inversion can produce unreadable combinations.
Yandex.Mail and Mail.ru. Both popular in Russia and CIS. Both have their own sanitization pipelines that strip certain CSS properties. Yandex handles media queries but sometimes overrides font sizes in its mobile app. Mail.ru ignores max-width on <div> elements but respects it on table cells. If your audience is Russian-speaking, these two clients are not optional to test.
How to test before you send
There are three approaches, and they are not mutually exclusive.
Automated preview services. Litmus and Email on Acid take your HTML, render it across 90+ email clients and devices, and return screenshots. You see exactly what your subscribers will see in Gmail on Android, Outlook 2019 on Windows, Apple Mail on iPhone 15, Samsung Mail, and dozens more. These services cost money - typically $80-150 per month - but they compress what would take hours of manual testing into minutes. For teams that send regularly, they pay for themselves.
Manual testing on real accounts. Create mailboxes on Gmail, Outlook.com, Yahoo, Yandex, Mail.ru, and iCloud. Send yourself a test email. Open it on desktop and mobile. Toggle dark mode. Check with images disabled. This is slower than Litmus but free, and it gives you the authentic experience rather than a static screenshot. The minimum viable set: Gmail (web), Outlook (Windows desktop), Apple Mail (iOS), and one Russian client if your audience includes that geography.
Code-level validation. Tools like HTMLHint with email-specific rules, or the Parcel email editor, catch common issues before you even send the test. Missing alt attributes, unsupported CSS properties, HTML weight over 102 KB, missing inline styles. These tools do not replace visual testing but they eliminate the obvious problems early.
Common rendering problems and how to fix them
Broken layout in Outlook. Use tables for structure. Not div-based grids. The outer table at 100% width sets the background. The inner table at 600px max-width holds the content. Wrap columns in conditional comments for Outlook and use display: inline-block divs for modern clients. This hybrid approach renders correctly across the board.
Clipped message in Gmail. Keep total HTML under 102 KB. Minify your markup. Remove unnecessary comments and whitespace. If your email includes long product lists, consider cutting the number of items and linking to the website for the full catalog.
Invisible logo in dark mode. Use PNG with transparent background and add a thin white or light-colored stroke around the logo edges. Or prepare two versions of the logo and swap them via @media (prefers-color-scheme: dark). For clients that do not support the media query, the light version will show by default - so make it the one that works on both backgrounds.
Images blocked by default. Many corporate Outlook installations and some webmail clients block images until the user clicks "Show images." Your email should be readable without any images at all. Use descriptive alt text. Set background colors on image containers so the layout does not collapse. Never put critical information only in an image.
Font rendering differences. Web fonts work in Apple Mail, iOS Mail, and Samsung Mail. Gmail and Outlook ignore them. Design your email around system fonts - Arial, Helvetica, Georgia - and treat web fonts as progressive enhancement. Match the fallback font metrics to the primary font so the layout does not shift for recipients whose clients drop the web font.
Rendering is half the problem. Delivery is the other half.
You can test rendering in every client on earth and still fail if the email never arrives. A perfectly designed message that lands in the spam folder is invisible. And one of the primary reasons emails go to spam is sending to invalid addresses. High bounce rates signal ISPs that the sender does not maintain their list, which drags down domain reputation and pushes subsequent sends into junk.
Validating your recipient list before sending removes dead addresses, catches disposable mailboxes, and flags spam traps. The bounce rate drops, reputation improves, and your carefully tested email actually reaches the inbox where it can render as intended.
Почему одно и то же письмо выглядит везде по-разному
Веб-браузеры договорились о стандартах. Chrome, Firefox, Safari рендерят CSS одинаково с минимальными отличиями. У email-клиентов такого соглашения нет. Каждый применяет собственные правила: вырезает одни CSS-свойства, переписывает другие, добавляет свои стили поверх ваших.
Outlook на Windows использует движок Microsoft Word для отображения HTML. Не браузерный движок - Word. Отсюда отсутствие поддержки flexbox, grid, ограниченная работа с фоновыми изображениями и непредсказуемое поведение отступов. Gmail вырезает весь блок <style> из <head>, если HTML превышает 102 КБ, и переименовывает CSS-классы даже когда оставляет их. Apple Mail поддерживает почти весь современный CSS, но в тёмном режиме агрессивно инвертирует цвета. Яндекс.Почта и Mail.ru имеют собственные конвейеры санитизации с ограничениями на max-width, позиционирование и обработку изображений.
Итог: одно письмо - четыре разных вида в четырёх клиентах. Если вы тестировали только в одном, три четверти получателей увидели то, что вы не планировали.
Что ломается и где: по клиентам
Outlook (Windows). Движок Word не понимает border-radius - кнопки со скруглениями становятся прямоугольниками. Фоновые изображения требуют VML-разметки. Padding на <div> часто игнорируется - используйте ячейки таблиц. Вертикальные отступы рассчитываются иначе, чем в любом другом клиенте. Стандартный обходной путь - условные комментарии <!--[if mso]>, которые вставляют HTML только для Outlook.
Gmail. Все имена классов получают префикс, поэтому CSS-селекторы, завязанные на вложенность или сложную специфичность, могут сломаться. Media queries работают в большинстве интерфейсов Gmail, но не всегда стабильно в Android-приложении для не-IMAP аккаунтов. Лимит в 102 КБ на размер HTML - жёсткая граница. Превысили - Gmail обрезает письмо со ссылкой «Показать целиком». Большинство подписчиков не кликнут.
Apple Mail. Самый лояльный клиент. Поддерживает веб-шрифты, media queries, CSS-анимации и prefers-color-scheme. Подвох - тёмная тема. Apple Mail автоматически инвертирует светлые фоны в тёмные и наоборот. Если дизайн использует средние тона или изображения с прозрачным фоном на предполагаемо белой подложке, автоинверсия может дать нечитаемые сочетания.
Яндекс.Почта и Mail.ru. Оба клиента популярны в России и СНГ. У обоих собственные конвейеры санитизации, вырезающие определённые CSS-свойства. Яндекс поддерживает media queries, но иногда перебивает размер шрифта в мобильном приложении. Mail.ru игнорирует max-width на <div>, но корректно применяет его на ячейках таблиц. Если аудитория русскоязычная, тестирование в этих двух клиентах обязательно.
Три подхода к тестированию
Они не взаимоисключающие - лучше всего работают в связке.
Автоматические сервисы превью. Litmus и Email on Acid берут ваш HTML, рендерят его в 90+ клиентах и устройствах, возвращают скриншоты. Вы видите именно то, что увидят подписчики: Gmail на Android, Outlook 2019 на Windows, Apple Mail на iPhone, Samsung Mail и десятки других. Стоимость - от $80 до $150 в месяц. Для команд с регулярными рассылками они окупаются за счёт сэкономленного времени.
Ручное тестирование на реальных аккаунтах. Заведите почтовые ящики на Gmail, Outlook.com, Yahoo, Яндексе, Mail.ru, iCloud. Отправьте себе тестовое письмо. Откройте на десктопе и мобильном. Включите тёмную тему. Отключите показ картинок. Это медленнее Litmus, но бесплатно - и даёт живой опыт вместо статичного скриншота. Минимальный набор: Gmail (веб), Outlook (десктоп Windows), Apple Mail (iOS), плюс один российский клиент.
Проверка на уровне кода. HTMLHint с email-правилами или редактор Parcel находят типичные ошибки ещё до отправки теста. Отсутствующие alt, неподдерживаемые CSS-свойства, вес HTML больше 102 КБ, пропущенные инлайн-стили. Это не замена визуальному тестированию, но отсечение явных проблем на раннем этапе.
Частые проблемы рендеринга и как их решать
Сломанная раскладка в Outlook. Используйте таблицы для структуры. Внешняя таблица 100% ширины для фона, внутренняя на 600px для контента. Колонки заворачивайте в условные комментарии для Outlook, а для современных клиентов применяйте display: inline-block на div-обёртках. Такой гибридный подход рендерится корректно везде.
Обрезанное письмо в Gmail. Держите общий вес HTML ниже 102 КБ. Минифицируйте разметку. Уберите лишние комментарии и пробелы. Если в письме длинный список товаров, сократите количество позиций и дайте ссылку на полный каталог на сайте.
Невидимый логотип в тёмной теме. Используйте PNG с прозрачным фоном и добавьте тонкую белую или светлую обводку по краям логотипа. Или подготовьте две версии и переключайте через @media (prefers-color-scheme: dark). Для клиентов без поддержки этого медиа-запроса покажется светлая версия - поэтому она должна работать на обоих фонах.
Заблокированные изображения. Корпоративные установки Outlook и некоторые веб-клиенты блокируют картинки по умолчанию. Письмо должно быть читаемым совсем без картинок. Описательный alt-текст, фоновые цвета в контейнерах изображений, критическая информация - только текстом.
Разные шрифты на разных клиентах. Веб-шрифты работают в Apple Mail, iOS Mail, Samsung Mail. Gmail и Outlook их игнорируют. Проектируйте письмо на системных шрифтах - Arial, Helvetica, Georgia. Веб-шрифт добавляйте как улучшение. Подберите fallback-стек с похожими метриками, чтобы раскладка не ехала у получателей, чей клиент отбросил кастомный шрифт.
Рендеринг - половина дела. Доставляемость - вторая половина.
Можно оттестировать рендеринг во всех клиентах на свете и всё равно проиграть, если письмо не дойдёт. Отлично свёрстанное сообщение в папке «Спам» - невидимое сообщение. А одна из главных причин попадания в спам - отправка на невалидные адреса. Высокий bounce rate сигнализирует ISP, что отправитель не поддерживает список. Репутация домена падает, последующие рассылки уходят в нежелательную почту.
Валидация списка получателей перед отправкой убирает мёртвые адреса, выявляет одноразовые ящики, помечает спам-ловушки. Bounce rate снижается, репутация восстанавливается, и ваше аккуратно протестированное письмо действительно попадает в inbox - туда, где рендеринг имеет значение.
Тестировать рендеринг без проверки базы - всё равно что полировать кузов машины без двигателя. Выглядит хорошо, но никуда не едет.
Перед следующей рассылкой проверьте базу в uChecker. Загрузите список - и через минуты увидите, какие адреса валидны, какие рискованны и от каких стоит отказаться.