O motivo principal: e-mail não é web

O HTML que você escreve para um site é interpretado por navegadores modernos (Chrome, Safari, Firefox), com padrões relativamente estáveis e suporte amplo a CSS. Já o HTML de e-mail é renderizado por clientes de e-mail — e cada um tem seu próprio motor, suas próprias regras e, em muitos casos, restrições agressivas por segurança.

Em outras palavras: para um cliente de e-mail, o seu HTML é “suspeito até que se prove o contrário”. Por isso ele corta scripts, remove partes do CSS, reescreve tags, aplica estilos próprios, e às vezes reorganiza o DOM para se proteger de rastreamento, phishing e comportamentos maliciosos.

Os vilões mais comuns (e como eles quebram seu layout)

1) CSS limitado ou removido

Muitos clientes não suportam CSS moderno de forma consistente. Propriedades como flex, grid, position, pseudo-classes avançadas e até estilos no <style> podem ser ignorados, reescritos ou parcialmente aplicados.

O resultado típico é: colunas que deveriam ficar lado a lado viram blocos empilhados, espaçamentos somem, alinhamentos mudam, e aquela “responsive magic” da web simplesmente não acontece.

2) Outlook e motores de renderização “diferentes”

Uma parte do Outlook (principalmente no Windows) renderiza HTML de e-mail usando um motor mais próximo do Word. Isso tem impacto direto: alguns estilos são ignorados, margens e paddings se comportam de forma estranha, e elementos “normais” na web podem ficar imprevisíveis.

Se você já viu um e-mail perfeito no Gmail e um caos no Outlook, é isso acontecendo na prática.

3) Imagens bloqueadas por padrão

Vários clientes não carregam imagens automaticamente por privacidade. Resultado: seu e-mail “vazio”, cheio de buracos, com o texto sem contexto e o call-to-action perdendo força.

Isso é muito comum em ambientes corporativos (políticas de segurança) e também quando o remetente não tem boa reputação ou autenticação adequada.

4) Fontes customizadas quase sempre falham

A web ama fontes externas. No e-mail, o suporte é fragmentado. Alguns clientes até aceitam, outros ignoram. Aí seu design “premium” chega com uma fonte genérica e tudo parece diferente: quebra de linha muda, peso muda, espaçamento muda. É o efeito dominó do layout.

5) Dark mode reescrevendo cores

Dark mode em e-mail não é apenas “fundo escuro”. Muitos clientes invertem cores ou ajustam automaticamente texto e background. Isso pode destruir contraste, “apagar” divisórias e deixar logotipos ilegíveis.

Clássico: seu e-mail tinha um card branco com texto cinza claro, e no dark mode vira um card estranho com texto sem contraste. 🕶️

6) Links e botões sendo reestilizados

Alguns clientes aplicam estilos próprios em links (azul, sublinhado) e até detectam automaticamente telefones e endereços, transformando tudo em links sem você pedir. Isso bagunça visual e hierarquia.

7) Media queries e responsividade inconsistente

Media queries funcionam em alguns clientes e falham em outros. E mesmo quando funcionam, podem ser filtradas ou alteradas. Por isso, depender apenas de CSS responsivo sofisticado costuma dar ruim.

O caminho das pedras: como fazer HTML de e-mail que aguenta pancada 💪

1) Pense em “compatibilidade”, não em “perfeição”

Em e-mail, o objetivo não é replicar uma landing page. É entregar uma mensagem clara, com leitura confortável e um CTA que funcione. Se ficar bonito em 90% dos clientes, já é vitória. Se ficar legível e clicável em 99%, melhor ainda.

2) Use layout com tabelas (sim, é 2026 e ainda é tabela 😄)

Tabelas continuam sendo a base mais confiável para estrutura. A web usa flex e grid, mas o e-mail historicamente se comporta melhor com tabelas, especialmente para colunas, alinhamento e largura.

Uma estrutura comum e estável: tabela externa com largura fixa (ex.: 600px) centralizada, e dentro dela blocos em tabelas menores.

3) CSS inline é o seu melhor amigo

Muitos clientes respeitam melhor estilos inline do que folhas de estilo completas. Em vez de confiar em classes e seletores complexos, aplique o essencial no próprio elemento: style="font-family:...; font-size:...; line-height:...; padding:...;".

Isso não é elegante, mas é robusto. Em e-mail, robustez vence.

4) Evite margens; prefira padding e espaçadores simples

Margens podem se comportar de forma inconsistente. Padding costuma ser mais previsível. Quando precisar “respiro”, use padding em cells de tabela ou blocos com background.

5) Defina largura e comportamento de imagens

Sempre declare largura/altura quando fizer sentido (ou ao menos a largura), e use: style="display:block; border:0; outline:none; text-decoration:none;" para evitar espaços estranhos e bordas de link.

E trate o cenário em que a imagem não carrega: alt text decente salva a mensagem. Alt text não é “imagem1”. É: “Logo da marca” / “Banner: Oferta de X” / “Botão: Confirmar e-mail”.

6) Botões “bulletproof” (não dependa só de background em um link)

Um botão que funciona em muitos clientes costuma ser uma combinação de tabela + link com padding, e às vezes fallback para clientes mais chatos. O objetivo é que, mesmo que o CSS falhe, ainda pareça um botão (ou ao menos um link bem destacado).

7) Tipografia simples, escalável e legível

Use fontes seguras (system fonts) com fallback bem definido. Garanta line-height confortável e tamanhos realistas. Em mobile, texto pequeno vira tortura. Se a pessoa precisa dar zoom, você já perdeu.

8) Dark mode: trabalhe com contraste e evite “cinzas delicados”

Tons muito sutis ficam perigosos no dark mode. Prefira contraste mais alto e áreas com cor sólida quando o bloco precisa ser legível. Para logos, considere versões que se adaptam melhor (ou ao menos um contorno).

9) Não use JavaScript, formulários e coisas “de site”

Script geralmente é bloqueado. Formulários são problemáticos. Carrosséis e interações “avançadas” podem virar bagunça. Em e-mail, a interação principal é: ler e clicar. O resto vai para a página de destino.

Checklist rápido antes de enviar ✅

• Largura base consistente (ex.: 600px) e alinhamento central.
• Tabelas para estrutura e colunas, evitando flex/grid.
• CSS inline no essencial: fonte, tamanhos, cores, padding.
• Imagens com alt útil e display:block para evitar gaps.
• Links claros e CTA repetido (topo e final) se fizer sentido.
• Texto legível no mobile (tamanho e line-height).
• Contraste no dark mode (evite cinza clarinho em fundo branco).
• Evite dependências de fontes externas e CSS avançado.

Testes: o segredo que separa “ok” de “profissional” 🔍

Mesmo seguindo boas práticas, o teste é indispensável. O ideal é validar em pelo menos: Gmail (web e mobile), Outlook (se seu público usa), Apple Mail (macOS) e iPhone (Mail).

Se você não consegue testar tudo sempre, foque em: um layout simples, com hierarquia de conteúdo bem marcada, e um CTA que não dependa de “truques”.

E um detalhe que muita gente ignora: mande o teste para contas diferentes e em redes diferentes. Às vezes o problema é cache, bloqueio de imagens ou reescrita de links por segurança.

Quando simplificar é a melhor decisão ✨

Tem um momento em que insistir no “design perfeito” vira armadilha. Para e-mails de verificação, OTP, reset de senha e confirmações, um template simples costuma ser o melhor: logo, título, texto direto, código grande, e um link/CTA claro.

Quanto mais “transacional” o e-mail, mais ele se beneficia de clareza e contraste, e menos ele precisa de efeitos visuais.

Resumo final: por que quebra e como parar de sofrer 😌

E-mails HTML ficam quebrados porque cada cliente de e-mail tem regras próprias e limitações reais, principalmente por segurança e legado. A solução é trabalhar com o que é mais compatível: tabelas para layout, CSS inline, tipografia simples, imagens bem configuradas e atenção especial ao dark mode.

Se você adotar um template “à prova de inbox” e testar com consistência, a sensação muda completamente: em vez de “mandei e rezei”, vira “mandei e sei que vai chegar bonito (ou, no mínimo, perfeito de ler)”. 🚀