Quishing en 2026: cómo los códigos QR están cambiando el phishing por correo electrónico

El phishing por correo electrónico lleva años adaptándose a los controles defensivos. En 2026, una de las técnicas que merece especial atención es el quishing: el uso de códigos QR para conducir a la víctima hacia un destino malicioso. El principio sigue siendo el de cualquier ataque de phishing, pero cambia una parte importante del recorrido. En lugar de presentar necesariamente un enlace visible y clicable, el atacante puede esconder el destino dentro de una imagen que el usuario escanea con otro dispositivo.

Esta diferencia aparentemente pequeña tiene consecuencias para las empresas. El análisis deja de limitarse al texto, los enlaces y los adjuntos tradicionales del mensaje. Además, cuando el empleado escanea el código con su teléfono, la interacción puede continuar fuera del equipo corporativo en el que recibió el correo.

Usuario escaneando con un teléfono móvil un código QR recibido en un correo electrónico de phishing

Qué es el quishing y cómo funciona

El término quishing combina QR y phishing. En un escenario típico, el usuario recibe un correo que intenta justificar el escaneo de un código QR: verificar una cuenta, consultar un documento, actualizar información o completar algún proceso. El código codifica una URL que conduce al siguiente punto de la infraestructura utilizada en el ataque.

El problema no está en la tecnología QR en sí. Un código QR es un mecanismo para representar información. El riesgo aparece cuando se utiliza para ocultar un destino malicioso y se combina con ingeniería social. Si la víctima continúa, puede terminar ante una página diseñada para imitar un servicio legítimo y solicitar credenciales u otra información sensible.

Por qué los códigos QR están cambiando el phishing

En el phishing tradicional, una URL suele formar parte directamente del mensaje o de un elemento HTML. Esto facilita que determinadas tecnologías de seguridad puedan extraerla, analizar su reputación, reescribirla o inspeccionar el destino. Con el quishing, la dirección puede encontrarse representada dentro de una imagen o de un documento que contiene el QR.

Los datos publicados en 2026 confirman que no se trata de un escenario teórico. Microsoft informó de que el volumen de phishing mediante códigos QR observado por sus sistemas pasó de 7,6 millones de ataques en enero a 18,7 millones en marzo de 2026, un incremento del 146 % durante el primer trimestre. La compañía también señaló que los PDF representaban el 70 % de los mecanismos de entrega de estos ataques en marzo.

Barracuda Research, tras analizar más de 3.100 millones de correos en enero de 2026, encontró códigos QR que conducían a sitios de phishing en el 70 % de los PDF maliciosos de su conjunto de datos y en el 56 % de los documentos maliciosos de Microsoft 365 analizados. Son métricas de conjuntos de telemetría concretos y no deben interpretarse como porcentajes universales de todo el correo electrónico.

Diagrama con las fases de un ataque de quishing desde el correo hasta el intento de robo de credenciales

Anatomía de un ataque de quishing

El recorrido ayuda a entender el problema. Primero llega el correo. El mensaje utiliza un pretexto para provocar una acción y presenta un código QR. El usuario utiliza la cámara o el lector de su teléfono para interpretarlo. A continuación, el navegador móvil abre el destino codificado y, si el engaño funciona, la víctima puede encontrarse ante una página fraudulenta que solicita autenticación.

El atacante ha conseguido así separar dos momentos del ataque: la recepción se produce en el correo y la navegación puede continuar en otro dispositivo. También puede incorporar redirecciones, acortadores u otros mecanismos intermedios antes de presentar el destino final. Por ello, analizar únicamente el contenido textual del mensaje resulta insuficiente para comprender todo el flujo.

El teléfono móvil cambia el contexto de seguridad

Este salto entre dispositivos es especialmente relevante para una empresa. Un equipo corporativo puede disponer de protección del endpoint, filtrado DNS, navegador gestionado, telemetría y otras medidas. Si el trabajador escanea el QR con un teléfono personal o no gestionado, algunos de esos controles pueden dejar de participar en la siguiente fase.

Esto no significa que cualquier escaneo abandone automáticamente la protección corporativa. Dependerá de cómo gestione cada organización sus dispositivos, identidad, red y acceso a servicios. El punto importante es que el equipo de seguridad debe contemplar el recorrido completo y no asumir que una amenaza recibida por correo permanecerá en el mismo endpoint.

Transición de un ataque de quishing desde un ordenador corporativo hasta un teléfono móvil

Qué señales pueden ayudar a detectar un intento

Un código QR no debe considerarse malicioso por el simple hecho de aparecer en un correo. La evaluación debe partir del contexto. Conviene prestar especial atención cuando un mensaje inesperado exige escanear un QR para autenticarse, resolver una supuesta incidencia, mantener activa una cuenta o completar urgentemente una acción relacionada con credenciales.

  • Comprobar si el procedimiento solicitado coincide con los procesos habituales de la empresa.
  • Revisar el remitente y el contexto del mensaje antes de escanear.
  • Desconfiar de solicitudes que introducen urgencia innecesaria o amenazan con bloquear una cuenta.
  • Comprobar cuidadosamente el dominio mostrado por el dispositivo antes de introducir credenciales.
  • Ante una solicitud inesperada, acceder al servicio desde su aplicación o dirección conocida en lugar de continuar desde el QR.

Cómo pueden defenderse las empresas

La respuesta al quishing no debería depender de un único control. En el correo resulta útil disponer de tecnologías capaces de identificar códigos QR, extraer de forma segura la información codificada y analizar los destinos aplicando los mismos principios utilizados con otros enlaces. La inspección de imágenes y documentos cobra especial importancia cuando la URL no está expuesta directamente en la estructura del mensaje.

La protección web y DNS puede proporcionar una segunda oportunidad de bloqueo cuando el usuario intenta alcanzar un dominio identificado como malicioso. La gestión de dispositivos móviles también reduce la diferencia entre el entorno del ordenador y el del teléfono cuando estos dispositivos forman parte del acceso corporativo.

En la capa de identidad, las organizaciones deberían reducir la dependencia de credenciales que puedan reutilizarse después de ser robadas y valorar mecanismos de autenticación resistentes al phishing cuando sean compatibles con sus servicios. A esto debe añadirse formación específica: enseñar únicamente a no pulsar enlaces sospechosos deja fuera precisamente el comportamiento que explota el quishing.

Infografía de las capas de defensa empresarial frente a ataques de quishing

Qué hacer ante un QR sospechoso recibido por correo

Cuando un correo inesperado solicita escanear un QR para iniciar sesión o proporcionar información sensible, la opción más segura es no continuar directamente desde ese código. El usuario puede verificar la solicitud mediante un canal conocido, acceder al servicio desde su aplicación habitual o escribir manualmente una dirección corporativa conocida.

Si el código ya se ha escaneado pero no se han introducido datos, conviene cerrar el destino y reportar el mensaje siguiendo el procedimiento interno. Si se han proporcionado credenciales, códigos de autenticación u otra información sensible, el incidente debe comunicarse cuanto antes para que el equipo responsable pueda evaluar las acciones necesarias.

El quishing es una evolución del phishing, no un problema aislado

Los códigos QR no sustituyen al phishing tradicional. Lo amplían con un mecanismo que permite ocultar el destino y, en determinados escenarios, trasladar la interacción a un dispositivo diferente. Los datos publicados durante 2026 muestran que los atacantes están utilizando activamente esta técnica y adaptando sus métodos de entrega.

Para las empresas, la respuesta pasa por observar el ataque como una cadena completa: correo, imagen o documento, QR, dispositivo utilizado para escanearlo, navegación, identidad y destino final. Combinar seguridad del correo, análisis de QR, protección web y DNS, gestión de dispositivos, controles de identidad y formación ofrece una defensa mucho más coherente que confiar exclusivamente en la detección de enlaces dentro del mensaje.

RFC esenciales para correo electrónico y DNS

Los Request for Comments (RFC) recogen las especificaciones técnicas que sustentan gran parte del funcionamiento de Internet. En correo electrónico y DNS constituyen la referencia para comprender protocolos como SMTP, mecanismos de autenticación como SPF, DKIM y DMARC, la protección del transporte mediante TLS o tecnologías de seguridad como DNSSEC.

Este recurso reúne los documentos más relevantes para administradores de correo, analistas de seguridad y profesionales que trabajan con infraestructuras de mensajería. Cada referencia incluye una identificación rápida de la tecnología, una descripción de su función y un enlace directo a la documentación oficial.

RFC principales del correo electrónico

RFC 5321 SMTP

Descripción
Define Simple Mail Transfer Protocol (SMTP), el protocolo utilizado para transferir mensajes entre servidores de correo. Describe las sesiones SMTP, comandos, respuestas, encaminamiento y comportamiento esperado durante la entrega de mensajes.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc5321

RFC 5322 Mensaje

Descripción
Define el formato de los mensajes de correo electrónico, incluida la estructura de las cabeceras y campos como From, To, Subject, Date, Message-ID o Reply-To, además del formato general del cuerpo del mensaje.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc5322

RFC 6531 SMTPUTF8

Descripción
Define la extensión SMTPUTF8, que amplía SMTP para permitir caracteres UTF-8 durante las transacciones SMTP y forma parte de la arquitectura de internacionalización del correo electrónico.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc6531

RFC 2045 MIME

Descripción
Define elementos fundamentales de MIME, como Content-Type y Content-Transfer-Encoding, necesarios para transportar diferentes tipos de contenido mediante correo electrónico.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2045

RFC 2046 MIME

Descripción
Define los tipos de medios MIME y estructuras multipart utilizadas para combinar texto, HTML, imágenes, documentos y otros elementos dentro de un mismo mensaje.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2046

RFC 2047 MIME

Descripción
Define mecanismos para representar caracteres que no pertenecen al conjunto ASCII en determinadas cabeceras de los mensajes de correo electrónico.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2047

RFC 2048 MIME

Descripción
Documento histórico de la familia MIME relacionado con procedimientos de registro. Forma parte del conjunto original de especificaciones MIME y fue reemplazado posteriormente por otros documentos.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2048

RFC 2049 MIME

Descripción
Completa la serie MIME original describiendo criterios de conformidad, ejemplos y consideraciones relacionadas con su implementación.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2049

RFC 3461 DSN

Descripción
Define la extensión SMTP para solicitar Delivery Status Notifications (DSN), permitiendo indicar cuándo deben generarse notificaciones sobre el resultado de la entrega de un mensaje.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc3461

RFC 3464 NDR

Descripción
Define el formato de los mensajes Delivery Status Notification utilizados para comunicar de forma estructurada errores, retrasos y otros estados relacionados con la entrega del correo.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc3464

RFC 4954 SMTP AUTH

Descripción
Define la extensión SMTP AUTH, mediante la que un cliente SMTP puede autenticarse ante un servidor utilizando mecanismos de autenticación compatibles.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc4954

RFC 3207 STARTTLS

Descripción
Define la extensión STARTTLS para SMTP, permitiendo establecer una sesión TLS sobre una conexión SMTP existente antes de continuar con el intercambio de información.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc3207

RFC 6409 Submission

Descripción
Define Message Submission y diferencia la presentación de mensajes por clientes y aplicaciones de la transferencia SMTP entre servidores. El servicio utiliza habitualmente el puerto TCP 587.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc6409

SPF y DKIM

RFC 7208 SPF

Descripción
Define Sender Policy Framework (SPF), el mecanismo mediante el cual un dominio publica en DNS información sobre los sistemas autorizados para utilizarlo durante determinadas fases de una transacción SMTP.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc7208

RFC 6376 DKIM

Descripción
Define DomainKeys Identified Mail (DKIM), un mecanismo que incorpora una firma criptográfica al mensaje y publica mediante DNS la información necesaria para que el receptor pueda verificarla.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc6376

RFC 8301 Seguridad

Descripción
Actualiza requisitos criptográficos y recomendaciones de seguridad aplicables a DKIM, incluidas consideraciones sobre algoritmos y tamaños de clave.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8301

RFC 8463 Ed25519

Descripción
Define el método para utilizar firmas Ed25519 con DKIM como alternativa criptográfica dentro del mecanismo de firma.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8463

DMARC

RFC 9989 DMARC

Descripción
Especificación actual de Domain-Based Message Authentication, Reporting, and Conformance (DMARC). Define la relación de DMARC con SPF y DKIM, el alineamiento de identificadores y las políticas que puede publicar el propietario de un dominio.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc9989

RFC 9990 Informes

Descripción
Define los informes agregados de DMARC y el formato empleado para proporcionar al propietario del dominio información sobre los resultados de autenticación observados por los receptores.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc9990

RFC 9991 Fallos

Descripción
Define los informes de fallo de DMARC destinados a proporcionar información sobre mensajes individuales que presentan problemas relacionados con la autenticación DMARC.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc9991

RFC 7489 DMARC

Descripción
Especificación original de DMARC publicada en 2015. Sigue siendo una referencia histórica importante, aunque ha sido sustituida por las especificaciones posteriores de DMARC.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc7489

RFC 8616 UTF-8

Descripción
Aborda la autenticación del correo electrónico internacionalizado y actualiza aspectos relacionados con SPF, DKIM y DMARC para nombres de dominio internacionalizados.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8616

ARC y BIMI

RFC 8617 ARC

Descripción
Define Authenticated Received Chain (ARC), un mecanismo que permite conservar y encadenar información de autenticación cuando un mensaje atraviesa sistemas intermediarios capaces de modificarlo.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8617

BIMI BIMI

Descripción
Brand Indicators for Message Identification (BIMI) se mantiene como especificación independiente y no debe confundirse con RFC 9421, que corresponde a HTTP Message Signatures.

Documento IETF
https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification-14

Seguridad del transporte SMTP

RFC 8461 MTA-STS

Descripción
Define SMTP MTA Strict Transport Security (MTA-STS), que permite a un dominio publicar una política para exigir TLS y la validación correcta del servidor de destino durante la entrega SMTP compatible.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8461

RFC 8460 TLS-RPT

Descripción
Define SMTP TLS Reporting (TLS-RPT), mediante el que un dominio puede indicar un destino para recibir informes sobre problemas encontrados al establecer conexiones SMTP protegidas mediante TLS.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8460

RFC 7672 DANE

Descripción
Define el uso de DANE con SMTP mediante registros TLSA protegidos con DNSSEC para asociar información criptográfica a los servidores de correo de un dominio.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc7672

DNS, DNSSEC y CAA

RFC 1034 DNS

Descripción
Describe los conceptos fundamentales del Domain Name System (DNS), incluida su arquitectura distribuida, jerarquía de nombres, zonas, delegaciones y servidores de nombres.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc1034

RFC 1035 DNS

Descripción
Define detalles de implementación y protocolo de DNS, incluido el formato de los mensajes y numerosos tipos de Resource Records.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc1035

RFC 4033 DNSSEC

Descripción
Introduce DNS Security Extensions (DNSSEC), sus conceptos principales y el modelo empleado para aportar autenticación del origen e integridad a los datos DNS.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc4033

RFC 4034 DNSSEC

Descripción
Define los Resource Records utilizados por DNSSEC y los formatos necesarios para publicar firmas, claves y otra información relacionada con su validación criptográfica.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc4034

RFC 4035 DNSSEC

Descripción
Describe las modificaciones al protocolo DNS necesarias para utilizar DNSSEC y el comportamiento esperado durante los procesos de consulta y validación.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc4035

RFC 8659 CAA

Descripción
Define Certification Authority Authorization (CAA), un registro DNS mediante el que un dominio puede indicar qué autoridades de certificación están autorizadas para emitir certificados para sus nombres.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8659

Registros DNS modernos

RFC 1035 A/MX/TXT

Descripción
Documento de referencia para registros DNS fundamentales como A, MX, NS, PTR, SOA y TXT, entre otros definidos originalmente por el protocolo.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc1035

RFC 3596 AAAA

Descripción
Define las extensiones de DNS para IPv6, incluido el registro AAAA utilizado para asociar nombres de dominio con direcciones IPv6.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc3596

RFC 2782 SRV

Descripción
Define el registro SRV, utilizado para indicar la ubicación, puerto, prioridad y peso de servicios disponibles para un dominio.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc2782

RFC 6698 TLSA

Descripción
Define el registro TLSA y el mecanismo DANE para asociar información de certificados o claves TLS con nombres publicados en DNS y protegidos mediante DNSSEC.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc6698

RFC 4255 SSHFP

Descripción
Define el registro SSHFP, utilizado para publicar huellas digitales de claves públicas SSH mediante DNS.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc4255

RFC 9460 SVCB/HTTPS

Descripción
Define los registros SVCB y HTTPS, diseñados para publicar información sobre endpoints de servicios y parámetros asociados a la conexión.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc9460

Consultas DNS cifradas

RFC 8484 DoH

Descripción
Define DNS over HTTPS (DoH), que transporta consultas y respuestas DNS utilizando HTTPS para proporcionar confidencialidad e integridad entre el cliente y el servidor DoH.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc8484

RFC 7858 DoT

Descripción
Define DNS over TLS (DoT), mediante el que las consultas DNS se transportan a través de una conexión protegida con TLS entre cliente y resolver.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc7858

RFC 9250 DoQ

Descripción
Define DNS over Dedicated QUIC Connections (DoQ), proporcionando transporte cifrado para consultas y respuestas DNS mediante QUIC.

RFC oficial
https://datatracker.ietf.org/doc/html/rfc9250

Para trabajos relacionados con seguridad del correo electrónico, los documentos sobre SMTP, formato de mensajes, SPF, DKIM, DMARC, ARC, MTA-STS, TLS-RPT, DNS y DNSSEC forman una base especialmente útil. Consultar directamente estas especificaciones permite verificar comportamientos, límites y requisitos sin depender únicamente de la interpretación realizada por fabricantes o productos concretos.

Seguridad en el correo electrónico: guía para proteger usuarios y organizaciones

El correo electrónico es una herramienta crítica para cualquier organización. Se utiliza para compartir documentos, aprobar operaciones, recuperar contraseñas y mantener comunicaciones con empleados, clientes y proveedores. Esta concentración de información y procesos también lo convierte en un objetivo prioritario para los atacantes.

La seguridad en el correo electrónico, conocida como Email Security, reúne las tecnologías, configuraciones y procedimientos destinados a proteger los mensajes, los dominios y las cuentas de usuario. Su finalidad no se limita a bloquear spam. También debe prevenir la suplantación de identidad, detectar intentos de fraude, reducir el riesgo de robo de credenciales y facilitar una respuesta rápida ante incidentes.

Ningún filtro o protocolo puede resolver por sí solo todos estos riesgos. Una estrategia eficaz necesita varias capas de protección: autenticación del dominio, análisis de mensajes, protección de identidades, monitorización, formación y procedimientos de respuesta.

Recorrido de un correo electrónico y controles de seguridad aplicados durante su procesamiento

Por qué el correo electrónico es un objetivo prioritario

Los ataques por correo electrónico aprovechan un elemento difícil de eliminar: la confianza. Los usuarios reciben mensajes de compañeros, responsables, servicios en línea y organizaciones externas. Un atacante puede imitar estas comunicaciones para conseguir que la víctima abra un archivo, visite una página falsa, revele sus credenciales o autorice una operación.

Una cuenta comprometida también puede utilizarse para lanzar nuevos ataques. Al enviar mensajes desde un buzón legítimo, el atacante consigue una apariencia de confianza difícil de obtener desde una dirección externa. Además, puede consultar conversaciones anteriores, identificar procesos internos y responder dentro de hilos existentes.

La protección debe contemplar tanto los ataques masivos como las campañas dirigidas. Mientras que el spam y el phishing genérico buscan alcanzar al mayor número posible de usuarios, los ataques selectivos utilizan información sobre la empresa, sus empleados y sus relaciones comerciales.

Principales amenazas del correo electrónico

Principales amenazas que afectan a la seguridad del correo electrónico

Phishing y robo de credenciales

El phishing intenta engañar al destinatario para que realice una acción perjudicial. Es habitual encontrar mensajes que simulan notificaciones de servicios de correo, plataformas de almacenamiento, entidades financieras, sistemas de firma electrónica o departamentos internos.

El enlace puede dirigir a una página que reproduce la apariencia del servicio legítimo y solicita las credenciales del usuario. Los ataques más elaborados adaptan el idioma, la identidad visual y el contenido al entorno de la víctima. Por este motivo, un mensaje bien redactado también puede ser malicioso.

Spear phishing

El spear phishing es un ataque dirigido contra una persona o un grupo concreto. El atacante investiga el puesto de la víctima, sus compañeros, sus proveedores y sus responsabilidades. Con esta información prepara un mensaje relacionado con una tarea, una reunión, una factura o un proyecto real.

Business Email Compromise

El Business Email Compromise, o BEC, engloba fraudes en los que el atacante suplanta o compromete una identidad empresarial para solicitar transferencias, modificar datos bancarios o conseguir información confidencial. El mensaje puede aparentar que procede de un directivo, un proveedor o un empleado del área financiera.

En muchos casos no contiene archivos ni enlaces maliciosos. El fraude se apoya en la ingeniería social y en argumentos de urgencia, autoridad o confidencialidad. Por ello, los controles centrados exclusivamente en detectar malware no son suficientes.

Archivos, enlaces y suplantación

Los adjuntos pueden contener código malicioso, explotar vulnerabilidades o intentar que el usuario habilite funciones peligrosas. Los enlaces pueden redirigir a páginas de phishing, descargas maliciosas o sitios legítimos comprometidos.

La dirección visible del remitente tampoco garantiza que el mensaje sea legítimo. Un atacante puede intentar utilizar un dominio ajeno, modificar el nombre mostrado o registrar un dominio visualmente parecido al de la organización.

Autenticación del dominio con SPF, DKIM y DMARC

Autenticación de un dominio de correo electrónico mediante SPF, DKIM y DMARC

SPF, DKIM y DMARC son mecanismos complementarios que ayudan a verificar el origen de los mensajes y a reducir la suplantación directa del dominio. Su despliegue debe planificarse teniendo en cuenta todas las plataformas autorizadas para enviar correo.

SPF publica en el DNS qué servidores pueden enviar mensajes en nombre del dominio. El sistema receptor compara el servidor de origen con la política publicada. Una configuración incompleta puede afectar a servicios legítimos, mientras que una política demasiado permisiva reduce su utilidad.

DKIM añade una firma criptográfica al mensaje. El servidor receptor obtiene la clave pública desde el DNS y verifica que los elementos firmados no hayan sido modificados. Su eficacia depende de una gestión adecuada de las claves y de la configuración de cada plataforma de envío.

DMARC utiliza los resultados de SPF y DKIM, junto con la alineación del dominio visible, para indicar cómo debe tratarse un mensaje que no supera las comprobaciones. Sus políticas permiten monitorizar, enviar a cuarentena o rechazar mensajes.

La implantación de DMARC debe comenzar con una fase de observación. Antes de aplicar una política restrictiva es necesario revisar los informes, identificar las fuentes legítimas y corregir los errores de configuración. Aplicar directamente una política de rechazo puede afectar a comunicaciones válidas.

Controles sobre mensajes, enlaces y buzones

La autenticación del dominio es fundamental, pero no detecta todas las amenazas. Un atacante puede utilizar un dominio propio correctamente autenticado, comprometer una cuenta legítima o registrar un nombre parecido al de la organización.

Los filtros de correo analizan la reputación del remitente, la infraestructura de envío, las cabeceras y el contenido. El análisis de identidad y comportamiento permite detectar mensajes que se apartan de las comunicaciones habituales, incluso cuando no contienen malware.

El sandboxing ejecuta archivos sospechosos en un entorno aislado para observar su comportamiento. Debe combinarse con análisis estático y políticas de control de archivos, ya que algunas amenazas intentan detectar el entorno de pruebas o retrasar su ejecución.

La protección de enlaces permite evaluar la dirección durante la entrega y, según la solución utilizada, cuando el usuario hace clic. Este control resulta útil frente a páginas que cambian su comportamiento después de superar el análisis inicial.

La autenticación multifactor añade una barrera frente al uso de contraseñas robadas. También es necesario supervisar reglas de reenvío, aplicaciones autorizadas, inicios de sesión anómalos y cambios realizados en la configuración de los buzones.

Buenas prácticas para los usuarios

Los usuarios forman parte de la estrategia de seguridad, pero no deben convertirse en el único control. La formación debe proporcionar criterios concretos y un procedimiento sencillo para reportar mensajes sospechosos.

  • Comprobar la dirección completa del remitente y no confiar únicamente en el nombre mostrado.
  • Revisar con atención las solicitudes urgentes, confidenciales o relacionadas con pagos.
  • Confirmar por un canal alternativo los cambios de cuenta bancaria y las operaciones excepcionales.
  • No introducir credenciales en páginas abiertas desde enlaces inesperados.
  • No abrir archivos que no se esperaban, aunque parezcan proceder de un contacto conocido.
  • Reportar los mensajes sospechosos sin responder ni interactuar con su contenido.

Las simulaciones de phishing pueden ayudar a medir comportamientos y detectar necesidades formativas. Deben utilizarse como herramienta educativa y acompañarse de instrucciones claras sobre cómo identificar y comunicar un posible ataque.

Buenas prácticas para administradores

Los administradores deben mantener un inventario actualizado de dominios, plataformas de envío, conectores y cuentas con privilegios. Este inventario es imprescindible para configurar correctamente la autenticación y retirar recursos que ya no deberían estar activos.

También conviene separar las cuentas administrativas de las cuentas de uso diario, limitar privilegios, revisar aplicaciones conectadas y aplicar políticas de acceso coherentes con el riesgo. Las reglas de transporte, las excepciones de filtrado y las listas de remitentes permitidos deben revisarse periódicamente.

La organización debe definir quién analiza los mensajes reportados, cómo se buscan correos similares, quién puede retirarlos de los buzones y cuándo es necesario bloquear indicadores, revocar sesiones o restablecer credenciales.

Respuesta ante un incidente

Cuando un usuario reporta un mensaje sospechoso, el análisis debe considerar las cabeceras, el remitente real, los resultados de autenticación, los enlaces, los adjuntos y la existencia de mensajes similares. Eliminar una única copia no es suficiente si la campaña ha alcanzado otros buzones.

Si el usuario ha introducido sus credenciales, puede ser necesario restablecer la contraseña, revocar sesiones, revisar los métodos de autenticación, comprobar reglas de reenvío y analizar la actividad de la cuenta. También deben revisarse los mensajes enviados para determinar si el buzón se utilizó contra otros destinatarios.

En incidentes relacionados con pagos o cambios bancarios, deben activarse los procedimientos financieros y contactar con las partes implicadas mediante canales previamente verificados.

Una estrategia de seguridad por capas

La seguridad del correo electrónico no depende de una única herramienta. Una estrategia sólida combina autenticación del dominio, filtrado de mensajes, análisis de archivos y enlaces, protección de identidades, monitorización, formación y respuesta ante incidentes.

Estos controles deben revisarse de forma periódica. Los servicios de envío cambian, aparecen nuevas técnicas de evasión y las organizaciones incorporan aplicaciones que modifican el flujo del correo. Una configuración correcta puede quedar obsoleta si no se mantiene.

Proteger el correo electrónico significa proteger identidades, información y procesos de negocio. La combinación de controles técnicos bien configurados, usuarios preparados y procedimientos operativos definidos permite reducir el riesgo sin depender de una falsa sensación de seguridad basada en un único filtro.