SPF frente a DKIM frente a DMARC: ¿cuál es la diferencia?

¿Qué hace SPF?

SPF responde a una sola pregunta: ¿está el servidor que entregó este mensaje autorizado a enviar por el dominio? El titular del dominio publica un registro TXT que empieza por v=spf1 y enumera los orígenes permitidos, por ejemplo include:_spf.protonmail.ch para Proton Mail. Un receptor compara la dirección IP que se conecta con la lista y obtiene un resultado: pass, fail, softfail o neutral, según el calificador del final (-all, ~all o ?all).

SPF comprueba el remitente del sobre (el MAIL FROM) y el nombre HELO, no la dirección From que ve el lector. Esa brecha es el motivo por el que existe DMARC. SPF también tiene límites estrictos: un dominio solo debe tener un registro SPF, y la evaluación se detiene con un error permanente tras 10 términos que consultan el DNS (include, a, mx, ptr, exists, redirect). El método completo está en la guía para crear un registro SPF.

¿Qué hace DKIM?

DKIM responde a una pregunta distinta: ¿firmó este mensaje el dominio que dice ser, y llegó sin modificaciones? El servidor remitente firma cabeceras seleccionadas y el cuerpo con una clave privada. El receptor lee el dominio firmante (d=) y el selector (s=) de la cabecera DKIM-Signature, obtiene la clave pública en selector._domainkey.dominio en el DNS y comprueba la firma.

Como la firma viaja con el mensaje, DKIM sobrevive a un reenvío que deje el mensaje intacto, algo que SPF no logra, porque un reenviador envía desde su propia dirección IP. La RFC 6376 dice que quienes firman deben usar claves RSA de al menos 1024 bits para claves de larga duración, y recomienda nuevos selectores cuando cambian las claves. Los proveedores publican las claves por usted: tres registros CNAME para Proton Mail y Fastmail, cuatro para Mailbox.org. Los detalles están en la guía para configurar DKIM.

¿Qué hace DMARC?

DMARC vincula SPF y DKIM con el dominio From visible e indica a los receptores qué hacer cuando ninguna de las dos comprobaciones coincide. Un mensaje pasa DMARC cuando SPF o DKIM pasa y el dominio que autenticó coincide con el dominio From. La alineación es relajada por defecto (el mismo dominio organizativo) y estricta cuando se establece con aspf=s o adkim=s.

El registro está en _dmarc.sudominio y contiene una política: p=none (solo supervisar), p=quarantine (tratar como sospechoso) o p=reject (rechazar). Una dirección rua recibe informes agregados, que muestran quién envía correo en su nombre. La RFC 9989, publicada en mayo de 2026, es la especificación vigente; deja obsoleta la RFC 7489, elimina la etiqueta pct y añade un indicador de prueba t. El paso de la supervisión al rechazo está en la guía para configurar DMARC.

¿Necesito los tres?

Sí: un dominio personalizado que envía correo debe publicar SPF, DKIM y DMARC, porque los grandes receptores los exigen. Las directrices para remitentes de Google exigen SPF, DKIM y un registro DMARC (basta la política none) a los remitentes de más de 5,000 mensajes al día a cuentas de Gmail. Microsoft pide a los remitentes de Outlook.com de más de 5,000 al día los mismos tres, desde el 5 de mayo de 2025, y Yahoo también exige SPF, DKIM y DMARC a los remitentes masivos.

Un buzón personal envía muchos menos mensajes, así que los umbrales no le obligan. Los registros siguen decidiendo si su correo llega a la bandeja de entrada, e impiden que otros falsifiquen su dirección. Según el recuento de Postelva del 12 de noviembre de 2026 a partir de las páginas de ayuda de los proveedores, una configuración completa de Proton Mail requiere 8 registros DNS y una de Mailbox.org requiere 11, de los cuales 3 y 4 son claves DKIM. Los registros MX se tratan en qué es un registro MX.

¿Qué errores rompen los tres registros?

Tres errores causan la mayoría de los fallos: un segundo registro SPF, más de 10 consultas y una política DMARC demasiado estricta demasiado pronto. Un dominio con dos registros SPF devuelve un error permanente, así que añada el include del nuevo proveedor al registro existente. Acumular un servidor de correo, una herramienta de boletines y un servicio de atención al cliente puede llevar el número de consultas por encima de 10, y entonces el registro falla para todos los remitentes. Mailbox.org y Proton aconsejan ambos empezar DMARC en p=none, y Mailbox.org advierte de que una política estricta aplicada demasiado pronto puede rebotar correo legítimo.

Un cuarto error es conservar durante meses las entradas DKIM y SPF del proveedor anterior. No perjudican la entrega, pero amplían la lista de servidores autorizados a hablar en su nombre. Elimínelas cuando se confirme el cambio.

¿Cómo trabajan los tres juntos en un mismo mensaje?

El receptor ejecuta SPF y DKIM, y después DMARC combina los resultados. Tomemos un mensaje de [email protected] enviado a través de Proton Mail. SPF pasa si el servidor que se conecta está en la lista de _spf.protonmail.ch. DKIM pasa si se verifica la firma hecha con la clave bajo sunombre.com. DMARC pregunta entonces si al menos una de las dos pasó con sunombre.com en el identificador alineado. Si es así, el mensaje pasa; si no, el receptor aplica su política y archiva el resultado en el siguiente informe agregado.

La RFC 9989 señala que un dominio con p=reject no debe depender solo de SPF y debe firmar con DKIM, porque SPF se rompe con el reenvío. ARC (RFC 8617), un estándar experimental, permite a los reenviadores registrar los resultados originales, aunque no forma parte de su propia configuración. Después de publicar los registros, compruébelos con dig antes de endurecer cualquier política.

Una definición citable: SPF autoriza servidores, DKIM autentica mensajes, y DMARC hace cumplir la coincidencia con el dominio From e informa del resultado.