Qué hacen realmente SPF, DKIM y DMARC
Piensa en los tres como una cadena de tres eslabones. SPF autoriza a los servidores que pueden enviar en nombre de tu dominio. DKIM añade una firma criptográfica para que el receptor pueda comprobar que el mensaje no se modificó por el camino. DMARC vincula ambos al dominio que el lector ve de verdad en la línea From: y publica una política sobre qué hacer cuando la comprobación falla. Dicho de forma sencilla: SPF revisa el sobre, DKIM revisa el contenido y DMARC comprueba que alguno de los dos coincida con el nombre que lee tu destinatario.
SPF: qué servidores pueden enviar en nombre de tu dominio
Un registro SPF es una única entrada DNS de tipo TXT que empieza por v=spf1, enumera los hosts e includes autorizados a enviar para el dominio y termina con un mecanismo all. Hay dos reglas que sorprenden a mucha gente. Primero, un dominio solo puede publicar un registro v=spf1; un segundo registro hace que la evaluación devuelva permerror y, en la práctica, la autenticación falla (RFC 7208, sección 4.5). Segundo, SPF puede ejecutar como máximo diez mecanismos que requieren consulta DNS —include, a, mx, ptr, exists y el modificador redirect— durante la evaluación; si superas los diez, el resultado vuelve a ser permerror (sección 4.6.4). El calificador final es la política: ~all es un softfail (aceptar pero marcar), -all es un hardfail (rechazar a los remitentes no incluidos) y +all dejaría pasar todo, por eso nunca debes publicarlo. Un límite estructural que conviene conocer: SPF autentica el dominio oculto del Return-Path, no el From: visible, y deja de funcionar con el reenvío, porque la IP del servidor que reenvía no está en tu registro. Justo por eso DMARC no depende solo de SPF.
DKIM: una firma que nadie puede alterar sin que se note
DKIM firma cada mensaje saliente con una clave privada que guarda tu sistema de envío y publica la clave pública correspondiente en el DNS. La firma cubre las cabeceras elegidas y el cuerpo, así que si algo se modifica en tránsito, la firma deja de validarse. Los receptores encuentran la clave mediante un selector: una cabecera DKIM-Signature lleva s= (el selector) y d= (tu dominio), y el verificador consulta selector._domainkey.yourdomain para obtener la clave pública (RFC 6376, sección 3.6.2.1). Los selectores también te permiten tener varias claves a la vez, y eso es lo que hace limpia la rotación: publicas un selector nuevo, pasas la firma a él y luego retiras el antiguo (un valor de clave vacío lo marca como revocado). En cuanto a la longitud de clave, RFC 6376 exige claves RSA de al menos 1024 bits para un uso prolongado, y los verificadores deben admitir claves de hasta 2048 bits; 2048 bits es el valor por defecto sensato hoy, y rotar las claves de forma periódica limita el daño si alguna llega a filtrarse.
DMARC: la política que lo une todo
DMARC es el registro que da sentido a SPF y DKIM para el dominio que lee tu destinatario. Su idea central es la alineación. Un mensaje supera DMARC solo cuando SPF o DKIM da un pass y ese pass se basa en un identificador alineado con el dominio From: visible (RFC 7489, sección 4.2). Por eso un mensaje puede superar SPF a secas y aun así fallar DMARC: si tu ESP (proveedor de envío de email) envía con su propio dominio de Return-Path, SPF da pass para el ESP, pero ese dominio no está alineado con tu From:, así que la parte SPF de DMARC falla. La alineación tiene dos modos: relaxed, que acepta un dominio organizativo coincidente (mail.yourco.com se alinea con yourco.com), y strict, que exige una coincidencia exacta. Como basta con cualquiera de los dos mecanismos alineados, la alineación DKIM suele sostener el correo que SPF no puede, como los mensajes reenviados. El registro en sí dice v=DMARC1; p=none; rua=mailto:reports@yourco.com; la etiqueta p fija la política (none, quarantine o reject), rua indica adónde se envían los informes agregados y sp define una política aparte para los subdominios, que por defecto toma tu valor de p si la omites.
Por qué pasó a ser obligatorio en 2024
La autenticación solía ser una buena práctica opcional. En febrero de 2024 se convirtió en un filtro. Gmail y Yahoo exigen ahora a los remitentes masivos —Google cuenta como tal a quien envía más de 5.000 mensajes al día a Gmail— que se autentiquen con SPF y DKIM y que publiquen un registro DMARC, que puede empezar en p=none. El correo de marketing y de suscripción también debe incluir la baja con un clic: la cabecera List-Unsubscribe (RFC 2369) más List-Unsubscribe-Post: List-Unsubscribe=One-Click, el mecanismo de un clic de RFC 8058, para que el cliente de correo del destinatario pueda darse de baja con un único POST HTTPS. Puedes leer las reglas completas de Gmail y Yahoo en la guía general de entregabilidad. Dos cosas a tener en cuenta: la aplicación de las reglas se ha endurecido desde 2024, así que cúmplelas aunque envíes menos de 5.000 al día, y mantener bajas las quejas por spam es un requisito al mismo nivel que la autenticación, no un extra.
Errores comunes que rompen la autenticación sin avisar
- Publicar +all en tu registro SPF, lo que autoriza a todo internet a enviar como tú: justo lo contrario de lo que se busca.
- Tener más de un registro v=spf1 en el mismo dominio, lo que devuelve permerror y anula SPF.
- Pasarte del límite de diez consultas DNS a medida que añades includes de proveedores, lo que también devuelve permerror.
- Una clave DKIM demasiado corta o que nunca se rota, de modo que una clave filtrada o descifrada por fuerza bruta sigue firmando indefinidamente.
- Saltar directamente a p=reject sin haber leído un solo informe agregado, lo que bloquea correo legítimo que habías olvidado que envías.
- Olvidar sp= para los subdominios, de modo que una política laxa deja marketing.yourco.com expuesto a la suplantación.
- Un remitente de terceros —un ESP, una herramienta de facturación, un servicio de soporte— que nunca alineaste con SPF y DKIM, así que su correo falla DMARC.
Dónde encaja la autenticación en tu stack
La autenticación es la base sobre la que se apoya todo lo demás. Si autoalojas, el DNS y las claves de firma son totalmente tuyos, que es la forma más sólida de controlar tu propia identidad como remitente. Una plataforma de customer engagement debería mostrar el estado de autenticación y alineación de cada dominio de envío en lugar de ocultarlo, para que veas de un vistazo qué fuentes lo superan. Envía el correo transaccional y el de marketing por flujos separados e, idealmente, por subdominios separados, para que un pico de quejas de marketing nunca ponga en riesgo la entrega de los restablecimientos de contraseña. Y haz el trabajo en el orden correcto: la autenticación y la alineación van primero, antes de calentar el dominio. Calentar un dominio sin autenticar solo enseña a los proveedores a desconfiar de ti más rápido.