# Porque as mensagens OTP falham — e como corrigir problemas de entrega

> As palavras-passe OTP falham por uma lista finita de motivos: rejeição do ID do remetente, rotas cinzentas, limitação de taxa, filtros de conteúdo, codificação, congestionamento. Um guia de diagnóstico e correção para engenheiros de campo.

- URL canônico: https://www.broadnet.me/pt/blog/why-otp-messages-fail-delivery-troubleshooting
- Idioma: pt
- Última atualização: 2026-10-20
- Editor: BroadNet (https://www.broadnet.me)

- Publicado em: 2026-05-20
- Autor: BroadNet Engineering

Quando um código de acesso único (OTP) não chega, o utilizador fica preso no ecrã de login ou de finalização da compra, a um passo de desistir. A parte frustrante para a equipa de engenharia é que, muitas vezes, a mensagem foi enviada corretamente — a API devolveu 202, o envio via SMPP foi aceito e a plataforma exibe uma mensagem na fila. A falha ocorreu em algum ponto da cadeia de dados que a equipa de desenvolvimento não consegue visualizar diretamente. Este artigo aborda a lista finita de motivos pelos quais os OTPs falham em produção, como diferenciá-los dos comprovativos de envio e o padrão de correção para cada um deles.

## A superfície de ruptura é menor do que parece.

O tráfego OTP falha por um destes sete motivos, aproximadamente nesta ordem de frequência: rejeição do ID do remetente na operadora de destino, um salto de rota cinza que descarta ou atrasa a mensagem, limitação de largura de banda no SMSC ou no firewall, filtros de conteúdo acionados por um modelo, incompatibilidade de codificação entre o conteúdo UCS-2 e um modelo GSM-7, congestionamento de rede na operadora de destino e o próprio aparelho inacessível (desligado, fora da área de cobertura, portado com encaminhamento desatualizado). Todos os outros casos — MSISDN corrompido, credenciais expiradas, eventos de inatividade de rota — representam uma pequena minoria. Diagnostique primeiro os casos mais comuns.

## Leia os comprovativos de entrega, não a resposta do envio.

O maior erro que as equipas cometem é tratar um envio bem-sucedido (202 de HTTP, ESME_ROK em submit_sm) como prova de que a mensagem foi entregue. Não é. Envio significa que a plataforma aceitou a mensagem; entrega significa que o dispositivo a recebeu. Todo sistema OTP precisa estar conectado ao [relatório de entrega](https://www.broadnet.me/answers/what-is-dlr) (DLR), que chega posteriormente como um webhook ou um PDU deliver_sm e contém um dos seguintes códigos de status: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. O primeiro sinal para qualquer investigação de OTP é a distribuição do status do DLR por rota, ID do remetente, operadora de destino e janela de tempo — não a taxa de sucesso do envio.

## Diagnostique identificando onde ocorreu a falha.

Uma investigação limpa de OTP divide a falha em quatro segmentos e trabalha de trás para frente, a partir do sinal mais a jusante. Segmento 1: falha na submissão — a plataforma rejeitou a chamada antes mesmo de ela ser enviada, quase sempre devido a um ID do remetente malformado, uma categoria de modelo não registada, um país não suportado ou um campo obrigatório ausente. Segmento 2: aceita na submissão, mas nunca entregue ao SMSC de destino — geralmente um problema de qualidade de rota ou um bloqueio de firewall. Segmento 3: entregue ao SMSC e devolveu um DLR negativo — conteúdo filtrado, ID do remetente na lista negra da operadora, destinatário bloqueado. Segmento 4: DLR positivo, mas o utilizador relata não ter recebido a mensagem — aparelho desligado, portabilidade para outra operadora com encaminhamento desatualizado, filtro de spam no nível do sistema operativo ou notificação suprimida. A solução difere em cada segmento; confundi-los leva as equipas a um caminho sem saída.

## As sete causas comuns e o que fazer em relação a cada uma delas.

### 1. Rejeição do ID do remetente

Muitos mercados regulamentados — Emirados Árabes Unidos sob a TDRA, Arábia Saudita sob a CST, Egito sob a NTRA, Índia sob a DLT da TRAI — exigem que cada ID de remetente alfanumérico seja pré-registado numa entidade legal verificada. O tráfego enviado com um ID não registado é rejeitado na fronteira da operadora e gera um DLR negativo, sem mensagem entregue, embora a resposta de envio tenha sido 202. A solução é o registo, e o diagnóstico consiste em correlacionar UNDELIV/REJECTD com o ID do remetente e o país de destino: se todas as falhas partilharem um ID de remetente num país, o problema está no registo. Consulte o [guia de registo de ID de remetente para mercados do GCC](https://www.broadnet.me/blog/sender-id-registration-guide-gcc-markets) para obter a documentação específica.

### 2. Saltos de rota cinza

Rotas internacionais de baixo custo frequentemente envolvem um ou mais saltos de reinjeção por meio de agregadores parceiros ou terminações em fazendas de SIM. Cada salto adiciona latência, aumenta a probabilidade de descarte silencioso e a chance de o firewall da operadora de destino categorizar o tráfego como A2P não autorizado e bloqueá-lo. A característica principal é uma alta taxa de UNDLIV (não entregue), alta variação de latência e uma taxa de entrega que cai drasticamente quando a operadora de destino implementa ou atualiza um firewall de SMS. A solução é mover o OTP para uma rota direta da operadora; a relação custo-benefício é discutida em [rotas diretas versus rotas cinzas].

### 3. Limitação de largura de banda no SMSC ou firewall

Cada operadora e cada firewall impõe um limite de TPS (transações por segundo) por ID de remetente e por rota. Se esse limite for ultrapassado, as mensagens são rejeitadas imediatamente (na melhor das hipóteses, você vê a falha) ou enfileiradas e entregues com atraso (na pior das hipóteses, chegam depois que o OTP (palavra-passe de uso único) expirou e o utilizador já desistiu). O diagnóstico consiste em observar os picos de submissão em relação à latência p95: uma curva de latência estável sob carga constante que apresenta picos durante rajadas indica limitação de taxa. A solução é limitar a taxa na camada de aplicação para suavizar as rajadas e negociar um limite de TPS mais alto especificamente para o tráfego da classe OTP.

### 4. Filtros de conteúdo

Classificadores de conteúdo de operadoras e firewalls podem sinalizar modelos de OTP que contenham palavras-chave, URLs (a maioria das operadoras é rigorosa com links curtos não verificados em conteúdo transacional), nomes de remetentes incomuns ou layouts que se assemelham a padrões de phishing conhecidos. A característica principal é um único modelo que repentinamente apresenta taxas elevadas de REJEIÇÃO, enquanto todo o resto é encaminhado normalmente. A solução é higienizar o modelo: texto de OTP curto e convencional, sem links curtos e sem linguagem que transmita urgência. Se o modelo for regulamentado (em alguns mercados, os modelos transacionais devem ser pré-registados), certifique-se de que a versão registada corresponda à versão enviada — pequenas variações são detetadas.

### 5. Incompatibilidade de codificação

Os modelos OTP com caracteres não ASCII (uma vogal acentuada, uma aspa especial copiada de um documento de design, um dígito arábico) atualizam silenciosamente a mensagem de GSM-7 para UCS-2, reduzindo o limite de caracteres por segmento de 160 para 70 e causando mensagens concatenadas que alguns aparelhos mais antigos remontam incorretamente. O diagnóstico consiste em inspecionar o modelo renderizado byte a byte, e não o modelo como o desenvolvedor o interpreta. A solução é a revisão do modelo considerando a codificação e uma verificação em tempo de compilação que sinaliza quaisquer caracteres não GSM-7 num modelo transacional.

### 6. Congestionamento da rede

Os SMSCs dos operadores de destino ocasionalmente ficam congestionados durante eventos importantes (Eid, Black Friday, feriados nacionais, grandes interrupções de energia) — os envios são aceitos, mas a latência de entrega aumenta de menos de um segundo para vários minutos. Não há uma solução simples por parte do remetente; a mitigação consiste em detetar a condição (um aumento acentuado na latência p95 em todas as rotas para um operador) e recorrer a um canal alternativo antes que a janela de OTP se feche.

### 7. Aparelho fora de área de alcance

Uma pequena, porém persistente, fração das falhas de OTP não se deve à infraestrutura — o aparelho está desligado, fora da área de cobertura, em modo avião, com o filtro de spam da operadora bloqueando remetentes desconhecidos, ou foi migrado para uma nova operadora e as tabelas de encaminhamento ainda não convergiram. A assinatura é de DLRs EXPIRADOS ou DESCONHECIDOS espalhados por todas as rotas e IDs de remetente, sem nenhuma concentração de operadora. A solução é a cadeia de fallback discutida abaixo.

## Crie o painel de diagnóstico uma vez e use-o para sempre.

A maioria das investigações de OTP (Opções de Entrega de Pacotes) fica paralisada porque a equipa está a analisar logs brutos sob pressão. As equipas que se recuperam rapidamente possuem um painel de controlo permanente com cinco widgets: distribuição do status DLR por operadora de destino (o gráfico mais útil), latência de ponta a ponta p50/p95/p99 por rota, taxa de entrega por ID do remetente, taxa de entrega por modelo de conteúdo e uma série temporal em tempo real do envio à entrega na última hora. Crie esses widgets uma única vez. Eles fazem toda a diferença entre um diagnóstico de quarenta minutos e um de quatro horas.

## Padrões de remediação que realmente funcionam

### Vinculação direta apenas para OTP

O tráfego de marketing em massa e o tráfego OTP não devem partilhar um vínculo ou uma rota. O marketing é sensível a custos, tolerante à latência e pode usar rotas grossistas; o OTP é crítico em termos de latência e entregabilidade, e precisa do vínculo direto. Partilhá-los significa que um pico de tráfego de marketing congestiona o caminho do OTP e um filtro de viagem de modelo de marketing prejudica a reputação da rota para o OTP.

### Cadeia de contingência, automática e com tempo limitado

Ao projetar o sistema, considere a possibilidade de que qualquer canal individual falhe ocasionalmente e projete a cadeia de contingência de acordo: utilize o modelo de autenticação do WhatsApp ou RCS como primeira opção quando o utilizador estiver acessível em qualquer um dos canais, SMS como contingência universal e OTP por voz como último recurso. A contingência deve ser automática (sem necessidade de nova tentativa manual pelo utilizador), com tempo limite definido (o tempo de espera antes da transição deve ser menor que a paciência do utilizador — geralmente de 8 a 15 segundos) e condicional (não utilize a contingência em caso de DLR positivo; utilize em caso de tempo limite ou DLR negativo). Além disso, o código OTP deve ser gerado uma única vez e reutilizado em todos os canais, para que o utilizador não receba dois códigos válidos.

### Evite duplicatas em todas as tentativas

Quando o utilizador toca em "reenviar" ou a aplicação tenta novamente automaticamente, verifique antes de enviar de novo. A API da BroadNet não aceita chave de idempotência, então a deduplicação fica no seu código: registe cada envio antes de fazê-lo, guarde o ID de mensagem que a API devolve e verifique o status dessa mensagem antes de qualquer reenvio (veja [idempotência e novas tentativas seguras](https://www.broadnet.me/developers/idempotency)). Sem essa verificação, um primeiro envio lento, porém bem-sucedido, e um reenvio automático geram dois códigos OTP na caixa de entrada do utilizador; o utilizador utiliza o mais antigo, a verificação falha e a equipa culpa o serviço de OTP quando o problema estava na lógica de repetição.

### Recurso de voz para a cauda longa.

Aproximadamente um por cento dos utilizadores num dia qualquer não receberá um SMS por qualquer um dos motivos acima, e esse um por cento é a pequena parcela que entra em contacto com o suporte. Um [OTP por voz](https://www.broadnet.me/products/myotp) — uma chamada que lê o código em voz alta — resolve quase todos esses problemas. É a diferença entre um utilizador irritado que tenta outro navegador e um utilizador perdido que desiste.

> O serviço OTP da BroadNet lida com a vinculação direta, a cadeia de fallback e a escalação de voz por meio de uma única chamada de API, devolve um ID de mensagem que você pode verificar antes de qualquer reenvio — e expõe a análise detalhada do DLR por canal e por operadora, da qual o guia de diagnóstico acima depende.

## O que significa um bom resultado, em números.

Um sistema OTP bem instrumentado, enviando dados para um mercado regulamentado do GCC por meio de rotas diretas da operadora, com uma cadeia de contingência funcional, deve apresentar: taxa de conclusão de ponta a ponta superior a 99% (o utilizador verificou com sucesso, e não apenas que a mensagem foi entregue), latência p95 inferior a cinco segundos no canal primário e uma taxa de contingência mensurável, porém pequena (1-3%), para o canal secundário. Se os seus números forem significativamente piores, o problema quase certamente se deve a uma das sete causas acima — diagnostique, não chute.

## Leituras relacionadas

- [API de SMS versus SMPP — qual é a melhor opção para empresas?](https://www.broadnet.me/blog/sms-api-vs-smpp-enterprise-decision-guide)
- [Como os bancos devem monitorizar a entrega de OTP e fraudes](https://www.broadnet.me/blog/bank-otp-delivery-monitoring-fraud-playbook)
- [Como a verificação de chamadas instantâneas afeta a receita A2P da operadora](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- Glossário — [o que é OTP](https://www.broadnet.me/answers/what-is-otp), [o que é um DLR](https://www.broadnet.me/answers/what-is-dlr), [o que é verificação de chamada instantânea](https://www.broadnet.me/answers/what-is-flash-call-verification)
- Páginas de produtos — [Serviço OTP](https://www.broadnet.me/products/otp) e [OTP de voz MyOTP](https://www.broadnet.me/products/myotp)
- Cobertura — [Encaminhamento de SMS A2P e OTP nos Emirados Árabes Unidos](https://www.broadnet.me/coverage/uae)