Cuando hablamos de "Autenticación por Email", nos referimos a una técnica que está destinada a proporcionar al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente reclamada del mensaje.
Business in a box.
Descubre nuestras soluciones.
Habla con nuestro equipo de ventas
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que tiene como objetivo proporcionar al destinatario de un mensaje un cierto nivel de certeza de que el mensaje realmente se originó en la fuente declarada del mensaje. La idea es lograr cierto nivel de defensa contra correos electrónicos fraudulentos, como el phishing y la suplantación, que podrían erosionar la confianza de un destinatario al recibir correos electrónicos. Dicho esto, el acto de enviar correos electrónicos autenticados no afirma, por sí mismo, que el correo electrónico sea bueno o deseado; solo significa que el correo es tal que se puede establecer y usar de manera confiable una reputación para la parte autenticada en las decisiones de aceptación y ubicación del correo electrónico.
Existen dos formas principales de autenticación de correo electrónico en uso hoy en día—Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM). En esta entrada de blog, explicaré qué es SPF y cómo funciona.
SPF Overview
Sender Policy Framework (SPF), parafraseando RFC 7208, es un protocolo que no solo permite a una organización autorizar hosts y redes para usar sus nombres de dominio al enviar correos electrónicos, sino que también proporciona una manera para que un host receptor pueda verificar esa autorización.
Cuando termines de leer esta publicación, espero que hayas aprendido lo siguiente:
SPF es un sistema de autenticación basado en "rutas".
Las políticas de SPF se declaran en registros DNS TXT.
La validación está vinculada al dominio Return-Path (lo que aquí en SparkPost llamamos el "bounce domain") o al dominio HELO.
La validación se puede realizar al principio de la transacción SMTP, por lo que es una buena verificación para usar y rechazar rápidamente el correo no autenticado.
Es propenso a un porcentaje relativamente alto de falsos negativos.
Autenticación basada en "Path-Based"
Declarar una política SPF
El registro de la política SPF de un dominio es simplemente un registro DNS TXT específicamente formateado, que comúnmente contiene uno o más de los siguientes “mecanismos”:
v=spf1 – Primer token requerido para indicar que el registro TXT es un registro SPF (un dominio puede tener múltiples registros TXT)
ipv4, ipv6 – Se utiliza para especificar direcciones IP y redes que están permitidas para enviar correo para el dominio
a – Si el dominio remitente tiene un registro DNS “A” que resuelve a la IP remitente, se permite la IP
mx – Si la IP remitente es también uno de los registros MX para el dominio remitente, se permite la IP
all – Último token requerido, siempre modificado:
-all – Solo lo que se enumera aquí puede pasar; rechazar fallos.
~all – Lo que no está aquí debería fallar suavemente; acéptalo pero tómalo en cuenta.
?all – No estamos seguros si lo que no está aquí debería pasar.
+all – Creemos que SPF es inútil; pasa todo.
Otros mecanismos menos comunes que aún son de uso generalizado son:
include – Se usa cuando un dominio no solo tiene sus propios servidores, sino que también utiliza los servidores de otra persona. Debe usarse con moderación. Cada include es otra consulta DNS, y los registros SPF no pueden requerir más de diez consultas DNS para resolverse.
redirect – Cuando el dominio A y el dominio B son propiedad de la misma entidad y usan la misma infraestructura. Los propietarios generalmente desean mantener solo una copia del registro SPF para ambos, y configurar B para redirigir consultas a A.
exists – Si un dominio tiene muchos bloques de red pequeños y no contiguos, puede usar este mecanismo para especificar su registro SPF, en lugar de enumerarlos todos. Útil para mantenerse dentro del límite de tamaño (512 bytes) para la respuesta DNS.
Una nota sobre el Mecanismo “ptr”
Un mecanismo final, “ptr” existía en la especificación original para SPF, pero ha sido declarado “no usar” en la especificación actual. El mecanismo ptr se usaba para declarar que si la dirección IP remitente tenía un registro PTR de DNS que se resolvía al nombre de dominio en cuestión, entonces esa dirección IP estaba autorizada para enviar correo para el dominio.
El estado actual de este mecanismo es que no debe ser usado. Sin embargo, los sitios que realizan la validación SPF deben aceptarlo como válido.
Algunos Example SPF Records
Aquí hay algunos registros de ejemplo y sus significados. Este ejemplo muestra direcciones RFC 1918, pero reconozco que tales direcciones nunca aparecerán en registros SPF reales.
Registro MX, una dirección IP, una red IP, fallo suave para todo lo demás:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Un registro, dos redes IP, rechazar todo lo demás:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
No enviamos correo:
“v=spf1 -all”
Creemos que SPF es tonto:
“v=spf1 +all”
El registro SPF para el dominio sparkpostmail.com (mecanismo de redirección usado)
“v=spf1 redirect=_spf.sparkpostmail.com”
El registro SPF para _spf.sparkpostmail.com (mecanismos de exists y ptr usados):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
En SparkPost, actualmente estamos usando el mecanismo ptr en nuestro registro SPF. Hemos encontrado necesario su uso debido a la falta de soporte universal para validar el mecanismo exists. Y hasta la fecha, no hemos visto fallos SPF debido a nuestro uso del mecanismo ptr.
¿Cómo funciona la autenticación SPF?
Así es como se ve una transacción SMTP típica cuando se involucra SPF:
El servidor emisor (cliente) se conecta al servidor receptor
El servidor receptor anota la dirección IP del cliente que se conecta
Intercambian saludos, incluyendo el nombre de host HELO del cliente
El cliente emite el comando SMTP MAIL FROM
El servidor receptor ahora puede buscar el registro SPF para el dominio MAIL FROM o el nombre de host HELO para determinar si la IP conectada está autorizada a enviar correo para el dominio, y decidir si aceptar o no el mensaje.
MAIL FROM o HELO – ¿Cuál comprobar?
La especificación SPF estipula que los sitios receptores DEBEN verificar SPF para el dominio MAIL FROM, y RECOMIENDAN verificarlo para el nombre de host HELO. En la práctica, la verificación solo ocurre en el dominio MAIL FROM, excepto quizás en aquellos casos en los que la dirección MAIL FROM es el remitente NULO (es decir, “<>”), en cuyo caso el nombre de host HELO es la única identidad disponible.
SPF No es infalible
Si bien parece una forma relativamente sencilla de autenticar el correo electrónico, SPF es vulnerable a fallos en forma de falsos negativos. Estos fallos pueden ocurrir con más frecuencia de la que muchos están cómodos.
Aquí hay dos escenarios comunes donde un correo perfectamente legítimo puede fallar la validación SPF y, por lo tanto, parecer fraudulento:
Reenvío automatizado, donde un mensaje enviado a jsmith@alumni.university.edu, un buzón configurado para reenviar automáticamente todo el correo a jsmith@isp.com
Listas de correo, donde el correo enviado a talk-about-stuff@listserv.foo.com se “explota” y se envía a cada suscriptor
En ambos casos, si el Return-Path no se modifica respecto a su original, el correo puede fallar las comprobaciones SPF (dependiendo del modificador usado con el mecanismo ‘all’). Esto se debe a que llega a su destino final desde un servidor intermedio, no desde el original, y es probable que ese servidor intermedio no esté en el registro SPF del dominio. Una técnica llamada “Sender Rewriting Scheme” o “SRS” puede mitigar este riesgo, y algunos sitios más grandes la han adoptado, pero no es universal.
Wrap Up
Así que esa es la autenticación SPF, cómo funciona, cómo declarar una política SPF y cuáles son las trampas al usar SPF. SPF fue el primer esquema de autenticación de correo electrónico en lograr una adopción generalizada, pero no es el único que existe. La autenticación SPF es más efectiva cuando se implementa en combinación con otras técnicas anti-fraude.
