Saltar al contenido principal

Autenticación de correo - SPF, DKIM y DMARC

Lectura de 2 min aprox.

La autenticación de correo electrónico es un mecanismo que combina tres protocolos, SPF, DKIM y DMARC, para verificar que el dominio remitente de un correo es legítimo. El protocolo de correo (SMTP) ha facilitado la suplantación del remitente desde su diseño original en 1982, convirtiéndose en un caldo de cultivo para el phishing y el fraude del correo corporativo. En febrero de 2024, Google y Yahoo hicieron obligatoria la configuración de SPF/DKIM/DMARC para los remitentes masivos, transformando la autenticación de correo de una práctica «recomendada» en una infraestructura «obligatoria».

Las funciones de los tres protocolos

SPF (Sender Policy Framework)

Enumera en un registro TXT de DNS las direcciones IP autorizadas a enviar correo desde este dominio. El servidor receptor verifica si la IP remitente está incluida en el registro SPF y, de no estarlo, considera el origen ilegítimo. Es un mecanismo que verifica el remitente del sobre (Return-Path).

DKIM (DomainKeys Identified Mail)

El servidor remitente adjunta una firma digital al encabezado y al cuerpo del correo. El servidor receptor verifica la firma con una clave pública publicada en DNS, confirmando que el correo no ha sido alterado y que se envió desde un dominio legítimo. Cumple una función parecida al sello de lacre de una carta.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

A partir de los resultados de verificación de SPF y DKIM, define una política sobre cómo tratar los correos que fallan la autenticación. Hay tres niveles: none (solo supervisión), quarantine (cuarentena) y reject (rechazo). Además, dispone de la función de enviar informes de los resultados de autenticación a los administradores del dominio.

Visión general del flujo de autenticación

El servidor remitente adjunta la firma DKIM
El servidor receptor verifica SPF (cotejo de IP)
Verifica la firma DKIM (cotejo de clave pública)
Decide el tratamiento según la política DMARC

La obligación de 2024 de Google / Yahoo

A partir de febrero de 2024, Google y Yahoo hicieron obligatorio lo siguiente para los dominios que envían más de 5.000 mensajes al día.

  • Aprobar SPF o DKIM (todos los remitentes)
  • Aprobar tanto SPF como DKIM y establecer una política DMARC (remitentes masivos)
  • Incluir un enlace de cancelación de suscripción con un clic (correos de marketing)
  • Mantener la tasa de quejas por spam por debajo del 0,3%

Como consecuencia de esta obligación, los correos de dominios que no han configurado la autenticación de correo ahora se clasifican en la carpeta de spam en Gmail y Yahoo Mail o se rechazan directamente. También desde la perspectiva de las medidas contra el phishing, configurar la autenticación de correo es una defensa básica que protege la credibilidad de una organización.

BIMI - El auge de la visualización del logotipo de marca

BIMI (Brand Indicators for Message Identification) es un mecanismo que permite a los dominios que ya han establecido una política de enforcement de DMARC (quarantine o reject) mostrar su logotipo de marca en la bandeja de entrada. Gmail, Apple Mail y Yahoo Mail lo admiten. Como se muestra el logotipo, los destinatarios pueden juzgar visualmente que un correo es legítimo, lo que mejora la resistencia frente al spear phishing. La adopción de BIMI requiere obtener un VMC (Verified Mark Certificate), que cuesta varios cientos de miles de yenes al año, por lo que actualmente lo usan sobre todo las grandes empresas y las organizaciones que dan prioridad a la protección de su marca.

Errores de configuración y trampas frecuentes

  • Las búsquedas DNS del registro SPF superan las 10. Cuando se usan muchos servicios externos, la cadena de directivas include alcanza el límite y SPF deja de funcionar
  • La longitud de la clave DKIM permanece en 1024 bits. Se recomiendan 2048 bits o más, y algunos servidores receptores consideran débil una firma de 1024 bits
  • Dejar la política DMARC en p=none. Es eficaz como fase de supervisión, pero como no rechaza realmente los correos no aporta efecto defensivo. Conviene analizar los informes y migrar gradualmente de p=quarantine a p=reject
  • SPF se rompe al reenviar el correo. Como la IP del servidor de reenvío no está incluida en el registro SPF original, a veces es necesario configurar ARC (Authenticated Received Chain)

Consultar también los artículos sobre la protección de cuentas de correo y el phishing generado por IA te dará una visión completa de la seguridad del correo electrónico.libros sobre seguridad del correo (Amazon) también son recomendables para aprender los detalles de implementación.

Términos relacionados

¿Te resultó útil este artículo?

XHatena