Autenticación SPF: Una Visión General y Mejores Prácticas
Pájaro
19 dic 2016
Correo electrónico
1 min read
Puntos clave
SPF (Sender Policy Framework) es un protocolo de autenticación de correo electrónico basado en rutas que verifica si el servidor de envío está autorizado para enviar correo para un dominio.
Las políticas SPF residen como registros DNS TXT, formateados con mecanismos que definen qué servidores, IP o redes están permitidos para enviar en nombre de un dominio.
La validación SPF está vinculada al dominio Return-Path (dominio de rebote) o al hostname HELO, no a la dirección visible de From.
Debido a que SPF verifica solo la ruta de envío, puede ser validado temprano en la transacción SMTP, siendo útil para rechazar rápidamente el correo no autorizado.
SPF es efectivo pero no perfecto—es propenso a falsos negativos, especialmente con el reenvío de correo y listas de correo.
Los registros SPF dependen de mecanismos como
mx,a,ipv4,ipv6,include,redirect,exists, y deben terminar con un modificadorall(-all,~all,?all,+all).Se aplican límites de búsqueda DNS: la evaluación SPF no puede exceder 10 consultas DNS, lo que hace importante la planificación de registros.
El mecanismo
ptrahora se considera “no usar”, pero los validadores aún deben aceptarlo. Algunos remitentes todavía lo usan debido a las brechas de compatibilidad.SPF por sí solo no garantiza que un correo electrónico sea legítimo—solo que fue enviado desde un servidor autorizado. Funciona mejor cuando se combina con DKIM, DMARC y otras técnicas antifraude.
Destacados de Q&A
¿Qué es SPF en términos simples?
SPF permite que un dominio declare qué servidores tienen permiso para enviar correos electrónicos en su nombre. Los servidores receptores verifican esto para detectar remitentes no autorizados.
¿Por qué se llama SPF “path-based”?
Debido a que SPF valida el path que siguió el mensaje, específicamente la IP del servidor de envío, en lugar de cualquier cosa en el contenido del mensaje.
¿Dónde se guarda una política SPF?
A: Como un registro DNS TXT, comenzando con
v=spf1, seguido de mecanismos que definen los remitentes permitidos.¿Qué dominio valida SPF?
El Return-Path (también llamado el dominio de rebote).
Si el Return-Path está vacío (remitente NULL), SPF verifica el dominio HELO en su lugar.
¿Se puede verificar SPF temprano en la transacción SMTP?
Sí. Porque depende solo de la IP y el dominio del servidor de envío, SPF se puede validar antes de recibir el cuerpo del mensaje, lo que lo hace eficiente para filtrar.
¿Por qué a veces falla SPF incluso para correos electrónicos legítimos?
Las causas comunes incluyen:
Reenvío de correo electrónico (el reenviador no está en el registro SPF del dominio original)
Listas de correo (los mensajes son reenviados por un servidor diferente)
Esto conduce a falsos negativos, que son inherentes a la autenticación basada en rutas.
¿Cuál es el papel de los mecanismos como include, redirect y exists?
include— autorizar el registro SPF de otro dominio (por ejemplo, tu ESP)redirect— reutilizar la política SPF de otro dominioexists— autorizar dinámicamente basado en una consulta DNS (útil para infraestructura compleja)
¿Cómo funcionan "all" modifiers?
-all→ rechazar cualquier cosa no listada (estricto)~all→ falla suave (aceptar pero marcar)?all → neutral+all→ pasar todo (efectivamente desactiva SPF)
¿Por qué se desaconseja el mecanismo ptr?
Es lento, poco fiable y obsoleto en la especificación moderna, pero los validadores SPF aún deben soportarlo.
¿Es SPF suficiente por sí solo para la autenticación de correo electrónico?
No. SPF verifica la infraestructura de envío, pero:
No protege la integridad del mensaje
No se alinea con los dominios visibles de From
Se rompe con el reenvío
SPF es más fuerte cuando se combina con DKIM y DMARC.
Antes de profundizar en la implementación técnica, vale la pena entender la evolución y variedad de técnicas de validación de email disponibles. Desde la comprobación de sintaxis simple hasta enfoques modernos basados en datos, los diferentes métodos de validación ofrecen niveles de precisión y fiabilidad diversos.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que está destinada a brindar al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente reclamada del mensaje. La idea es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, que podría erosionar la confianza del destinatario en recibir correos electrónicos. Para las organizaciones que requieren encriptación a nivel de mensaje más allá de la autenticación, S/MIME proporciona seguridad de extremo a extremo, con la colección automatizada de clave pública del destinatario haciendo la implementación más escalable. Dicho esto, el acto de enviar correo electrónico autenticado no, por sí solo, afirma que el correo electrónico es bueno o deseado; solo significa que el correo es tal que una reputación para la parte autenticada puede establecerse y usarse de manera confiable en las decisiones de aceptación y colocación de correo electrónico.
Hay 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 publicación del blog, explicaré qué es SPF y cómo funciona.
Antes de profundizar en la implementación técnica, vale la pena entender la evolución y variedad de técnicas de validación de email disponibles. Desde la comprobación de sintaxis simple hasta enfoques modernos basados en datos, los diferentes métodos de validación ofrecen niveles de precisión y fiabilidad diversos.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que está destinada a brindar al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente reclamada del mensaje. La idea es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, que podría erosionar la confianza del destinatario en recibir correos electrónicos. Para las organizaciones que requieren encriptación a nivel de mensaje más allá de la autenticación, S/MIME proporciona seguridad de extremo a extremo, con la colección automatizada de clave pública del destinatario haciendo la implementación más escalable. Dicho esto, el acto de enviar correo electrónico autenticado no, por sí solo, afirma que el correo electrónico es bueno o deseado; solo significa que el correo es tal que una reputación para la parte autenticada puede establecerse y usarse de manera confiable en las decisiones de aceptación y colocación de correo electrónico.
Hay 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 publicación del blog, explicaré qué es SPF y cómo funciona.
Antes de profundizar en la implementación técnica, vale la pena entender la evolución y variedad de técnicas de validación de email disponibles. Desde la comprobación de sintaxis simple hasta enfoques modernos basados en datos, los diferentes métodos de validación ofrecen niveles de precisión y fiabilidad diversos.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que está destinada a brindar al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente reclamada del mensaje. La idea es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, que podría erosionar la confianza del destinatario en recibir correos electrónicos. Para las organizaciones que requieren encriptación a nivel de mensaje más allá de la autenticación, S/MIME proporciona seguridad de extremo a extremo, con la colección automatizada de clave pública del destinatario haciendo la implementación más escalable. Dicho esto, el acto de enviar correo electrónico autenticado no, por sí solo, afirma que el correo electrónico es bueno o deseado; solo significa que el correo es tal que una reputación para la parte autenticada puede establecerse y usarse de manera confiable en las decisiones de aceptación y colocación de correo electrónico.
Hay 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 publicación del 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.
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.
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"
SPF se considera un sistema de autenticación basado en rutas porque está vinculado únicamente a la ruta que el mensaje tomó desde su origen hasta su destino. Cuando un servidor de envío inicia una transacción SMTP con un servidor de recepción, el servidor de recepción determinará si el servidor de envío está autorizado a enviar ese mensaje basado en la política SPF del dominio. Es únicamente una decisión basada en de dónde viene el mensaje, sin tener nada que ver con el contenido del mensaje.
SPF se considera un sistema de autenticación basado en rutas porque está vinculado únicamente a la ruta que el mensaje tomó desde su origen hasta su destino. Cuando un servidor de envío inicia una transacción SMTP con un servidor de recepción, el servidor de recepción determinará si el servidor de envío está autorizado a enviar ese mensaje basado en la política SPF del dominio. Es únicamente una decisión basada en de dónde viene el mensaje, sin tener nada que ver con el contenido del mensaje.
SPF se considera un sistema de autenticación basado en rutas porque está vinculado únicamente a la ruta que el mensaje tomó desde su origen hasta su destino. Cuando un servidor de envío inicia una transacción SMTP con un servidor de recepción, el servidor de recepción determinará si el servidor de envío está autorizado a enviar ese mensaje basado en la política SPF del dominio. Es únicamente una decisión basada en de dónde viene el mensaje, sin tener nada que ver con el contenido del mensaje.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
