Phishing y suplantación de correo: DMARC, SPF y DKIM explicados

SPF, DKIM y DMARC son tres registros DNS que permiten a cualquier servidor de correo comprobar si un mensaje que dice venir de tu dominio realmente salió de tu empresa. SPF lista quién puede enviar en tu nombre, DKIM firma cada mensaje y DMARC le indica al receptor qué hacer cuando algo falla, además de enviarte reportes. Bien configurados y llevados a una política de rechazo, impiden que un atacante use tu dominio exacto para engañar a tus clientes, proveedores y empleados.

Por qué la suplantación de correo es un problema de negocio

El phishing sigue encabezando las denuncias de delitos en internet. En su informe de 2025, el centro de denuncias de delitos en internet del FBI (IC3) registró 191,561 denuncias de phishing y suplantación, la categoría más reportada del año. El fraude por compromiso de correo empresarial, conocido como BEC, sumó 24,768 denuncias y más de 3,046 millones de dólares en pérdidas reportadas: el segundo delito con más pérdidas, solo detrás del fraude de inversiones.

El patrón se repite en las brechas de seguridad. El Verizon DBIR 2026 encontró que el phishing fue el punto de entrada en 16% de las brechas de su conjunto de datos global, y en 20% de las brechas de Latinoamérica y el Caribe, una muestra de 718 brechas confirmadas en la región. No son cifras de Panamá en particular, pero describen el entorno en el que operan las empresas panameñas.

Para una empresa, el escenario típico es muy concreto: un correo que parece venir de tu gerente general pide un pago urgente, o un mensaje con el dominio de un proveedor avisa que cambió su cuenta bancaria. Si el atacante puede poner tu dominio exacto en el remitente, la estafa es mucho más creíble, para tu equipo y para tus clientes. SPF, DKIM y DMARC existen para cerrar esa puerta.

SPF: la lista de quién puede enviar con tu dominio

SPF (Sender Policy Framework) es un registro TXT en el DNS de tu dominio que enumera los servidores y servicios autorizados para enviar correo en tu nombre. Cuando llega un mensaje, el servidor que lo recibe revisa si la dirección IP de origen está en esa lista.

Tiene dos límites que conviene conocer. Primero, SPF valida el dominio del sobre del mensaje, es decir, la dirección técnica de rebote, y no necesariamente el remitente que tu usuario ve en Outlook. Segundo, el estándar (RFC 7208) limita a 10 las consultas DNS que puede generar una evaluación SPF; si tu registro pasa de ese límite, el resultado es un error permanente y tus mensajes dejan de pasar la verificación.

Ese límite se alcanza más rápido de lo que parece. Microsoft 365 o Google Workspace, el sistema de facturación, el CRM, la plataforma de boletines y el formulario del sitio web pueden agregar cada uno su propia entrada. Por eso un SPF que funcionaba hace dos años puede estar fallando hoy sin que nadie lo note. Cada vez que sumas o retiras un servicio que envía correo, el registro SPF necesita una revisión.

DKIM: la firma que prueba que el mensaje no fue alterado

DKIM (DomainKeys Identified Mail) agrega una firma criptográfica a cada mensaje que sale. La clave pública se publica en tu DNS y el receptor la usa para comprobar dos cosas: que el mensaje fue firmado por un dominio concreto y que su contenido no cambió en el camino.

A diferencia de SPF, la firma DKIM viaja dentro del mensaje, así que no depende del servidor que lo entrega y suele sobrevivir cuando alguien lo reenvía. Por eso es la pieza más confiable para pasar DMARC.

Un detalle que muchas empresas pasan por alto: Microsoft indica que el correo que sale de tus dominios personalizados en Microsoft 365 no se firma con DKIM hasta que configuras la firma para cada dominio. Lo mismo ocurre con cada servicio externo que envía por ti, desde la facturación hasta los boletines: cada uno necesita su propia configuración de DKIM con tu dominio.

DMARC: la regla que une a SPF y DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) es un registro TXT que se publica en _dmarc.tudominio.com y hace tres trabajos. El primero es exigir alineación: para pasar DMARC, el mensaje debe aprobar SPF o DKIM con el mismo dominio que aparece en el remitente visible. Así se cierra el hueco que SPF deja abierto por sí solo.

El segundo trabajo es pedir reportes. Con la etiqueta rua, los proveedores de correo te envían reportes agregados que muestran qué servidores enviaron mensajes con tu dominio y si pasaron las verificaciones. Con esos datos sabes qué servicios legítimos faltan por corregir y quién intenta hacerse pasar por ti. Sin reportes, cualquier cambio de política es una apuesta.

El tercero es definir qué hacer con el correo que falla. La política tiene tres niveles:

• p=none: solo monitorea. El correo se entrega igual y tú recibes los reportes.
• p=quarantine: pide al receptor tratar el correo que falla como sospechoso, normalmente enviándolo a la carpeta de spam.
• p=reject: pide rechazar el correo que falla. Es el nivel que realmente impide que alguien use tu dominio para suplantarte.

El nuevo estándar DMARC de 2026 y lo que exigen Gmail y Outlook

En mayo de 2026 la IETF publicó el RFC 9989, que reemplaza al RFC 7489, una versión informativa anterior, y convierte a DMARC en un estándar formal de internet. Tus registros actuales siguen funcionando, porque la versión sigue siendo v=DMARC1. Los cambios prácticos: desaparece la etiqueta pct, que se usaba para aplicar la política solo a un porcentaje del correo; llega la etiqueta t, que indica que estás en modo de prueba; y la etiqueta np permite fijar una política para subdominios que no existen.

Los grandes proveedores de correo ya lo exigen. Desde el 1 de febrero de 2024, Google pide a todo remitente que envía a cuentas de Gmail configurar SPF o DKIM, y a quien envía más de 5,000 mensajes diarios le exige SPF, DKIM y un registro DMARC, que puede estar en p=none, con el remitente alineado. Microsoft anunció requisitos equivalentes para Outlook.com desde el 5 de mayo de 2025: los dominios que envían más de 5,000 correos diarios deben pasar SPF y DKIM y publicar DMARC con al menos p=none. El correo que no cumple va primero a la carpeta de correo no deseado y puede llegar a ser rechazado.

Aunque tu empresa no envíe 5,000 correos al día, tus boletines, tus estados de cuenta o tu CRM pueden acercarse a ese volumen en un día de campaña. Y la razón principal para configurarlo no es la entrega: es que nadie más pueda escribir en tu nombre.

Cómo llegar a p=reject sin bloquear tu propio correo

El error clásico es publicar p=reject el primer día y descubrir que la facturación o los boletines dejaron de llegar. El camino seguro es por etapas y con los reportes en la mano, como recomienda la propia guía de Microsoft:

1. Inventario. Lista cada servicio que envía con tu dominio: Microsoft 365 o Google Workspace, facturación, CRM, plataformas de boletines, formularios del sitio web y hasta las impresoras multifuncionales que mandan escaneos por correo.

2. DMARC en monitoreo. Publica p=none con reportes rua y déjalo correr varias semanas, para que aparezcan también los envíos que solo ocurren a fin de mes.

3. Corrige SPF y activa DKIM. Agrega cada servicio legítimo al SPF sin pasar de 10 consultas y activa DKIM en cada uno, con tu dominio alineado.

4. Cuarentena. Cuando los reportes muestran que tu correo legítimo pasa las verificaciones, sube a p=quarantine y vigila los resultados.

5. Rechazo. Con la cuarentena estable, pasa a p=reject. Publica también p=reject en los dominios que tu empresa tiene registrados pero no usa para enviar correo: un dominio sin DMARC puede usarse para suplantarte aunque nunca envíes nada desde él.

En Techno hacemos este recorrido con DMARC Management de Cloudflare, que muestra cada servicio que envía en nombre de tu dominio y si pasa las verificaciones; está disponible para los dominios que usan el DNS de Cloudflare. Endurecemos la política por etapas y decidimos cada paso con los reportes, no a ciegas.

Lo que DMARC no resuelve

DMARC protege tu dominio exacto. No impide que alguien registre un dominio parecido, con una letra cambiada, ni que use una cuenta de correo gratuita con el nombre de tu gerente en el remitente. Tampoco detiene un correo que sale de la cuenta real de un proveedor cuya contraseña fue robada: ese mensaje pasa SPF, DKIM y DMARC porque es auténtico.

Por eso DMARC es una capa dentro de una estrategia de ciberseguridad empresarial, y necesita otras capas a su alrededor. Estas son las que recomendamos:

• Filtrado del correo entrante que detecte phishing, dominios parecidos y fraude de proveedores, con Defender para Office 365 o con Cloudflare Email Security, según tu licencia y tu nivel de riesgo.
• MFA para todos, de preferencia resistente al phishing, para que una contraseña robada no abra un buzón. Lo explicamos en nuestra guía de seguridad en Microsoft 365.
• Un proceso para pagos: todo cambio de cuenta bancaria o pago urgente se confirma por un canal distinto al correo, con un contacto que ya conoces.
• Capacitación breve y frecuente para que tu equipo reconozca las señales de un correo fraudulento antes de hacer clic.

Preguntas frecuentes

¿Mi empresa necesita DMARC aunque sea pequeña?

Sí. La suplantación no depende del tamaño: basta con que tu dominio exista y que tus clientes confíen en él. Además, Gmail y Outlook ya exigen SPF, DKIM y DMARC a quien envía grandes volúmenes de correo.

¿Pasar DMARC a p=reject puede bloquear mi propio correo?

Sí, si se hace sin revisar los reportes. Por eso se empieza en p=none, se corrigen SPF y DKIM en cada servicio legítimo y solo después se pasa a cuarentena y a rechazo.

¿DMARC detiene todo el phishing?

No. Detiene el uso de tu dominio exacto. Los dominios parecidos, las cuentas gratuitas con nombres falsos y los buzones comprometidos de terceros requieren filtrado de correo, MFA y un proceso para verificar pagos.

¿Qué cambió con el RFC 9989?

Desde mayo de 2026 DMARC es un estándar formal de la IETF. Tus registros v=DMARC1 siguen funcionando; la etiqueta pct queda obsoleta y la reemplaza la etiqueta t para el modo de prueba, y la etiqueta np define la política para subdominios que no existen.

¿Qué hago con los dominios que no uso para enviar correo?

Publica en ellos un SPF que no autorice a ningún servidor (v=spf1 -all) y un DMARC con p=reject. Así nadie puede enviar correo convincente con esos dominios.

Si quieres saber cómo están hoy el SPF, el DKIM y el DMARC de tu dominio, envíanos tu dominio y te decimos qué conviene corregir primero. Protege el correo de tu dominio

Fuentes

1. FBI IC3 – 2025 Internet Crime Report (2026): Phishing y suplantación con 191,561 denuncias, la categoría más reportada; BEC con 24,768 denuncias y 3,046,598,558 dólares en pérdidas reportadas, segundo por pérdidas.
2. Verizon – 2026 Data Breach Investigations Report: Phishing como punto de entrada en 16% de las brechas; en Latinoamérica y el Caribe, 20% de 718 brechas confirmadas.
3. Google – Directrices para remitentes de correos (Ayuda de Gmail): Desde el 1 de febrero de 2024: SPF o DKIM para todo remitente; SPF, DKIM, DMARC (puede estar en p=none) y alineación para más de 5,000 mensajes diarios.
4. Microsoft Community Hub – Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (2025): Desde el 5 de mayo de 2025, SPF, DKIM y DMARC con al menos p=none para dominios que envían más de 5,000 correos diarios a Outlook.com; el correo que no cumple va a no deseados y puede ser rechazado.
5. IETF – RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (2026): Estándar de mayo de 2026 que reemplaza a los RFC 7489 y 9091; elimina la etiqueta pct y agrega las etiquetas t y np.
6. IETF – RFC 7208: Sender Policy Framework (SPF) (2014): Límite de 10 consultas DNS por evaluación SPF; si se supera, el resultado es un error permanente.
7. Microsoft Learn – Cómo usar DKIM para el correo electrónico en su dominio personalizado: El correo saliente de los dominios personalizados no se firma con DKIM hasta configurar la firma en cada dominio.
8. Microsoft Learn – Configuración de DMARC para validar el correo electrónico en Microsoft 365: Implementación por etapas: p=none para monitorear, luego p=quarantine y p=reject, revisando los reportes.
9. Cloudflare Docs – DMARC Management: Reportes DMARC por servicio que envía con tu dominio; disponible para clientes que usan el DNS de Cloudflare.