← RFC Reference

Explicación de la Autenticación de Correo Electrónico

Cómo funcionan juntos SPF, DKIM, DMARC y ARC como un sistema — y qué sucede paso a paso cuando un mensaje llega a un servidor receptor.

Por qué el correo electrónico necesita autenticación

SMTP fue diseñado a principios de los años 80 sin verificación de remitente integrada. Cualquier servidor puede conectarse a cualquier otro servidor y afirmar que está enviando correo desde cualquier dirección. Esto no es un error — es cómo fue construido el protocolo.

La autenticación de correo electrónico es un conjunto de estándares superpuestos en SMTP para responder tres preguntas:

1. SPF: ¿Está autorizado este servidor para enviar correo para este dominio?
2. DKIM: ¿Fue este mensaje realmente enviado por el dominio reclamado, y está sin modificar?
3. DMARC: ¿Qué debo hacer si SPF y DKIM fallan — y algún resultado se alinea con el encabezado From:?

Cada mecanismo aborda una superficie de ataque diferente. Juntos, forman un sistema de defensa en profundidad.

SPF: Quién está autorizado para enviar

SPF (Marco de política del remitente, RFC 7208) permite que un dominio publique una lista de servidores autorizados para enviar correo en su nombre. Es un registro DNS TXT:

Cuando llega un mensaje, el servidor receptor extrae el dominio del MAIL FROM (remitente del sobre) y consulta DNS para el registro SPF. Comprueba si la dirección IP del servidor que se conecta coincide con cualquier mecanismo autorizado.

Resultados de evaluación de SPF:

• pass — La IP está explícitamente autorizada
• fail — La IP está explícitamente no autorizada (-all)
• softfail — La IP probablemente no está autorizada (~all) — aceptar pero marcar
• neutral — El dominio no hace aseveración sobre esta IP (?all)
• temperror / permerror — Búsqueda DNS falló o registro es malformado

Limitaciones de SPF

SPF valida el remitente del sobre, no el encabezado From: que ven los usuarios. Un suplantador puede pasar SPF usando su propio dominio en el sobre mientras falsifica tu dominio en el encabezado From:. SPF también se rompe cuando el correo es reenviado, porque la IP del servidor reenviador no está en el registro SPF del dominio original. Estas limitaciones son por qué SPF solo no es suficiente.

DKIM: Firma de mensaje criptográfica

DKIM (Correo identificado con claves de dominio, RFC 6376) agrega una firma digital al mensaje. El servidor de envío firma encabezados seleccionados y el cuerpo usando una clave privada. La clave pública correspondiente se publica en DNS:

La firma se agrega como un encabezado DKIM-Signature:

Campos clave de DKIM-Signature:

• d= — El dominio de firma (esto es lo que DMARC comprueba para alineación)
• s= — El selector, utilizado para buscar la clave pública en DNS
• h= — Qué encabezados se incluyen en la firma
• bh= — Hash del cuerpo del mensaje
• b= — La firma real
• c= — Algoritmo de canonicalización (relaxed/relaxed es estándar — tolera cambios menores de espacios en blanco)

El servidor receptor obtiene la clave pública de DNS, recomputa el hash sobre los encabezados y cuerpo firmados, y verifica la firma. Si coincide, el mensaje fue firmado por alguien con acceso a la clave privada para ese dominio, y el contenido firmado no ha sido alterado.

Limitaciones de DKIM

DKIM sobrevive al reenvío (a diferencia de SPF) porque la firma viaja con el mensaje. Sin embargo, listas de correo que modifican el Asunto o cuerpo romperán la firma. DKIM tampoco le dice al receptor qué hacer con una firma fallida — ese es el trabajo de DMARC.

DMARC: La capa de política

DMARC (Autenticación, informes y conformidad basados en dominio, RFC 7489) vincula SPF y DKIM juntos y agrega una política. Se publica como un registro DNS TXT en _dmarc.example.com:

DMARC introduce el concepto crítico de alineación — el dominio en el resultado de autenticación debe coincidir con el dominio en el encabezado From: que ve el usuario:

• Alineación SPF: El dominio en MAIL FROM debe coincidir (o ser un subdominio de) el dominio del encabezado From:, Y SPF debe pasar.
• Alineación DKIM: El dominio d= en una firma DKIM válida debe coincidir (o ser un subdominio de) el dominio del encabezado From:.

Un mensaje pasa DMARC si SPF o DKIM pasan con alineación. Ambos pueden fallar individualmente mientras uno tenga éxito con alineación.

Políticas DMARC

• p=none — Solo monitorear. No tomar acción en fallos. Usar esto mientras se implementa.
• p=quarantine — Tratar fallos como sospechosos (típicamente enrutar a carpeta de spam).
• p=reject — Rechazar mensajes que fallan DMARC. Este es el objetivo.

La etiqueta rua= especifica dónde se envían informes agregados — informes XML mostrando resultados de autenticación para todos los mensajes que reclaman tu dominio. Estos informes son esenciales para entender tu ecosistema de correo antes de endurecér la política.

Qué sucede cuando llega un mensaje

Aquí está la secuencia completa de autenticación, paso a paso, cuando mx.receiver.com recibe un mensaje que dice ser de alice@example.com:

1. Conexión: El servidor de envío se conecta desde la IP 198.51.100.42 y envía MAIL FROM:<bounce-123@sender.example.com>.
2. Comprobación SPF: El receptor consulta sender.example.com para su registro SPF. La IP 198.51.100.42 está listada → SPF pass. Pero el dominio del sobre es sender.example.com, y el encabezado From: dice example.com — estos no coinciden, así que no hay alineación SPF.
3. Mensaje recibido: La fase DATA entrega encabezados y cuerpo.
4. Comprobación DKIM: El receptor encuentra un encabezado DKIM-Signature con d=example.com; s=mtg. Obtiene la clave pública de mtg._domainkey.example.com, verifica la firma → DKIM pass. El dominio d= coincide con el encabezado From: → DKIM alineado.
5. Comprobación DMARC: El receptor obtiene _dmarc.example.com. La política es p=reject. SPF pasó pero no está alineado. DKIM pasó Y está alineado. Al menos un mecanismo pasa con alineación → DMARC pass.
6. Authentication-Results: El receptor registra el resultado en un encabezado:

Este encabezado (RFC 8601) es agregado por el servidor receptor y es el registro autoritativo de resultados de autenticación para ese salto.

ARC: Preservando autenticación a través de reenvío

ARC (Cadena de recepción autenticada, RFC 8617) resuelve el problema de reenvío. Cuando un mensaje pasa a través de un intermediario (como una lista de correo o servicio de reenvío), SPF se rompe (la IP del reenviador no está en el registro SPF original) y DKIM puede romperse (si la lista modifica el mensaje).

ARC funciona haciendo que cada intermediario registre los resultados de autenticación que observó antes de modificar el mensaje, luego firmando esos resultados. Agrega tres encabezados por salto:

• ARC-Authentication-Results (AAR): Los resultados de autenticación en este salto
• ARC-Message-Signature (AMS): Una firma similar a DKIM del mensaje como estaba en este salto
• ARC-Seal (AS): Una firma sobre todos los encabezados ARC anteriores, encadenándolos juntos

Cada conjunto de encabezados está numerado (i=1, i=2, etc.), formando una cadena. El receptor final puede inspeccionar la cadena para ver que el mensaje originalmente pasó DMARC en el salto 1, aunque ahora falla porque un reenviador lo modificó en el salto 2.

ARC no anula DMARC. Proporciona evidencia que el receptor final puede elegir confiar. Es a discreción del receptor honrar los resultados de ARC.

Configuración común: Envío a través de un tercero

Cuando usas un servicio de correo transaccional como Mailer To Go para enviar correo como your-domain.com, necesitas configurar las tres capas:

El servicio de correo envía con tu dominio en el campo DKIM d=, asegurando alineación DKIM. La directiva SPF include: autoriza sus servidores. DMARC los vincula.

Qué puede salir mal

SPF demasiadas búsquedas DNS

SPF tiene un límite duro de 10 búsquedas DNS. Cada mecanismo include:, a:, mx:, y redirect= cuenta como una búsqueda. Los includes anidados cuentan hacia el total. Si superas 10, la evaluación de SPF retorna permerror y DMARC lo trata como un fallo. Audita tu registro SPF con una herramienta validadora.

Fallos de rotación de clave DKIM

Si rotas tu clave DKIM (publicas una nueva clave pública) antes de que tu infraestructura de envío comience a usar la nueva clave privada, todos los mensajes en vuelo fallarán la verificación DKIM. Siempre publica la nueva clave primero, espera la propagación DNS, cambia a la nueva clave privada, luego elimina la clave pública antigua después de un período de gracia.

Desajuste de alineación DMARC

Tu SPF pasa y tu DKIM pasa, pero DMARC aún falla. Esto sucede cuando ningún resultado se alinea con el encabezado From:. Por ejemplo, SPF valida bounces.esp.com (el remitente del sobre) pero el encabezado From: dice your-domain.com. La solución: asegura que DKIM firme con d=your-domain.com.

Correo reenviado rechazado

Un usuario reenvía su correo old@example.com a new@gmail.com. Tu mensaje pasa DMARC en el servidor original, pero Gmail ve la IP del servidor reenviador (falla SPF) y el mensaje puede ser modificado (falla DKIM). Con p=reject, la copia reenviada es rechazada. ARC puede ayudar, pero la adopción varía.

Brechas de política de subdominio

Publicas p=reject en _dmarc.example.com, pero un suplantador envía desde billing.example.com, que no tiene registro DMARC. Sin sp=reject (política de subdominio) en tu registro DMARC, el subdominio hereda la política organizacional — pero solo si no hay un registro separado. Establece explícitamente sp=reject o publica registros DMARC para todos los subdominios.

Puntos clave

• SPF comprueba la IP del servidor de envío contra DNS. Valida el remitente del sobre, no el encabezado From:.
• DKIM firma criptográficamente el mensaje. Sobrevive al reenvío (a menos que el mensaje sea modificado) y valida el dominio de firma.
• DMARC requiere que SPF o DKIM pasen con alineación al encabezado From:. Publica una política para qué hacer en caso de fallo.
• ARC preserva evidencia de autenticación a través de saltos de reenvío.
• Necesitas los tres (SPF, DKIM, DMARC) configurados correctamente. Cualquiera solo tiene brechas explotables.
• Comienza con p=none, lee tus informes agregados DMARC, luego progresa a p=reject.

Lectura adicional

Related RFCs