Filtrado de SMS A2P: cómo investigar bloqueos de contenido y remitente
Una guía operativa para distinguir fallos de envío, estados reportados y posibles restricciones, reunir evidencias comparables y coordinar una investigación responsable sin intentar eludir filtros.
Qué significa que un SMS A2P pueda estar filtrado
Un SMS que no alcanza el resultado esperado no demuestra por sí solo que haya sido bloqueado por su contenido o remitente. Puede haber un rechazo al enviar, un problema de aceptación o procesamiento, un estado de entrega no concluyente o una restricción en algún punto posterior de la cadena. Con la información disponible, no es posible asignar cada caso a una etapa concreta sin consultar los registros y definiciones del proveedor implicado.
Por eso conviene tratar «filtrado» como una hipótesis que debe investigarse, no como una explicación automática para todo fallo. Empiece por identificar qué sistema generó cada estado y qué significa exactamente en esa ruta.
- Separe los mensajes que no se aceptaron para envío de los que el proveedor reporta como aceptados.
- Registre los estados de entrega tal como fueron comunicados y solicite al proveedor la definición aplicable.
- No concluya que hubo bloqueo por contenido o remitente basándose en un único fallo o código no interpretado.
Rechazo, aceptación, DLR y recepción: no son equivalentes
Un rechazo al enviar indica que una solicitud no fue aceptada en ese punto del proceso; el motivo debe verificarse en el error reportado. La aceptación por un proveedor tampoco confirma que el teléfono destinatario haya recibido el mensaje. Un DLR es un estado comunicado dentro de la cadena, pero su alcance depende de cómo lo genere y defina el proveedor. No lo presente como prueba independiente de recepción en el terminal.
Si necesita conocer el significado de un estado, pida la documentación correspondiente a la ruta y al proveedor. Cuando el estado no permita confirmar lo ocurrido en el dispositivo, deje explícita esa incertidumbre en sus informes.
- Conserve por separado la respuesta de envío, los estados posteriores y cualquier confirmación adicional disponible.
- Pregunte qué evento representa cada DLR y qué sistemas participan en su generación.
- Describa un resultado como «DLR reportado» cuando no exista verificación independiente del terminal.
Busque patrones antes de atribuir una causa
Compare los casos por destino, operador cuando esa información esté disponible, remitente, contenido y periodo de envío. Un patrón repetido puede ayudar a delimitar la investigación, pero no demuestra por sí mismo la causa. También pueden influir diferencias de ruta, configuración o interpretación de estados; confirme estos aspectos con el proveedor.
Use comparaciones de mensajes autorizados y legítimos. Si el problema aparece solo en un grupo definido, acote ese grupo antes de hacer cambios generales que puedan afectar tráfico que funciona.
- Determine si el problema afecta a todos los destinos o solo a algunos.
- Compruebe si coincide con un remitente específico o con una familia de plantillas.
- Compare ventanas temporales equivalentes y anote los cambios operativos conocidos.
- No interprete una correlación aislada como confirmación de filtrado.
Recopile evidencias comparables
Prepare un conjunto de ejemplos que permita al proveedor revisar los eventos concretos. La evidencia de entrega, los detalles del error, el registro del remitente y el contenido son elementos útiles para investigar; documentarlos juntos evita depender de descripciones generales como «no llega».
Proteja los datos personales y comparta únicamente la información necesaria por canales autorizados. Mantenga una referencia interna que permita relacionar cada mensaje con sus eventos, sin exponer credenciales ni datos sensibles en comunicaciones no seguras.
- Identificador del mensaje o de la solicitud, según lo proporcione el sistema.
- Marcas temporales con zona horaria y destino en formato normalizado.
- Remitente utilizado y texto exacto enviado, conservando una copia controlada.
- Respuesta inicial, estados posteriores, códigos y descripciones de error.
- Proveedor o ruta implicada y cualquier cambio relevante conocido.
Aísle la causa con pruebas controladas
Una prueba útil mantiene constantes las variables que no se están investigando. Defina primero una población autorizada y una muestra limitada; luego compare un elemento por vez, por ejemplo el remitente o la plantilla, manteniendo el destino, el periodo y la ruta tan comparables como sea posible. Si no puede controlar una variable, documente esa limitación.
No envíe mensajes de prueba a destinatarios sin autorización ni genere volumen innecesario. Antes de ejecutar una comparación, acuerde con el proveedor cómo identificar los mensajes y qué estados podrá observar.
- Formule una hipótesis concreta, como «el patrón ocurre solo con este remitente».
- Defina qué se mantendrá igual y qué variable se comparará.
- Use tráfico legítimo, autorizado y limitado; registre cada envío y su resultado.
- Detenga la prueba si aumenta el impacto o aparecen señales de riesgo operativo.
Coordine la investigación con proveedor y operador
Envíe al proveedor una selección representativa de identificadores, marcas temporales, destinos, remitente, contenido y estados recibidos. Pida que confirme qué etapa cubre cada registro, quién origina el código de error y si hay información adicional de la ruta que permita acotar el caso. Si la investigación requiere participación de un operador, solicite al proveedor que indique el canal y los datos necesarios.
Evite pedir una conclusión binaria cuando los datos solo permiten una hipótesis. Si no se puede confirmar que el mensaje llegó al terminal, la respuesta debe conservar esa distinción.
- Comparta ejemplos concretos y comparables, no solo tasas agregadas.
- Solicite la definición documentada de los estados y errores relevantes.
- Aclare qué comprobaciones puede realizar el proveedor y cuáles dependen de terceros.
- Acuerde una próxima actualización y mantenga un registro de las conclusiones y sus límites.
Aplique cambios seguros y trazables
Revise el uso del remitente y el contenido frente a los requisitos aplicables a los destinos y a la finalidad del mensaje. Los requisitos pueden depender del país, la ruta y el tipo de tráfico; no dé por hecho que una regla es universal. Confirme las condiciones con el proveedor y, cuando corresponda, con la documentación oficial aplicable.
Si se autoriza un cambio, aplíquelo de forma controlada y registre qué se modificó, cuándo y para qué tráfico. Compare los resultados con la línea de base y conserve una versión aprobada de la plantilla. El objetivo es mantener la legitimidad y claridad del mensaje, no disfrazarlo para atravesar controles.
- Compruebe que el remitente y el contenido correspondan al propósito legítimo del envío.
- Valide los requisitos aplicables antes de cambiar un remitente o una plantilla.
- Cambie una variable por prueba y mantenga trazabilidad de versiones y resultados.
- Evalúe el impacto sobre entregas correctas antes de ampliar un cambio.
Qué no hacer y cómo cerrar el incidente
No altere mensajes para evadir filtros ni haga cambios que oculten la identidad o la finalidad del envío. Tampoco aumente los reintentos a ciegas: sin conocer el motivo del fallo y las reglas de reintento de la ruta, podría generar tráfico repetido sin resolver la causa. Consulte al proveedor antes de modificar la política de reintentos.
Cierre la investigación cuando la causa esté suficientemente acotada o documente qué información falta. Deje constancia del alcance afectado, las evidencias, las acciones aprobadas, el resultado observado y las incertidumbres pendientes. Mantenga el seguimiento de los estados sin presentar un DLR como recepción verificada.
- No use variaciones engañosas de texto o remitente para sortear controles.
- No reenvíe automáticamente sin revisar el error y la política acordada.
- No prometa recepción en el dispositivo cuando solo existe un estado reportado.
- Conserve un resumen del incidente que permita comparar futuros casos.
Preguntas frecuentes
¿Un SMS que no llega necesariamente fue filtrado?
No. Un fallo puede deberse a distintas etapas o condiciones. Revise la respuesta de envío, los estados posteriores y los detalles del error antes de atribuirlo a un filtro.
¿Un DLR confirma que el mensaje se vio en el teléfono?
No debe tratarse automáticamente como confirmación independiente de recepción en el terminal. Su significado depende de la definición y los sistemas del proveedor; solicite esa información y describa el estado con precisión.
¿Qué datos ayudan a abrir una investigación con el proveedor?
Prepare identificadores, marcas temporales, destino, remitente, texto enviado, respuestas y estados, además de los errores reportados y la ruta implicada cuando esté disponible.
¿Conviene cambiar el texto para comprobar si se evita un bloqueo?
No cambie mensajes con el objetivo de evadir controles. Si existe una razón legítima para revisar contenido, consulte los requisitos aplicables y haga cambios autorizados, controlados y trazables.
¿Debo aumentar los reintentos cuando hay fallos?
No de forma automática ni a ciegas. Primero identifique el error y consulte las reglas de reintento de la ruta con el proveedor.
Fuentes consultadas
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMS filtering investigation guidanceBird