El email sigue siendo el vector de ataque mas efectivo
Cada dia se envian mas de 300.000 millones de correos electronicos en el mundo. De todos los ciberataques registrados, el 91% comienzan con un email de phishing. La razon es simple: el protocolo SMTP, disenado en 1982, no incluye ningun mecanismo de autenticacion del remitente. Cualquier servidor puede enviar un correo afirmando ser tu-dominio.com.
Si tu dominio no tiene SPF, DKIM y DMARC configurados, un atacante puede enviar correos en nombre de tu empresa a tus clientes, proveedores o empleados. No necesita acceder a tus servidores. Solo necesita un servidor SMTP y tu nombre de dominio.
Esta es la amenaza que la triada de autenticacion de email resuelve.
SPF: quien puede enviar en tu nombre
SPF (Sender Policy Framework) es un registro DNS de tipo TXT que declara que servidores IP tienen permiso para enviar correo en nombre de tu dominio. Cuando un servidor receptor recibe un email que dice provenir de tu-dominio.com, consulta el registro SPF en tu DNS y verifica si la IP del servidor que lo envio esta autorizada.
Un registro SPF tipico tiene este aspecto:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all
Desglosemos cada parte:
v=spf1-- Version del protocolo.include:_spf.google.com-- Autoriza los servidores de Google Workspace.include:sendgrid.net-- Autoriza los servidores de SendGrid para envios transaccionales.ip4:203.0.113.5-- Autoriza una IP especifica.-all-- Rechaza todo lo que no coincida (hard fail).
La diferencia entre -all y ~all es critica. Con -all (hard fail), los servidores receptores rechazan los correos no autorizados. Con ~all (soft fail), los marcan como sospechosos pero los entregan igualmente. En produccion, siempre deberias usar -all.
Error comun: SPF tiene un limite de 10 lookups DNS. Cada include cuenta como un lookup, y los includes anidados tambien. Si superas 10, el registro SPF se invalida por completo. Herramientas como dmarcian o mxtoolbox te permiten verificar cuantos lookups consume tu registro.
DKIM: la firma criptografica del mensaje
DKIM (DomainKeys Identified Mail) anade una firma criptografica a las cabeceras de cada correo saliente. El servidor emisor firma el mensaje con una clave privada, y el receptor verifica la firma consultando la clave publica publicada en un registro DNS TXT.
El registro DNS de la clave publica se ubica en un subdominio especifico:
selector1._domainkey.tu-dominio.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Cuando el servidor receptor obtiene un email firmado con DKIM:
- Extrae el selector y el dominio de la cabecera
DKIM-Signature. - Consulta la clave publica en DNS.
- Verifica que la firma coincida con el contenido del mensaje.
Si alguien modifica el cuerpo o las cabeceras del correo en transito, la firma se invalida. DKIM garantiza integridad: el mensaje que llega es exactamente el que se envio.
Error comun: No rotar las claves DKIM periodicamente. Si una clave privada se compromete y no la rotas, el atacante puede firmar correos en tu nombre indefinidamente. La recomendacion es rotar claves al menos cada 6-12 meses y usar claves de 2048 bits como minimo.
DMARC: la politica que une todo
DMARC (Domain-based Message Authentication, Reporting and Conformance) es la capa de politica. No autentica por si mismo, sino que indica a los servidores receptores que hacer cuando SPF o DKIM fallan, y exige alineacion: el dominio del From debe coincidir con el dominio validado por SPF o DKIM.
Un registro DMARC se publica como TXT en _dmarc.tu-dominio.com:
_dmarc.tu-dominio.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@tu-dominio.com; pct=100"
Las tres politicas posibles son:
| Politica | Comportamiento |
|---|---|
| p=none | Solo monitoriza. Los correos se entregan aunque fallen las verificaciones. |
| p=quarantine | Los correos que fallan se envian a spam o cuarentena. |
| p=reject | Los correos que fallan se rechazan directamente. No llegan al destinatario. |
El parametro rua especifica la direccion donde recibiras los informes agregados de DMARC. Estos informes son XML y te muestran que servidores estan enviando correo en nombre de tu dominio, cuales pasan las verificaciones y cuales fallan.
Error comun: Configurar p=none y no avanzar nunca hacia reject. El modo none es para observacion inicial, no para produccion permanente. Un dominio con p=none no esta protegido contra la suplantacion.
Como funcionan juntos
El flujo completo de verificacion cuando un correo llega al servidor receptor es:
- Verificacion SPF -- El receptor consulta el registro SPF del dominio del envelope sender (
MAIL FROM) y comprueba si la IP del servidor emisor esta autorizada. - Verificacion DKIM -- El receptor localiza la firma DKIM en las cabeceras, obtiene la clave publica de DNS y verifica la firma.
- Evaluacion DMARC -- El receptor comprueba si al menos uno de los dos (SPF o DKIM) ha pasado con alineacion respecto al dominio del
From. Aplica la politica definida.
Ninguno de los tres protocolos es suficiente por separado:
- SPF solo no protege contra ataques de reenvio (forwarding), porque la IP cambia al reenviarse el correo.
- DKIM solo no impide que un atacante envie correo desde una IP no autorizada si no firma con DKIM.
- DMARC solo no existe sin SPF o DKIM, porque necesita al menos uno de ellos para evaluar la alineacion.
Los tres juntos forman un sistema robusto donde SPF valida el servidor, DKIM valida el mensaje y DMARC define la politica y la alineacion.
Hoja de ruta para desplegar DMARC
Pasar directamente a p=reject sin preparacion puede causar que correos legitimos sean rechazados. La implantacion debe ser gradual:
Semana 1: Despliegue en modo observacion
_dmarc.tu-dominio.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@tu-dominio.com"
Activa SPF y DKIM para todos los servicios que envian correo en tu nombre. Publica DMARC con p=none y rua para empezar a recibir informes.
Semanas 2-4: Analisis de informes
Revisa los informes agregados. Identifica todos los servicios legitimos que envian correo (CRM, marketing, transaccional, tickets de soporte). Anade sus IPs o includes al registro SPF y configura DKIM para cada uno.
Mes 2: Cuarentena
_dmarc.tu-dominio.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@tu-dominio.com; pct=100"
Los correos que fallen iran a spam. Monitoriza los informes para detectar falsos positivos.
Mes 3: Rechazo total
_dmarc.tu-dominio.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@tu-dominio.com; pct=100"
Solo cuando no haya falsos positivos, activa el rechazo total. Tu dominio esta ahora protegido contra la suplantacion de identidad por email.
DNSSEC: el cimiento que protege todo lo anterior
SPF, DKIM y DMARC dependen de consultas DNS. Si un atacante puede falsificar las respuestas DNS (DNS poisoning o DNS spoofing), puede eludir los tres protocolos. DNSSEC (DNS Security Extensions) firma criptograficamente las respuestas DNS, garantizando que los registros TXT que contienen SPF, DKIM y DMARC no han sido manipulados.
Sin DNSSEC, un atacante con capacidad de interceptar trafico DNS podria devolver un registro SPF falso que autorice sus propias IPs, o un registro DKIM con una clave publica que el controle. DNSSEC cierra este vector.
Que evalua UareSafe
UareSafe evalua la autenticacion de email como parte de la dimension DNS de su certificacion de seguridad web. Los controles especificos incluyen:
- SPF: Existencia del registro, uso de
-all, numero de lookups dentro del limite. - DKIM: Existencia de registros DKIM, longitud de clave adecuada.
- DMARC: Existencia del registro, politica (
none/quarantine/reject), configuracion derua. - MX: Configuracion correcta de los registros MX del dominio.
- DNSSEC: Validacion de la cadena de confianza DNSSEC.
Un dominio sin DMARC en politica reject pierde puntuacion significativa en la certificacion. La configuracion correcta de estos cinco controles demuestra que la organizacion protege activamente su identidad de correo electronico.
La autenticacion de email no es opcional en 2026
Desde febrero de 2024, Google y Yahoo exigen DMARC para remitentes de correo masivo (mas de 5.000 mensajes diarios). Microsoft ha seguido el mismo camino. Los dominios sin autenticacion de email sufren problemas de entregabilidad, ademas del riesgo de suplantacion.
Configurar SPF, DKIM y DMARC correctamente protege tres cosas:
- Tu marca: Nadie puede enviar correos fraudulentos con tu dominio.
- Tus clientes: No recibiran phishing que aparente venir de ti.
- Tu entregabilidad: Los proveedores de correo confian mas en dominios con DMARC en
reject.
La triada de autenticacion de email es una de las medidas de seguridad con mejor relacion coste-beneficio que puedes implementar. No requiere software adicional, no tiene coste de licencia y se configura directamente en tu DNS. El unico requisito es hacerlo bien.