SPF, DKIM y DMARC: guía completa de autenticación de correo

El correo electrónico se diseñó en una época en la que nadie esperaba que la dirección del remitente fuera mentira. Nada en el protocolo original impide que una máquina cualquiera de internet se conecte a un servidor de correo y afirme ser tú. Esa carencia es la razón de que el phishing funcione, y por la que hoy tres estándares basados en DNS, SPF, DKIM y DMARC, deciden si tu correo llega a la bandeja de entrada o a la carpeta de spam.

Los tres viven en los registros DNS de tu dominio, así que puedes inspeccionar la configuración de autenticación de cualquier dominio, incluido el tuyo, con una simple búsqueda de DNS. Esta guía explica qué hace cada registro, cómo leerlo y cómo llegar a una política DMARC estricta sin bloquear por accidente tus propias facturas.

Para revisar los tres registros a la vez, incluido el número de consultas SPF y el tamaño de tu clave DKIM, usa nuestro comprobador de SPF, DKIM y DMARC.

Por qué importa la autenticación de correo

Dos cosas han cambiado en los últimos años. Los atacantes son mucho mejores suplantando marcas de confianza, y los grandes proveedores de buzones han respondido haciendo la autenticación prácticamente obligatoria. Gmail y Yahoo exigen ya SPF, DKIM y DMARC a quien envía en volumen, y Microsoft ha seguido el mismo camino. Si tus registros faltan o están rotos, las consecuencias son inmediatas y muy prácticas:

• Tu correo se filtra. Los mensajes sin autenticar acaban en cuarentena con mucha más frecuencia, y a veces se rechazan antes de llegar a ningún buzón.
• Cualquiera puede suplantar tu dominio. Sin una política DMARC, el servidor receptor no tiene ninguna instrucción para rechazar el correo falsificado que usa tu nombre.
• No ves los abusos. Los informes de DMARC son la única forma de enterarte de que alguien envía phishing en tu nombre.
• Se frenan los contratos. Los cuestionarios de seguridad y las revisiones de proveedores piden una política DMARC, y «none» se considera cada vez más un hallazgo.

Los tres registros de un vistazo

Son capas, no alternativas. SPF comprueba el servidor que envía, DKIM comprueba el mensaje, y DMARC conecta ambos con el dominio que la persona ve realmente en la cabecera From y dice qué hacer si fallan. Necesitas los tres.

SPF: quién puede enviar por tu dominio

Sender Policy Framework es una lista pública de los servidores autorizados a enviar correo por tu dominio. El servidor receptor toma la dirección IP que se ha conectado, consulta tu registro SPF y comprueba si esa dirección está en la lista.

Cómo leer un registro SPF

Un registro típico tiene este aspecto:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Se lee de izquierda a derecha. v=spf1 es la versión y debe ir primero. Cada include: incorpora el registro SPF de otro dominio, que es la forma de autorizar a un proveedor como Google Workspace o un servicio de correo transaccional. ip4: e ip6: autorizan direcciones o rangos concretos, normalmente tu propio servidor. El último mecanismo es el comodín, y es el que más gente equivoca:

• -all es un fallo duro. Todo lo que no esté listado no está autorizado y se espera que el receptor lo rechace.
• ~all es un fallo suave. Los remitentes no listados resultan sospechosos pero se aceptan, con penalización de spam.
• ?all es neutro y no le dice nada al receptor, lo que anula el sentido de publicar el registro.

Empieza con ~all mientras confirmas que todos los remitentes legítimos están en la lista y pasa a -all cuando tus informes DMARC estén limpios.

El límite de diez consultas

SPF permite como máximo diez consultas DNS al evaluar un registro. Cuentan todos los include:, a, mx y redirect, también los que estén anidados. Si te pasas, el resultado es un error permanente, que la mayoría de receptores trata como si no hubiera SPF. Con tres o cuatro proveedores de correo ya suele superarse, así que revisa el registro cada vez que añadas un servicio de envío y elimina los proveedores que hayas dejado de usar.

Hay otra regla que sorprende: un dominio solo puede publicar un registro SPF. Dos registros TXT con v=spf1 en el mismo nombre son un error permanente, no una fusión.

DKIM: firmar tu correo

DomainKeys Identified Mail añade una firma criptográfica a cada mensaje saliente. Tu servidor guarda una clave privada y firma determinadas cabeceras más el cuerpo; la clave pública correspondiente se publica en DNS. El receptor recupera la clave pública, verifica la firma y aprende dos cosas: que el mensaje lo firmó realmente tu dominio y que nada de lo firmado se ha modificado por el camino.

La clave pública vive en un nombre construido a partir de un selector, por ejemplo google._domainkey.example.com o s1._domainkey.example.com. Los selectores existen para que puedas tener varias claves a la vez, y eso hace que rotarlas sea indoloro: publica un selector nuevo, cambia la firma a él y retira el antiguo más tarde.

Como la firma viaja con el mensaje, DKIM sobrevive a los reenvíos en casos en los que SPF no. Si una lista de correo retransmite tu mensaje, la IP que conecta cambia y SPF falla, pero la firma DKIM sigue siendo válida mientras la lista no reescriba las cabeceras firmadas ni el cuerpo. Esa resistencia es el motivo principal por el que DKIM importa aunque ya tengas SPF.

DMARC: decirle al receptor qué hacer

SPF y DKIM producen cada uno un «pasa» o un «falla», pero ninguno dice qué debe hacer el receptor, y ninguno mira la dirección From que lee realmente tu destinatario. DMARC cubre las dos lagunas. Un registro tiene este aspecto:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= es la política: none (solo monitorizar), quarantine (tratar los fallos como spam) o reject (rechazarlos en la puerta). rua= es la dirección que recibe los informes agregados diarios, y es la parte más valiosa del registro. pct= permite aplicar la política a un porcentaje del correo durante el despliegue.

La alineación, lo que casi todos pasan por alto

DMARC no exige solo que SPF o DKIM pasen. Exige que el dominio que pasa esté alineado con el dominio de la cabecera From visible. Un mensaje puede pasar SPF para mailer.vendor.com y aun así fallar DMARC para example.com, porque ambos no coinciden. Esta es, con diferencia, la causa más habitual de que una configuración aparentemente correcta siga fallando.

adkim y aspf controlan lo estricta que debe ser la coincidencia. Relajada (r, la opción por defecto) acepta un subdominio como mail.example.com; estricta (s) exige una coincidencia exacta. Empieza en relajada. DMARC pasa si cualquiera de SPF o DKIM pasa y está alineado, así que basta con una firma DKIM alineada.

Cómo aplicar una política sin riesgos

1. Publica p=none con una dirección de informes. Nada cambia en tu flujo de correo, pero empiezan a llegar informes.
2. Lee los informes durante dos a cuatro semanas. Revelarán servicios de envío que habías olvidado: el CRM, el servicio de soporte, la herramienta de facturación, la vieja plataforma de marketing.
3. Cierra las lagunas. Añade cada remitente legítimo a SPF, activa la firma DKIM con un dominio alineado y confirma el cambio en el informe siguiente.
4. Pasa a p=quarantine. Usa pct= para subir poco a poco si envías mucho volumen.
5. Termina en p=reject. Solo cuando los informes no muestren correo legítimo fallando. Esta es la política que de verdad detiene la suplantación.

Cómo comprobar tus propios registros

Los tres registros son registros TXT públicos, así que comprobarlos lleva segundos:

1. SPF. Haz una consulta TXT sobre tu dominio sin subdominio con la herramienta de búsqueda de DNS y localiza la cadena que empieza por v=spf1. Confirma que hay exactamente una y cuenta las consultas.
2. DMARC. Haz una consulta TXT sobre _dmarc. más tu dominio. Si no vuelve nada, no tienes ni política ni informes.
3. DKIM. Haz una consulta TXT sobre selector._domainkey. más tu dominio. La documentación de tu proveedor indica el selector que utiliza.
4. Verifica de extremo a extremo. Envía un mensaje a una cuenta de un gran proveedor e inspecciona las cabeceras recibidas. La vista «Mostrar original» de Gmail informa de los resultados de SPF, DKIM y DMARC del mensaje que acabas de enviar, y es la única prueba que cubre toda la cadena.

Ya que estás en DNS, conviene confirmar el resto de tu configuración de correo: comprueba que tus registros MX apuntan donde esperas y que el nombre del certificado de tu servidor coincide, algo que puedes verificar con el verificador de certificados SSL.

Errores habituales que debes evitar

• Dos registros SPF. Únelos en uno. Dos son un error permanente.
• Dejar DMARC en p=none para siempre. Monitorizar es el punto de partida, no el destino. Solo quarantine o reject evitan la suplantación.
• No poner dirección de informes. Un registro DMARC sin rua= tira a la basura la información que necesitas para endurecer la política con seguridad.
• Olvidar los dominios aparcados. Los dominios que no envían correo deberían publicar v=spf1 -all y p=reject, precisamente porque los atacantes prefieren los dominios sin uso.
• Saltar directamente a la alineación estricta. Poner adkim=s y aspf=s antes de tener informes limpios romperá correo legítimo enviado desde subdominios.
• Ignorar el TTL. Un TTL alto en un registro TXT hace que una corrección tarde horas en propagarse. Bájalo antes de una migración y súbelo después.

Autentica tu correo hoy mismo

La autenticación de correo es una de las pocas tareas de seguridad con un beneficio inequívoco: mejor entregabilidad, visibilidad sobre los abusos y un dominio que no se puede suplantar a la ligera. Además es totalmente legible desde fuera, así que no hay motivo para adivinar tu propia configuración. Empieza con una consulta TXT sobre tu dominio usando la herramienta gratuita de búsqueda de DNS, lee lo que hay publicado realmente y recorre el despliegue anterior paso a paso.

Herramientas y guías relacionadas:

• Búsqueda de DNS: consulta registros TXT, MX, SPF y cualquier otro de cualquier dominio.
• Búsqueda de DNS: guía completa: todos los tipos de registro explicados.
• Verificador de certificados SSL: inspecciona el certificado de tu servidor de correo o web.
• Códigos de estado HTTP: referencia rápida de todos los códigos de respuesta.
• Por qué tu registro SPF falla una y otra vez (y cómo arreglarlo) - el límite de diez consultas, los include rotos y otras causas de fallo de SPF.

Preguntas frecuentes