> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ar-online.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Hard bounce e prova jurídica

> O que é uma recusa permanente de entrega (hard bounce), por que a plataforma não reenvia automaticamente e como o evento é transformado em prova pericial.

Um **hard bounce** é a recusa **permanente** de entrega de um e-mail pelo servidor de destino. Ele é sinalizado por códigos de resposta SMTP da família **5xx**, como:

| Código                      | Significado                 |
| --------------------------- | --------------------------- |
| `550 User unknown`          | Usuário inexistente         |
| `550 Mailbox not found`     | Caixa postal não encontrada |
| `550 Account disabled`      | Conta desativada            |
| `550 Domain does not exist` | Domínio inexistente         |

<Note>
  **Hard bounce ≠ soft bounce.** O hard bounce é **definitivo** (o endereço não existe ou foi desativado). O **soft bounce** é **temporário** — por exemplo, uma caixa postal cheia — e pode ser reentregue mais tarde.
</Note>

## Por que a plataforma não reenvia automaticamente

Os provedores de e-mail monitoram a **qualidade do remetente**. Reenviar repetidamente para endereços que retornam hard bounce prejudica essa reputação e pode causar:

* **Redução da taxa de entrega** de todos os seus envios.
* **Inclusão em blacklists** internacionais.
* **Desvio das mensagens para a pasta de Spam**.

Por isso, diante de um hard bounce, a plataforma **interrompe** novas tentativas para aquele endereço, preservando a entregabilidade dos demais envios.

<Warning>
  Endereços incluídos manualmente na **whitelist** que gerarem hard bounce são movidos **automaticamente para a blacklist**.
</Warning>

## Do bounce à prova pericial

Um hard bounce não é apenas uma falha — é um **evento comprovável**. A plataforma transforma o retorno do servidor em prova jurídica seguindo este processo:

<Steps>
  <Step title="Captura do NDR">
    Registro do **NDR completo** (Non-Delivery Report) — a resposta integral do servidor de destino, com o código SMTP e a mensagem de recusa.
  </Step>

  <Step title="Carimbo de tempo">
    Aplicação de **carimbo de tempo** com validade legal (ICP-Brasil), atestando o momento exato do evento. Veja como [verificar o carimbo](/acompanhando/comprovante-e-laudo#verificacao-do-carimbo-do-tempo).
  </Step>

  <Step title="Hash de integridade">
    Geração de um **hash SHA-256** do conteúdo, garantindo que o registro não foi alterado.
  </Step>

  <Step title="Armazenamento imutável">
    Guarda em **storage imutável (WORM)** — *write once, read many* —, impedindo modificação ou exclusão posterior.
  </Step>

  <Step title="Relatório pericial">
    Emissão de um **relatório pericial** com assinatura digital, pronto para uso comprobatório.
  </Step>
</Steps>

Um registro pericial típico documenta o evento de forma objetiva, por exemplo:

> Na data 11/05/2026 às 14:32:17 (carimbo de tempo), o servidor de destino `mx.gmail.com` retornou o código `550 5.1.1 User unknown`.

## Envios em volume

Para operações de **alto volume**, a plataforma oferece tratamento dedicado ao hard bounce:

* **Domínio secundário exclusivo** para isolar a reputação dos envios.
* **Controle individual** de cada envio.
* **Relatório pericial automático** por evento.
* **Estratégia de fallback** para outros canais ([WhatsApp](/enviando/whatsapp) / [SMS](/enviando/sms)) quando o e-mail falha.
* **Relatórios consolidados** do conjunto de envios.

<Info>
  O laudo pericial de um envio pode ser baixado pela API. Veja [Comprovante e laudo pericial](/acompanhando/comprovante-e-laudo).
</Info>