O que é a estrutura de um e mail
A estrutura de um e mail é basicamente a maneira como uma mensagem eletrônica é organizada dentro dos sistemas de transporte de protocolo. Muita gente acha que é só colocar um assunto e escrever o texto, mas o funcionamento por trás disso é muito mais técnico do que a maioria das pessoas imagina. Quando você clica em enviar, várias partes estão sendo construídas ao mesmo tempo. Os cabeçalhos são a parte mais importante e a que quase ninguém vê. Eles vão antes do corpo da mensagem e contém informações como de onde o e mail veio, por quais servidores ele passou, qual protocolo foi usado e até metadados sobre o conteúdo. Tudo isso existe independentemente do que você escreveu no corpo.
Eu trabalhava com migração de servidores de e mail antigamente e um dos problemas mais chatos era justamente entender a estrutura real dos e mails que os clientes enviavam. Tem gente que manda e mail usando editores de texto puro sem formatar nada, e aí a estrutura vem toda bagunçada. Outros usam clientes que injetam rastreamento, pixels de abertura e scripts dentro do corpo. Isso bagunça a legibilidade da mensagem para quem está do outro lado.
Entendendo a estrutura de um e mail na prática
Um e mail típico dividido em duas camadas principais: os headers e o body. Os headers contêm campos como From, To, Subject, Date, MIME-Version, Content-Type, Reply-To e mais alguns outros que os servidores adicionam automaticamente durante o trânsito. O body é o conteúdo efetivo que o destinatário lê, e dentro dele existe uma subdivisão que as pessoas ignoram completamente: a parte texto simples e a parte HTML, que muitas vezes coexistem no mesmo e mail. O formato MIME permite que um e mail carregue múltiplos tipos de conteúdo junto. Um e mail padrão pode ter uma versão em texto puro dentro de uma parte e uma versão formatada em HTML dentro de outra parte separada. O cliente de e mail do destinatário decide qual exibir. Se o cliente não suportar HTML, ele mostra a versão em texto. Se suportar, mostra a versão formatada. Se o remetente esquecer de incluir a versão em texto, os clientes que não renderizam HTML recebem um e mail vazio ou incompreensível.
No meu caso, já vi gente enviar e mail apenas com a parte HTML ativa porque estava usando ferramentas de automação de marketing que vinham configuradas assim por padrão. Resultado: cerca de 15 a 20 por cento dos destinatários recebiam o e mail sem conseguir ler nada. A solução foi simples, mas demorou para descobrir. Basta ativar a opção de gerar a versão em texto puro automaticamente dentro da ferramenta. Aí o e mail passa a ter ambas as partes e funciona em qualquer cliente. Outro detalhe que as pessoas costumam negligenciar é a linha do Subject. Ela não pode ter caracteres especiais demais, não pode exceder certos limites de tamanho senão os servidores cortam. E se você colocar palavras sensíveis demais ou que pareçam spam, o e mail pode ser marcado antes mesmo de chegar na caixa de entrada. Isso não tem relação direta com a estrutura técnica, mas afeta diretamente se a estrutura chega intacta.
Os campos de cabeçalho também incluem Received, que mostra a trilha que o e mail percorreu desde o remetente até o destinatário. Cada servidor adiciona uma linha Received com data, hora e endereço IP. É possível usar essas informações para identificar se um e mail passou por algum servidor suspeito no caminho, o que ajuda bastante em situações de investigação de phishing ou de problemas de entrega. A estrutura também determina como anexos funcionam. Um arquivo anexado não viaja junto com o corpo do e mail como você pode imaginar. Ele é codificado em base64 e transformado em parte do corpo, com um Content-Type específico que identifica o tipo do arquivo. O cliente do destinatário decodifica de volta quando recebe. Se a codificação falhar ou o servidor intermediário corromper parte dela, o anexo chega quebrado. Isso acontece mais frequentemente com arquivos muito grandes ou com tipos raros que alguns filtros de segurança rejeitam.
Como montar a estrutura de um e mail corretamente
Se você está construindo um e mail manualmente ou desenvolvendo algo que gere e mails automaticamente, o processo básico envolve definir os cabeçalhos essenciais, estruturar o corpo com as versões em texto e HTML e adicionar os anexos se necessário. Vou explicar cada parte com calma. Os cabeçalhos obrigatórios mínimos são From, To e Subject. O campo From indica o endereço do remetente e deve ser um endereçamento válido, pois alguns servidores rejeitam e mail com From inválido. O campo To indica o destinatário principal. Você também pode usar Cc para cópia conhecida e Bcc para cópia oculta, que não aparece para os demais destinatários.
Além desses, há campos importantes que melhoram a entrega e a funcionalidade. O campo Reply-To define para onde as respostas devem ir, o que é útil quando você separa o endereço de envio do endereço de resposta. O campo MIME-Version informa a versão do padrão MIME usada. O campo Content-Type define o tipo de conteúdo do corpo, e o campo Content-Transfer-Encoding define como o conteúdo foi codificado, sendo base64 ou quoted-printable os mais comuns. No corpo da mensagem, a estrutura em partes mistas usa boundary strings para separar cada seção. Cada parte começa com um marcador que informa seu Content-Type e Content-Transfer-Encoding. A primeira parte geralmente carrega a versão em texto puro, e a segunda a versão em HTML. Existemboundary tags de início e fim que delimitam tudo. Se você errar um boundary, o e mail chega corrompido e o cliente não consegue montar a mensagem corretamente.
Uma coisa que muita gente não sabe é que o corpo de um e mail não é necessariamente apenas texto. Ele pode conter imagens embutidas em base64, links, tabelas, estilos CSS inline. Muitos desenvolvedores colocam CSS externo dentro do e mail esperando que funcione, mas a maioria dos clientes de e mail ignora CSS externo por segurança. O certo é colocar todo o estilo diretamente nos elementos HTML usando atributos inline. Isso aumenta o tamanho do código, mas garante que a formatação chegue correta. Quando se trata de anexos, cada arquivo recebe uma parte separada com Content-Disposition: attachment e um nome de arquivo identificado pelo campo filename. O tipo MIME do arquivo deve corresponder ao conteúdo real. Enviar um arquivo PDF com Content-Type de imagem é um erro comum que causa problemas de abertura em alguns clientes.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Existem ferramentas que facilitam muito a construção manual. O MIMEMessage do Python, por exemplo, permite criar e mails completos programaticamente com poucas linhas. O módulo email.mime do Python lida com a geração automática de boundary strings, headers e codificação. Se você estiver fazendo isso em outro idioma, procure bibliotecas equivalentes. Fazer manualmente sem biblioteca é possível, mas propenso a erros e demorado. Uma limitação real da estrutura tradicional de e mail é que ela não prevê muitos cenários modernos. E mails com conteúdo dinâmico que muda conforme o destinatário, por exemplo, precisam de soluções adicionais. Autenticação SPF, DKIM e DMARC não fazem parte da estrutura em si, mas são essenciais para a entrega e para evitar que o e mail seja considerado spam. Sem eles, mesmo uma estrutura perfeitamente montada pode cair na caixa de spam.
Outro ponto prático é o tamanho. E mails muito grandes tendem a ter problemas de entrega. Alguns servidores rejeitam e mails acima de 25 MB, outros aceitam mas demoram para processar. Se você precisa enviar arquivos grandes, o ideal é usar um serviço de compartilhamento e colocar o link no corpo do e mail em vez de anexar diretamente. Isso também evita que o anexo seja bloqueado por filtros de segurança. Uma situação que eu enfrentei recentemente envolvia um cliente que enviava newsletters com imagens inline em alta resolução. O e mail tinha mais de 4 MB. A taxa de entrega caía para cerca de 60 por cento e muitos destinatários reclamavam que o e mail levava minutos para carregar. A correção foi redimensionar as imagens para largura máxima de 600 pixels, comprimil-as e hospedá-las externamente com links ao invés de embutir. A taxa de entrega subiu para 94 por cento e o tempo de carregamento caiu para segundos.
Erros comuns na estrutura de um e mail
Um dos erros mais frequentes é colocar HTML mal formatado no corpo. Tags não fechadas, atributos soltos e estruturas inconsistentes fazem com que alguns clientes exibam o e mail de forma quebrada ou ignorem partes inteiras. Sempre valide o HTML antes de enviar, principalmente se o e mail tiver múltiplas seções. Outro erro comum é esquecer de incluir a versão em texto puro junto com a versão em HTML. Isso deixa o e mail inacessível para clientes mais simples ou para pessoas que desativaram a renderização de HTML. A solução é configurar o sistema de envio para gerar automaticamente ambas as versões. Nenhuma ferramenta séria de e mail deve enviar apenas HTML sem texto puro.
Headers mal construídos também causam problemas sérios. Usar caracteres especiais no Subject sem codificação adequada pode fazer com que o assunto chegue distorcido ou seja truncado. Endereços de remetente inválidos ou domínios não autenticados geram rejeição imediata em muitos servidores. Verifique sempre se o domínio do remetente tem registros SPF, DKIM e DMARC configurados corretamente. Alguns desenvolvedores colocam JavaScript dentro do corpo do e mail achando que vai funcionar. E-mails não executam código do lado do cliente por questões de segurança. Scripts são simplesmente ignorados ou removidos pelos filtros. Se você precisa de interatividade, use links que levem para páginas na web.
Outro problema prático é a falta de compatibilidade entre clientes. O que funciona no Gmail pode não funcionar no Outlook, e o que funciona no Outlook pode falhar no Apple Mail. Teste em pelo menos três clientes diferentes antes de enviar campanhas em larga escala. Uma verificação rápida economiza horas de problema depois. Existe também a questão do encoding de caracteres. Se o e mail contém acentos, emojis ou caracteres de idiomas específicos e o encoding não está configurado corretamente, o destinatário recebe texto ilegível. Use sempre UTF-8 com charset explicitamente declarado nos headers e no corpo. A maioria dos clientes modernos lida bem com UTF-8, mas servidores mais antigos podem ter problemas.
Uma limitação que poucos mencionam é a forma como os filtros de spam interpretam a estrutura. E-mails com muitos links, pouco texto em relação a imagens, ou conteúdo muito repetitivo tendem a ser marcados como spam independentemente de quão bem montada esteja a estrutura técnica. A estrutura correta é mas não suficiente para uma boa entrega.
Dicas práticas para melhorar a estrutura de um e mail
Mantenha os cabeçalhos limpos e relevantes. Remova headers que não são necessários, especialmente aqueles que exponham informações internas da sua infraestrutura. Headers excessivos podem ser vistos como sinal de spam por alguns filtros. Sempre inclua uma versão em texto puro mesmo que o conteúdo principal seja HTML. Use uma ferramenta ou biblioteca que gere as duas versões automaticamente. Isso resolve 90 por cento dos problemas de compatibilidade relacionados ao corpo do e mail.
Teste o e mail em diferentes clientes e dispositivos antes de enviar. Ferramentas como Litmus ou Email on Acid permitem visualizar como o e mail aparece em diversos ambientes. O custo é baixo comparado ao prejuízo de um e mail mal exibido para milhares de pessoas. Mantenha o tamanho do e mail controlado. Imagens devem ser otimizadas, scripts evitados, e anexos substituídos por links quando possível. Um e mail entre 50 e 100 KB tende a ter melhor desempenho de entrega do que um e mail de vários megabytes.
Configure corretamente a autenticação do domínio. SPF, DKIM e DMARC não são opcionais se você quer que seus e mails cheguem à caixa de entrada principal. Sem eles, mesmo uma estrutura perfeita terá dificuldade para passar pelos filtros modernos.
