SPF, DKIM y DMARC son tres registros que se publican en el DNS de un dominio para que el resto del mundo pueda comprobar si un correo que dice venir de ese dominio realmente salió de él. SPF dice qué servidores pueden enviar en su nombre. DKIM firma cada mensaje para demostrar que no se alteró por el camino. DMARC une los dos, los compara con la dirección que ve el destinatario y le dice al servidor que recibe qué hacer cuando algo no cuadra.
Por separado se entienden a medias. Juntos son la razón por la que alguien puede, o no puede, mandar un correo con su dominio sin haber tocado nunca sus servidores.
¿Qué pregunta responde cada uno?
| Registro | Qué pregunta responde | Dónde se publica |
|---|---|---|
| SPF | ¿Este servidor tiene permiso para enviar correo de este dominio? | Un registro TXT en el propio dominio |
| DKIM | ¿El mensaje llegó tal como salió, firmado por quien dice? | Una clave pública en selector._domainkey.sudominio |
| DMARC | ¿Lo anterior coincide con el remitente que ve el usuario? ¿Qué hago si no? | Un registro TXT en _dmarc.sudominio |
¿Qué es SPF?
SPF (Sender Policy Framework) es una lista. El dueño del dominio publica qué servidores y qué servicios pueden enviar correo en su nombre: su plataforma de correo, el sistema de facturación, la herramienta de envíos masivos. Cuando llega un mensaje, el servidor que lo recibe consulta esa lista y comprueba si quien lo entrega está en ella. La especificación vigente es el RFC 7208.
El registro termina con una instrucción para todo lo que no está en la lista. Con -all el dueño afirma que cualquier otro servidor no está autorizado. Con ~all dice lo mismo con menos fuerza. La especificación pide que un correo no se rechace solo por ese resultado.
SPF tiene dos límites que conviene conocer. El primero es que comprueba el remitente técnico del sobre, no la dirección que aparece en el campo “De” y que lee la persona. Un atacante puede pasar SPF con su propio dominio y poner el suyo en el “De”. El segundo es que se rompe cuando un correo se reenvía, porque el servidor que lo reenvía no está en su lista.
¿Qué es DKIM?
DKIM (DomainKeys Identified Mail) es una firma. El servidor que envía firma cada mensaje con una clave privada y añade esa firma a la cabecera. El dominio publica en su DNS la clave pública correspondiente, bajo un nombre llamado selector. Quien recibe el correo busca la clave, verifica la firma y sabe dos cosas: que un servidor autorizado por ese dominio firmó el mensaje y que nadie cambió las partes firmadas por el camino.
A diferencia de SPF, la firma viaja con el mensaje, así que suele sobrevivir a los reenvíos. Lo que DKIM no hace es decidir nada. Una firma que falla, o un mensaje sin firma, no le dice al servidor que recibe si debe entregarlo o no.
¿Qué es DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) es la pieza que convierte las dos anteriores en una política. Está descrito en el RFC 7489 y hace tres cosas.
Primero, exige alineación. No basta con que SPF o DKIM den por bueno el mensaje: el dominio que validaron tiene que coincidir con el dominio del campo “De”, el que ve el destinatario. Así se cierra la puerta que SPF dejaba abierta.
Segundo, publica una política. El dueño del dominio le dice al mundo qué hacer con los mensajes que dicen venir de él y no pasan la comprobación.
Tercero, pide informes. Con la etiqueta rua el dominio indica a qué dirección deben mandar los grandes proveedores de correo un resumen periódico de lo que recibieron en su nombre. Esos informes son la única forma de saber quién está enviando correo con su dominio, incluidos los servicios legítimos que nadie recordaba.
¿Qué significan none, quarantine y reject?
La política se escribe en la etiqueta p del registro DMARC y solo tiene tres valores.
p=none: solo mirar. El dueño no pide ninguna acción sobre los mensajes que fallan. Se entregan igual. Sirve para empezar y recibir informes, pero un dominio en none no está protegido contra la suplantación, solo está observando.
p=quarantine: tratarlos como sospechosos. Los mensajes que fallan van, según el proveedor, a la carpeta de correo no deseado o a una revisión más estricta. Es el paso intermedio.
p=reject: no aceptarlos. El dueño pide que los mensajes que fallan se rechacen, idealmente en el momento de la entrega. Es la política más estricta y la única que de verdad le cierra el dominio a quien quiera usarlo para suplantar.
¿Cómo se ve en un dominio real?
El nuestro, tal como lo devuelve hoy cualquier consulta pública al DNS:
zettatek.com SPF v=spf1 include:spf.protection.outlook.com include:spf-us.emailsignatures365.com ~all
_dmarc.zettatek.com DMARC v=DMARC1; p=reject; rua=mailto:(buzón de informes)
selector1 y selector2 DKIM de Microsoft 365, los dos publicadosSe lee así. SPF autoriza a Microsoft 365 y al servicio de firmas corporativas. DKIM firma con las dos claves que Microsoft 365 rota entre sí. Y DMARC está en reject, así que un correo que diga venir de zettatek.com y no pase SPF o DKIM alineados no debería llegar a ninguna bandeja.
El ~all de SPF no es un descuido. Con DMARC en reject, la decisión no la toma SPF por su cuenta sino la política de DMARC, que mira SPF y DKIM juntos.
¿Cómo se implementa sin romper el correo de la empresa?
El error más caro es saltar directo a reject. El orden que funciona es este:
- Hacer inventario de todo lo que envía correo con su dominio: la plataforma principal, el CRM, la facturación electrónica, las encuestas, el sistema de nómina, los avisos del sitio web.
- Publicar SPF con todos ellos y activar DKIM en cada servicio que lo permita.
- Publicar DMARC en
p=nonecon una dirección de informes y leerlos durante unas semanas. Ahí aparecen los remitentes que faltaban. - Corregir lo que falla y pasar a
quarantine. - Cuando los informes estén limpios, pasar a
rejecty seguir leyéndolos, porque cada servicio nuevo que se contrate tiene que entrar en la lista.
¿Cuáles son los errores más comunes?
Quedarse en p=none para siempre. Es el más frecuente: se publica DMARC para cumplir, nadie lee los informes y el dominio sigue igual de expuesto que antes.
Pasarse del límite de consultas de SPF. La especificación limita a diez los mecanismos que obligan a hacer consultas DNS. Cada include cuenta. Una empresa que suma servicios sin revisar el registro acaba con un SPF que da error y deja de servir.
Publicar dos registros SPF en el mismo dominio. Debe haber uno solo. Con dos, la comprobación falla.
Olvidar los subdominios y los dominios que no envían correo. Un dominio que nunca manda mensajes también se puede suplantar. Lo sensato es publicarle un SPF que no autorice a nadie y un DMARC en reject.
¿Por qué importa fuera del área de sistemas?
Porque sin DMARC en una política estricta, cualquiera puede mandar a sus clientes, a sus proveedores o a su propio equipo de finanzas un correo con su dominio exacto en el remitente. Es la puerta de entrada del fraude del CEO y de muchas campañas de phishing. Ningún filtro del lado del destinatario puede adivinar que un correo es falso si el dominio verdadero nunca dijo qué hacer con los falsos.
Hay un límite que también conviene decir: DMARC protege su dominio exacto. No impide que alguien registre uno parecido, con una letra cambiada. Para eso hace falta vigilancia y gente entrenada para mirar la dirección completa.
Preguntas frecuentes
¿Cómo sé si mi dominio tiene SPF, DKIM y DMARC?
dig TXT sudominio.com muestra el SPF y dig TXT _dmarc.sudominio.com el DMARC. DKIM depende del selector de cada servicio. También hay herramientas web gratuitas que hacen la consulta sin instalar nada.¿Basta con tener SPF?
¿Pasar a reject puede hacer que se pierdan correos legítimos?
none, se leen los informes y se corrige cada servicio que envía en su nombre antes de endurecer la política.Si no tiene claro en qué política está hoy su dominio o quién envía correo en su nombre, es parte de lo que revisamos en la evaluación de seguridad gratuita. Y si algún término le resultó nuevo, el glosario lo explica.
