Por que o e-mail que você encaminhou para si mesmo caiu na spam — ilustração editorial

read receipts

Por que o e-mail que você encaminhou para si mesmo caiu na spam

Você não fez nada de errado. SPF fez. Aqui está o mecanismo que ninguém no seu provedor vai explicar.

·3 min

Configure um encaminhamento automático da sua conta antiga para a nova, e parte desse correio desaparecerá silenciosamente na spam — não porque seu provedor esteja quebrado, mas porque o encaminhamento reescreve quem está enviando a mensagem sem reescrever a prova criptográfica. O SPF verifica o servidor errado, o veredito de DMARC muda para falha, e um e-mail legítimo que você enviou para si mesmo é colocado em quarentena. A solução tem um nome: ARC, definido em RFC 8617 em 2019.

Por que o encaminhamento faz meu correio falhar no SPF?

Porque o SPF verifica o último servidor que retransmitiu a mensagem, e o encaminhamento muda esse servidor. SPF — Sender Policy Framework — é um registro DNS que lista quais endereços IP podem enviar correio para um domínio. Quando bank.com envia você um recibo, o servidor receptor verifica: isso chegou de um IP que bank.com autorizou? Sim. Passou.

Agora encaminhe esse recibo do seu Gmail para seu novo endereço. Os servidores do Google o retransmitem adiante. O servidor receptor final executa a verificação de SPF e pergunta: o Google é autorizado a enviar para bank.com? Não, não é. SPF falha. A própria documentação Workspace do Google explica isso claramente — mensagens encaminhadas falham no SPF porque o servidor de encaminhamento não está no registro SPF do domínio original. Nada foi falsificado. A verificação está apenas olhando para o salto errado.

Então por que isso o envia para spam?

DMARC. SPF falhando sozinho costumava ser sobrevivível; DMARC transformou isso em um veredito. DMARC vincula SPF e DKIM e diz aos receptores o que fazer quando ambos falham: nada, quarentena ou rejeição. Em 2024, grandes remetentes não tinham escolha — Google e Yahoo começaram a exigir DMARC de qualquer um que enviasse mais de 5.000 mensagens por dia aos seus usuários.

DKIM, o outro pilar, é uma assinatura incorporada à mensagem. Em teoria, ela sobrevive ao encaminhamento, porque assina o conteúdo, não a rota. Na prática, qualquer coisa que toque na mensagem a quebra. Uma lista de discussão que anexa um rodapé "você está inscrito, desinscreva-se aqui", um servidor que reescreve a linha de assunto, até mesmo uma mudança em como uma linha se quebra — a assinatura não corresponde mais, e DKIM também falha. Agora ambos os pilares caíram, DMARC diz falha, e seu próprio recibo está na pasta de lixo.

O que é ARC e ele realmente conserta isso?

ARC — Authenticated Received Chain, RFC 8617 — permite que um encaminhador honesto ateste que o correio passou na autenticação antes de ele tocá-lo. O servidor de encaminhamento carimba a mensagem com um registro selado dizendo "quando isso chegou até mim, SPF e DKIM eram válidos — confie na minha palavra pelo trecho que você não consegue verificar." O receptor final, se confiar nesse encaminhador, pode anular a falha de DMARC e entregar.

A ressalva está em "se confiar". ARC não é uma senha; é um sistema de reputação. Um receptor pesa se o selador de ARC é um operador conhecido e bem-comportado. Google tanto carimba cabeçalhos ARC quanto os honra de remetentes em quem confia, é por isso que um encaminhamento de Gmail para Gmail geralmente sobrevive enquanto um encaminhamento através de alguma retransmissão de universidade antiga não.

Se você executar o encaminhamento você mesmo, dois passos concretos ajudam. Use reescrita Server-Side Redirect / SRS-style se seu host oferecê-la, que reescreve o remetente do envelope para que verificações de SPF sejam contra seu encaminhador em vez do domínio original. E prefira encaminhar entre provedores que ambos suportam ARC. Se você está consolidando contas e quer que o destino apenas cuide da bagunça de autenticação para você, esse é exatamente o tipo de infraestrutura que uma plataforma de e-mail com IA foi construída para absorver.

Quando devo parar de culpar meu provedor?

Quando o padrão é "apenas correio encaminhado falha", o provedor está fazendo seu trabalho corretamente — o protocolo é o problema. Aqui está o indicador: abra os cabeçalhos da mensagem perdida e procure pela linha Authentication-Results. Se você vê spf=fail ao lado de um IP de envio que pertence a um encaminhador em vez do remetente original, esse é o SPF verificando o salto errado. Se dkim=fail aparece em correio que passou por uma lista ou retransmissão que edita mensagens, essa é uma assinatura danificada, não uma falsificação.

A verdade incômoda é que a autenticação de e-mail foi aparafusada, camada por camada, ao longo de duas décadas a um sistema que nunca assumiu que alguém mentiria. SPF chegou em 2006, DKIM em 2007, DMARC em 2015, ARC em 2019 — cada um remendando um buraco que o último abriu. Encaminhamento é a costura onde todos os quatro se esfregam um contra o outro, e sua caixa de entrada é onde você sente o atrito.

@@END@@
daily messages that trigger Google & Yahoo's DMARC requirement (2024)

Fontes

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← Todos os artigos