SPF, DKIM y DMARC explicados sin jerga (y los fallos que veo siempre)

Los tres registros que deciden si tu correo entra o se rechaza tienen nombres intimidantes y hacen cosas bastante simples. Merece la pena entender qué hace cada uno, porque casi todos los problemas que veo vienen de tener dos bien y uno a medias.

Los tres, en una frase cada uno

SPF dice quién puede enviar en nombre de tu dominio. Es una lista de servidores autorizados, publicada en tu DNS.

DKIM firma cada mensaje con una clave criptográfica. El receptor comprueba la firma contra la clave pública que publicas en tu DNS y sabe que el mensaje no se ha alterado y que sale de quien dice salir.

DMARC es la política: le dice al receptor qué hacer cuando SPF y DKIM fallan, y a dónde enviarte informes de lo que está pasando.

El orden importa: SPF y DKIM son los mecanismos, DMARC es la decisión. Publicar DMARC sin tener los otros dos funcionando es como poner una cerradura en una puerta que no está montada.

Alineación: la parte que casi nadie mira

Esta es la idea que falta en la mayoría de explicaciones. No basta con que SPF y DKIM pasen: DMARC exige que además estén alineados con el dominio que el destinatario ve en el De:.

Un ejemplo de lo que pasa a diario: contratas una herramienta de facturación que envía en tu nombre. Sus servidores firman con su dominio, y su SPF autoriza sus IPs. Técnicamente el correo está autenticado — pero autenticado como ellos, no como tú. DMARC lo ve desalineado y, según tu política, lo manda a spam o lo rechaza.

Por eso un dominio puede tener los tres registros y seguir teniendo problemas con las facturas que envía la herramienta, mientras el correo normal de la oficina entra sin más.

Los cinco fallos que aparecen una y otra vez

1. Dos registros SPF

Es el error más silencioso y el más grave. Cuando añades un proveedor nuevo y creas un segundo registro v=spf1 en vez de fusionarlo con el que ya tenías, la norma dice que la política queda inválida — no que se sumen. Los receptores la descartan entera, así que pasas de tener SPF a no tener ninguno, sin ningún aviso.

Solución: un único registro SPF, con todos los include: dentro.

2. ~all en lugar de -all

El final del registro SPF dice qué hacer con lo no autorizado. -all significa «recházalo»; ~all significa «acéptalo pero márcalo como sospechoso». Muchos proveedores dejan ~all por defecto porque es más difícil de romper.

Funciona, pero protege menos: con ~all sigue siendo posible que alguien envíe en tu nombre y el mensaje entre marcado en vez de rechazado. Si ya tienes controlado quién envía por ti, -all es lo correcto.

3. DMARC en p=none dado por bueno

p=none solo observa: pide informes y no pide ninguna acción. Es el punto de partida sensato mientras averiguas quién envía en tu nombre, pero no es un destino. El problema es que muchos paneles de hosting muestran «DMARC ✓ configurado» y ahí se queda para siempre.

Si tu DMARC lleva años en p=none, tienes DMARC en el mismo sentido en que tienes una alarma desconectada.

4. DMARC sin rua

El campo rua=mailto: es la dirección a la que llegan los informes agregados. Sin él, publicas una política y no te enteras de nada: ni de quién intenta suplantarte, ni de qué envíos legítimos tuyos están fallando. Es la parte que hace que DMARC sea útil antes de endurecer la política.

5. Migrar de servidor y no tocar el DNS

El clásico: se cambia de hosting, el correo se mueve a otra IP, y SPF, DKIM y el PTR se quedan apuntando al sitio antiguo. Funcionaba el viernes y el lunes rebota todo. No es un fallo raro, es el orden natural de las cosas cuando la migración la hace quien mueve la web y no quien entiende el correo.

En qué orden hacerlo

1. Inventario: qué herramientas envían correo en tu nombre. Facturación, CRM, formularios de la web, boletines. Es el paso que más se salta y el que evita romper cosas después.
2. SPF: un registro único que autorice todo lo del inventario, terminando en -all cuando estés seguro de la lista.
3. DKIM: firmando en cada servicio que envíe por ti, cada uno con su selector.
4. DMARC en p=none con rua: recoges informes unas semanas y compruebas que no queda nada legítimo fallando.
5. Subir a p=quarantine y luego a p=reject: cuando los informes estén limpios.

Ese último paso es el que casi nadie da, y es el que de verdad cierra la puerta.

Compruébalo tú

Los tres registros son públicos, así que no necesitas acceso a nada para ver cómo está tu dominio. La comprobación de esta web te los lee y te dice qué significa cada uno en lenguaje de negocio — incluido el caso de p=none, que marca como aviso y no como correcto.

Una advertencia honesta sobre DKIM: no se puede enumerar desde fuera. El selector es una palabra que elige quien configura el servidor, así que solo se pueden probar los habituales. Que una herramienta no lo encuentre no significa que no exista, y cualquiera que te diga lo contrario en rojo te está asustando sin motivo.