# ¿Por qué fallan los mensajes OTP y cómo solucionar los problemas de entrega?

> Las contraseñas de un solo uso (OTP) fallan por una lista finita de razones: rechazo del identificador del remitente, rutas grises, limitación de velocidad, filtros de contenido, codificación, congestión. Guía de diagnóstico y solución de problemas para ingenieros de campo.

- URL canónica: https://www.broadnet.me/es/blog/why-otp-messages-fail-delivery-troubleshooting
- Idioma: es
- Última actualización: 2026-10-20
- Editor: BroadNet (https://www.broadnet.me)

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

Cuando no llega un código de acceso de un solo uso, el usuario se queda atascado en la pantalla de inicio de sesión o de pago, a punto de abandonar la compra. Lo frustrante para el equipo de ingeniería es que, a menudo, el mensaje se envía correctamente: la API devuelve el código 202, la solicitud SMPP se acepta y la plataforma muestra un mensaje en cola. El fallo se produce en algún punto de la red, en una conexión que el equipo de desarrollo no puede ver directamente. Este artículo analiza la lista de posibles fallos de los códigos de acceso de un solo uso en producción, cómo distinguirlos de los recibos que sí se tienen y el método de solución para cada caso.

## La superficie de falla es más pequeña de lo que parece.

El tráfico OTP falla por una de siete razones, aproximadamente en este orden de frecuencia: rechazo de ID de remitente en el operador de destino, un salto de ruta gris que descarta o retrasa el mensaje, limitación de velocidad en el SMSC o el firewall, filtros de contenido que se activan en una plantilla, discrepancia de codificación entre el contenido UCS-2 y una plantilla GSM-7, congestión de la red en el operador de destino y el propio terminal inaccesible (apagado, fuera de cobertura, con enrutamiento obsoleto). Todo lo demás —MSISDN corrupto, credenciales caducadas, eventos de enrutamiento caído— es una pequeña minoría. Diagnostique primero los casos más comunes.

## Lea las confirmaciones de entrega, no la respuesta a la solicitud.

El error más grave que cometen los equipos es interpretar un envío exitoso (202 de HTTP, ESME_ROK en submit_sm) como prueba de que el mensaje fue entregado. No lo es. El envío significa que la plataforma aceptó el mensaje; la entrega significa que el terminal lo recibió. Cada sistema OTP debe estar conectado al [confirmación de entrega](https://www.broadnet.me/answers/what-is-dlr) (DLR), que llega posteriormente como un webhook o una PDU deliver_sm y contiene uno de un pequeño conjunto de códigos de estado: DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. La primera señal para cualquier investigación de OTP es la distribución del estado del DLR por ruta, ID del remitente, operador de destino y ventana de tiempo, no la tasa de éxito del envío.

## Diagnostique separando dónde ocurrió la falla.

Una investigación de OTP limpia divide el fallo en uno de cuatro segmentos y trabaja hacia atrás desde la señal más distal. Segmento 1: fallo en el envío: la plataforma rechazó la llamada antes de que saliera, casi siempre por un ID de remitente mal formado, una categoría de plantilla no registrada, un país no compatible o un campo obligatorio faltante. Segmento 2: aceptado en el envío pero nunca entregado al SMSC de destino: generalmente un problema de calidad de ruta o un bloqueo de firewall. Segmento 3: entregado al SMSC y devuelto un DLR negativo: contenido filtrado, ID de remitente en la lista negra del operador, destinatario bloqueado. Segmento 4: DLR positivo pero el usuario informa que no hay mensaje: teléfono apagado, portabilidad a un operador diferente con enrutamiento obsoleto, filtro de spam a nivel del sistema operativo o notificación suprimida. La remediación difiere en cada segmento; confundirlos lleva a los equipos por un camino equivocado.

## Las siete causas comunes y qué hacer al respecto.

### 1. Rechazo de identificador de remitente

Muchos mercados regulados —EAU bajo TDRA, Arabia Saudita bajo CST, Egipto bajo NTRA, India bajo DLT de TRAI— requieren que cada ID de remitente alfanumérico esté preregistrado con una entidad legal verificada. El tráfico enviado con un ID no registrado es rechazado en el límite del operador y produce un DLR negativo sin que se entregue ningún mensaje, pero la respuesta de envío fue 202. La solución es el registro, y el diagnóstico consiste en correlacionar UNDELIV/REJECTD con el ID de remitente y el país de destino: si todos los fallos comparten un mismo ID de remitente en un país, el problema reside en el registro. Consulte la [guía de registro de ID de remitente para los mercados del CCG](https://www.broadnet.me/blog/sender-id-registration-guide-gcc-markets) para obtener la documentación específica.

### 2. Saltos de ruta gris

Las rutas internacionales económicas suelen implicar uno o más saltos de reinyección a través de agregadores asociados o terminaciones de granjas de SIM. Cada salto añade latencia, aumenta la probabilidad de pérdida silenciosa y eleva la posibilidad de que el firewall del operador de destino clasifique el tráfico como A2P no autorizado y lo bloquee. La característica principal es una alta tasa de entregas no entregadas (UNDELIV), una alta variabilidad de latencia y una tasa de entrega que cae drásticamente cuando el operador de destino implementa o actualiza un firewall SMS. La solución consiste en trasladar la OTP a una ruta directa del operador; la disyuntiva se analiza en el artículo "Rutas directas frente a rutas grises" (/blog/direct-routes-vs-grey-routes-a2p-sms).

### 3. Limitación de ancho de banda en el SMSC o el cortafuegos.

Cada operador y cada firewall impone un límite de TPS por remitente y por ruta. Si se supera este límite, los mensajes se rechazan inmediatamente (en el mejor de los casos, se observa el fallo) o se ponen en cola y se entregan con retraso (en el peor de los casos, llegan después de que la OTP haya expirado y el usuario ya haya desistido). El diagnóstico consiste en analizar los picos de envío frente a la latencia p95: una curva de latencia estable bajo carga constante que presenta picos durante los picos indica limitación de velocidad. La solución consiste en limitar la velocidad en la capa de aplicación para suavizar los picos y negociar un límite de TPS más alto específicamente para el tráfico de clase OTP.

### 4. Filtros de contenido

Los clasificadores de contenido de operadores y firewalls pueden marcar las plantillas OTP que contienen palabras clave, URL (la mayoría de los operadores son estrictos con los enlaces cortos no verificados en el contenido transaccional), nombres de remitente inusuales o diseños que se asemejan a patrones de phishing conocidos. La señal es que una sola plantilla de repente presenta tasas de RECHAZO elevadas mientras que todo lo demás se enruta correctamente. La solución es la higiene de la plantilla: texto OTP corto y convencional, sin enlaces cortos ni lenguaje que genere urgencia. Si la plantilla está regulada (en algunos mercados las plantillas transaccionales deben registrarse previamente), asegúrese de que la versión registrada coincida con la versión que se envía; las pequeñas variaciones se detectan.

### 5. Discrepancia en la codificación

Las plantillas OTP con caracteres no ASCII (vocales acentuadas, comillas especiales copiadas de documentos de diseño, dígitos arábigos) actualizan silenciosamente el mensaje de GSM-7 a UCS-2, reduciendo el límite de caracteres por segmento de 160 a 70 y generando mensajes concatenados que algunos teléfonos antiguos reensamblan incorrectamente. El diagnóstico consiste en inspeccionar la plantilla renderizada byte a byte, no la plantilla tal como la percibe el desarrollador. La solución es una revisión de la plantilla que tenga en cuenta la codificación y una comprobación en tiempo de compilación que identifique cualquier carácter que no sea GSM-7 en una plantilla transaccional.

### 6. Congestión de la red

Los SMSC de los operadores de destino a veces se saturan durante eventos importantes (Eid, Black Friday, días festivos nacionales, grandes interrupciones del servicio): se aceptan los envíos, pero la latencia de entrega aumenta de menos de un segundo a varios minutos. No existe una solución definitiva por parte del remitente; la mitigación consiste en detectar la situación (un aumento brusco de la latencia p95 en todas las rutas hacia un operador) y cambiar a un canal alternativo antes de que se cierre la ventana de OTP.

### 7. Teléfono fuera de alcance

Una pequeña pero persistente fracción de fallos de OTP no se debe a problemas de infraestructura: el teléfono está apagado, fuera de cobertura, en modo avión, tiene el filtro de spam del operador bloqueando remitentes desconocidos o se transfirió a un nuevo operador y las tablas de enrutamiento no han convergido. La firma es EXPIRADA o DLR DESCONOCIDA dispersa en todas las rutas e identificadores de remitente sin concentración de operador. La solución es la cadena de reserva que se describe a continuación.

## Crea el panel de diagnóstico una vez y úsalo para siempre.

La mayoría de las investigaciones de OTP se estancan porque el equipo está leyendo registros sin procesar bajo presión. Los equipos que se recuperan rápidamente cuentan con un panel de control permanente con cinco widgets: distribución del estado DLR por operador de destino (el gráfico más útil), latencia de extremo a extremo p50/p95/p99 por ruta, tasa de entrega a nivel de ID de remitente, tasa de entrega a nivel de plantilla de contenido y una serie temporal en tiempo real de envío a entrega de la última hora. Cree estos widgets una sola vez. Marcan la diferencia entre un diagnóstico de cuarenta minutos y uno de cuatro horas.

## Patrones de remediación que realmente funcionan

### Enlaces directos solo para OTP

El tráfico de marketing masivo y el tráfico OTP no deben compartir una ruta ni un enlace. El marketing es sensible al costo, tolera la latencia y puede usar rutas mayoristas; el OTP es crítico en cuanto a latencia y capacidad de entrega, y necesita un enlace directo. Compartirlos implica que un pico de marketing congestiona la ruta OTP y que un filtro de viaje de plantilla de marketing perjudica la reputación de la ruta para OTP.

### Cadena de reserva, automática y con límite de tiempo.

Arquitecto partiendo de la premisa de que cualquier canal individual fallará en ocasiones y diseñando la cadena de respaldo en consecuencia: plantilla de autenticación de WhatsApp o RCS primero cuando el usuario esté localizable en cualquiera de ellos, SMS como respaldo universal, OTP de voz como último recurso. El respaldo debe ser automático (sin reintentos manuales por parte del usuario), con límite de tiempo (la espera antes del respaldo es menor que el margen de paciencia del usuario, normalmente de 8 a 15 segundos) y condicional (no se debe realizar el respaldo ante un DLR positivo; sí se debe realizar ante un tiempo de espera agotado o un DLR negativo). Además, el código OTP debe generarse una sola vez y reutilizarse en todos los canales para que el usuario no reciba dos códigos válidos.

### Evite duplicados en cada reintento

Cuando el usuario pulsa «reenviar» o la aplicación reintenta automáticamente, compruebe antes de volver a enviar. La API de BroadNet no admite una clave de idempotencia, así que la deduplicación depende de su código: registre cada envío antes de hacerlo, conserve el ID de mensaje que devuelve la API y compruebe el estado de ese mensaje antes de cualquier reenvío (consulte [idempotencia y reintentos seguros](https://www.broadnet.me/developers/idempotency)). Sin esa comprobación, un primer envío lento pero exitoso y un reenvío automático generan dos códigos OTP en la bandeja de entrada del usuario; este utiliza el más antiguo, la verificación falla y el equipo culpa al servicio de OTP cuando el error reside en la lógica de reintento.

### Sustitución de voz para la cola larga

Aproximadamente el uno por ciento de los usuarios no recibirá un SMS por ninguno de los motivos mencionados, y ese uno por ciento representa la gran cantidad de usuarios que solicitan asistencia técnica. Una llamada con el código de verificación por voz resuelve casi todos estos problemas. Es la diferencia entre un usuario molesto que prueba con otro navegador y un usuario perdido que se da por vencido.

> El servicio OTP de BroadNet [/products/otp](https://www.broadnet.me/products/otp) gestiona la conexión directa, la cadena de reserva y la escalada de voz mediante una única llamada a la API, devuelve un ID de mensaje que puede comprobar antes de cualquier reenvío y expone el desglose del DLR por canal y por operador del que depende la guía de diagnóstico anterior.

## Cómo se ve el éxito, en números.

Un sistema OTP bien instrumentado, que envía mensajes a un mercado regulado del CCG a través de rutas directas del operador y cuenta con una cadena de respaldo operativa, debería ofrecer: una tasa de finalización de extremo a extremo superior al 99 % (el usuario verificó correctamente la entrega del mensaje, no solo que se entregó), una latencia p95 inferior a cinco segundos en el canal principal y una tasa de respaldo medible pero pequeña (1-3 %) al canal secundario. Si sus resultados son significativamente peores, es casi seguro que el problema se deba a una de las siete causas mencionadas anteriormente; diagnostique, no adivine.

## Lecturas relacionadas

- [API de SMS frente a SMPP: ¿cuál es mejor para las empresas?](https://www.broadnet.me/blog/sms-api-vs-smpp-enterprise-decision-guide)
- [Cómo deben los bancos supervisar la entrega de OTP y el fraude](https://www.broadnet.me/blog/bank-otp-delivery-monitoring-fraud-playbook)
- [Cómo afecta la verificación de llamadas instantáneas a los ingresos A2P de los operadores](https://www.broadnet.me/blog/flash-call-verification-operator-a2p-revenue-impact)
- Glosario — [¿Qué es OTP?](https://www.broadnet.me/answers/what-is-otp), [¿Qué es un DLR?](https://www.broadnet.me/answers/what-is-dlr), [¿Qué es la verificación de llamada flash?](https://www.broadnet.me/answers/what-is-flash-call-verification)
- Páginas de productos: [Servicio OTP](https://www.broadnet.me/products/otp) y [OTP de voz MyOTP](https://www.broadnet.me/products/myotp)
- Cobertura — [Enrutamiento de SMS y OTP A2P en los EAU](https://www.broadnet.me/coverage/uae)