Remetente E Quem Envia

A diferença prática entre remetente e quem envia no dia a dia

Muita gente confunde os dois termos e acaba perdendo e-mail para o spam ou não consegue rastrear problemas de entrega. O remetente e quem envia são coisas relacionadas, mas tecnicamente distintas, e entender a diferença resolve metade dos problemas de Deliverability que vejo no suporte. O remetente, no contexto técnico de e-mail, é o endereço que aparece no campo MAIL FROM do protocolo SMTP. É o endereço usado para o retorno de rejeições e bounces. É o que os servidores usam para validar SPF e construir o Return-Path. Esse campo é invisível para o usuário final da maioria das plataformas de e-mail comum. Na prática, quando você configura uma campanha de marketing ou um sistema transacional, o envelope sender normalmente deve ser algo como noreply@seudominio.com ou bounce@seudominio.com. Esse domínio precisa ter SPF, DKIM e DMARC configurados, porque é ele que os servidores receptores vão consultar primeiro.

O que é quem envia (From header)

Já o campo "De" ou From header é o que o destinatário vê na barra do seu leitor de e-mail. É o nome e endereço que aparecem como origem da mensagem. Esse campo é manipulado pelo cliente de e-mail ou pela ferramenta de envio e não tem a mesma função técnica que o envelope sender. O problema é que muitos administradores tratam os dois como sinônimos. Isso gera falhas sérias. Se o seu From header usa o domínio da sua empresa, mas o envelope sender aponta para um domínio diferente, o SPF do domínio do From não será validado e o e-mail pode ser rejeitado ou marcado como spam.

Como configurar corretamente

Vou descrever o fluxo que uso no meu trabalho, que é o seguinte: primeiro defino o domínio autorizador, depois configuro o envelope sender, e por último alinho o From header com a assinatura da empresa. O detalhe importante é que o domínio do envelope sender e o domínio do From header podem ser diferentes, desde que o domínio do envelope tenha validação adequada. No meu caso, tenho um cenário específico que costuma dar dor de cabeça. Uma empresa de logística que eu apoio usava o domínio principal nos dois campos, mas o sistema transacional deles enviava pelo servidor de marketing. Quando o Gmail passou a aplicar políticas mais rigorosas de DMARC em 2024, os e-mails transacionais começaram a cair na caixa de spam porque o servidor de marketing não estava autorizados pelo SPF do domínio principal. A solução foi criar um subdomínio dedicado para e-mails transacionais, como transacional.logistica.com.br, configurar SPF separado e usar esse subdomínio como envelope sender enquanto mantinha o domínio principal apenas no From header. O processo de configuração leva cerca de 30 minutos se você já tem acesso DNS, mas a propagação de SPF e DMARC pode levar até 48 horas. Não adianta testar antes desse prazo.

Passo a passo prático

Comece verificando se o domínio que você vai usar como envelope sender já possui registro SPF, DKIM e DMARC. Use ferramentas como mxtoolbox.com ou mail-tester.com para confirmar. Se algum desses registros estiver ausente, o servidor receptor vai tratar o e-mail com desconfiança, independentemente do conteúdo da mensagem. Em seguida, configure o subdomínio ou domínio do envelope sender no seu painel de envio. A maioria dos serviços como SendGrid, Amazon SES, Mailchimp e Brevo permite definir um domínio dedicado para bounces. Coloque esse mesmo domínio no campo Return-Path da sua configuração. Para o campo From header, use o domínio principal da empresa com um nome amigável. Exemplo: Empresa XYZ <contato@dominioprincipal.com.br>. Mantenha consistência. Não mude o remetente de campanha para campanha, porque isso confunde os filtros de reputação dos provedores.

Erros comuns que prejudicam a entrega

O erro mais frequente é usar o mesmo domínio para envelope sender e From header sem ter ambos devidamente autorizados no SPF. O segundo erro mais comum é configurar DKIM em um domínio e usar outro domínio no envelope sender. O DMARC fallthrough existe, mas não conta como regra — é uma falha de segurança que alguns provedores ainda permitem, mas cada vez menos. Um terceiro problema é a falta de um subdomínio dedicado para e-mails transacionais. Quando o volume de disparos de marketing sobe, a reputação do domínio principal prejudica os e-mails funcionais como senhas, comprovantes e notificações. Os clientes não recebem o que é urgente e acabam entrando em contato com o SAC.

Quando a diferença não importa tanto

Em ambientes internos, com servidores de e-mail próprios e poucos destinatários externos, a distinção entre remetente e quem envia tem pouco impacto prático. Troca-se um e-mail entre colegas e pronto. O problema aparece quando o e-mail sai para o mundo, especialmente para Gmail, Outlook e Yahoo. Esses provedores aplicam verificação rigorosa de autenticidade e a divergência entre os dois campos é uma das principais causas de rejeição. Se você não tem condições de manter um subdomínio separado ou não consegue configurar DKIM em dois domínios, uma alternativa é usar um serviço de terceiros com domínio próprio de envelope. Plataformas como SendGrid e Amazon SES oferecem opções de dedicated IP e domínio de origem gerenciado. Isso transfere a complexidade técnica do SPF e DMARC para o provedor, mas custa entre US$ 1 e US$ 5 por mil e-mails, dependendo do volume. Para pequenas empresas que enviam menos de 500 e-mails por mês, a solução mais simples é manter um único domínio com SPF, DKIM e DMARC rigorosos e usar esse mesmo domínio tanto no envelope quanto no From header. É menos flexível, mas evita problemas de autenticidade sem custo adicional.

O que mais vejo gente errando hoje é achar que colocar um nome bonito no campo De resolve. O envelope sender é o que os servidores levam a sério. Negligenciar essa parte é o motivo pelo qual e-mails importantes continuam indo para o lixo eletrônico, mesmo com conteúdo impecável.