Módulo 6 · 6.1
Ler um bounce
Módulo 6: Mensagens de erro e resolução de problemas · Tempo de leitura: 11 minutos
Objetivo de aprendizagem: No final desta lição, será capaz de analisar uma mensagem de erro sobre um email não entregue (um bounce): que servidor deu o erro, para que endereço, o que significa o código, e se é temporário ou definitivo.
Conceitos-chave: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, código de resposta (RFC 5321), código de estado alargado X.Y.Z (RFC 3463), mensagem de adiamento, backscatter
O que é um bounce?
Se um servidor de correio não conseguir entregar um email, envia uma mensagem de volta ao remetente. A isto chama-se um bounce (ou: non-delivery report, NDR). Vem de um remetente como Mailer-Daemon@..., MAILER-DAEMON ou Mail Delivery System, com um assunto como:
Mail delivery failed: returning message to senderUndelivered Mail Returned to SenderDelivery Status Notification (Failure)Warning: message ... delayed 24 hours(isto não é um bounce mas sim uma mensagem de adiamento, ver mais adiante)
Muitas pessoas deitam fora estas mensagens de imediato, ou assustam-se com o texto em inglês. É uma pena, porque um bounce quase sempre diz exatamente o que correu mal. Só precisa de saber onde olhar.
Um bounce tem sempre um remetente de envelope vazio (Return-Path: <>). Isto é intencional: um bounce sobre um bounce poderia, caso contrário, criar um ciclo infinito (RFC 5321).
Quem recusou o email?
Um email passa por pelo menos dois servidores: o do seu fornecedor e o do destinatário. Um bounce pode surgir em duas situações:
- O servidor de destino recusa o email durante a conversa SMTP (lição 1.2), por exemplo após
RCPT TO(endereço desconhecido) ou após o conteúdo (spam ou DMARC). O seu próprio servidor recebe essa recusa e cria um bounce para si. O erro vem então do destinatário, o bounce do seu próprio servidor. - O seu próprio servidor desiste, por exemplo porque o destinatário esteve inacessível durante dias, ou porque atingiu um limite próprio.
Esta distinção é importante: no primeiro caso, precisa de saber o que desagradou ao destinatário; no segundo caso, o problema está mais perto de si.
A parte legível
No topo encontra um texto destinado a pessoas. Varia consoante o software de correio, mas quase sempre contém as mesmas informações:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
pieter.devries@example.net
host mx1.example.net [198.51.100.20]
SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknownLeia-o assim:
| Parte | O que significa |
|---|---|
permanent error | Definitivo: o servidor não volta a tentar |
pieter.devries@example.net | O endereço para o qual correu mal (com vários destinatários: apenas este) |
host mx1.example.net [198.51.100.20] | O servidor do destinatário com o qual se estabeleceu a conversa |
SMTP error from remote mail server | O erro veio do destinatário, não do seu próprio servidor |
after RCPT TO | Em que momento da conversa: aqui, ao indicar o destinatário |
550 5.1.1 ... User unknown | O código e o texto do destinatário: este endereço não existe |
A parte para máquinas: o DSN
Por baixo do texto encontra-se geralmente uma parte destinada a programas, a delivery status notification (RFC 3464). Tem sempre a mesma estrutura, o que facilita a leitura:
Reporting-MTA: dns; mail.hosting.example
Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown| Campo | Significado |
|---|---|
Reporting-MTA | O servidor que escreveu este bounce (geralmente o seu próprio servidor de envio) |
Final-Recipient | O endereço em questão |
Action | failed (falhou, definitivo), delayed (adiado, ainda vai tentar), por vezes delivered ou relayed |
Status | O código de estado alargado, ver abaixo |
Remote-MTA | O servidor do outro lado que deu a resposta |
Diagnostic-Code | A resposta literal desse servidor: aqui encontra o verdadeiro motivo |
Will-Retry-Until | Em delayed: até quando o servidor continuará a tentar |
Totalmente em baixo encontra o email original ou apenas os seus cabeçalhos. Aí pode ver qual foi o email, e que endereço de remetente e que Return-Path foram utilizados. Isso é por vezes a chave para a solução (ver o caso de DMARC no exercício).
Ler os códigos
Existem dois tipos de códigos, e geralmente ambos aparecem num bounce.
O código de resposta (RFC 5321): três algarismos, como 550 ou 451. O primeiro algarismo é o mais importante:
| Começa por | Significado | O que o servidor de envio faz |
|---|---|---|
2 | Sucesso | Nada mais, o email foi aceite |
4 | Erro temporário | Guarda o email e volta a tentar mais tarde |
5 | Erro definitivo | Desiste e envia um bounce |
O código de estado alargado (RFC 3463): três números separados por pontos, como 5.1.1 ou 4.7.500. O primeiro número é novamente 2, 4 ou 5. O segundo número indica onde está o problema:
| Segundo número | Assunto | Exemplos |
|---|---|---|
X.1 | Endereço | 5.1.1 o endereço não existe, 5.1.2 o domínio não existe |
X.2 | Caixa de correio | 5.2.2 / 4.2.2 caixa de correio cheia, 5.2.1 caixa de correio desativada |
X.3 | Sistema de correio | 5.3.4 mensagem demasiado grande |
X.4 | Rede e encaminhamento | 4.4.1 sem resposta, 4.4.7 demasiado tempo na fila, 5.4.4 sem rota |
X.5 | Protocolo | 5.5.1 comando inválido |
X.6 | Conteúdo | 5.6.0 problema com o conteúdo ou a codificação |
X.7 | Segurança e política | 5.7.1 recusado, 5.7.26 não autenticado (Gmail), 5.7.509 DMARC (Microsoft) |
O terceiro número é o motivo preciso. Os grandes destinatários utilizam os seus próprios números para isso, como o Gmail com 5.7.25 a 5.7.30 e a Microsoft com 4.7.500 e 5.7.509. Estes constam da respetiva documentação (lição 6.2).
Regra prática: o código que começa por 5 e tem um 7 no meio (5.7.x) é quase sempre uma questão de política: autenticação, reputação ou spam. Reenviar não ajuda nesse caso; é preciso alterar algo.
Adiado ainda não é falhado
Perante um erro temporário (4xx), o seu servidor guarda o email e volta a tentar. A RFC 5321 recomenda persistir durante pelo menos quatro a cinco dias, com pelo menos meia hora entre tentativas. Muitos servidores enviam, ao fim de algumas horas ou de um dia, uma mensagem de adiamento:
Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100Isto significa: não reenviar, o servidor ainda vai tentar por si próprio. Se mesmo assim reenviar, o destinatário poderá acabar por recebê-lo duas vezes. Se finalmente não resultar antes de Will-Retry-Until, surgirá ainda assim um bounce real, frequentemente com 4.4.7 (mensagem expirada na fila).
Bounces falsos: backscatter
Recebeu subitamente dezenas de bounces de emails que nunca enviou? Verifique então o email original em baixo. Se lá aparecer um remetente do seu domínio, mas um servidor e um texto que não reconhece, então um spammer utilizou o seu endereço como remetente. Os destinatários enviam os seus bounces para si. A isto chama-se backscatter.
A sua caixa de correio normalmente não foi pirateada nesse caso (ver a lição 3.4 para a diferença). O que ajuda: uma política DMARC que se torna gradualmente mais rigorosa (lição 4.4), de modo a que os destinatários recusem o email falsificado antes de se gerar um bounce. Verifique no entanto os seus emails enviados e junto do seu fornecedor se não foi realmente enviado nada a partir da sua caixa de correio.
Na prática: é assim que se apresenta
No WebOké, além do bounce, também pode ver em Rastreamento de e-mails no DirectAdmin o que o servidor fez com uma mensagem: Entregue, Adiado ou Falha, com a resposta do servidor de destino. Outros painéis têm frequentemente um registo de correio ou "rastreamento de mensagens" semelhante; no Microsoft 365, por exemplo, chama-se rastreamento de mensagens. É útil verificar primeiro aí se não recebeu nenhum bounce, ou se alguém diz que o seu email não chegou.
Resumo
- Um bounce vem do Mailer-Daemon e tem um Return-Path vazio. Leia-o, geralmente diz exatamente o que correu mal.
- Verifique primeiro quem deu o erro (
SMTP error from remote mail server= o destinatário) e para que endereço. - Na parte para máquinas:
Action,Status,Remote-MTAe, sobretudo,Diagnostic-Code. - Primeiro algarismo: 4 = temporário, 5 = definitivo. Segundo número: 1 endereço, 2 caixa de correio, 3 sistema, 4 encaminhamento, 5 protocolo, 6 conteúdo, 7 política.
- Mensagem de adiamento (
delayed): não reenviar. Bounces de emails que não enviou: backscatter.
Quiz
Exercício
Exercício Z6.1: Analisar três bounces. Recebe três bounces de exemplo (bounce-1.txt, bounce-2.txt e bounce-3.txt). Preencha, para cada bounce: o endereço para o qual correu mal, o servidor que deu o erro (Remote-MTA), o código de estado, se é temporário ou definitivo, e o que o remetente deve fazer (escolha de uma lista). O programa verifica com uma chave fixa e dá explicação por cada campo.
Para saber mais
Os passos descritos nestes artigos aplicam-se aos painéis do WebOké; noutros fornecedores o funcionamento é semelhante.
- Falha na entrega do email: como interpretar a mensagem de erro e o que significam os códigos
- Mensagem de erro: 550 5.5.0 Requested action not taken: mailbox unavailable
- Verificar se um e-mail chegou com o rastreio de e-mail (Email Tracking) no DirectAdmin
- Manual DirectAdmin 9.3: Rastreamento de e-mails: onde ficou o meu e-mail?
- RFC 3464 (estrutura de um DSN), RFC 3463 (códigos de estado alargados), RFC 5321 secção 4.2 (códigos de resposta) e 4.5.4.1 (repetição de tentativas)