Bounce de e-mail: como ler um e o que cada código significa

O que é um bounce, e os dois momentos em que ele acontece

A palavra vem do papel, e é a imagem errada. Nada viaja de volta. Uma mensagem é passada de servidor em servidor, e o último que ainda a segura e não consegue se livrar dela escreve uma mensagem nova — endereçada a você, sobre a antiga — e envia essa em vez da outra. Tudo o que dá para aprender está nesse relatório, e o relatório só é tão bom quanto a máquina que o escreveu.

Ele pode ser produzido em dois momentos bem diferentes, e diferenciar entre eles é a maior parte do diagnóstico. Dois outros resultados parecem falhas de onde você está, mas não são:

Então “deu bounce” nomeia duas coisas. Uma é um erro que o seu próprio software mostrou a você, e a outra é uma carta que a máquina de um estranho escreveu para você — e só a segunda tem um relatório para ler dentro dela. O resto deste guia é sobre esse relatório.

Onde o motivo realmente está

Um relatório de entrega é uma mensagem em três partes, e o formato está fixado desde a RFC 3464. A primeira parte é o pedido de desculpas, escrito para um humano pela máquina mais próxima de você. A segunda é o bloco legível por máquina, que é a única parte que tem fatos dentro dela. A terceira é a sua mensagem original, ou só os cabeçalhos dela, para que você consiga saber qual mensagem falhou.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Leia a parte do meio nesta ordem:

Final-Recipient:

Qual endereço falhou. Um relatório pode carregar um bloco por destinatário, então em uma mensagem enviada para várias pessoas é assim que você descobre de qual delas se trata — e as outras muito bem podem ter chegado.

Action:

failed é um bounce. delayed é um aviso de que um servidor ainda está tentando e não desistiu de nada; você ainda pode receber um segundo relatório dizendo que funcionou. relayed e delivered não são falhas de jeito nenhum, e é fácil interpretá-las como se fossem.

Status:

O código de status estendido — três números, feitos para serem lidos por software, não por você. É a parte que dá para comparar entre um provedor e outro, o que as frases nunca são.

Diagnostic-Code:

A linha que importa. É a própria resposta do servidor remoto, citada palavra por palavra, carregando o código de resposta dele e a frase que o administrador dele escreveu. Tudo acima dela é um reconto; esta é a original.

Remote-MTA:

Qual host disse isso. Vale uma olhada sempre que a falha for sobre roteamento: um nome de host que você não reconhece geralmente significa que o e-mail do domínio está indo para um lugar que você não esperava, ou para um lugar aonde ele só costumava ir.

A frase bem no topo do relatório não é evidência. O seu próprio servidor de saída a escreve, com qualquer texto que o software dele venha configurado, sobre uma falha que ele só está repassando. Dois pedidos de desculpas idênticos podem estar acima de duas linhas Diagnostic-Code: completamente sem relação, e é por isso que um bounce lido a partir do topo é lido errado com tanta frequência.

Os dois números, e o dígito que decide

Uma recusa é escrita assim, e são três coisas separadas unidas por espaços:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

O 550 é o código de resposta: três dígitos, definidos pelo próprio SMTP na RFC 5321, e a parte que o protocolo precisa para decidir o que fazer a seguir. O 5.1.1 é o código de status estendido da RFC 3463, criado porque três dígitos não conseguiam expressar o suficiente. Tudo que vem depois dele é texto livre, escrito por quem administra aquele servidor, e não padronizado por absolutamente nada.

Os dois números começam com o mesmo dígito, e esse dígito é o veredito:

O segundo número é o assunto — que tipo de coisa deu errado. É a forma mais rápida de situar um código que você nunca viu antes:

Falha permanente (hard bounce)

Um 5. O endereço está errado, não existe mais, ou é recusado por política, e reenviar a mesma mensagem não muda nada. Remetentes em massa removem um endereço da lista já no primeiro, porque insistir é o que faz um domínio de envio ser limitado em todo lugar de uma vez.

Falha temporária (soft bounce)

Um 4. Uma caixa cheia, um servidor ocupado, uma recusa temporária de política. É reenviado sem a ajuda de ninguém e geralmente chega; você só fica sabendo se as tentativas se esgotarem antes.

Nenhum dos dois termos está em alguma especificação. São a abreviação que o setor de envio usa para esse primeiro dígito — o que vale a pena saber, porque toda ferramenta de entregabilidade que você algum dia usar dá o relatório nesses termos.

Os códigos que você vai realmente encontrar

Existem dezenas no registro que a IANA mantém, e cerca de uma dúzia no dia a dia. Estes cobrem quase todo bounce que alguém lê:

Existem códigos fora desta lista, e todos eles significam alguma coisa, mas um código que você nunca viu antes é quase sempre um .7. — a política de alguém, descrita com as próprias palavras dessa pessoa na linha ao lado.

O que pode e o que não pode gerar bounce em um endereço temporário

Quase nada — e vale a pena explicar isso em detalhes, porque três das coisas que as pessoas descrevem como bounce aqui não são um bounce de jeito nenhum:

“Usuário desconhecido” não pode acontecer

O servidor aceita qualquer nome nos domínios públicos dele. anything@grabmail.io é um endereço válido antes mesmo de alguém digitá-lo, porque não existe nenhuma lista de caixas para conferir contra ela — então um 5.1.1 de GrabMail não é uma coisa que existe. Como o e-mail temporário funciona por baixo tem o mecanismo completo.

Expirar não é um bounce

Uma mensagem é apagada 5 dias depois de chegar, e nessa altura o servidor de envio já ouviu 250 fazia tempo e já esqueceu a troca inteira. Ninguém é avisado, porque nada falhou: a mensagem foi entregue, e só depois foi apagada. Quanto tempo dura uma caixa descartável é o guia para essa metade.

Um formulário que recusa o endereço não é um bounce

Nenhum e-mail chegou a ser enviado. O site comparou o domínio com uma lista e rejeitou o formulário; nada chegou a alcançar um servidor de e-mail, e não há nada para ler. Por que formulários de cadastro recusam e-mail descartável é um problema diferente, com um conjunto diferente de respostas.

Silêncio também não é um bounce

Se algo que você esperava nunca chegou e ninguém te enviou um relatório, a falha — se é que houve alguma — aconteceu do lado de quem enviou, onde você não consegue ver. E-mail que não aparece percorre as causas na ordem que vale a pena verificar.

Isso deixa exatamente uma recusa genuína, que é o teto de tamanho. Um servidor de envio que anuncia o tamanho de antemão é recusado imediatamente, antes de um único byte ser armazenado:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Um remetente que não anuncia o tamanho recebe a mesma resposta no final da mensagem, depois que os bytes já foram contados. De qualquer forma o código é 5.3.4, nada é armazenado, e uma pessoa de verdade é avisada pelo próprio sistema de e-mail dela — que é exatamente o motivo de recusar na porta em vez de aceitar e descartar.

Não existe plano nem cabeçalho que aumente o teto, e não existe bounce para mais nada aqui: sem cota de entrada, sem limite de taxa, sem recusa porque alguém já está usando aquele nome. Em um domínio compartilhado, duas pessoas que digitam o mesmo nome simplesmente compartilham a caixa de entrada, o que é uma característica de privacidade, não de entrega.

Bounces em um domínio que você acabou de apontar para cá

Apontar um domínio para uma caixa catch-all é um registro DNS, e quase todo bounce que isso produz pertence à hora em torno da mudança, não à configuração em si. Existem cinco casos, e eles parecem diferentes uns dos outros:

1. Antes de o registro existir. Um domínio sem MX e sem registro de endereço como alternativa dá aos remetentes 5.4.4 ou 5.1.2: não há para onde entregar, e nada vale a pena tentar de novo.
2. Enquanto a mudança está se propagando. Remetentes que já consultaram o registro mantêm a resposta antiga até o TTL dela acabar. Um bounce nessa janela nomeia o host antigo na linha Remote-MTA:, que é exatamente como você diferencia isso de um registro que você configurou errado.
3. Depois de se propagar. Todo nome no domínio é aceito, então “usuário desconhecido” também deixa de ser possível ali. Um registro, prioridade 10, apontando para smtp.grabmail.io, e nada mais para publicar para que o e-mail chegue.
4. Se o domínio costumava publicar um MX nulo. Domínios estacionados costumam carregar o registro que significa “este domínio nunca recebe e-mail”. Remetentes que guardaram isso em cache respondem 5.1.10 até que expire, não importa o que você tenha publicado desde então.
5. Se o domínio também envia e-mail. Um 5.7.26 em e-mail de saída não tem nada a ver com isso — é o seu próprio SPF ou DMARC não cobrindo o que quer que tenha enviado a mensagem. O guia de domínio só de recebimento é o caso estrito; um domínio que também envia precisa da implantação gradual comum, em vez disso.

Consultar o registro responde a quase tudo isso antes de alguém precisar ler um bounce:

$ dig +short MX yourdomain.com

A resposta deveria ser uma linha só: a prioridade, depois o host, depois um ponto final. Qualquer outra coisa — duas linhas, um host desconhecido, nada de jeito nenhum — é o bounce que você está prestes a receber, três minutos antes. Apontar seu próprio domínio para cá é a configuração inteira, e os três registros que impedem a falsificação são o que publicar assim que o e-mail começar a chegar.

Um bounce de uma mensagem que você nunca enviou

Ele chega parecendo exatamente um relatório de falha comum, citando uma mensagem que você nunca viu, para um destinatário de quem você nunca ouviu falar. Nada foi invadido. Alguém enviou e-mail com o seu endereço escrito no envelope como remetente, um servidor de destino aceitou a mensagem antes de descobrir que não conseguia entregá-la, e então fez o correto com uma mensagem que falhou: escreveu um relatório e o enviou para o remetente que constava. Que é você.

O nome disso é backscatter, e o que isso prova vale a pena dizer sem rodeios: nada sobre a sua caixa de entrada. Falsificar um remetente de envelope não precisa de acesso a nada — é uma linha digitada em uma conversa. Quem fez isso precisava só do seu endereço, e nada mais, e muito bem pode ter adivinhado ele.

Três coisas o separam de um bounce de verdade em cerca de dez segundos:

• A mensagem devolvida não é sua. A terceira parte do relatório carrega a original, ou pelo menos os cabeçalhos dela. Se você nunca a escreveu, você não a enviou, e tudo o mais no relatório é sobre o problema de outra pessoa.
• A cadeia Received: começa em algum lugar que você nunca usou. Leia-a de baixo para cima: a linha mais baixa é a máquina que realmente injetou a mensagem, e ela não vai ser o seu provedor. Como ler um cabeçalho de e-mail cobre a direção certa e por que a parte de baixo é o lado honesto.
• As datas não batem. Backscatter normalmente relata uma mensagem enviada horas ou dias antes de o relatório chegar até você, saída de uma fila que vem tentando reenviar a campanha de outra pessoa desde então.

Não há nada para consertar e nada para responder. Se o endereço pertence a um domínio seu, publicar SPF e DMARC reduz isso da única forma que funciona: um servidor de destino que confere a política do remetente antes de aceitar recusa a falsificação dentro da própria conversa, e nunca gera um relatório para ninguém. Três registros em um domínio só de recebimento são a versão mais estrita disso, e de longe a mais fácil de publicar.

Um nome curto em um domínio público compartilhado coleta mais disso do que um endereço privado, pelo mesmo motivo que coleta mais spam: é adivinhável, e um falsificador escolhendo remetentes de envelope não está mirando em você especificamente. É ruído sobre outra pessoa, e diferente do spam, não existe botão nenhum que treine alguma coisa — o que os controles de spam realmente fazem é o guia dos botões que funcionam de verdade.

A ordem certa para ler um

1. Decida qual tipo você tem em mãos. Um erro no seu próprio aplicativo de e-mail no momento em que você apertou enviar é uma recusa. Uma mensagem de MAILER-DAEMON que chegou depois é um relatório, e só o relatório tem alguma coisa dentro para ler.
2. Confira se é sobre uma mensagem que você realmente enviou. A cópia devolvida está na terceira parte. Se não for sua, é backscatter, e você já terminou.
3. Abra a fonte bruta. O pedido de desculpas no topo é o texto padrão do seu próprio servidor, não o motivo, e o bloco legível por máquina não é mostrado por padrão em lugar nenhum.
4. Encontre Status: e leia o primeiro dígito. Um 4 ainda está sendo tentado de novo e ainda pode dar certo sozinho; um 5 é definitivo, e nada mais vai acontecer.
5. Leia Diagnostic-Code:. Essa é a frase do outro lado, e o único lugar onde a regra que te recusou é realmente nomeada.
6. Situe o segundo dígito. .1. é o endereço, .2. a caixa de entrada, .4. a rota, .7. a política de alguém. Isso normalmente já basta para saber de quem é o problema.
7. Aja de acordo com o dono do problema. Uma falha de endereçamento se resolve tendo o endereço certo; uma falha de roteamento, consertando o DNS; uma falha de política, satisfazendo a política, ou pedindo para a pessoa do outro lado olhar os próprios logs — onde a mesma recusa está escrita com muito mais detalhes do que te enviaram.

Duas coisas nunca são a resposta. Reenviar a mensagem sem mudar nada depois de um 5 repete a mesma recusa e, feito com frequência demais, prejudica a reputação do domínio de envio em todo lugar de uma vez. E responder ao relatório não alcança ninguém: ele veio de um remetente de envelope vazio, que é exatamente o motivo pelo qual ele conseguiu ser entregue a você, para começar.

Perguntas