Estrutura De Email

Entendendo como um email é construído por dentro

A estrutura de email é basicamente o esqueleto técnico de qualquer mensagem que sai do seu cliente e chega ao destinatário. Muita gente acha que é só escrever o corpo e enviar. Na prática, existem várias camadas de cabeçalho, dados de roteamento e codificação que fazem o email funcionar entre servidores diferentes.

A estrutura de email: o que compõe na realidade

Um email é dividido em duas partes principais: o cabeçalho (headers) e o corpo (body). O cabeçalho carrega metadados como de, para, assunto, data, caminho dos servidores e informações técnicas de segurança. O corpo pode ser texto simples ou HTML, e muitas vezes vem em multipart para compatibilidade. A sintaxe segue a RFC 5322, que define a formatação dos campos do cabeçalho, e a RFC 2045, que trata da codificação do corpo. Quando você dá send, o que sai do seu cliente é um fluxo de bytes seguindo essas regras. Se uma linha tiver um caractere fora do padrão, o servidor rejeita ou corrompe o conteúdo.

Já enfrentei um problema específico com emails que tinham acentos e caracteres especiais no campo From. Alguns servidores mais antigos, especialmente em empresas brasileiras com infraestrutura legado, rejeitavam o email inteiro porque o nome do remetente vinha codificado em UTF-8 direto no cabeçalho. A solução foi forçar o envio com encoding quoted-printable nos headers, usando charset ISO-8859-1 ou UTF-8 com base64, usando um parâmetro como =?UTF-8?B?base64?...?= no campo From. Isso resolve, mas exige configuração manual no smtp settings se a sua ferramenta não faz isso automaticamente. Os campos essenciais que todo cabeçalho deve ter são:

From: endereço e nome do remetente.
To: endereço do destinatário principal.
Subject: a linha de assunto.
Date: data e hora do envio.
Message-ID: identificador único gerado pelo cliente.
MIME-Version: indica que usa MIME para múltiplos tipos de conteúdo.
Content-Type: define o tipo do corpo, como text/plain ou multipart/alternative. Campos adicionais que fazem diferença na entrega incluem Reply-To, se você quer respostas indo para outro endereço. Return-Path, que é o envelope return address usado pelo MTA. E DKIM-Signature, que é o selo criptográfico que autenticou o domínio do remetente.

O corpo do email pode ser enviado de três formas básicas. Texto puro (text/plain), que é o mínimo e garante compatibilidade absoluta. HTML (text/html), que permite formatação visual mas aumenta o risco de bloqueio por filtros anti-spam. E multipart/alternative, que envia as duas versões simultaneamente. O cliente do destinatário escolhe a que prefere. A maioria dos serviços de email modernos mostra a versão HTML se disponível, mas cai para texto puro se o HTML falhar no render. Outro ponto que os iniciantes frequentemente ignoram é a questão do tamanho. O padrão RFC não impõe um limite rígido, mas praticamente todos os provedores comerciais cortam email acima de 25MB. Gmail, Outlook, Yahoo — todos seguem essa linha. Se você precisa enviar arquivos grandes, anexe via link em nuvem ao invés de empacotar no email. Um anexo de 30MB geralmente é rejeitado silenciosamente ou vai direto para a caixa de spam.

Tem também a questão do encoding. Texto em português precisa de um charset declarado corretamente no Content-Type. Se você manda HTML com charset equivocado, o destinatário vê caractere estranho no lugar dos acentos. A configuração padrão recomendada é charset UTF-8 para o corpo HTML. Para o texto simples, UTF-8 também funciona na maioria dos casos modernos. Quanto à segurança, a estrutura de email suporta assinaturas e criptografia via S/MIME e DKIM/SPF/DMARC. SPF é uma entrada DNS que diz quais IPs têm permissão para enviar emails pelo seu domínio. DMARC combina SPF e DKIM com uma política de como tratar falhas de autenticação. Se seu domínio não tem DMARC configurado, qualquer um pode fraudar seu From e seus emails acabam indo para o spam por comparação de reputação.

Um insight que não vejo muita gente comentando: muitos desenvolvedores acham que o campo Message-ID é opcional. Ele não é. Sem Message-ID, alguns servidores tratam o email como genérico e penalizam na entrega. O formato correto é algo como @, onde unique-id é um hash gerado aleatoriamente. A maioria dos bibliotecas gera isso automaticamente, mas se estiver enviando diretamente pelo SMTP, certifique-se de que o header está presente. Outro detalhe prático é a quebra de linha nos headers. Em emails clássicos, cada linha do cabeçalho não pode ultrapassar 78 caracteres. Se o assunto é muito longo, ele precisa ser quebrado e cada linha subsequente deve começar com espaço ou tabulação. Isso se chama folding. Clientes modernos lidam bem com isso, mas servidores de retransmissão mais antigos ainda processam mal headers sem folding correto, resultando em assunto cortado ou corrompido.

A estrutura multipart também permite anexos. Nesse caso, o Content-Type vira multipart/mixed e dentro dele cada parte tem seu próprio Content-Type e Content-Disposition. O anexo é separado do corpo textual com delimitadores base64. Essa estrutura é mais complexa e propensa a erro. Se o delimitador não bater no final, o email todo fica ilegível para o cliente do destinatário. Uma limitação importante da estrutura de email é que ela não é projetada para interatividade. Você não consegue saber se o email foi aberto, se o link foi clicado, ou se o destinatário leu o conteúdo. Trackers de abertura existem mas funcionam via imagem pixel e são cada vez mais bloqueados. É uma arquitetura dos anos 80 que ainda aguenta porque a padronização é universal.

Se você precisa de algo mais moderno com confirmação de leitura e interação, considere alternativas como mensagens empresariais (Slack, Teams) ou plataformas de comunicação com API própria. Email ainda é o padrão para comunicação formal e transacional, mas para conversação em tempo real, a estrutura atual não serve.