SPF, DKIM y DMARC: diferencias y límites de una comprobación externa
Qué hace cada uno de los tres, en qué orden ponerlos, y por qué DKIM no se puede verificar desde fuera sin ver un correo tuyo.
Por SiteGuardiaPublicado 4 min de lectura
Los tres sirven para que alguien no pueda enviar correo haciéndose pasar por tu dominio. Hacen cosas distintas y solo funcionan de verdad cuando están los tres.
Resumido antes de entrar en detalle: SPF dice qué servidores pueden enviar, DKIM firma el mensaje, y DMARC dice qué hacer cuando algo falla y a dónde enviar los informes. Sin DMARC, los dos primeros no tienen consecuencias.
SPF
Un registro TXT en tu dominio que lista los servidores autorizados a enviar correo en tu nombre. El servidor que recibe compara la dirección IP del remitente con esa lista.
El final del registro es lo que decide qué pasa con lo que no está en la lista:
~allmarca el correo no autorizado como sospechoso, sin rechazarlo. Es lo correcto mientras no estés seguro de haber listado todo.-alllo rechaza. Es el objetivo, y romperá tu facturación el día que alguien envíe desde una herramienta que nadie incluyó.+allautoriza a cualquiera. Es equivalente a no tener SPF.
Un límite del protocolo que sorprende: SPF no puede hacer más de diez búsquedas DNS. Si encadenas varios include: de proveedores distintos, te pasas, y el registro deja de evaluarse correctamente. Es un fallo silencioso y habitual en empresas que usan tres o cuatro servicios de correo.
DKIM
Una firma criptográfica que tu servidor de correo añade a cada mensaje. El receptor busca la clave pública en tu DNS y comprueba la firma. Si el mensaje se modificó por el camino, o si no lo envió quien dice, la firma no cuadra.
Aquí está el límite que este tipo de comprobación no puede saltarse, y conviene decirlo claro:
DKIM no se puede verificar desde fuera sin un correo tuyo. La clave pública vive en un nombre DNS que depende del selector que use tu servidor al firmar, y el selector va dentro de la cabecera del mensaje. Sin un mensaje firmado en la mano, no hay forma de saber qué nombre consultar.
Por eso SiteGuardia informa de DKIM como "no verificable externamente" en lugar de inventarse un resultado probando selectores comunes. Un comprobador que te diga "DKIM: no encontrado" después de probar default, google y selector1 te está diciendo que no acertó con el nombre, no que no tengas DKIM.
Para comprobarlo de verdad: envía un correo desde tu dominio a una cuenta tuya en otro proveedor y mira la cabecera Authentication-Results del mensaje recibido. Ahí aparece el resultado real de los tres.
DMARC
Un registro TXT en _dmarc.tudominio que responde a dos preguntas: qué debe hacer el receptor cuando SPF y DKIM fallan, y a dónde enviar los informes.
La política tiene tres valores:
| Política | Qué pide | Cuándo usarla |
|---|---|---|
p=none | No hagas nada distinto, pero infórmame | Al empezar, para ver qué está pasando |
p=quarantine | Manda a spam lo que falle | Cuando los informes salen limpios |
p=reject | Rechaza lo que falle | Cuando estás seguro |
Un `p=none` sin `rua=` no sirve para casi nada. No cambia el tratamiento del correo y tampoco te manda informes, así que no aprendes nada. Si vas a dejarlo en none mientras observas, pon la dirección de informes; ese es el único motivo para estar en none.
Un ejemplo
Un dominio sintético con los tres puestos y uno de ellos mal:
`` tudominio.example TXT "v=spf1 include:_spf.proveedor.example ~all" _dmarc.tudominio.example TXT "v=DMARC1; p=none" ``
Lo que un análisis externo puede decir de esto:
- SPF existe y termina en
~all. Confirmado. - DMARC existe y está en
p=nonesin dirección de informes. Confirmado, y es el punto débil: la política no hace nada y nadie está mirando. - DKIM: no verificable desde fuera. No es una ausencia, es un desconocido.
El orden de trabajo aquí es: añadir rua, esperar un par de semanas de informes, y entonces subir a quarantine.
Qué pedir a quien gestiona tu DNS
Hola. En [dominio] quiero cerrar la autenticación de correo. Tres pasos, en este orden: 1. Cambiar el registro _dmarc a v=DMARC1; p=none; rua=mailto:[dirección]; fo=1, para empezar a recibir informes. Esto no cambia cómo se trata el correo. 2. Dentro de dos o tres semanas, revisar los informes y confirmar que todo el correo legítimo está saliendo autenticado, incluido el de [herramientas que enviéis: facturación, boletines, formularios]. 3. Si sale limpio, subir a p=quarantine. Aparte: ¿puedes comprobar cuántas búsquedas DNS consume nuestro SPF? El límite son diez y con varios include: es fácil pasarse sin darse cuenta.
Fuentes
- RFC 7208, Sender Policy Framework, incluido el límite de diez búsquedas en la sección 4.6.4.
- RFC 6376, DomainKeys Identified Mail
- RFC 7489, DMARC
Relacionado
Compruébalo en tu web
Esta guía explica la señal. La comprobación la lee en tu dominio y te dice qué encontró.