Por que o seu email aparece com "via" do domínio de outra pessoa?
Um cliente mandou um print do seu último email. Logo abaixo do seu nome, em texto cinza pequeno, o Gmail imprimiu via sendgrid.net. O seu endereço está bem ali na linha From. É o seu próprio domínio. Então por que o Gmail está dizendo às pessoas que outra pessoa enviou isso?
O Gmail não está errado. Um servidor sendgrid.net realmente entregou essa mensagem, e nenhum dos domínios escondidos dentro dela bateu com o seu. A linha “via” é o Gmail dizendo isso em voz alta. E consertar é mais fácil do que parece.
O que é a linha “via”
Todo email carrega dois endereços de remetente. O header From: é o que o seu leitor vê. O envelope sender é o que os servidores de email usam. Você o encontra nos cabeçalhos como Return-Path:, e ele pertence à máquina que transportou a sua mensagem. Um terceiro domínio também aparece: o campo d= da assinatura DKIM. Ele nomeia o domínio que assinou a mensagem.
A documentação do Google resume a regra. O Gmail mostra “via” e um nome de domínio ao lado do remetente quando o domínio de onde veio a mensagem não corresponde ao domínio do endereço From. Alinhe o domínio do envelope ou o domínio da assinatura com o seu domínio do From, e a linha some.
Estes são os cabeçalhos de uma mensagem que mostra via sendgrid.net, reduzidos às duas partes que importam:
Return-Path: <bounces+e81f-jane=example.org@sendgrid.net>
From: Ana <ana@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.net; s=smtp1; ...
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounces+e81f@sendgrid.net
designates 198.51.100.24 as permitted sender)
dkim=pass header.i=@sendgrid.net
dmarc=fail (p=NONE dis=NONE) header.from=example.comLeia essas linhas como um servidor receptor lê. O SPF passou, mas para sendgrid.net. O DKIM passou, mas para sendgrid.net também. O remetente que todo mundo vê é example.com, e nada amarra os dois. O Gmail imprimiu o resumo honesto dessa bagunça embaixo do nome do remetente.
Faça isso: abra uma mensagem que mostra o marcador, clique em “Mostrar original” e localize a linha Return-Path: e o d= dentro de DKIM-Signature:. O domínio que aparecer ali é o do seu rótulo “via”. Agora você sabe qual plataforma envia o seu email desalinhado.
Por que isso importa
A linha cobra de você duas vezes.
Primeiro, o custo humano. O Gmail mostra “via” para que as pessoas percebam email que alega uma origem mas chega de outra. É a forma que a maioria dos golpes de phishing assume. Então o Gmail acabou de convidar o seu leitor a desconfiar da mensagem. As respostas caem. Ninguém conta o porquê.
Segundo, o custo técnico. Quando o domínio do envelope e o da assinatura pertencem a outra pessoa, o alinhamento do DMARC falha. É exatamente isso que a linha dmarc=fail acima registra. Alinhamento em uma frase: uma mensagem só passa no DMARC se o domínio que passou no SPF ou o domínio que assinou com DKIM corresponde ao domínio da linha From. Esse pareamento é o que se chama de alinhamento. As suas duas checagens hoje passam pelo domínio de outra pessoa, e essa única condição causa o marcador e boa parte do posicionamento no spam. Se o seu email também cai no lixo, comece pelo diagnóstico completo de spam depois de terminar por aqui.
Faça isso: trate a linha “via” como um bug de alinhamento que dá para ver. A correção abaixo também restaura o DMARC.
As três causas, em ordem
Causa um: você nunca configurou a plataforma para enviar como o seu domínio
A maioria das linhas “via” vem daí. Todo ESP, ferramenta de faturamento, helpdesk e plataforma de cursos envia pelo próprio equipamento por padrão. E, por padrão, o envelope sender e a assinatura DKIM nomeiam o domínio da plataforma.
Os padrões são parecidos em todo lugar. O Mailchimp assina com mailchimpapp.net até você autenticar o domínio, que é exatamente o caso percorrido no post sobre Mailchimp. O Amazon SES usa um envelope amazonses.com até você configurar um domínio MAIL FROM personalizado, e o post sobre SES cobre esse caso. O SendGrid assina como sendgrid.net até você autenticar um domínio de envio. Nada disso é a plataforma falhando. Você só não terminou a configuração, e ninguém avisou.
A pista: Return-Path: e d= nomeiam a plataforma, e você nunca publicou registros DNS para ela. O email health check mostra os registros que faltam.
O que fazer: ativar o domínio de envio personalizado da plataforma. A seção de correção abaixo mostra como.
Causa dois: a configuração ficou pela metade
O painel insiste nos registros de DKIM, então a maioria publica esses. O subdomínio de return path é fácil de pular. Às vezes acontece o contrário: o envelope migrou para o seu domínio, os CNAMEs de DKIM nunca resolveram, e a assinatura ainda nomeia a plataforma.
Eis por que a metade funciona, por um tempo. Os dois caminhos de alinhamento são alternativos. Qualquer um deles, alinhado com o seu domínio do From, satisfaz o DMARC e remove a linha “via”. Publique um conjunto e pule o outro, e tudo funciona até a metade alinhada quebrar. Aí o marcador volta. Nenhum erro em lugar nenhum. Uma rotação de DKIM selector ou uma chave expirada no lado do ESP faz exatamente isso.
A pista: um dos dois domínios é seu e o outro ainda nomeia a plataforma. O primo SPF desse estado, em que o registro existe mas lista os remetentes errados, está no post sobre falha de SPF.
O que fazer: publicar tudo o que a plataforma pediu, o subdomínio do envelope e os registros da assinatura juntos.
Causa três: um encaminhador reenviou a sua mensagem
Às vezes a sua configuração está certa e o marcador continua honesto. Quando uma mensagem passa por uma lista de discussão ou pelo auto-encaminhamento de uma empresa, essa máquina a reenvia com o próprio envelope. O SPF e a assinatura original não batem mais com o novo salto, então o provedor do destinatário mostra “via” com o domínio do encaminhador.
A pista: a sua cópia em Enviados mostra domínios alinhados, e o domínio do “via” é um que você nunca ouviu falar. Muitas vezes pertence ao próprio empregador do destinatário ou a um gerenciador de listas. Pergunte à pessoa onde a mensagem caiu.
O que fazer: nada do seu lado conserta este caso. O encaminhador reenviou o seu email, então cabe a eles consertar. Verifique que os seus próprios cabeçalhos se alinham e trate o resto como informação. É também por esse caso que os receptores criaram o ARC, que carrega veredictos de alinhamento entre saltos. Esse é problema do lado de quem recebe, não seu.
A correção
Os passos são os mesmos em toda plataforma, só que cada uma dá outro nome. O Mailchimp chama de authenticated domain. O SendGrid chama de sending domain authentication. O SES chama de custom MAIL FROM.
A plataforma entrega os registros DNS. Um conjunto no estilo SendGrid se parece com isto:
em123.example.com. CNAME u123.wl.sendgrid.net.
s1._domainkey.example.com. CNAME s1.domainkey.u123.wl.sendgrid.net.
s2._domainkey.example.com. CNAME s2.domainkey.u123.wl.sendgrid.net.A primeira entrada move o envelope para o seu subdomínio, então Return-Path: termina em em123.example.com e o SPF se alinha. As outras duas deixam a plataforma assinar com o seu domínio, então d=example.com aparece na assinatura e o DKIM se alinha. Para saber como publicar registros como esses, incluindo as peculiaridades de hostname nos diferentes provedores de DNS, leia o guia de configuração de DKIM. Esses passos não se repetem aqui.
Quando os registros resolverem, os cabeçalhos contam a história com clareza:
Return-Path: <bounces+e81f-jane=example.org@em123.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.google.com;
spf=pass (... domain of bounces+e81f@em123.example.com ...)
dkim=pass header.i=@example.com
dmarc=pass (p=NONE dis=NONE) header.from=example.comOs dois caminhos agora nomeiam example.com. O DMARC passa. O Gmail não tem nada para imprimir depois do nome do remetente.
Faça isso: publique o conjunto completo de registros, espere o TTL passar e envie um teste novo para a mesma caixa de entrada que mostrou o marcador.
Confira se a correção funcionou
Cole a mensagem nova no header analyzer gratuito e confira três coisas: o domínio do envelope, o domínio do d= e o veredicto do dmarc=. Os três devem nomear o seu domínio agora, e a mensagem não deve exibir linha “via”.
Depois confirme o DNS de fora do painel da plataforma. O email health check lê os seus registros como um receptor lê, então pega coisas como um CNAME colado no hostname errado enquanto a plataforma ainda diz “pending verification”.
As duas ferramentas respondem por uma mensagem, em um dia, em um domínio.
O que a checagem pontual não vê
Essa correção é um estado, não um evento. O alinhamento se mantém só enquanto os registros se mantêm. Coisas rotineiras os quebram em silêncio: uma migração de DNS derruba os CNAMEs, uma plataforma rotaciona os DKIM selectors dela, alguém adiciona uma ferramenta nova sob o seu domínio e ela começa a enviar pela própria configuração padrão. Cada uma dessas traz a linha “via” de volta. Nenhuma delas envia um erro. Você descobre semanas depois, pelo print de um cliente.
A parte de vigiar já existe. O LitInboxes reconfere os seus registros SPF, DKIM e DMARC a cada seis horas, carimba cada mudança com uma data para você rastrear uma quebra até o dia em que ela começou e alerta quando um registro se move. Você não precisa lembrar de olhar. Alertas por email estão em todos os planos, e alertas por Slack, Discord e webhook estão no Pro. Há uma demo ao vivo se você quiser ver primeiro.
O checklist
- Abra uma mensagem que mostra o marcador. Escolha “Mostrar original”.
- Encontre o domínio no
Return-Path:e no campod=do DKIM. Esse é o seu domínio do “via”. - Encontre a configuração de domínio de envio personalizado nessa plataforma e inicie.
- Publique todos os registros que ela entregar. Sim, o subdomínio do envelope também.
- Espere o TTL do DNS passar. Envie um teste novo para a mesma caixa de entrada.
- Confirme com o header analyzer que os dois domínios e o veredicto do DMARC agora nomeiam o seu domínio.
- Rode o email health check para confirmar os registros de fora da plataforma.
- Coloque os registros em um ciclo de vigilância, semanal à mão ou com monitoramento contínuo. O marcador volta em silêncio quando um deles quebra.
Como remover a linha "via" dos seus emails
- Ler os cabeçalhos de uma mensagem que mostra o marcadorAbra a mensagem no Gmail, use o menu de três pontos e escolha Mostrar original. Anote qual domínio aparece no Return-Path e no campo d= do DKIM-Signature. Esse é o domínio que o Gmail imprime depois de "via".
- Ativar o domínio de envio personalizado na sua plataformaNa sua plataforma de envio, procure por authenticated domain, custom domain ou dedicated sending domain e comece a configuração para o domínio do seu campo From. A plataforma entrega os registros DNS para publicar.
- Publicar os registros de return path e DKIMNormalmente são dois tipos: um subdomínio para o envelope sender, muitas vezes chamado de return path ou MAIL FROM, e um ou dois CNAMEs de DKIM sob _domainkey. Publique todos, não apenas o conjunto de DKIM.
- Esperar o TTL do DNS e enviar um teste novoMudanças de DNS só se comprovam com uma mensagem nova. Registros antigos ficam em cache por um tempo, então teste de novo depois de uma hora e use a mesma caixa de entrada que mostrou o marcador.
- Confirmar que os domínios agora se alinhamLeia os cabeçalhos da mensagem nova: Return-Path e d= devem nomear o seu domínio, dmarc deve estar como pass e o Gmail não deve exibir linha "via" sob o nome do remetente. O header analyzer mostra tudo isso em uma única tela.
Perguntas frequentes
A linha "via" significa que invadiram a sua conta de email?
Não. Significa que a máquina que enviou a mensagem pertence a um domínio diferente do que está no seu campo From. Qualquer plataforma de envio faz isso até a configuração dela ficar completa. Se suspeita de invasão, verifique a pasta de itens enviados e os acessos recentes à conta.
O "via" manda o seu email para o spam?
Não por si só. É um marcador de exibição, não um veredito. Mas a condição por trás dele, a falha dos dois caminhos de alinhamento do DMARC, prejudica o posicionamento. Trate o marcador como sintoma desse problema maior.
"Via" continua aparecendo mesmo com os registros no DNS. Por quê?
Três possibilidades: os CNAMEs de DKIM resolveram mas o registro de return path não, a mensagem de teste saiu antes do DNS terminar de se propagar, ou um encaminhador ou lista de discussão reenviou a mensagem com um terceiro domínio. Um teste novo para um endereço direto separa os dois primeiros casos do terceiro.
O destinatário pode esconder a linha "via"?
Não. O Gmail monta o rótulo a partir dos resultados de autenticação da própria mensagem, então só o remetente pode removê-lo, alinhando o domínio de envio com o domínio do From. Nenhuma configuração dos dois lados esconde o rótulo em mensagens desalinhadas.