Entendendo o remetente e quem envia na prática
Quando você trabalha com sistemas de comunicação, seja email, SMS, APIs ou formulários web, a distinção entre remetente e quem envia não é apenas semântica — é técnica. E já perdi tempo demais tentando depurar isso. O remetente é o endereço ou identificação que aparece como origem em uma mensagem. Quem envia é a entidade real por trás disso: um serviço automatizado, um sistema de newsletter, ou uma pessoa usando uma conta corporativa. A confusão entre os dois causa erros de entrega, rejeição em filtros anti-spam e bugs que parecem não fazer sentido nenhum.
Remetente e quem envia: onde mora a diferença
No header de um email, o campo From pode mostrar "suporte@loja.com.br" mas o SMTP authentication identificou "newsletter@mailgun.net". Para o usuário, o remetente é a loja. Para o servidor de destino, quem enviou foi o Mailgun. Dois registros, uma mensagem. Isso importa porque servidores como Gmail e Outlook cruzam essas informações com SPF, DKIM e DMARC. Se o domínio do From não bater com o domínio que autenticou no SMTP, a mensagem cai no spam. Já vi campanhas inteiras de marketing serem marcadas como spam porque o setor de TI configurou o From para o domínio principal da empresa, mas esqueceu de atualizar o SPF do domínio do service de envio.
No caso de APIs REST, a coisa fica mais simples visualmente mas não menos crítica. O campo "from_user" ou "sender_id" no payload diz quem é o remetente lógico. O token de autorização na requisição diz quem enviou. Quando esses dois não correspondem, seja por bug ou má intenção, o backend precisa decidir se valida, rejeita ou simplemente registra e deixa passar. A maioria dos sistemas que eu já configurei opta por validar o token e ignorar discrepâncias no payload, porque spoofing de remetente em APIs internas geralmente é problema de outro tipo.
Como configurar corretamente
Se você está configurando um sistema de envio de email, aqui vai o que funciona sem dor de cabeça: Primeiro, use um subdomínio dedicado para envios. Algo como emails.seuportal.com.br. Configure o SPF dele permitindo apenas os servidores que realmente vão enviar (SendGrid, AWS SES, Mailgun, o que for). Defina o DKIM com chave de 2048 bits. Ative o DMARC com policy reject e um email de relatório. Esse último ponto é importante: os relatórios DMARC vão te mostrar na prática quantas mensagens estão sendo rejeitadas e porquê, o que economiza horas de debugging.
Segundo, mantenha o From alignado com o domínio autenticado. Se seu SPF permite envios de mail.seuportal.com.br, o From deve ser @mail.seuportal.com.br ou um subdomínio que também esteja no SPF. Diferentes domínios no From são permitidos tecnicamente, mas é receita certa para problemas com filtros modernos. Terceiro, verifique antes de colocar no ar. Use ferramentas como Mail-Tester ou o próprio Gmail's built-in diagnostic. O teste leva 30 segundos e mostra exatamente por que sua mensagem está caindo no spam.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Em APIs, a regra é mais simples. Use um header de autorização consistente. Se o sistema suporta múltiplos tipos de token (JWT, OAuth, API key), documente claramente qual é o esperado. E se você está validando remetente contra payload, faça essa validação no middleware, não no controller, para não duplicar lógica.
O problema que eu encontrei e como resolvi
Em 2023, configuro um sistema de notificações para uma plataforma de e-commerce que usava SendGrid para transacionais e um serviço próprio para marketing. O From dos transacionais era notifications@loja.com e dos marketing era newsletter@loja.com. Ambos os domínios estavam no SPF. Ambos tinham DKIM. Tudo parecia certo. Mesmo assim, cerca de 15% das mensagens de recuperação de senha iam para o spam no Gmail. A causa era sutil: o SendGrid, por padrão, adiciona um header Reply-To com o endereço da conta corporativa do cliente, que era um subdomínio diferente. O Gmail via o From correto, via o SPF batecendo, mas o Reply-To dessincronizado ativava um sinalizador interno de suspeita. A solução foi sobrescrever o Reply-To no template do SendGrid para o mesmo endereço do From, e adicionar um headers customizado alinhando tudo.
Depois de corrigido, a taxa de entrega no Gmail subiu de 85% para 98%. O resto era usuários que manualmente tinham marcado como spam antes, e isso não tem configuração que resolva.
Quando isso não funciona
Configure tudo perfeitamente e mesmo assim suas mensagens não chegam, a culpa pode não ser sua. Alguns provedores de email, especialmente corporativos com firewalls próprios, têm políticas de whitelist que não obedecem SPF ou DKIM. Se você está enviando para um domínio que exige pré-cadastro, CadKit ou similar, a perfeição técnica não resolve. Nesses casos, o caminho é entrar em contato com o team de TI do domínio alvo e pedir para adicionarem seu IP ou domínio à whitelist. Outro cenário onde remetente e quem envia se tornam irrelevantes é em sistemas legacy que não suportam autenticação moderna. Se você está integrando com um software que só aceita SMTP sem TLS, ou que não permite customizar headers, as garantias de identidade se perdem. Nesses casos, o melhor é isolar esse tráfego em um subdomínio separado com política DMARC stricter, para não contaminar a reputação do domínio principal.
E se o seu sistema envia milhões de mensagens por dia, considere usar IP warming progressivo. Começar com um volume baixo e aumentar gradualmente, monitorando taxas de bounce e reclamações, evita que seu IP novo seja flagrado automaticamente por provedores que ainda não têm histórico de entrega confiável.
