Porque é que a sua caixa de entrada está a transbordar de relatórios de não entrega para campanhas que nunca enviou? O painel da sua ferramenta de emailing mostra zero envios. Mesmo assim, os NDR acumulam-se desde o dia anterior. Este fenómeno tem um nome preciso: o backscatter. Um spammer usou o seu domínio como endereço de retorno nos seus envios fraudulentos; os servidores que rejeitam essas mensagens a posteriori devolvem-lhe a conta sob a forma de bounces. Nada a ver com uma pirataria da sua conta nem com uma fuga da sua lista de contactos.
O mecanismo do backscatter: From visível e Return-Path, dois endereços distintos
O cliente de email mostra um remetente. O comando SMTP MAIL FROM tem outro, invisível na interface. Este segundo endereço, o Return-Path, serve de destino aos bounces. Um spammer usurpa este campo técnico, não necessariamente o From visível que o destinatário final vê na sua caixa de correio. Ele insere o seu domínio no envelope SMTP no momento do comando MAIL FROM, sem que o corpo da mensagem mostre alguma vez o seu nome. Esta distinção determina tudo o que se segue, incluindo a escolha da configuração que corta o fluxo. Explicamos o mecanismo completo da usurpação, do From falsificado até à contrafação de identidade completa, no nosso artigo sobre como funciona o email spoofing. Aqui, o alvo é mais restrito: o envelope técnico, aquele que o protocolo utiliza para encaminhar os relatórios de erro, distinto da mensagem que o destinatário final lê realmente.
Porque é que o servidor do destinatário lhe devolve o bounce a si
Porque envia o relatório de erro para o endereço inscrito no envelope. Esse endereço tem o seu domínio. Nenhum elemento do protocolo lhe permite saber que foi falsificado. Na prática, existem dois comportamentos possíveis num servidor que recebe um email fraudulento. O primeiro rejeita a ligação em direto, durante a transação SMTP, com um código de erro imediato; nunca é gerado nenhum bounce, o problema termina ali mesmo do lado do servidor emissor do spam. O segundo aceita a mensagem. Só a descobre tarde demais: a caixa está cheia ou o destinatário não existe. É este segundo caso que produz o backscatter: o servidor gera um NDR (Non-Delivery Report), no formato definido pela RFC 3464 (IETF, 2003), e depois envia-o de boa-fé para o Return-Path usurpado.
Um investigador que recebeu 49.000 mensagens de backscatter em quatro meses analisou os seus bounces através de quatro blocklists: de 4.177 bounces com IP emissor identificável, 19% dessas IPs ainda não constavam em nenhuma, com a SpamCop a assinalar 73% e a CBL 69% (Christopher Fuhrman, École de technologie supérieure de Montréal, 2008).
Esta velha constatação continua atual. Os servidores mal configurados que aceitam e só depois rejeitam, em vez de recusar à entrada, formam um parque residual que continua em funcionamento, muitas vezes sistemas de correio eletrónico empresariais administrados por equipas que já não seguem as recomendações SMTP habituais. Já dedicámos outro artigo à tipologia completa dos diferentes motivos de emails não entregues. O backscatter junta-se a esta lista como um caso particular, gerado por terceiros e sem relação com o seu próprio envio.
Ler os cabeçalhos do bounce para confirmar que o envio não é seu
Chega um bounce suspeito. Bastam geralmente três verificações para decidir, pela ordem seguinte:
- A cadeia Received, no topo da mensagem em bruto, lista cada servidor atravessado do primeiro ao último. Se nenhum corresponder à sua infraestrutura de envio habitual, IP, MTA, plataforma de emailing identificada, a origem é externa.
- O Message-ID da mensagem original, geralmente incluído no corpo do bounce sob a forma de citação parcial. Um Message-ID que os seus próprios registos de envio nunca geraram confirma que a mensagem nunca partiu de si.
- O Enhanced Status Code do relatório, no formato 5.x.x, indica a causa exata da rejeição do lado do servidor destinatário: caixa inexistente ou quota excedida.
Um bounce de backscatter reconhece-se pela ausência total de correspondência entre o seu Message-ID e os registos de envio do remetente legítimo, seja qual for a plataforma de envio utilizada, Twilio SendGrid, Mailjet ou um SMTP próprio. Sem essa correspondência, não é necessária qualquer investigação adicional.
O que isto não significa: nem pirataria, nem fuga de lista
A primeira reação, ao descobrir dezenas de NDR desconhecidos, tende muitas vezes para a hipótese da conta comprometida. Compreende-se. Mas um backscatter não pressupõe qualquer acesso ao domínio nem à caixa de correio. Não há fuga da base de contactos nem compromissão da ferramenta de emailing. O spammer só precisa de uma informação pública, o seu nome de domínio, para a inscrever no envelope de um envio que nunca envolve os seus servidores. Poder-se-ia também pensar que um ESP basta para cobrir este risco, já que gere a autenticação dos envios de saída. O SPF e o DMARC declaram-se, no entanto, ao nível do DNS do domínio, não ao nível da ferramenta de envio: mudar de ESP não resolve nada enquanto esses registos permanecerem ausentes ou permissivos.
Depois surge sempre a mesma preocupação: este fluxo vai fazer com que eu entre numa blocklist? O Backscatterer.org, a blocklist dedicada a este fenómeno, regista os servidores que emitem backscatter, nunca os domínios usurpados que o recebem. Entra-se nela ao devolver bounces para terceiros inocentes. Receber milhares deles em nada muda isso.
O que se pode realmente fazer: publicar um SPF em hard fail
Um registo SPF publicado com -all é a única configuração que atua sobre a origem do backscatter. Este hard fail pede ao servidor recetor para rejeitar, durante a transação SMTP, qualquer mensagem que inscreva o seu domínio no MAIL FROM sem provir dos seus servidores autorizados. A mensagem morre à porta, não é gerado nenhum NDR, nada regressa até si. Detalhamos a sintaxe completa no nosso artigo sobre o que acontece quando o SPF está ausente. Este guia sobre o limite das 10 consultas DNS trata da armadilha do excesso. O que nenhuma configuração fará, no entanto: impedir um spammer de escrever o seu domínio num envelope ou obrigar um servidor terceiro mal configurado a respeitar o SPF.
O DMARC intervém noutro plano. A nuance decide aquilo que se pode esperar dele aqui. Uma política em p=quarantine ou p=reject avalia-se sobre o domínio do campo From de cabeçalho, aquele que o destinatário vê, depois de verificar que uma assinatura DKIM ou um controlo SPF autentica de facto esse domínio. É a regra de alinhamento. Quando o spammer se limita a usurpar o envelope e assina a sua mensagem com um From alheio ao seu domínio, a sua política DMARC nunca é consultada pelo servidor recetor. Ela protege a sua marca contra a usurpação visível, mas não corta por si só os bounces perdidos: esse papel cabe ao SPF, com o DMARC a assumir o relevo assim que o spammer também usurpa o From apresentado.
Do lado da receção, o BATV (Bounce Address Tag Validation) resolve a triagem na origem. O seu servidor assina o endereço de retorno de cada envio de saída com um token datado, e depois recusa qualquer NDR endereçado a um endereço não assinado. Um backscatter não pode ter esse token, uma vez que responde a um envelope que nunca emitiu. Monitorizar os relatórios agregados DMARC (rua) dá, além disso, uma imagem do volume e da origem da usurpação, sem nunca a travar na fonte, com a mesma ressalva referida acima: estes relatórios só reportam as mensagens que têm o seu domínio no From de cabeçalho. Uma usurpação limitada ao envelope não aparecerá aí. Explicamos a leitura completa destes ficheiros XML no nosso guia para ler um relatório DMARC agregado.
Este endurecimento tem um teto. Um SPF hard fail não silencia os servidores que ignoram a política, que não atualizaram o seu resolvedor ou que aplicam uma avaliação parcial dos registos DNS. Esse resíduo continua a produzir bounces perdidos, mesmo depois de uma implementação correta do lado do domínio. O -all tem também um custo colateral a conhecer: uma mensagem legítima reencaminhada por um alias ou uma caixa de reencaminhamento falha o controlo SPF no destinatário final, uma vez que o IP que apresenta a mensagem já não é o seu. Os servidores de reencaminhamento bem geridos reescrevem o envelope através de SRS para evitar isso; os outros vão quebrar os seus reencaminhamentos.
Verificar que o seu próprio servidor não o produz
O raciocínio inverte-se. Esta metade do tema é quase sempre passada em silêncio. Um servidor que aceita tudo e depois devolve um NDR fabrica exatamente o ruído descrito acima, em casa de outra pessoa. As configurações que produzem este comportamento são conhecidas:
- um endereço catch-all que absorve qualquer destinatário antes de descobrir que a caixa não existe;
- uma resposta automática de ausência que responde mecanicamente a um envelope usurpado;
- uma gateway antispam que filtra depois da aceitação, em vez de recusar durante a transação SMTP.
A correção resume-se a uma regra: validar a existência do destinatário no momento do RCPT TO e recusar logo aí, com um código 5.x.x, em vez de aceitar e pedir desculpa depois. É isto que separa um servidor que protege os outros de um servidor que acaba no Backscatterer.org.
Não confundir backscatter com uma lista realmente suja
Um pico súbito de bounces nas estatísticas de envio parece, à primeira vista, uma degradação da sender reputation. Na maior parte das vezes não é nada disso, se os bounces disserem respeito a campanhas nunca enviadas. A confusão custa caro quando leva a depurar uma lista de contactos com base num sinal que não vem dela: os erros de entrega reportados pelo Google Postmaster Tools, tal como os contadores de hard bounce da sua plataforma de envio, permanecem surdos aos backscatter que nunca transitaram pelas suas próprias campanhas, uma vez que nenhum envio real os desencadeou. Antes de concluir por uma list hygiene deficiente com base num fluxo de NDR, verifique através dos cabeçalhos descritos acima se estes bounces correspondem a um envio real ou a um envelope usurpado: limpar a lista de contactos não resolverá nada se o problema vier de outro lado.
A adoção do DMARC está a progredir, impulsionada pelas regras impostas aos grandes remetentes pela Google e pela Yahoo desde fevereiro de 2024, que exigem no mínimo uma política publicada em p=none. A revisão do standard publicada em 2026 sob o nome de DMARCbis (RFC 9989) não eleva esse patamar: reformula o protocolo e substitui a lista de sufixos públicos por uma subida na árvore DNS, sem impor uma política estrita a ninguém. Já o parque residual de sistemas de correio mal configurados segue um calendário muito mais lento, o das atualizações DNS que ninguém planeou.
