Cuando hablamos de “Autenticación de Email”, nos referimos a una técnica que está destinada a proporcionar al destinatario de un mensaje un cierto nivel de certeza de que el mensaje realmente se originó con la fuente declarada del mensaje. La idea es lograr un cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, que podría erosionar la confianza de un destinatario al recibir correos electrónicos. Dicho esto, el acto de enviar un correo electrónico autenticado no afirma, por sí mismo, que el correo electrónico sea bueno o deseado; solo significa que el correo es tal que una reputación para la parte autenticada puede establecerse de manera confiable y usarse en decisiones de aceptación y colocación de correo electrónico.
Hoy en día, hay dos formas principales de autenticación de correo electrónico en uso: Sender Policy Framework (SPF) y DomainKeys Identifed Mail (DKIM). En esta publicación del blog, explicaré qué es SPF y cómo funciona.
Descripción General de SPF
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 forma en que un host receptor puede 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 la ruta”.
Las políticas de SPF se declaran en registros DNS TXT.
La validación se basa en el dominio de Return-Path (lo que aquí en SparkPost llamamos el “dominio de rebote”) o el dominio HELO.
La validación se puede realizar temprano en la transacción SMTP, por lo que es una buena verificación para rechazar rápidamente el correo no autenticado.
Es propenso a un porcentaje relativamente alto de falsos negativos.
Autenticación “Basada en la Ruta”
SPF se considera un sistema de autenticación basado en la ruta porque está vinculado únicamente a la ruta que tomó el mensaje para ir desde su origen a su destino. Cuando un servidor de envío inicia una transacción SMTP con un servidor receptor, el servidor receptor determinará si el servidor de envío está autorizado o no para enviar ese mensaje en función de la política SPF del dominio. Es únicamente una decisión basada en de dónde proviene el mensaje, sin tener nada que ver con el contenido del mensaje.
Declarando una Política SPF
El registro de la política SPF de un dominio es solo un registro DNS TXT específicamente formateado, que comúnmente contiene uno o más de los siguientes “mecanismos”:
v=spf1 – Token requerido primero para indicar que el registro TXT es un registro SPF (un dominio puede tener múltiples registros TXT)
ipv4, ipv6 – Usado para especificar direcciones IP y redes que están permitidas para enviar correo para el dominio
a – Si el dominio de envío tiene un registro DNS “A” que se resuelve a la IP de envío, la IP está permitida
mx – Si la IP de envío también es uno de los registros MX para el dominio de envío, la IP está permitida
all – Token requerido al final, siempre modificado:
-all – Solo lo que está listado aquí puede pasar; rechazar fracasos.
~all – Las cosas que no están aquí deben fallar suavemente; aceptarlas pero anotarlas.
?all – No estoy seguro de si las cosas que no están aquí deben pasar.
+all – Creemos que SPF es inútil; pasar todo.
Otros mecanismos menos comunes que aún están en uso generalizado son:
include – Se utiliza cuando un dominio no solo tiene sus propios servidores, sino que también utiliza los servidores de otra persona. Debe utilizarse con juicio. Cada inclusión 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 utilizan 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 utilizó para declarar que, si la dirección IP de envío tenía un registro DNS PTR 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 usarse. Sin embargo, los sitios que realizan validación SPF deben aceptar esto como válido.
Algunos Registros SPF de Ejemplo
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, suave todo lo demás:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Registro A, 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 estúpido:
“v=spf1 +all”
El registro SPF para el dominio sparkpostmail.com (mecanismo de redirección utilizado)
“v=spf1 redirect=_spf.sparkpostmail.com”
El registro SPF para _spf.sparkpostmail.com (existen y ptr mecanismos utilizados):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
En SparkPost, actualmente estamos utilizando el mecanismo ptr en nuestro registro SPF. Hemos encontrado que es necesario debido a la falta de soporte universal para validar el mecanismo exists. Y hasta la fecha, no hemos visto fallos de SPF como resultado del uso del mecanismo ptr.
¿Cómo Funciona la Autenticación SPF?
Aquí está cómo se ve una transacción SMTP típica cuando SPF está involucrado:
El servidor de envío (cliente) se conecta al servidor receptor
El servidor receptor nota la dirección IP de conexión del cliente
Intercambian saludos, incluido el nombre de host HELO del cliente
El cliente emite el comando SMTP MAIL FROM
El servidor receptor ahora puede buscar el registro SPF ya sea para el dominio MAIL FROM o para el nombre de host HELO para determinar si la IP de conexión está autorizada para enviar correo para el dominio y decidir si aceptar o no el mensaje.
MAIL FROM o HELO – ¿Cuál Verificar?
La especificación de 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 momentos en que la dirección MAIL FROM es el remitente NULL (es decir, “<>”), en cuyo caso el nombre de host HELO es la única identidad disponible.
SPF No Es Infalible
Aunque parece una forma relativamente sencilla de autenticar el correo electrónico, SPF es vulnerable a fallas en forma de falsos negativos. Estas fallas pueden ocurrir con más frecuencia de lo que muchos están cómodos.
Aquí hay dos escenarios comunes donde el correo perfectamente legítimo puede fallar la validación de 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 cambia desde el original, el correo puede fallar las verificaciones de SPF (dependiendo del modificador utilizado con el mecanismo ‘all’). Esto se debe a que llega a su destino final desde un servidor intermedio, no desde el original, y ese servidor intermedio es poco probable que esté en el registro SPF del dominio. Una técnica llamada “Esquema de Reescritura de Remitente” o “SRS” puede mitigar este riesgo, y algunos sitios más grandes lo han adoptado, pero no es universal.
Conclusión
Así que eso es la autenticación SPF, cómo funciona, cómo declarar una política SPF y cuáles son las trampas de 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 contra el fraude.