Solução de problemas do Emailify

Guia de solução de problemas do Emailify para questões de design, exportação e de clientes de e-mail específicos.

Figma ​

Designs de e-mail do Figma criados fora do Emailify não são compatíveis ​

Monte o layout do e-mail com as ferramentas de design do Emailify antes de exportar o HTML pronto para produção. Essas ferramentas adicionam as camadas Row, Column, Button e outras camadas estruturadas de que o Emailify precisa para gerar o HTML. Depois de adicioná-las, você pode personalizar o conteúdo e os estilos.

Camadas ou frames criados antes no Figma sem o plugin Emailify serão renderizados como uma imagem estática, e não como conteúdo HTML ou rich text.

Definir o formato de exportação das imagens ​

O Emailify detecta automaticamente se uma camada tem áreas totalmente transparentes e, nesse caso, define PNG como formato de exportação padrão; caso contrário, define JPG. Você pode mudar o formato de exportação de qualquer camada para JPG ou PNG adicionando sua própria configuração de exportação.

Travamentos com as configurações “Scroll Wheel” ou “Drag to Pan” do Figma ativadas ​

Existe um problema aleatório em que o plugin ou o canvas podem travar de um jeito estranho quando essas configurações (mostradas na captura de tela abaixo) estão ativadas.

Se isso estiver acontecendo no seu arquivo do Figma, você pode resolver desativando essas configurações: abra o Main Figma Menu, vá até Preferences e desmarque as opções Use scroll wheel zoom e Right-click and drag to pan.

Preferências de zoom com a roda do mouse e de arrastar para mover no Figma

Destaque o texto que você quer transformar em link na camada de texto do Figma e clique no botão com o ícone “Link” nativo do Figma, na barra de ferramentas do cabeçalho do Figma. Assim você pode colar uma URL, que o Emailify renderiza automaticamente.

Use isso só em camadas de texto de conteúdo (não em botões nem em links de navegação). Isso só funciona em camadas de texto de conteúdo normais; para definir um link em uma camada de botão, ícone de rede social ou link de navegação gerada pelo Emailify, clique nessa camada do Figma, clique no botão Settings no cabeçalho do plugin Emailify e cole sua URL no campo de link.

Se um botão aparece vazio ou um link de navegação está faltando, mesmo com o texto visível no Figma, a causa pode ser um problema de exportação com dados de fonte mistos, incluindo fontes variáveis. Uma URL de link correta não garante que o rótulo foi exportado.

Mantenha os rótulos como texto editável dentro dos componentes originais de Button ou de navegação do Emailify. Feche e abra o Emailify de novo, atualize a pré-visualização e exporte outra vez. Confira o HTML baixado antes de fazer o upload para a sua plataforma de e-mail.

Se os rótulos continuarem faltando, entre em contato com o suporte e envie o frame de e-mail do Figma afetado e o HTML ou ZIP exportado, para que a gente possa inspecionar as camadas de texto e reproduzir o problema.

Adicionar texto sobrescrito ou subscrito ​

Você pode adicionar sobrescrito e subscrito às camadas de texto do Figma, e isso é renderizado automaticamente como tags de sobrescrito (por exemplo, sup) ou subscrito (por exemplo, sub) na exportação HTML do plugin.

Usar tags de título (por exemplo, h1, h2, h3) no texto do HTML ​

Se precisar, você pode trocar a tag de parágrafo padrão (p) por qualquer tag de título (por exemplo, h1, h2). Você pode envolver o conteúdo da camada de texto do Figma com a tag de título que quiser, e a troca da tag é feita automaticamente quando o HTML é exportado pelo plugin Emailify.

Arquivos sem extensão no app para desktop do Figma no Windows ​

Existe um problema conhecido no app para desktop do Figma (só no Windows), que também acontece nas exportações normais de arquivos do Figma. Ao salvar o arquivo, talvez você veja o rótulo “all files”. Se ignorar isso e continuar clicando em “Save”, o arquivo deve ser salvo com a extensão correta e abrir normalmente depois de baixado para o seu computador. Se mesmo assim o arquivo for salvo sem extensão, você pode renomeá-lo e adicionar manualmente a extensão correta ao nome do arquivo.

Otimizar seus designs para reduzir o tamanho da exportação HTML ​

O número de componentes Row é o que mais afeta o tamanho do HTML exportado, porque cada Row cria mais um conjunto de elementos de tabela. Reutilize uma Row quando o conteúdo couber na mesma estrutura.

Por exemplo, um título, um subtítulo, o corpo do texto e um botão podem ficar na mesma Column dentro de uma Row. Eles não precisam de quatro camadas Row separadas.

As opções do painel de configurações do Emailify não aparecem ao clicar em uma camada do Emailify no Figma ​

Se você clica em uma camada do Emailify no seu design do Figma e as configurações não aparecem ao clicar no botão Settings no cabeçalho do plugin, talvez o frame principal do Emailify esteja aninhado dentro de outros frames, grupos etc. Para resolver, tire o frame do Emailify de dentro dos frames ou camadas em que ele está aninhado e leve-o de volta ao nível da “Page”, para que ele não fique dentro de nenhuma outra camada.

Os parâmetros de consulta UTM são removidos ao enviar um e-mail HTML ​

Existem alguns motivos para os parâmetros de query string UTM serem removidos quando você envia seus e-mails HTML, já que, mais ou menos no último ano, cada vez mais navegadores e dispositivos começaram a removê-los automaticamente (por questões de privacidade). Se as query strings funcionam quando você abre os links na janela de pré-visualização do Emailify, mas não depois que o e-mail é enviado pela sua plataforma de e-mail marketing, provavelmente algum redirecionador ou encurtador de links adicional é aplicado no envio e está removendo ou quebrando esses parâmetros.

Lentidão em “Please wait, loading Figma images...” ​

Há algum tempo, uma atualização do Figma passou a obrigar todos os plugins do Figma a esperar o carregamento de todas as imagens em resolução máxima da página atual do Figma antes de exportar qualquer dado de imagem (mesmo que o plugin só precise de uma camada ou imagem).

Por enquanto, a única solução é tentar limitar o número de frames e camadas na página atual do Figma, o que deixa esse processo muito mais rápido quando o plugin é executado pela primeira vez. Por exemplo, você pode criar uma página nova no seu arquivo do Figma atual, levar para essa página em branco só os frames do Emailify em que quer trabalhar ou que quer exportar, e ela deve carregar muito mais rápido quando você executar o plugin de novo ali.

Imagens exportadas pixeladas ​

Se você exportar o e-mail enquanto as imagens no Figma ainda estão carregando progressivamente, elas podem sair pixeladas, porque a imagem não tinha carregado por completo no arquivo do Figma antes da exportação. Para resolver, confira se todas as imagens carregaram 100% e estão nítidas no arquivo do Figma antes de exportar os e-mails com o plugin Emailify.

Para ajudar ainda mais a resolver esse problema, você pode usar o recurso “Downsizer” do TinyImage para reduzir os preenchimentos de imagem ao tamanho das camadas, o que diminui o tamanho dos arquivos e faz com que carreguem muito mais rápido no seu arquivo do Figma.

Linhas pontilhadas ao editar PDFs no Adobe Acrobat ​

Para resolver, desmarque a opção “Show bounding boxes” na barra lateral do app Acrobat enquanto edita o PDF. Mostrar as linhas pontilhadas das caixas delimitadoras é algo que a Adobe ativa por padrão ao entrar no modo “Edit” com um PDF aberto no app, mas desativar a opção “Show bounding boxes” esconde essas linhas com um clique.

Pode ser necessário usar uma VPN na China ​

Atenção: se você estiver na China, o servidor de contas pode estar bloqueado pelo “Grande Firewall da China”. Se aparecer um erro de ativação mesmo com uma chave válida, provavelmente você vai precisar usar uma VPN para resolver o problema.

“An error occurred while loading the plugin environment” ​

Isso pode acontecer no app para desktop do Figma se a configuração de depuração Use Developer VM do Figma tiver sido ativada por engano. Para garantir que ela esteja desativada, clique com o botão direito em qualquer lugar do canvas do Figma, passe o mouse sobre Plugins, depois sobre Development, e confira se Use Developer VM está desmarcado. Depois de desmarcar a opção (ela não deve ter um ícone de visto ao lado), o plugin para Figma deve funcionar normalmente quando você executá-lo de novo.

Uploads de imagens bloqueados na sua rede ​

Se você ativou o recurso Upload Hosted Image URLs ou fez o upload do e-mail HTML para qualquer plataforma de e-mail usando as opções de exportação nativas do Emailify, o plugin faz automaticamente o upload das imagens para hospedá-las on-line.

Se aparecer uma mensagem de aviso no plugin (Images uploads may be blocked on your current network), significa que o plugin não consegue acessar o serviço de upload necessário para hospedar essas imagens on-line.

Isso costuma acontecer porque a rede (por exemplo, a da sua empresa, que pode ter um firewall bloqueando certas URLs) ou o provedor de internet ao qual você está conectado restringe ou bloqueia as URLs. Para resolver:

  • Tente rotear a internet do celular para o computador (ponto de acesso Wi-Fi) e execute de novo o plugin Emailify para Figma para ver se o problema é resolvido. Se for, sua outra rede estava bloqueando as solicitações.
  • Você também pode tentar usar uma VPN, que deve encapsular as solicitações de rede e contornar qualquer bloqueio de rede.
  • Se você já usa uma VPN, tente desativá-la e execute de novo o plugin Emailify para Figma para ver se o problema é resolvido.

Se o problema continuar, fale com a gente por e-mail.

Clientes de e-mail ​

O novo Outlook pode reescrever os estilos depois que o e-mail carrega ​

O novo Outlook para Windows tem um problema de pós-processamento relatado que pode fazer o e-mail aparecer corretamente no início e mudar depois de carregado. O Outlook parece reescrever partes do CSS do e-mail nessa segunda etapa de renderização, o que pode causar problemas como colunas de desktop que se empilham verticalmente sem motivo.

Esse comportamento é inconsistente: um destinatário pode ser afetado enquanto todos os outros veem o layout esperado, e envios de teste idênticos podem ser renderizados de formas diferentes na mesma caixa de entrada. A Customer.io documentou esses sintomas e as descobertas atuais em New Outlook, same headache.

As novas exportações do Emailify incluem uma camada de compatibilidade preventiva para o caso conhecido de empilhamento de colunas. O Emailify mantém os estilos responsivos originais do MJML e as alternativas em tabelas para o Outlook clássico e coloca uma segunda cópia, só com as regras de largura de colunas de desktop geradas, dentro do corpo do e-mail. Isso ajuda as variantes do Outlook na web que removem os estilos do head do e-mail e preserva o empilhamento normal no celular e os breakpoints do MJML nos outros clientes.

Você não precisa refazer o design. Atualize o Emailify e exporte o e-mail de novo para que o HTML gerado contenha essa alternativa antes de enviar outro teste.

Se você encontrar esse problema:

  • Abra o e-mail afetado em uma janela separada, em vez do painel de leitura ou pré-visualização do Outlook. Nos casos relatados, o e-mail costuma aparecer corretamente na janela separada.
  • Envie o mesmo HTML exportado para outro destinatário ou cliente de e-mail para ver se o problema se limita a um usuário do Outlook.
  • Se envios idênticos aparecerem de formas diferentes, baixe as duas mensagens recebidas como arquivos .eml e compare o HTML delas antes de mudar o design ou a exportação do Emailify.

A alternativa reduz a falha relatada de empilhamento de colunas no desktop, mas o Emailify não consegue controlar todas as reescritas de estilo feitas depois da entrega. Se o problema continuar e o HTML recebido não tiver mudado, evite fazer grandes mudanças no design só para resolver uma pré-visualização inconsistente do Outlook.

Encaminhar templates de e-mail HTML quebra o layout ​

Infelizmente, quando alguém encaminha para outra pessoa um e-mail HTML personalizado que recebeu, o visual do e-mail muitas vezes quebra depois do encaminhamento.

Isso acontece porque os clientes de e-mail modificam (ou removem) parte do código HTML quando o e-mail é encaminhado, o que faz o layout quebrar, como explica este artigo da Litmus, When Forwarded Emails Break:

Todo mundo sabe que cada cliente de e-mail renderiza os e-mails de um jeito. Quando um assinante encaminha um e-mail, alguns clientes de e-mail fazem mudanças no código da mensagem encaminhada. Isso pode incluir remover certos elementos HTML, envolver o e-mail em um blockquote ou inserir classes adicionais no código, e tudo isso pode quebrar o design e deixar o e-mail menos funcional para quem o recebe encaminhado.

Uma opção comum para reduzir esse impacto é ter uma versão “Web link” que possa ser aberta no navegador caso o e-mail não seja exibido corretamente, geralmente adicionada em algum lugar no topo do e-mail (como esta no MailChimp). Se precisar, você também pode criar isso como um link compartilhável em algum lugar do e-mail.

Meus e-mails estão indo para o spam. O que pode estar causando isso? ​

Existem alguns motivos comuns para seus e-mails caírem no spam:

  • Links demais: cada link afeta a entregabilidade. Remova os links que não forem essenciais, incluindo links de redes sociais desnecessários, para melhorar a chegada à caixa de entrada.
  • Reputação ruim do remetente: se o seu domínio ou IP tem um histórico de pouco engajamento, devoluções ou reclamações, os provedores de e-mail podem marcar seus e-mails.
  • Conteúdo com cara de spam: o excesso de linguagem promocional (por exemplo, “Grátis!”, “Aja agora!”, “Oferta por tempo limitado”) ou muitas imagens e pouco texto podem acionar os filtros.
  • Problemas de autenticação: confira se você configurou corretamente SPF, DKIM e DMARC no domínio de envio.
  • Pouco engajamento: se os assinantes não costumam abrir nem clicar, é mais provável que seus próximos e-mails sejam marcados como spam.
  • Qualidade da lista: enviar para listas antigas ou compradas pode causar devoluções e reclamações de spam que prejudicam sua pontuação de remetente.

Comece simplificando o e-mail, verificando a autenticação do domínio e cortando os links desnecessários; só essas mudanças já costumam melhorar a entregabilidade.

Os ajustes de modo escuro só funcionam nos apps Apple Mail do iOS e do Mac ​

Por enquanto, a compatibilidade dos clientes de e-mail com estilos de ajuste para o modo escuro ainda é relativamente baixa. Tenha isso em mente e tente criar seus e-mails pensando nesses ajustes de modo escuro como um “aprimoramento progressivo”.

Também vale a pena usar outras técnicas de design inteligentes para criar o e-mail pensando no modo escuro, como alternativa nos outros clientes de e-mail.

A solução do Gmail para o texto branco dos botões tem um objetivo mais limitado: preservar o texto branco puro dos botões. Ela não serve para manter inalterado um texto preto sobre um fundo claro no modo escuro do Gmail.

Linhas brancas finas de subpixel em imagens empilhadas no celular ​

Isso às vezes acontece quando você usa imagens inline de largura total, porque, dependendo da largura do dispositivo, quando a imagem é reduzida no celular, esses “subpixels” podem entrar na altura da imagem (é isso que deixa aquele espaço fino entre as imagens e deixa o fundo aparecer por trás).

A solução mais rápida é adicionar uma camada Wrapper em volta das camadas “Row” que contêm essas imagens e definir o fundo desse Wrapper como um “Linear Gradient” com a sua cor de fundo (por exemplo, cinza) nos dois lados do gradiente. Assim, o fundo é renderizado como uma imagem, o que evita que a cor de fundo do CSS seja trocada ou invertida para preto no modo escuro, e deve garantir um fundo uniforme atrás das linhas de imagens para cobrir esses espaços de subpixel.

As fontes do Google e personalizadas incorporadas só funcionam nos apps Apple Mail do iOS e do macOS ​

Por enquanto, as fontes personalizadas só são compatíveis com o Apple Mail para iOS e macOS entre os clientes de e-mail, então recomendamos usar fontes seguras para a web nas camadas de texto do Figma. Você pode defini-las no painel Configure Fonts, no recurso “Preview” do Emailify.

Além disso, alguns provedores de serviços de e-mail (como o MailChimp) removem essas fontes antes mesmo de o e-mail ser enviado, para garantir que só sejam usadas fontes seguras para a web.

Mesmo assim, o Emailify inclui os @imports das fontes do Google e também define uma fonte alternativa segura para a web (por exemplo, “Arial”, “Georgia” ou “Courier”) quando uma fonte do Google é usada em rich text. Elas aparecem em qualquer cliente de e-mail compatível com @font-face nos e-mails.

Use fontes personalizadas nas suas imagens. Se você precisa garantir que uma fonte personalizada fique visualmente igual em todos os clientes de e-mail, pode valer a pena colocar as camadas de texto dentro de um frame “Image”. Esse texto é exportado como parte da própria imagem e, por isso, não depende da compatibilidade com fontes web personalizadas para ser exibido corretamente.

Elementos de formulário em e-mails não são compatíveis ​

A compatibilidade com elementos de form em e-mails HTML ainda é bem baixa, e incluí-los pode fazer os e-mails serem marcados como spam, entre outros problemas. Por isso, por enquanto, é melhor evitar formulários nativos dentro de e-mails HTML.

A melhor alternativa é criar um botão de call to action (CTA) bonito no seu design do Emailify e vinculá-lo a uma URL de formulário externa, como Google Forms ou Typeform, para coletar as informações dos destinatários pelo navegador.

Entender como funciona o bloqueio de imagens em alguns clientes ​

Abaixo estão dois artigos muito bons que explicam o que é o bloqueio de imagens e quais clientes de e-mail o ativam por padrão (principalmente o Outlook), enquanto outros clientes, como Gmail, Android, Apple/iOS etc., mostram as imagens por padrão.

How Image Blocking Works in Email

Email Image Blocking: Answering the What, Why, Where, Who, and How

Infelizmente, isso não tem relação com as imagens serem seguras (SSL) ou não: o bloqueio sempre vale para todas as imagens dentro do e-mail.

O lado bom é que, normalmente, quem usa um desses clientes de e-mail já está acostumado com isso e clica no botão “show images”, ou, mais provavelmente, já configurou as imagens para aparecer por padrão nos e-mails recebidos.

Texto roxo no Gmail (vários envios de teste com o mesmo assunto) ​

Se você enviar vários testes de um e-mail para uma conta do Gmail, talvez perceba que parte do texto aparece em roxo-escuro.

Isso não é um problema no seu código HTML; acontece quando o Gmail decide que vários e-mails enviados no mesmo dia com o mesmo assunto são respostas uns dos outros. Quando isso acontece, ele mostra a sequência de e-mails em uma “visualização de conversa”.

Para saber mais sobre a visualização de conversa do Gmail, leia a documentação do Google:

A cor roxa é um recurso apenas de exibição, que só existe na tela em que está sendo vista. Ela não é enviada em nenhuma mensagem, e você pode usar o recurso de mostrar o original do Gmail para confirmar isso; para isso, é preciso entender um pouco de código HTML.

A cor é aplicada ao texto que se repete de uma mensagem anterior na conversa atual, e ela aparece para os destinatários porque eles também usam o Gmail e também têm cópias das mensagens anteriores da conversa atual. O que fica colorido na conversa deles pode ser bem diferente do que fica colorido na sua.

Esse é um problema antigo em que alguns clientes de e-mail aplicam links automaticamente a coisas como datas, números de telefone e endereços e também aplicam seus próprios estilos de cor a eles (geralmente links azuis).

O Emailify aplica automaticamente todas as correções de código sugeridas para ajudar a reduzir isso em alguns clientes de e-mail, mas os clientes costumam ser atualizados de um jeito que contorna ou impede a aplicação dessas correções.

Existem 2 métodos extras que você pode tentar para evitar que o cliente de e-mail adicione links automaticamente (os dois são citados nos artigos acima):

Método nº 1: aplique antes um link provisório (por exemplo, para o seu próprio site) a cada uma dessas camadas de texto no Figma, remova qualquer estilo de sublinhado no Figma e defina a cor que quiser (para que não pareça clicável). Isso coloca uma tag de link em volta do texto da data, e o cliente de e-mail não tenta aplicar automaticamente um link próprio sem estilo.

Método nº 2: adicione uma entidade HTML invisível especial (que é ‌) logo depois do primeiro caractere de cada data, número de telefone ou endereço (por exemplo, 6‌75 Massachusetts Ave, Cambridge, MA 02139). Com sorte, isso faz o cliente de e-mail achar que não é uma data e evita que ele aplique um link de data automaticamente.

Algumas VPNs podem ser impedidas de exibir as imagens enviadas ​

Se você ativou o recurso Upload Hosted Image URLs ou fez o upload do e-mail HTML para qualquer plataforma de e-mail usando as opções de exportação nativas do Emailify, existe um caso extremo muito raro em que certos endereços IP atribuídos por algumas VPNs são bloqueados pelo serviço de hospedagem de imagens, o que impede as imagens de carregar.

Se você tiver problemas com imagens que não carregam, essa é a causa provável (desative a VPN temporariamente para confirmar).

Assinaturas de e-mail não são compatíveis com fontes personalizadas ​

Ao contrário dos e-mails HTML completos ou normais, em que dá para incorporar fontes personalizadas (mas só para o Apple Mail; outros clientes, como Gmail e Outlook, não aceitam nenhum tipo de fonte personalizada incorporada), as assinaturas de e-mail não aceitam uma tag style para adicionar qualquer código de incorporação de fontes. Por isso, crie suas assinaturas usando fontes do sistema seguras para a web.

O app do Gmail para iOS não renderiza os estilos responsivos para celular ​

O principal motivo é quando alguma das propriedades ou estilos CSS na query @media tem um erro de digitação (por exemplo, padding-bottm em vez de padding-bottom) ou quando há uma quebra de linha no meio de uma propriedade de estilo (por exemplo, padd nova linha ing-top). Nesses casos, o app do Gmail ignora todos os outros estilos e não renderiza nenhum ajuste responsivo para celular.

Isso não deve acontecer com o código exportado diretamente pelo plugin, mas pode ocorrer se você editar o código HTML manualmente depois de exportá-lo do Emailify (ou se a sua plataforma de e-mail marketing modificar o código ou adicionar limites de comprimento de linha).

Limite de 500 caracteres por linha em e-mails HTML ​

O Emailify limita o HTML exportado a 500 caracteres por linha. Embora o limite formal seja de 998 caracteres, linhas mais curtas evitam problemas de renderização e de entrega vistos no Outlook e em alguns provedores de serviços de e-mail.

Embora pareça raro, se você tiver problemas com links para algumas redes sociais (por exemplo, Facebook, Instagram) que não abrem corretamente, essa é a causa provável (desative a VPN temporariamente para confirmar), e não um problema do e-mail HTML ou dos próprios links.

Outlook ​

O arredondamento de bordas não aparece no Outlook ​

Infelizmente, a propriedade border-radius não é compatível com o Outlook, então ele sempre volta para cantos retos normais. Consulte a lista de compatibilidade do border-radius para ter uma ideia melhor de quais clientes de e-mail aceitam essa propriedade CSS.

A altura do botão encolhe no Outlook.com (por não ter uma URL real) ​

Se a altura de um componente de botão está encolhendo até o tamanho da camada de texto dentro dele, é porque o Outlook.com faz isso quando o href não está definido com uma URL real (por exemplo, [replaceLinkInHere] em vez de uma URL real como https://google.com). Defina uma URL real no componente de botão: clique na camada do botão no Figma, use o botão Settings no plugin e cole sua URL ali.

Linha branca de 1px em rows com “ordem invertida” em algumas versões do Outlook ​

Existe um bug conhecido em algumas versões do Outlook ao usar a configuração de colunas invertidas, em que pode aparecer uma linha branca de 1px ao lado de uma das colunas. Essa é uma das peculiaridades de renderização do Outlook causadas pelo mecanismo de renderização do Microsoft Word, e pode acontecer quando a Row invertida também tem padding aplicado.

A melhor solução é remover o padding dessa camada Row invertida, envolver a Row em um Wrapper e passar o padding para o Wrapper externo. Isso mantém o mesmo espaçamento visual, mas evita o bug de renderização do Outlook na própria Row invertida.

Essa solução segue a abordagem discutida na issue do MJML no GitHub relacionada.

Para evitar que o Outlook interprete o texto como data ou horário e o renderize automaticamente como link, você pode inserir uma entidade HTML de “espaço de largura zero” (​) entre os dias, datas e horários para quebrar o reconhecimento de padrões do Outlook, como neste exemplo testado e funcionando: Monday​ — Friday 8​am to 5​pm

Texto em maiúsculas com acentos (diacríticos) cortado ​

Se você tem uma camada de texto em maiúsculas e alguns caracteres têm diacríticos (por exemplo, Ä, Ö, Ü) cujo acento de cima não aparece no Outlook, isso acontece porque o valor de “line height” da camada de texto no Figma é menor que o valor de “font size” do texto, e o Outlook basicamente recorta qualquer conteúdo que não caiba no valor de line-height (ao contrário de outros clientes, que simplesmente deixam o conteúdo transbordar normalmente).

Para resolver, basta aumentar o valor de line-height para um pouco mais que o tamanho da fonte. Por exemplo, se você tem uma camada de texto com fonte de “24px” e o line-height está em “23px”, aumente o line-height de “23px” para “28px” no Figma (para dar altura extra suficiente aos acentos que ficam acima das maiúsculas de 24px). Assim, os acentos e diacríticos são renderizados corretamente no Outlook, sem serem cortados por causa do line-height menor.

O bug aleatório da “linha de 1px” no Outlook ​

Existe um problema bem chato conhecido como o bug da linha de 1px do Outlook, que aparece aleatoriamente em algumas versões do Outlook, em que:

O Outlook adiciona linhas extras aos nossos e-mails. Essas linhas herdam o fundo definido na tag body... e, para piorar, esse bug parece acontecer aleatoriamente, embora apareça com mais frequência em máquinas com Windows 10 do que com Windows 7.

Como diz o artigo acima, embora seja bem aleatório e não exista uma correção confiável, o problema costuma ser resolvido com algumas tentativas de ajustar o tamanho da fonte do texto acima de onde a linha aparece. Por exemplo (do artigo):

Para algumas pessoas, a correção é tão simples quanto trocar tamanhos de fonte ímpares por pares. Por exemplo, se você tem uma fonte de 13px ou 15px, tente mudar para 14px.

Também existe outro bom artigo, Fixing White Lines in Outlook, que traz mais detalhes e possíveis correções.

Para se aprofundar, o artigo Outlook 2016 madness and the weird 1px thin horizontal lines dá mais detalhes sobre o problema de fundo, e esta discussão detalhada no fórum da Litmus também levanta possíveis causas e formas de tentar resolver.

Gmail ​

O Gmail corta o e-mail ​

O Gmail corta e-mails com mensagem maior que 102KB e esconde o conteúdo completo atrás de um link “View entire message”. Para evitar isso, use o botão Preview para ver o tamanho do arquivo HTML antes de exportar e remova o máximo de conteúdo possível para tentar reduzir o tamanho do arquivo.

Se o e-mail continuar sendo cortado mesmo abaixo do limite de tamanho do arquivo HTML, a causa mais provável é um caractere UTF-8 no conteúdo do e-mail, que também pode fazer o Gmail cortá-lo. A melhor solução é trocar o caractere UTF-8 pela versão codificada em HTML (por exemplo, usar &copy em vez de ©), o que o plugin faz automaticamente.

Outro motivo é enviar e-mails com o mesmo assunto (por exemplo, ao enviar vários testes para você mesmo): o Gmail junta os e-mails em uma única conversa e pode cortar o conteúdo dos envios seguintes. Para contornar isso, use sempre um assunto diferente (por exemplo, “Test v1”, “Test v2” etc.).

Botões com texto branco ficam pretos no modo escuro do app do Gmail para celular ​

O Gmail (e outros apps) aplica automaticamente estilos de modo escuro ao seu e-mail quando o tema do sistema do usuário está no modo escuro, e isso inclui os botões.

Para botões que devem ter texto branco tanto no modo claro quanto no escuro:

  1. Defina a camada de texto do botão como branco puro (#FFFFFF) no Figma.
  2. Selecione o componente Button, abra Settings e defina também a cor do texto no ajuste de modo escuro como branco puro (#FFFFFF).
  3. Exporte o e-mail de novo e envie um teste para o app do Gmail para celular em que você viu o problema.

Com as duas cores definidas como branco puro, o Emailify adiciona um código de compatibilidade extra para preservar o texto branco do botão. Essa solução não preserva texto preto ou de outras cores além do branco, nem fixa a cor de fundo do botão. Se o seu design precisa de texto preto sobre um fundo claro, mantenha essas cores e teste esse design separadamente; trocar o texto para branco mudaria o design em vez de atender a essa necessidade.

Se o resultado ainda for diferente do seu design, entre em contato com o suporte e envie o HTML ou ZIP exportado, uma captura de tela, o app de e-mail e o dispositivo, e as cores de texto e de fundo que você quer manter. Informe também as configurações que você já testou. Veja design e testes no modo escuro para conhecer o fluxo de trabalho completo e as limitações.

Colunas empilhadas no desktop no Gmail ​

Alguns provedores de serviços de e-mail (como o MailChimp) tentam modificar o HTML do seu e-mail antes do envio, o que pode fazer algumas colunas do e-mail ficarem empilhadas no Gmail no desktop, em vez de lado a lado.

Normalmente, essas plataformas modificam o HTML para fazer o “inlining” dos estilos nos elementos HTML. Mas o Emailify já faz o inlining de todos os estilos CSS automaticamente, para que seus e-mails fiquem prontos para produção. Se você encontrar uma configuração nas opções de HTML ou de importação do seu provedor de serviços de e-mail para “desativar” esse inlining ou essa modificação, o problema deve ser resolvido.

Se você não tiver certeza se a causa é o provedor de serviços de e-mail ou o próprio código, use um serviço gratuito como o htmltest.email (que não modifica nada do seu HTML) para enviar um e-mail de teste para você mesmo. Se o teste funcionar pelo htmltest.email, seu provedor de serviços de e-mail está modificando o HTML antes do envio.

O Gmail no iOS impõe um line-height mínimo ​

Se você definir o line-height com um valor menor que o font-size atual, o Gmail o troca automaticamente por line-height:normal;. Ou seja, line-height:1, line-height:1em e line-height:100% funcionam normalmente, mas line-height:0.9, line-height:0.9em e line-height:99% são todos convertidos em line-height:normal;.

O mesmo vale para valores em px: font-size:20px; line-height:19px não funciona, mas font-size:19px; line-height:19px funciona.

Para resolver, basta garantir que o line-height da camada de texto seja igual ou maior que o tamanho da fonte.

O app do Gmail para iOS não renderiza os estilos responsivos para celular ​

O principal motivo é quando alguma das propriedades ou estilos CSS na query @media tem um erro de digitação (por exemplo, padding-bottm em vez de padding-bottom) ou quando há uma quebra de linha no meio de uma propriedade de estilo (por exemplo, padd nova linha ing-top). Nesses casos, o app do Gmail ignora todos os outros estilos e não renderiza nenhum ajuste responsivo para celular.

Isso não deve acontecer com o código exportado diretamente pelo plugin, mas pode ocorrer se você editar o código HTML manualmente depois de exportá-lo do Emailify (ou se a sua plataforma de e-mail marketing modificar o código ou adicionar limites de comprimento de linha).

O Gmail traduz por engano e-mails só em inglês para outros idiomas ​

Se o seu e-mail tem principalmente blocos de imagem, sem rich text, ou muitos blocos de imagem antes de qualquer rich text mais abaixo no e-mail, às vezes o Gmail acha que o e-mail está em outro idioma e oferece a tradução para o inglês, mesmo que o Emailify adicione automaticamente o atributo lang="en" às tags html e body do código.

Como diz este artigo que discute o assunto nos fóruns da Litmus:

Descobrimos (empiricamente) que e-mails com muito CSS e HTML antes de qualquer conteúdo real são classificados como inglês, mesmo quando o conteúdo está em outro idioma.

Nossa solução é enviar um e-mail multipart com texto e HTML, com uma versão em texto antes da parte em HTML. Claro que o texto precisa ser consistente, não só “Bonjour ...”, senão as tags HTML e o CSS continuam predominando.

O algoritmo de tradução não parece tentar remover o HTML e o CSS do corpo do e-mail, ou, se tenta, talvez corte a mensagem antes de remover e acabe com pouquíssimo conteúdo para a detecção. (Hoje em dia é fácil acabar com mais de 5000 caracteres de cabeçalhos e CSS antes de uma única linha de conteúdo.)

GIFs ​

Converter vídeos em GIFs animados para seus e-mails ​

Embora as tags video nativas, infelizmente, não sejam compatíveis com e-mails HTML, a melhor forma de adicionar imagens animadas ou conteúdo em vídeo aos designs de e-mail HTML é usar GIFs, seja um arquivo GIF baixado da internet ou um que você mesmo criou.

Se você já tem um vídeo que quer usar como GIF, pode usar um app gratuito chamado Gifski para converter vídeos curtos em arquivos GIF animados para usar nos seus designs de e-mail.

Também existe um bom vídeo tutorial que mostra as diferentes formas de usar GIFs nos seus designs do Emailify e incluí-los nas exportações para HTML.

As cores e os gradientes dos GIFs ficam um pouco granulados ​

Os GIFs são um pouco diferentes das imagens JPG/PNG normais, porque só podem ter no máximo 256 cores. Se você usa imagens muito detalhadas ou gradientes com muita variação de cor, é normal que o resultado não fique tão nítido nem tenha a mesma precisão de cores das imagens originais usadas como fonte do GIF, por causa dessa limitação do formato GIF.

A transparência não aparece nos GIFs ​

O formato de arquivo GIF aceita opacidade de 0% ou de 100%, mas nada entre esses valores. Isso significa que você pode ter um GIF animado com fundo totalmente transparente atrás de elementos totalmente opacos e visíveis. Ou seja, as camadas precisam ser totalmente transparentes ou não; qualquer camada com opacidade menor que 50% fica transparente, e qualquer camada com opacidade maior que 50% fica opaca.

Marcar GIFs transparentes no Figma. O Emailify tenta detectar automaticamente se o seu GIF tem fundo transparente; se o GIF precisa de transparência e o plugin não está detectando isso sozinho, adicione a palavra Transparent em qualquer lugar do nome da camada no Figma (por exemplo, My Layer Name - Transparent) para forçar a exportação com o fundo transparente ativado.

Manter o arquivo GIF original na exportação (mantendo a proporção) ​

Se você colocar o GIF no Figma e redimensionar a camada proporcionalmente, mantendo a proporção original, o Emailify usa automaticamente o arquivo GIF original nas exportações.

Por outro lado, se você mudar a proporção da camada do Figma em relação ao GIF original, o Emailify vai precisar recriar o GIF para considerar a área recortada da imagem, o que pode gerar arquivos GIF maiores e exportações mais lentas.

A imagem GIF não aparece no Gmail (limite de tamanho do arquivo) ​

Se você usou GIFs no design, mas eles não aparecem quando você faz um envio de teste para uma caixa de entrada do Gmail, provavelmente o limite de cache de imagens do Gmail está sendo atingido, o que impede a renderização.

Durante a exportação para HTML, o Emailify tenta comprimir os GIFs grandes para deixá-los abaixo do limite de tamanho de arquivo do Gmail, o que deve resolver o problema em quase todos os casos (a menos que o GIF seja excepcionalmente longo, muito grande ou tenha uma taxa de quadros muito alta desde o início).

Klaviyo ​

O editor de templates do Klaviyo (às vezes) trava quando há GIFs no design do e-mail ​

Existe um bug aleatório no Klaviyo que causa um Error 500 (erro interno do servidor) e mostra uma página com a mensagem Something is amiss. We're on it.; isso parece acontecer principalmente quando o template é “Editable”.

O Klaviyo conhece esse bug, mas não parece haver planos de corrigi-lo no curto prazo.

Uma alternativa é remover o GIF do design no Figma antes de exportar o HTML para o Klaviyo e fazer o upload da imagem GIF separadamente no Klaviyo depois que o editor de templates carregar sem o erro acima.

Padding extra em volta dos blocos de texto em templates editáveis do Klaviyo ​

Como o Klaviyo atualizou o editor e passou a obrigar todos os templates a usá-lo a partir de 6 de junho de 2023, infelizmente, se você exportar e-mails HTML com a opção Editable Content ativada no Emailify, o Klaviyo aplica por padrão ~18px de padding adicional em volta de cada elemento de texto, como um atributo style inline em um novo elemento td que ele injeta no HTML quando o template é editável.

Ativar a opção Force the padding added by Klaviyo's new editor to be 0px no Emailify adiciona automaticamente um CSS extra para remover esse padding em todos os clientes de celular e nos clientes de desktop que não são o Outlook, como o Gmail. Mas o Outlook continua renderizando o padding, a menos que cada valor de “Padding” dos blocos de texto editáveis do template seja trocado manualmente para “0” ao editar o e-mail da sua Campaign no editor do Klaviyo.

O texto de pré-visualização do Klaviyo aparece duplicado ou mostra parte do corpo do e-mail ​

Defina o texto de pré-visualização em um lugar só. Se você já preencheu o Preheader Text no Emailify, deixe vazio o campo de texto de pré-visualização do próprio Klaviyo. Se preferir gerenciar o texto de pré-visualização no Klaviyo, deixe o preheader do Emailify em branco nessa exportação.

Se o Klaviyo continuar mostrando parte do corpo do e-mail depois do texto de pré-visualização que você definiu, ative Add Whitespace to Preview Text nas opções de exportação do Emailify e exporte o e-mail de novo. Isso adiciona um espaçador de compatibilidade oculto depois de um preheader preenchido, mas o comportamento da caixa de entrada ainda pode variar entre o Klaviyo e os diferentes clientes de e-mail.

Veja Definir o assunto e o texto de preheader dos seus e-mails HTML para conhecer o fluxo de trabalho completo do preheader.

MailChimp ​

Ativar imagens editáveis usa imagens @1x mais borradas (em vez de @2x retina) ​

Se quiser, você pode deixar as imagens do template editáveis no MailChimp com a opção Editable Images, mas, infelizmente, o MailChimp não aceita imagens @2x retina editáveis, então elas ficam em @1x.

Se preferir ter imagens @2x retina que não são editáveis, deixe essa opção desativada.

O MailChimp remove os estilos dos links quando uma Typekit stylesheet personalizada é adicionada ao e-mail. Mais especificamente, se você incluir uma tag como: <link rel="stylesheet" href="https://use.typekit.net/lml7iwl.css">

no <head>, o MailChimp remove todos os atributos style das suas tags <a>. Remover essa tag corrige o problema e restaura os estilos dos links.

Se ainda quiser usar suas fontes do Typekit, você pode fazer isso pelo recurso Web Fonts nativo do plugin. Em vez de vincular a folha de estilos, você vai precisar da URL direta do arquivo de fonte .woff2 no arquivo CSS do Typekit (por exemplo: https://use.typekit.net/...). Cole essa URL no painel Configure Fonts do plugin, e ele gera automaticamente o estilo @font-face correto para corresponder aos nomes das fontes do Figma no HTML. Veja o vídeo tutorial passo a passo para mais orientações.

As fontes web personalizadas só funcionam no Apple Mail. Outros clientes de e-mail (como Outlook ou Gmail) não são compatíveis com elas, então recomendamos definir uma fonte alternativa segura para a web no plugin para controlar o que aparece. Muitos usuários acham mais fácil criar o design com fontes seguras para a web no Figma, mas adicionar fontes web personalizadas ainda pode ser um bom aprimoramento progressivo para quem usa o Apple Mail.