O Que É Corpo Do Email

O que é corpo do email e por que ele trava seu delivery

Corpo do email é tudo que vem depois do cabeçalho. Assunto, de, para, data, DKIM, SPF — isso é estrutura. O corpo começa onde termina o primeiro \r\n\r\n simples e vai até o final da mensagem. Na prática, é o conteúdo que o destinatário lê na aba principal da caixa de entrada, dividido entre versão de texto puro e versão HTML quando o email é multipart. Quando eu falo em corpo, a maioria das pessoas pensa no texto visível. Só que no SMTP ele tem nome técnico: o campo Body, ou payload. E ele carrega um peso enorme pra entregar ou não entregar. A gente subestima isso porque o visual importa mais pro remetente do que o raw message, mas os filtros são cegos pros seus designs bonitos. Eles leem código. No padrão MIME, um email comum segue essa estrutura:

mime-version: 1.0\r\ncontent-type: multipart/alternative; boundary=\"------------=_5F8A9B2C\"\r\n\r\n--------------=_5F8A9B2C\r\ncontent-type: text/plain; charset=\"UTF-8\"\r\n\r\n(versão de texto aqui)\r\n--------------=_5F8A9B2C\r\ncontent-type: text/html; charset=\"UTF-8\"\r\n\r\n(versão HTML aqui)\r\n--------------=_5F8A9B2C--\r\n O corpo inteiro existe dentro desses blocos. Se você só envia text/plain, o cliente mostra aquele texto sem formatação. Se manda só HTML, os clientes mais restritivos ou filtros antispam enxergam menos sinal de legítimo. O ideal, e o padrão das plataformas de envio confiáveis, é multipart/alternative com ambas as versões. Um detalhe que ninguém conta: o boundary define os limites entre partes. Se esse boundary aparecer dentro do próprio conteúdo de texto ou HTML, o parser quebra. Eu perdi uma manhã inteira em 2022 debugando um servidor que rejeitava mensagens de uma lista de transacionais porque o texto plano continha a string \"--=_5F8A9B2C\" escrita naturalmente por um template dinâmico. O workaround foi simples mas custoso pra descobrir: escapa o boundary com um caractere extra no início de qualquer linha que o repita, ou troca o boundary por algo randômico e garante, via código, que ele não apareça no conteúdo. No fim eu mudei o boundary pra algo com 32 caracteres hexadecimais aleatórios e sanitizei o texto antes do envio. O problema sumiu.

Estrutura real do corpo de um email profissional

Um corpo bem construído tem três camadas que funcionam juntas. Primeira, o header MIME que declara o content-type e o charset. Segunda, o bloco text/plain como fallback. Terceira, o bloco text/html com o layout real. Charset importa muito. UTF-8 é o padrão atual, mas alguns servidores mais antigos ainda travam com caracteres acentuados se o charset não estiver explícito. Coloca sempre charset=\"UTF-8\" em todas as partes. Sem exceção. Encoding também é parte do corpo. O padrão pra textos longos é quoted-printable ou base64. Textos ASCII puros podem ir sem encoding declarado, mas assim que aparece um caractere fora do range 7-bit, o MIME exige encoding. Base64 é mais seguro pra imagens em formato attachment ou inline, mas infla o tamanho em 33%. Quoted-printable é mais legível em logs e costuma ser preferido pros textos em HTML com muitos acentos.

Por que o corpo define sua reputação de domínio

SpamAssassin, Google Postmaster Tools, Microsoft SNDS, Yahoo Actionable Metrics — todos avaliam o corpo. Não só o conteúdo do texto, mas a proporção entre texto e imagem, a presença de links suspeitos, o tamanho absoluto da mensagem, a qualidade do HTML. Um insight que pouca gente leva a sério: emails 100% imagem são red flag. Clientes modernos permitem renderizar, mas os filtros tratam como indício forte de spam. A proporção recomendada pela maioria dos especialistas de deliverability é manter pelo menos 10% a 15% de texto real no corpo HTML, além da versão text/plain completa. Text-only não resolve problema de template ruim, mas ajuda nos scores. Outro ponto cego: embedded CSS dentro de