Quem vem do desenvolvimento web tem um choque ao construir o primeiro email: técnicas que funcionam em qualquer navegador desde 2015 simplesmente não funcionam. Este texto explica por quê, e mostra o que fazer no lugar — inclusive a parte que ninguém avisa sobre o Outlook e o modo escuro.
Existem três razões, e nenhuma delas vai mudar tão cedo.
Um site precisa funcionar em alguns navegadores, todos razoavelmente modernos. Um email precisa funcionar em Gmail (web, Android, iOS), Apple Mail, Outlook (desktop, web, Mac, celular), Yahoo, Thunderbird e nos apps nativos de cada fabricante — cada um com regras próprias sobre o que aceita de CSS.
Boa parte deles descarta ou reescreve a tag <style>, ignora seletores complexos, remove <script> por segurança e limita o que pode ser posicionado. O que sobra é um subconjunto bem menor do que o HTML e CSS que você conhece.
Num site, você atende o navegador que o usuário escolheu. Num email, você atende todos ao mesmo tempo, sem saber qual será usado — e sem chance de corrigir depois que a mensagem saiu.
Não é conservadorismo. É porque float, flexbox e grid não têm suporte confiável no conjunto de clientes que importa — em especial nas versões de desktop do Outlook.
A estrutura padrão continua sendo tabelas aninhadas, com o CSS inline em cada elemento:
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="padding:24px 16px;">
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="font-family:Arial,sans-serif;font-size:16px;
line-height:24px;color:#1a1a1a;">
Conteúdo aqui
</td>
</tr>
</table>
</td>
</tr>
</table>Três detalhes que importam nesse trecho:
role="presentation" — diz ao leitor de tela que a tabela é layout, não dado. Sem isso, quem usa leitor ouve "tabela com 1 linha e 1 coluna" antes de cada bloco.Use um framework de email (MJML e similares) ou o construtor da sua plataforma. Eles geram a tabelada e as correções de compatibilidade automaticamente. Entender o que acontece por baixo serve para depurar quando algo quebra — não para digitar tudo.
As versões desktop do Outlook para Windows renderizam email com o motor do Word, não com um motor de navegador. Isso produz um conjunto de comportamentos próprios que explicam a maioria dos "ficou perfeito em todo lugar, menos no Outlook".
background-image em divs é ignorado. Para fundo com imagem, é preciso usar a marcação específica de VML ou aceitar uma cor sólida como alternativa.border-radius não é aplicado — botões arredondados aparecem quadrados.max-width é ignorado em muitos contextos. Use width fixo nas tabelas.padding em alguns elementos se comporta de forma imprevisível. Prefira padding em <td>.line-height explicitamente e em pixels.width e height no atributo, não só no CSS.A saída padrão para tratar o Outlook separadamente é o comentário condicional, que só ele interpreta:
<!--[if mso]>
<!-- código que só o Outlook do Windows vai ler -->
<![endif]-->Serve para dar um fallback específico — um botão retangular onde os outros veem um arredondado, por exemplo — sem afetar o restante.
Olhe a distribuição de clientes de email da sua base nos relatórios. Se 2% abrem no Outlook desktop, um botão quadrado para eles é aceitável. Se 40% da sua base é corporativa, o Outlook define o projeto inteiro — e o layout precisa nascer pensando nele.
Mais de 60% das aberturas acontecem no celular. Duas abordagens dominam:
Funciona na maior parte dos clientes modernos. As media queries vão numa tag <style> no <head> — que alguns clientes descartam, e é por isso que ela nunca deve ser a única linha de defesa.
Construir com larguras percentuais e max-width, de forma que o layout se adapte mesmo sem media query. Onde ela funcionar, refina; onde não funcionar, o email continua legível.
width:100%; height:auto dentro do container.Boa parte dos clientes de email hoje oferece tema escuro, e cada um inverte cores de um jeito. O resultado clássico: um logotipo preto em fundo branco vira preto em fundo preto — invisível.
#000) e branco puro (#fff). Tons ligeiramente deslocados sofrem menos com a inversão automática.Nossos templates são testados em Gmail, Apple Mail e Outlook, no claro e no escuro, antes de qualquer disparo.
Passe por todos. Leva dez minutos e evita o email que ninguém consegue ler.
role="presentation" e CSS inlinewidth e height declarados em todas as imagensalt descritivo em toda imagem — é o que aparece quando o carregamento está bloqueadoList-Unsubscribe de um clique configuradoAbra o email no celular, com as imagens bloqueadas e o modo escuro ligado. Se ele continuar legível e a chamada continuar clara nessas condições, vai funcionar em praticamente todo lugar.
E vale lembrar do óbvio: HTML impecável não salva email que não chega. Antes de investir horas em compatibilidade, confirme que SPF, DKIM e DMARC estão corretos — é o que decide se alguém vai ver o seu trabalho.
Os limites reais dos planos gratuitos das principais plataformas, o que costuma ficar de fora e a partir de que ponto o grátis passa a sair caro.
As estruturas AIDA e PAS aplicadas ao email, por que a primeira linha importa mais que o resto, e os gatilhos que funcionam sem soar desesperado.
O que testar, qual tamanho de amostra dá resultado confiável, por que a maioria dos testes não prova nada e como ler o resultado sem viés.
Analisamos sua base, sua entregabilidade e seus fluxos — e mostramos, com números, onde está o dinheiro parado. Sem custo e sem compromisso.
