Hay una escena que se repite cada vez más: recibes un SMS aparentemente enviado por tu banco, por una empresa de paquetería, por una administración pública o por una plataforma conocida. El mensaje aparece dentro del mismo hilo donde ya tenías mensajes legítimos anteriores. Mismo nombre de remitente, misma conversación, mismo aspecto.
Y claro, el cerebro hace lo suyo: “Si está en el mismo hilo, será de verdad”.
Pero no…
Este es uno de los problemas más incómodos del ecosistema SMS actual: un mensaje fraudulento puede llegar con un nombre de remitente aparentemente legítimo y el móvil puede integrarlo en la misma conversación que los mensajes auténticos. No porque el teléfono haya sido hackeado ni porque el banco haya sufrido una brecha, sino porque el SMS tradicional arrastra una limitación de diseño muy antigua: no dispone de un mecanismo universal de autenticación del remitente equivalente a SPF, DKIM, rDNS o DMARC como ocurre en el correo electrónico.
Sí, has leído bien: en algunos aspectos, hoy puede ser más fácil falsificar visualmente un SMS que falsificar correctamente un correo corporativo bien configurado.
El problema: el nombre del remitente no prueba quién lo envía
En los SMS empresariales es habitual usar un identificador alfanumérico como remitente. En lugar de ver un número de teléfono, el usuario ve algo como:
BancoXCorreosMiPaqueteSeguridadTiendaOnline
Este identificador se conoce normalmente como Sender ID, alias de remitente o remitente alfanumérico. Es cómodo, reconocible y mejora la experiencia del usuario. El problema es que, por sí solo, no equivale a una identidad verificada criptográficamente.
En el estándar SMS, el remitente forma parte de los campos de direccionamiento del mensaje. El protocolo contempla direcciones de origen numéricas y alfanuméricas, pero no incorpora de forma universal una firma criptográfica que permita al terminal comprobar que ese alias pertenece realmente a la entidad que dice representar.
Dicho de forma más directa: que en la pantalla ponga “BancoX” no significa necesariamente que el mensaje haya sido enviado por BancoX.
Y ahí empieza la fiesta. Una fiesta bastante cutre, pero muy rentable para los delincuentes.
Tip técnico: en SMS, el campo relevante a nivel de protocolo es el TP-Originating-Address o dirección de origen. Puede contener una representación alfanumérica. Esa posibilidad es legítima, pero no implica autenticación fuerte del titular de la marca.
Por qué el móvil mezcla mensajes reales y fraudulentos
Los móviles actuales, tanto Android como iPhone, agrupan los mensajes por conversación (en función del remitente visible o del identificador asociado al mensaje). Desde el punto de vista de experiencia de usuario tiene sentido, ya que si recibes varios SMS de “BancoX”, lo lógico es que aparezcan agrupados en un mismo hilo.
El problema aparece cuando un atacante consigue enviar un SMS usando el mismo alias o uno visualmente muy similar. Si el terminal interpreta que el remitente coincide, el mensaje puede quedar integrado en la conversación existente.
El resultado es peligrosísimo: el usuario no ve un SMS aislado de un número raro, sino un mensaje dentro de una conversación donde ya existen códigos de verificación, avisos legítimos o notificaciones reales.
El contexto hace el trabajo sucio. Si un SMS falso fuera de contexto ya puede engañar, un SMS falso dentro del hilo legítimo de tu banco es muchísimo más convincente.
Por qué el SMS no tiene un SPF, DKIM, rDNS o DMARC
Para entender el problema, conviene compararlo con el correo electrónico. En este contexto existen varios mecanismos que ayudan a verificar si un mensaje realmente está autorizado por el dominio que dice usar:
- SPF permite que un dominio publique qué servidores están autorizados a enviar correos en su nombre.
- DKIM permite firmar criptográficamente partes del mensaje para comprobar que no han sido alteradas y que una entidad con control sobre el dominio ha asumido responsabilidad sobre ese envío.
- Reverse DNS: traduce una dirección IP de vuelta a su nombre de dominio correspondiente. Al recibir un correo desde una IP, se comprueba mediante rDNS si coincide con el dominio que dice ser.
- DMARC añade una política de alineación y actuación: indica qué debe hacer el receptor si un mensaje no supera las comprobaciones de SPF o DKIM.
Aunque no son perfectos, forman una arquitectura de confianza bastante razonable cuando están bien configurados.
En SMS tradicional no existe un equivalente universal a esa combinación. No hay un registro DNS global del estilo: BancoX autoriza a estos proveedores SMS a enviar mensajes usando este alias
Tampoco hay una firma criptográfica estándar que el móvil pueda verificar antes de mostrar el mensaje. No hay una política global que diga: Si alguien usa mi alias sin autorización, rechaza el mensaje
Lo que existe, en cambio, es una combinación de controles de operadores, agregadores, filtros antispam, acuerdos comerciales y, cada vez más, registros regulatorios nacionales. Aunque ayuda, no es lo mismo.
Tip técnico: SPF, DKIM, rDNS y DMARC funcionan porque el dominio de Internet actúa como ancla de confianza. En SMS, el alias de remitente no está vinculado universalmente a un dominio, certificado o clave pública verificable por el dispositivo final.
El ecosistema SMS es más complejo de lo que parece
Cuando una empresa envía un SMS a sus clientes, normalmente no lo hace directamente desde “su operador” hacia tu móvil. La cadena suele incluir varios actores:
- La empresa que quiere enviar el mensaje.
- Un proveedor de mensajería o plataforma CPaaS.
- Uno o varios agregadores SMS.
- Operadores de tránsito.
- El operador móvil del usuario final.
En teoría, cada actor debería aplicar controles. En la práctica, el ecosistema es global, antiguo y muy heterogéneo. Hay rutas internacionales, acuerdos entre operadores, proveedores con distintos niveles de control y mercados donde las normas son más estrictas que en otros.
Además, durante años han existido rutas grises, atajos y mecanismos de encaminamiento que permiten reducir costes o saltarse controles. Para una empresa legítima esto puede traducirse en entregabilidad irregular. Para un atacante, puede convertirse en una oportunidad.
El SMS nació en un mundo donde las redes telefónicas se consideraban entornos relativamente cerrados y confiables. Hoy se usa para banca, autenticación, recuperación de cuentas, logística, trámites administrativos y comunicaciones sensibles.
El problema no es que el SMS no funcione. El problema es que lo estamos usando para cosas que requieren más garantías de las que el protocolo original ofrecía.
Qué es el smishing y por qué funciona tan bien
El smishing es phishing a través de SMS. El objetivo es el mismo que en el phishing tradicional: engañar al usuario para que pulse un enlace, llame a un número, descargue algo o introduzca credenciales.
Un SMS tiene varias ventajas para el atacante:
- Llega directamente al móvil.
- Suele generar una notificación inmediata.
- Se percibe como más personal que un email.
- Tiene poco espacio, así que el usuario espera mensajes breves y urgentes.
- Muchas empresas legítimas usan SMS para códigos, avisos y alertas.
Ese último punto es clave. Durante años hemos entrenado a los usuarios para confiar en el SMS como canal de seguridad:
- “Te hemos enviado un código por SMS”.
- “Confirma la operación con el código recibido”.
- “Pulsa aquí para revisar tu entrega”.
Y ahora pretendemos que el usuario distinga, en décimas de segundo, entre una comunicación legítima y una falsa que aparece en el mismo hilo.
Tip técnico: si una empresa sigue enviando enlaces críticos por SMS, debería revisar su estrategia. El SMS puede servir como canal informativo, pero no debería ser el punto de confianza final para operaciones sensibles.
Por qué los operadores no lo han solucionado antes
La pregunta lógica es: si el problema es conocido, ¿por qué no se ha arreglado ya? Porque el SMS es una tecnología heredada, global y extremadamente fragmentada.
Arreglarlo bien implica coordinar a operadores, agregadores, reguladores, fabricantes de terminales, sistemas de mensajería empresarial y plataformas de envío. No hablamos de actualizar una app, sino de modificar un ecosistema mundial con décadas de historia.
Además, existe un incentivo económico complicado. Los SMS A2P (application-to-person), es decir, mensajes enviados por aplicaciones o empresas a usuarios, siguen moviendo mucho dinero. Bancos, administraciones, tiendas online, plataformas logísticas y servicios digitales los siguen utilizando masivamente.
El canal tiene problemas, pero también funciona lo bastante bien como para que muchas organizaciones no hayan tenido prisa en migrar. Hasta que el fraude se ha vuelto demasiado visible.
España y el Registro de alias
En España ya se están desplegando medidas específicas para combatir la suplantación mediante SMS, MMS y RCS. La CNMC ha creado el Registro de alias, cuyo objetivo es verificar los nombres o marcas que aparecen como remitentes en mensajes enviados a números españoles.
La idea es sencilla: si una empresa quiere usar un alias como remitente, debe acreditar que tiene derecho a usarlo. Los proveedores de mensajería deberán bloquear mensajes que utilicen alias no inscritos, procedan de proveedores no registrados o no cuenten con la habilitación correspondiente.
Esto es importante porque cambia el modelo de “cualquiera puede intentar usar un alias” a “solo quien lo haya acreditado debería poder usarlo”. Aunque no soluciona el problema del todo.
Es una medida nacional y depende de la correcta aplicación por proveedores y operadores. Y no convierte mágicamente el SMS en un sistema criptográficamente autenticado extremo a extremo, pero algo es algo.
Tip técnico: para empresas que envían SMS en España, el uso de alias debería tratarse como un activo de identidad digital. Igual que se gestionan dominios, certificados TLS o registros SPF/DKIM/DMARC, habrá que gobernar quién puede enviar SMS con el nombre de la marca.
RCS: la alternativa moderna al SMS
RCS, siglas de Rich Communication Services, nació como evolución del SMS. Permite mensajes enriquecidos, imágenes, botones, confirmaciones de lectura, mejor experiencia conversacional y, lo más importante para este tema, mecanismos más sólidos de identidad empresarial.
En RCS Business Messaging, las empresas pueden trabajar con agentes verificados, perfiles de marca, logotipos, colores corporativos y procesos de validación, lo que reduce la ambigüedad del remitente y mejora la confianza del usuario.
Dicho de otra forma: RCS intenta acercar la mensajería móvil a un modelo más parecido a las comunicaciones verificadas modernas.
Ahora bien, tampoco conviene vender humo, porque RCS no es una varita mágica. Su despliegue depende de operadores, dispositivos, sistemas operativos, clientes de mensajería y proveedores. Además, hay que distinguir entre RCS de usuarios y RCS empresarial. No todos los escenarios tienen las mismas garantías de cifrado, privacidad o verificación.
Aun así, la dirección es evidente: el SMS tradicional debería ir perdiendo peso en comunicaciones sensibles, y RCS, las notificaciones push verificadas y las passkeys, deberían ganar terreno.
El gran error: usar SMS como segundo factor principal
Durante muchos años, el SMS fue el segundo factor de autenticación más extendido. Era fácil, barato y universal. Pero desde el punto de vista de seguridad tiene debilidades claras:
- Puede ser víctima de SIM swapping.
- Puede ser interceptado en ciertos escenarios.
- Depende del operador móvil.
- Puede ser usado en ataques de ingeniería social.
- Y, como estamos viendo, convive con un canal donde la identidad visual del remitente puede resultar engañosa.
Por eso muchas guías de seguridad recomiendan priorizar alternativas más robustas:
- Aplicaciones TOTP como Aegis, Google Authenticator, Microsoft Authenticator o similares.
- Llaves físicas FIDO2.
- Passkeys.
- Autenticación biométrica vinculada a clave criptográfica.
- Confirmaciones dentro de la app oficial.
El SMS puede seguir siendo útil como canal de respaldo, pero no debería ser el mecanismo principal de autenticación para cuentas críticas.
Tip técnico: para cuentas importantes, lo recomendable es usar passkeys o FIDO2 cuando estén disponibles. Como segunda opción, TOTP. SMS debería quedar como último recurso, no como primera línea de defensa.
Recomendaciones para usuarios
La recomendación más importante es incómoda pero sencilla: no confíes en un SMS solo porque aparezca dentro de un hilo legítimo. Hay que cambiar el criterio mental. El hilo de mensajes no es una prueba de autenticidad. Algunas buenas prácticas:
- No pulses enlaces recibidos por SMS para iniciar sesión o verificar datos.
- Accede manualmente a la web oficial escribiendo la dirección en el navegador o usando la app oficial.
- No llames a teléfonos incluidos en SMS sospechosos.
- No introduzcas códigos, claves o datos bancarios tras llegar desde un enlace SMS.
- Desconfía de mensajes con urgencia, amenaza o bloqueo inmediato.
- Revisa el dominio real del enlace, no solo el texto visible.
- Y, sobre todo, recuerda esto: si una comunicación te empuja a actuar rápido, probablemente quiere que pienses lento.
Recomendaciones para empresas
Las empresas también tienen deberes. No basta con decir al usuario “cuidado con los fraudes” mientras se le siguen enviando enlaces por SMS con dominios raros, acortadores o textos ambiguos. Una estrategia seria debería incluir:
- Registrar los alias oficiales allí donde exista registro nacional.
- Usar proveedores de mensajería homologados y con controles antifraude.
- Evitar enlaces sensibles en SMS.
- Usar dominios propios, claros y coherentes.
- Centralizar operaciones críticas en app o área privada.
- Promover passkeys y autenticación fuerte.
- Monitorizar campañas de smishing que suplanten la marca.
- Informar claramente a los clientes de qué canales oficiales se usan y qué acciones nunca se pedirán por SMS.
Tip técnico: un buen patrón es que el SMS sea solo una alerta. Por ejemplo: “Tienes una notificación en tu área privada”. Sin enlace, teléfono alternativo o petición de datos. El usuario debe abrir la app oficial o escribir manualmente el dominio conocido.
Entonces, ¿deberíamos dejar de usar SMS?
No totalmente. El SMS sigue teniendo virtudes: universalidad, compatibilidad, sencillez y alcance. Funciona en móviles antiguos, no requiere datos y llega casi a cualquier usuario.
Pero hay que rebajar su nivel de confianza. El SMS es válido para comunicaciones de bajo riesgo: avisos informativos, recordatorios, notificaciones no sensibles o mensajes donde no se pida ninguna acción crítica. Pero para autenticación, operaciones financieras, recuperación de cuentas o verificación de identidad, deberíamos migrar hacia mecanismos más robustos.
Durante años se ha culpado al usuario por caer en enlaces fraudulentos. Y sí, la formación en ciberseguridad importa. Pero hay que ser justos: si un mensaje falso aparece en el mismo hilo que los mensajes reales de tu banco, con el mismo nombre de remitente y con un contexto aparentemente coherente, el diseño está jugando en contra del usuario.
El SMS tradicional no fue diseñado para el mundo actual de phishing industrializado, bots, IA generativa, suplantación masiva y fraude financiero global. Por eso necesitamos tres movimientos a la vez:
- Mejores controles regulatorios y técnicos sobre los alias SMS.
- Migración progresiva hacia RCS, passkeys y canales verificados.
- Mejor diseño de comunicaciones por parte de empresas y administraciones.
La confianza digital no puede basarse en que “parece legítimo”, tiene que basarse en verificación real.
Deja una respuesta