Por que não dá para usar flexbox em uma assinatura de e-mail?

O mecanismo de renderização do Outlook para Windows, herdado do Microsoft Word, não suporta flexbox nem grid. Os elementos se empilham na vertical, o que destrói qualquer layout em colunas. As tabelas continuam sendo o único mecanismo de posicionamento confiável.

As tags funcionam em uma assinatura?

Não de forma confiável. Muitos clientes removem o bloco ao limpar o HTML, e uma assinatura colada em um campo de configuração geralmente perde tudo o que não está inline. Os estilos devem estar em atributos style em cada elemento.

Posso usar uma fonte personalizada?

Não de forma confiável: as web fonts não carregam na maioria dos clientes de e-mail. Use uma fonte do sistema e declare uma pilha de fontes alternativas.

Assinatura de e-mail em HTML: as regras de compatibilidade a seguir

O HTML de uma assinatura não é o HTML de um site. Tabelas, estilos inline, dimensões em atributos: as regras para uma assinatura aparecer igual no Outlook, no Gmail e no celular.

O HTML de um e-mail não segue as mesmas regras do HTML de um site. O que funciona em um navegador moderno pode se desmontar no Outlook, e um código perfeitamente válido segundo o W3C pode dar um resultado inutilizável. Estas são as restrições reais, e os motivos delas.

Por que essas restrições existem

Nem todos os clientes de e-mail usam um mecanismo de renderização web. O Outlook para Windows — na versão clássica, ainda muito presente nas empresas — exibe o HTML com o mecanismo do Microsoft Word. O Word nunca foi feito para isso, e o suporte dele ao CSS se limita a um subconjunto restrito.

Os webmails, por sua vez, limpam o HTML recebido por razões de segurança: removem scripts, muitas vezes as tags <style> e, às vezes, atributos inteiros.

Uma assinatura precisa, portanto, aparecer corretamente no menor denominador comum. O novo Outlook melhora a situação — veja o que muda em 2026 —, mas, enquanto o cliente antigo continuar em uso nas empresas, a restrição permanece.

Regra 1 — Tabelas para o layout

flexbox e grid não são suportados pelo mecanismo do Word. Os elementos se empilham na vertical e qualquer layout em colunas desaparece.

O posicionamento deve, portanto, se apoiar em tabelas:

<table cellpadding="0" cellspacing="0" border="0" role="presentation">
  <tr>
    <td style="padding-right:16px;vertical-align:top">
      <img src="..." width="120" height="40" alt="Empresa" />
    </td>
    <td style="vertical-align:top">
      <div style="font-weight:700">Nome Sobrenome</div>
    </td>
  </tr>
</table>

Três detalhes importam. cellpadding="0" cellspacing="0" border="0" neutraliza os espaçamentos padrão, que variam de um cliente para outro. role="presentation" indica aos leitores de tela que a tabela serve ao layout, e não a dados. E o vertical-align precisa ser explícito: os valores padrão são diferentes.

Regra 2 — Todos os estilos inline

Uma folha de estilo externa fica inacessível. Uma tag <style> é removida com frequência. E, quando se cola uma assinatura no campo de configuração de um cliente, tudo o que não está em um atributo style desaparece.

Cada propriedade deve, portanto, ser declarada no próprio elemento. É verboso, redundante e não tem alternativa.

Regra 3 — Dimensões de imagem em atributos

O Outlook ignora com frequência width e height declarados no CSS. A imagem aparece então no tamanho original: um arquivo de 1.200 px ocupa toda a largura da mensagem.

Coloque as dimensões nos atributos HTML, repetindo no CSS para os clientes modernos:

<img src="https://cdn.exemplo.com.br/logo.png"
     width="180" height="48" alt="Empresa"
     style="display:block;border:0;width:180px;height:48px" />

display:block elimina o espaço indesejado abaixo da imagem; border:0 tira a borda azul quando ela é clicável. Os detalhes estão em inserir um logo sem que ele quebre.

Regra 4 — Fontes do sistema, com pilha de alternativas

As web fonts não carregam de forma confiável. Declare uma pilha realista:

font-family: Arial, Helvetica, sans-serif;

É melhor escolher você mesmo a fonte substituta do que deixar o cliente escolher.

Regra 5 — Unidades absolutas

As unidades relativas — rem, em, porcentagens nos tamanhos de texto — se comportam de forma irregular. Use pixels para tamanhos de fonte, espaçamentos internos e dimensões de imagem. As porcentagens continuam aceitáveis na largura das tabelas.

Regra 6 — Links explícitos

Um link deve ter o protocolo completo, inclusive para o telefone:

<a href="tel:+5511912345678" style="color:#1A1A1A;text-decoration:none">+55 11 91234-5678</a>

Sem style explícito, alguns clientes aplicam o próprio azul sublinhado, que vai destoar da sua identidade visual.

Regra 7 — Um conteúdo acessível sem as imagens

As imagens remotas são bloqueadas por padrão para remetentes desconhecidos. Se a sua assinatura depender de uma imagem, o destinatário verá um retângulo vazio no lugar dos seus dados de contato.

O nome, o cargo, o telefone e as informações legais devem continuar em texto. E cada imagem deve ter um alt útil — o nome da empresa para o logo, o nome da rede para um ícone.

Bom saber: teste sempre com as imagens desativadas. É o teste mais rápido para saber se a sua assinatura continua útil no pior cenário.

É preciso escrever esse HTML à mão?

É possível, e é um mau uso do tempo. Os erros clássicos — tabela não fechada, cellspacing esquecido, dimensão ausente, estilo perdido em um copiar e colar — são difíceis de identificar na leitura e só aparecem em alguns clientes.

Um editor visual que gera diretamente um HTML de acordo com essas regras e pré-visualiza o resultado no Outlook para Windows, no Outlook na Web, no Gmail, no Apple Mail e no celular evita a maior parte do problema. É o que faz o editor do Signally, com acesso gratuito.

O ganho não é só de tempo: é de confiabilidade. Um modelo centralizado garante que as regras acima sejam respeitadas por todas as assinaturas da organização, inclusive as das pessoas que nunca ouviram falar de cellpadding.