O que checar antes de cada campanha e os limites da auditoria do Brew: corte em 102 KB, links quebrados, texto alternativo, compatibilidade e tamanho do texto.
Um checklist de QA antes do envio é a lista curta de verificações que você faz em todo e-mail antes que ele saia. Campanhas quebradas costumam sair com um botão que ainda aponta para #, uma imagem principal trocada às 18h por um PNG de 4 MB ou um layout de duas colunas que o Outlook clássico ignora. Cada um desses problemas leva um minuto para ser detectado antes do envio e não tem conserto depois.
Neste mês, reconstruímos a auditoria de e-mail do Brew em torno dessas verificações, cada uma com um limite exato. Faça-as manualmente, com ou sem o Brew.
Resultados agrupados por gravidade, com um único veredito de prontidão.
Um link quebrado desperdiça o envio. Verifique se:
#, example.com ou um {{url}} não preenchidohttpsbrew.new/pricing que leva a outro lugar parece phishingClique em todos os links num teste entregue, não no editor. O seu ESP reescreve os links para rastrear os cliques no momento do envio, então cadeias de redirecionamento e parâmetros de rastreamento quebrados só aparecem ali.
Nunca deixe um verificador automático acessar links de descadastro ou de preferências. Alguns provedores tratam qualquer acesso a essa URL como um descadastro. E uma barreira antibot exibida a um verificador não prova que o link está quebrado. Clique você mesmo.
O Gmail corta as mensagens com mais de cerca de 102 KB de HTML e deixa o restante atrás de um link “Exibir toda a mensagem” (“View entire message”). Com isso, o rodapé, o link de descadastro e o endereço postal ficam escondidos, e um e-mail de marketing cortado vira, sem alarde, um problema de conformidade.
Os nossos limites:
Avisamos a partir de 80 KB porque o rastreamento de cliques troca links curtos por URLs de redirecionamento mais longas, e alguns ESPs acrescentam marcação. Os 98 KB do seu editor podem chegar como 105 KB.
O inchaço mais comum: estilos inline repetidos em todos os elementos, comentários que sobraram do editor, seções duplicadas e ocultas para celular e desktop e imagens embutidas em base64.
Toda imagem deve:
alt, ou alt="" se for puramente decorativawidth e height, para o layout se manter enquanto as imagens carregam ou quando elas estão bloqueadasUma imagem grande em cima de uma linha de texto fica ilegível com as imagens desativadas, é opaca para leitores de tela e funciona como sinal de spam para alguns filtros. Coloque o título e a oferta em texto real.
Flexbox, grid, position, imagens de fundo e SVG inline quebram em pelo menos um cliente importante. O Can I email acompanha a compatibilidade por recurso e por cliente, e é a melhor referência que existe num só lugar.
Fique de olho principalmente no Outlook. O Gmail e o Apple Mail costumam degradar sem alarde. O Outlook clássico no Windows renderiza com o mecanismo de layout do Word, ignora muitas larguras de CSS, descarta imagens de fundo e remove o padding de botões feitos como links estilizados.
Só sinalizamos um recurso para uma família de clientes, como Gmail ou Outlook, quando pelo menos dois clientes dela o descartam. Ele só vira aviso quando o Outlook o quebra sem alternativa (fallback). Todo o resto fica no nível Info. Do contrário, cada e-mail receberia vinte avisos de clientes, e as pessoas ignorariam todos eles.
As verificações que custam pouco:
lang no <html>, para que os leitores de tela pronunciem as palavras corretamente<title>h1 para h4A referência é a WCAG 2.2. A maioria dos problemas de e-mail corresponde aos critérios dela sobre alternativas em texto, contraste, idioma da página e títulos.
Mantenha os assuntos abaixo de cerca de 60 caracteres e 9 palavras, ou os celulares vão cortá-los. Evite TUDO EM MAIÚSCULAS, “RE:” ou “FWD:” em e-mails que não são respostas e sequências de pontos de exclamação.
Mantenha o texto de pré-visualização abaixo de cerca de 90 caracteres, sem repetir o assunto. Se você deixá-lo vazio, muitos clientes mostram “Ver no navegador” no lugar dele.
Uma tag de mesclagem sem valor padrão envia “Olá, ,” para todo mundo que está sem o primeiro nome. Os leitores não esquecem.
Todo número deve ter uma fonte que você consiga indicar, principalmente nos primeiros rascunhos feitos com IA, que produzem números convincentes com facilidade. O guia Como escrever e-mails de marketing e o guia de linhas de assunto se aprofundam na redação.
Pela lei CAN-SPAM, o e-mail comercial precisa de um link de descadastro que funcione e de um endereço postal válido. Os remetentes em massa que enviam para o Gmail e o Yahoo também precisam de cabeçalhos de descadastro com um clique, explicados em O que continua valendo quando um agente envia os seus e-mails.
O e-mail transacional escapa de algumas regras de marketing, mas não deste checklist. Um recibo com um link quebrado continua virando um chamado no suporte.
Remova o que os clientes de e-mail removem ou bloqueiam:
<script>, <form> e <iframe>data:background-color de reserva, para que o texto continue legível se a imagem falharComece com um doctype. Sem ele, alguns clientes renderizam em modo quirks e o espaçamento muda.
A auditoria de e-mail do Brew roda esta lista a partir de:
POST /v1/emails/audit ou a ferramenta audit_emailVeja todos os campos na documentação da auditoria e na referência da API.
As verificações instantâneas, gratuitas, rodam automaticamente para todas as regras que só precisam do HTML: marcadores provisórios, tamanho, texto alternativo e dimensões de imagem ausentes, ordem dos títulos, lang e <title>, tamanho do assunto e do texto de pré-visualização, tags de mesclagem sem valor padrão e marcação bloqueada.
Executar auditoria acrescenta as verificações que precisam de rede ou de julgamento:
Cada julgamento da IA é calibrado para que um resultado apontado esteja certo em pelo menos 95% das vezes nos e-mails que são nossos. Um revisor de IA que dá alarme falso é pior do que nenhum.
Uma auditoria completa custa 5 créditos. Se uma verificação obrigatória estiver indisponível, você recebe uma auditoria parcial gratuita, sem pontuação, já que uma pontuação que pulou verificações enganaria.
Toda auditoria retorna uma pontuação de 0 a 100 e um estado: pronto, precisa de revisão ou não está pronto (no app, aparecem como Pronto para enviar, Precisa de revisão e Problemas encontrados). Cada resultado tem uma gravidade (Crítico, Erro, Aviso ou Info) e uma evidência, como o status HTTP de um link quebrado.
A pontuação começa em 100. Cada crítico custa 20 pontos; cada erro, 10; cada aviso, 3; e cada Info, nada. Só contam as três primeiras ocorrências de cada regra.
Exemplo: um botão com link para #, um link do rodapé que retorna 404, duas imagens sem texto alternativo, um assunto de 68 caracteres e um flexbox que dois clientes do Yahoo ignoram.
| Resultado | Gravidade | Pontos |
|---|---|---|
| O link do botão é um marcador provisório | Crítico | −20 |
| O link do rodapé retorna 404 | Erro | −10 |
| Imagem sem texto alternativo (×2) | Aviso | −6 |
| Assunto com mais de 60 caracteres | Aviso | −3 |
| Flexbox descartado por 2 clientes do Yahoo | Info | 0 |
| Pontuação | 61 |
Qualquer crítico ou erro significa “não está pronto”; só avisos, “precisa de revisão”. Corrija os dois links e este e-mail passa a ter 91 pontos, com o estado “precisa de revisão”. É um resultado honesto: o e-mail seria enviado sem problemas, e o resto vale um minuto de atenção.
Corrigir no chat passa os avisos e tudo o que for mais grave para o agente do Brew e depois roda de novo as verificações instantâneas gratuitas na versão corrigida.
Ela não bloqueia envios. Quando há resultados críticos, a janela de envio pede um Enviar assim mesmo e registra a exceção. Os envios pela API, pelo MCP e por automações informam os resultados e seguem em frente. Esse é o padrão certo. Alguns e-mails de que a auditoria não gosta devem sair mesmo assim, e uma ferramenta de QA que faz os envios de refém acaba sendo desligada.
Ela não reescreve o seu HTML. As correções são uma etapa separada, que você inicia.
Ela não testa a chegada à caixa de entrada, não gera capturas de tela da renderização nem verifica o modo escuro. Para o modo escuro, abra um teste no celular com o modo escuro ativado. É assim que você pega o logo que some no fundo preto.
Na janela de envio, 15 minutos. Depois disso, ou se o e-mail mudar, o painel pede que você a execute de novo. Pelo MCP, você pode ler de novo um relatório salvo durante 7 dias, sem custo.
Não. A auditoria verifica o e-mail em si. A chegada à caixa de entrada também depende da reputação do domínio, da autenticação e da taxa de reclamações, temas do guia de entregabilidade.
Sim, pela API ou pelo MCP. Envie emailHtml ou emailJsx no lugar do ID de um e-mail do Brew e receba o mesmo relatório antes de levar o e-mail para o seu ESP. Se você remixar um modelo da galeria e exportá-lo para o seu ESP, audite-o no Brew antes de exportar.
Qualquer pessoa com acesso à marca: os admins da organização e os membros adicionados a ela. O Brew não tem uma função só de visualização.
