Hispanopedia Wiki
Articulo de referencia

Marco de políticas del remitente

Sender Policy Framework ( SPF ) es un método de autenticación de correo electrónico que permite comprobar si el servidor de correo remitente está autorizado a originar correo de...

Hispanopedia WikiContenido en espanolLectura gratuita

Sender Policy Framework ( SPF ) es un método de autenticación de correo electrónico que permite comprobar si el servidor de correo remitente está autorizado a originar correo desde el dominio del remitente. [ 1 ] [ 2 ] Esta autenticación solo se aplica al remitente de correo electrónico que aparece en el campo "envelope from" durante la conexión SMTP inicial. Si el correo electrónico rebota, se envía un mensaje a esta dirección, [ 2 ] y para la transmisión posterior, normalmente aparece en el encabezado "Return-Path". Para autenticar la dirección de correo electrónico que realmente ven los destinatarios en la línea "From:", deben utilizarse otras tecnologías, como DMARC . La falsificación de esta dirección se conoce como suplantación de correo electrónico , [ 3 ] y se utiliza a menudo en el phishing y el spam .

La lista de hosts y direcciones IP autorizados para enviar correos electrónicos a un dominio se publica en los registros DNS de dicho dominio. El Sender Policy Framework se define en el RFC 7208, de abril de 2014, como un "estándar propuesto".

Historia

La primera mención pública del concepto fue en 2000, pero pasó prácticamente desapercibida. [ 4 ] No se volvió a mencionar el concepto hasta que Dana Valerie Reese publicó en 2002 un primer intento de especificación similar a SPF en la lista de correo "namedroppers" de la IETF , [ 5 ] [ 3 ] [ 4 ] quien desconocía la mención de la idea en 2000. Al día siguiente, Paul Vixie publicó su propia especificación similar a SPF en la misma lista. [ 6 ] [ 4 ] Estas publicaciones despertaron mucho interés y llevaron a la formación del Grupo de Investigación Antispam de la IETF (ASRG) y su lista de correo, donde se desarrolló aún más la idea de SPF. Entre las propuestas presentadas al ASRG se encontraban "Reverse MX " (RMX) de Hadmut Danisch y "Designated Mailer Protocol" (DMP) de Gordon Fecyk. [ 7 ]

En junio de 2003, Meng Weng Wong fusionó las especificaciones RMX y DMP [ 8 ] y solicitó sugerencias a otros. Durante los siguientes seis meses, se realizaron numerosos cambios y una gran comunidad comenzó a trabajar en SPF. [ 9 ] Originalmente, SPF significaba Sender Permitted From y a veces también se le llamaba SMTP+SPF ; pero su nombre se cambió a Sender Policy Framework en febrero de 2004.

A principios de 2004, el IETF creó el grupo de trabajo MARID e intentó utilizar SPF y la propuesta CallerID de Microsoft como base para lo que ahora se conoce como Sender ID ; pero esto fracasó debido a conflictos técnicos y de licencias. [ 10 ]

La comunidad SPF volvió a la versión original "clásica" de SPF. En julio de 2005, esta versión de la especificación fue aprobada por el IESG como un experimento del IETF , invitando a la comunidad a observar SPF durante los dos años posteriores a su publicación. El 28 de abril de 2006, el RFC de SPF se publicó como RFC experimental 4408 [ 11 ] .

El 25 de abril de 2014, el IETF publicó SPF en RFC 7208 como un "estándar propuesto" que "dejó obsoleto" RFC 4408 y, a mayo de 2026, RFC 7208 no había quedado obsoleto [ 12 ] .

Principios de funcionamiento

Escenario de ejemplo

El Protocolo Simple de Transferencia de Correo (SMTP) permite que cualquier ordenador envíe correos electrónicos haciéndose pasar por cualquier dirección de origen. Esto es aprovechado por los spammers y estafadores, quienes a menudo utilizan direcciones de correo electrónico falsificadas , [ 13 ] lo que dificulta rastrear un mensaje hasta su origen y facilita que los spammers oculten su identidad para evitar responsabilidades. También se utiliza en técnicas de phishing , donde se puede engañar a los usuarios para que revelen información privada en respuesta a un correo electrónico supuestamente enviado por una organización como un banco.

SPF permite al propietario de un dominio de Internet especificar qué ordenadores están autorizados a enviar correo con direcciones de remitente en ese dominio, utilizando registros del Sistema de Nombres de Dominio (DNS). Los receptores que verifican la información SPF en los registros TXT pueden rechazar los mensajes de fuentes no autorizadas antes de recibir el cuerpo del mensaje. Por lo tanto, los principios de funcionamiento son similares a los de las listas negras basadas en DNS ( DNSBL ), excepto que SPF utiliza el esquema de delegación de autoridad del Sistema de Nombres de Dominio. La práctica actual requiere el uso de registros TXT, [ 14 ] tal como lo hacían las primeras implementaciones. Durante un tiempo, se registró un nuevo tipo de registro (SPF, tipo 99) y se puso a disposición en el software DNS común. El uso de registros TXT para SPF se concibió en ese momento como un mecanismo transitorio. El RFC experimental, RFC 4408, sección 3.1.1, sugería que "un nombre de dominio compatible con SPF DEBERÍA tener registros SPF de ambos tipos de RR ". [ 15 ] El estándar propuesto, RFC 7208, dice que "el uso de tipos alternativos de DNS RR fue admitido en la fase experimental de SPF, pero se ha descontinuado". [ 14 ]

La dirección del remitente se transmite al inicio del diálogo SMTP. Si el servidor rechaza el dominio, el cliente no autorizado recibirá un mensaje de rechazo y, si dicho cliente es un agente de transferencia de mensajes (MTA), se generará un mensaje de rebote a la dirección original del remitente. Si el servidor acepta el dominio y, posteriormente, también los destinatarios y el cuerpo del mensaje, insertará un campo Return-Path en la cabecera del mensaje para guardar la dirección del remitente. Si bien la dirección en Return-Path suele coincidir con otras direcciones de origen en la cabecera del correo, como header-from , esto no siempre es así, y SPF no impide la falsificación de estas otras direcciones, como la cabecera del remitente .

Los remitentes de spam pueden enviar correos electrónicos con un resultado SPF PASS si tienen una cuenta en un dominio con una política de remitente o si abusan de un sistema comprometido en dicho dominio. Sin embargo, al hacerlo, resulta más fácil rastrear al remitente de spam.

SPF beneficia a los propietarios de direcciones de correo electrónico falsificadas en la ruta de retorno. Estos reciben gran cantidad de mensajes de error no solicitados y otras respuestas automáticas. Si dichos receptores utilizan SPF para especificar sus direcciones IP de origen legítimas e indicar un resultado de FALLO para todas las demás direcciones, los receptores que verifican SPF pueden rechazar las falsificaciones, reduciendo o eliminando así la cantidad de backscatter .

SPF ofrece ventajas potenciales que van más allá de la identificación de correo no deseado. En concreto, si un remitente proporciona información SPF, los destinatarios pueden usar los resultados de SPF PASS junto con una lista de remitentes permitidos para identificar remitentes fiables conocidos. Situaciones como sistemas comprometidos y servidores de correo compartidos limitan este uso.

Razones para implementar

Si un dominio publica un registro SPF, es menos probable que los spammers y los estafadores falsifiquen correos electrónicos haciéndose pasar por ese dominio, ya que es más probable que los filtros de spam que verifican el registro SPF detecten los correos falsificados. Por lo tanto, un dominio protegido con SPF resulta menos atractivo para los spammers y los estafadores. Dado que un dominio protegido con SPF es menos atractivo como dirección suplantada, es menos probable que los filtros de spam lo incluyan en listas negras y, en consecuencia, es más probable que el correo electrónico legítimo del dominio llegue a su destino. [ 16 ]

FALLO y reenvío

SPF interrumpe el reenvío de mensajes simple . Cuando un dominio publica una política SPF FAIL, los mensajes legítimos enviados a destinatarios que reenvían su correo a terceros pueden ser rechazados o devueltos si se da alguna de las siguientes circunstancias:

  1. A diferencia de las listas de correo, el reenviador no modifica la ruta de retorno .
  2. El siguiente salto no permite el reenviador.
  3. Este lúpulo controla el FPS.

Esta es una característica necesaria y obvia de SPF: las comprobaciones detrás del MTA ( MX ) de "frontera" del receptor no pueden funcionar directamente.

Los editores de políticas SPF FAIL deben aceptar el riesgo de que sus correos electrónicos legítimos sean rechazados o devueltos. Deben realizar pruebas (por ejemplo, con una política SOFTFAIL) hasta que estén satisfechos con los resultados. A continuación, encontrará una lista de alternativas al reenvío de mensajes simple.

Pruebas HELO

Para un Return-Path vacío, como el que se usa en los mensajes de error y otras respuestas automáticas, es obligatorio realizar una comprobación SPF de la identidad HELO .

Con una identidad HELO falsa, el resultado NINGUNO no sería útil, pero para nombres de host válidos, SPF también protege la identidad HELO. Esta función de SPF siempre ha estado disponible como opción para los receptores, y los borradores posteriores de SPF, incluida la especificación final, recomiendan verificar siempre la identidad HELO.

Esto permite a los receptores incluir en la lista blanca a los remitentes que envían correos electrónicos basándose en un resultado HELO PASS, o rechazar todos los correos electrónicos tras un resultado HELO FAIL. También puede utilizarse en sistemas de reputación (cualquier lista de permitidos o denegados es un ejemplo sencillo de un sistema de reputación).

Implementación

El cumplimiento de la normativa SPF consta de tres tareas vagamente relacionadas:

  • Publicación de una política : Los dominios y hosts identifican las máquinas autorizadas para enviar correo electrónico en su nombre. Para ello, añaden registros adicionales a su información DNS existente: cada nombre de dominio u host que tenga un registro A o MX debe tener un registro SPF que especifique la política si se utiliza en una dirección de correo electrónico o como argumento HELO/EHLO. Los hosts que no envían correo deben tener un registro SPF publicado que lo indique ("v=spf1 -all").
  • Verificación y uso de la información SPF : Los receptores utilizan consultas DNS ordinarias, que normalmente se almacenan en caché para mejorar el rendimiento. A continuación, los receptores interpretan la información SPF según lo especificado y actúan en consecuencia.
  • Revisión del reenvío de correo : SPF no permite el reenvío de correo simple. Las alternativas son:
    • Reenvío de correo (es decir, reemplazar el remitente original por uno que pertenezca al dominio local).
    • Negarse (por ejemplo, responder 551 User not local; please try <user@example.com>)
    • Agregar a la lista de permitidos el servidor de destino, para que no rechace un mensaje reenviado.
    • Esquema de reescritura del remitente , un mecanismo más complejo que gestiona el enrutamiento de las notificaciones de no entrega al remitente original.

Por lo tanto, la cuestión clave en SPF es la especificación de la nueva información DNS que establecen los dominios y que utilizan los receptores. Los registros que se muestran a continuación están en la sintaxis DNS típica, por ejemplo:

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

"v=" define la versión de SPF utilizada. Las siguientes palabras proporcionan mecanismos para determinar si un dominio es apto para enviar correo. "ip4" y "a" especifican los sistemas autorizados para enviar mensajes para el dominio dado. "-all" al final especifica que, si los mecanismos anteriores no coinciden, el mensaje debe ser rechazado.

Mecanismos

Se definen ocho mecanismos :

Clasificados

Cada mecanismo se puede combinar con uno de cuatro calificadores :

  • +para un resultado APROBADO. Esto se puede omitir; por ejemplo, +mxes lo mismo que mx.
  • ?para un resultado NEUTRAL interpretado como NINGUNO (sin política).
  • ~( tilde ) para SOFTFAIL, una ayuda de depuración entre NEUTRAL y FAIL. Normalmente, los mensajes que devuelven un SOFTFAIL se aceptan pero se etiquetan.
  • -(menos) para FAIL, el correo debe ser rechazado (ver más abajo).

El calificador es opcional y por defecto es "+". [ 17 ]

Modificadores

Los modificadores permiten futuras extensiones del marco. Hasta la fecha, solo los dos modificadores definidos en el RFC 4408 se han implementado ampliamente:

  • exp=some.example.comProporciona el nombre de un dominio con un registro DNS TXT (interpretado mediante el lenguaje de macros de SPF) para obtener una explicación de los resultados de FALLO; normalmente, una URL que se añade al código de error SMTP. Esta función se utiliza con poca frecuencia.
  • redirect=some.example.comSe puede utilizar en lugar del mecanismo ALL- para vincularse al registro de política de otro dominio. Este modificador es más fácil de entender que el mecanismo INCLUDE-, que es algo similar .

Manejo de errores

En cuanto las implementaciones de SPF detectan errores de sintaxis en una política de remitente, deben abortar la evaluación con el resultado PERMERROR. Omitir los mecanismos erróneos no puede funcionar como se espera include:bad.exampley , por lo tanto, redirect=bad.exampletambién provoca un PERMERROR.

Otra medida de seguridad es el máximo de diez mecanismos que consultan DNS, es decir, cualquier mecanismo excepto IP4, IP6 y ALL. Las implementaciones pueden abortar la evaluación con el resultado TEMPERROR cuando tarda demasiado o cuando una consulta DNS agota el tiempo de espera, o pueden seguir simulando que la consulta no devolvió datos , lo que se denomina una "búsqueda vacía". Sin embargo, deben devolver PERMERROR si la política necesita, directa o indirectamente, más de diez consultas para los mecanismos . Además, deben devolver PERMERROR tan pronto como se hayan encontrado más de dos "búsquedas vacías". Cualquiera redirect=también cuenta para estos límites de procesamiento . [ 18 ]

Una política SPF HELO típica v=spf1 a mx ip4:192.0.2.0 -allpuede ejecutar cuatro o más consultas DNS: (1) registro TXT (el tipo SPF fue obsoleto por RFC 7208), (2) A o AAAA para el mecanismo a, (3) registro MX y (4+) A o AAAA para cada nombre MX, para el mecanismo mx. Excepto la primera, todas esas consultas cuentan para el límite de 10. Además, si, por ejemplo, el remitente tiene una dirección IPv6 , mientras que su nombre y sus dos nombres MX tienen solo direcciones IPv4, entonces la evaluación de los dos primeros mecanismos ya resulta en más de dos búsquedas vacías y por lo tanto PERMERROR. Los mecanismos ip4, ip6y allno necesitan búsqueda DNS.

Asuntos

Registros DNS SPF

Para permitir pruebas e implementación rápidas, las versiones iniciales de SPF verificaban su configuración en el registro DNS TXT del dominio remitente, aunque tradicionalmente se suponía que este registro era texto libre sin semántica adjunta. [ 19 ] Si bien en julio de 2005, IANA asignó un tipo de registro de recursos específico, el 99, a SPF, su adopción nunca fue alta, y tener dos mecanismos resultaba confuso para los usuarios. En 2014, se suspendió el uso de este registro después de que el grupo de trabajo SPFbis concluyera que "...una migración significativa al tipo de registro de recursos de SPF en el futuro previsible era muy improbable y que la mejor solución para resolver este problema de interoperabilidad era dejar de dar soporte al tipo de registro de recursos de SPF". [ 14 ]

Limitaciones del encabezado

Dado que SPF impide cada vez más que los spammers falsifiquen la dirección del remitente en el sobre, muchos han optado por falsificar únicamente la dirección del campo "De" del encabezado del correo, que es la que se muestra al destinatario en lugar de ser procesada solo por su agente de transferencia de mensajes (MTA). Sin embargo, SPF (o DKIM ) puede utilizarse junto con DMARC para comprobar también el campo "De" del encabezado del correo. Esto se denomina "alineación de identificadores".

Se requieren implementaciones propietarias personalizadas para protegerse contra la suplantación de nombre de visualización y no pueden utilizar SPF. [ 20 ] [ 21 ] [ 22 ]

Despliegue

El software antispam como SpamAssassin versión 3.0.0 y ASSP implementan SPF. Muchos agentes de transferencia de correo (MTA) admiten SPF directamente, como Courier , CommuniGate Pro , Wildcat , MDaemon y Microsoft Exchange , o tienen parches o complementos disponibles que admiten SPF, incluidos Postfix , Sendmail , Exim , qmail y Qpsmtpd . [ 23 ] A partir de 2017, más de ocho millones de dominios publican -allpolíticas SPF FAIL. [ 24 ] En una encuesta publicada en 2007, el 5% de los dominios .comy .nettenían algún tipo de política SPF. En 2009, una encuesta continua realizada en Nokia Research informa que el 51% de los dominios probados especifican una política SPF. [ 25 ] Estos resultados pueden incluir políticas triviales como v=spf1 ?all. [ 26 ] [ 27 ]

En abril de 2007, BITS, una división de la Mesa Redonda de Servicios Financieros, publicó recomendaciones de seguridad de correo electrónico para sus miembros, incluyendo la implementación de SPF. [ 28 ] En 2008, el Grupo de Trabajo Anti-Abuso de Mensajería (MAAWG) publicó un documento sobre autenticación de correo electrónico que abarca SPF, Sender ID y DomainKeys Identified Mail (DKIM). [ 29 ] En sus "Mejores Prácticas de Comunicación para Remitentes", el MAAWG declaró: "Como mínimo, los remitentes deberían incorporar registros SPF para sus dominios de correo". [ 30 ] En 2015, el Grupo de Trabajo Anti-Abuso de Mensajería (MAAWG) revisó un documento sobre autenticación de correo electrónico que abarca SPF, DomainKeys Identified Mail (DKIM) y DMARC (DMARC). En sus "Mejores Prácticas de Comunicación para Remitentes" revisadas, el MAAWG declaró: "La autenticación respalda la transparencia al identificar aún más al o los remitentes de un mensaje, al tiempo que contribuye a la reducción o eliminación de direcciones suplantadas y falsificadas". [ 31 ]

A partir del 1 de febrero de 2024, Google exige SPF o DKIM para todos los dominios que envían correos electrónicos a cuentas de Gmail . Los remitentes masivos (más de 5000 correos electrónicos al día) deben tener configurados SPF, DKIM y DMARC para sus dominios. [ 32 ]

Véase también

Referencias

  1. ↑ "Marco de políticas del remitente: Introducción" . Archivado del original el 22 de febrero de 2019.
  2. 1 2 Carranza, Pablo (16 de julio de 2013). "Cómo usar un registro SPF para prevenir la suplantación de identidad y mejorar la confiabilidad del correo electrónico" . DigitalOcean . Archivado del original el 20 de abril de 2015. Recuperado el 23 de septiembre de 2019. Un registro SPF cuidadosamente adaptado reducirá la probabilidad de que su nombre de dominio sea suplantado fraudulentamente y evitará que sus mensajes sean marcados como spam antes de que lleguen a sus destinatarios. La suplantación de identidad por correo electrónico es la creación de mensajes de correo electrónico con una dirección de remitente falsificada; algo que es fácil de hacer porque muchos servidores de correo no realizan autenticación. Los correos electrónicos de spam y phishing suelen usar dicha suplantación para engañar al destinatario sobre el origen del mensaje.
  3. 1 2 David, Green. "Mail-Transmitter RR" . marc.info . Consultado el 15 de mayo de 2019 .
  4. 1 2 3 "La historia de SPF" . DMARCian . DMARCian.org. 18 de marzo de 2019. Consultado el 15 de mayo de 2019 .
  5. ↑ escribiendo como David Green
  6. ↑ Paul, Vixie. "Re: Mail-Transmitter RR" . marc.info . Consultado el 15 de mayo de 2019 .
  7. ↑ "SPF: Historia/Pre-SPF" . Archivado del original el 16 de julio de 2011. Recuperado el 16 de mayo de 2009 .
  8. ↑ Para una comparación entre RMX, DMP y SPF, consulte RMX y DMP comparados. Archivado el 25/04/2008 en Wayback Machine en el sitio histórico de openspf.
  9. ↑ "SPF: Historia/SPF-2003" . Archivado del original el 1 de diciembre de 2017. Consultado el 13 de enero de 2026 .
  10. ↑ Seltzer, Larry (22 de septiembre de 2004). "Internet Task Force Shuts Down Anti-Spam Working Group" . eWeek . Recuperado el 15 de mayo de 2019 .
  11. ↑ Schlitt, Wayne; Wong, Meng Weng (abril de 2006). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Versión 1 (Informe). Internet Engineering Task Force.
  12. ↑ Kitterman, Scott (abril de 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Versión 1 (Informe). Internet Engineering Task Force.
  13. ↑ Dan Schlitt (29 de agosto de 2013). "Última llamada: <draft-ietf-spfbis-4408bis-19.txt> (Marco de políticas del remitente (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1) al estándar propuesto" . Lista de discusión de la IETF . IETF . Consultado el 16 de diciembre de 2013 .
  14. 1 2 3 4 Scott Kitterman (abril de 2014). "Registros de recursos DNS" . Sender Policy Framework (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1. IETF . sec. 5.5. doi : 10.17487/RFC7208 . RFC 7208. Recuperado el 26 de abril de 2014 . 
  15. ^ Wong, M. y W. Schlitt. RFC 4408. Abril de 2006 <rfc:4408>
  16. ↑ "¿Por qué debería implementar un registro SPF en mi dominio?" . Manual de correo electrónico. Mayo de 2009. Archivado del original el 29 de enero de 2010. Consultado el 1 de enero de 2010 .
  17. ↑ Kitterman, S. "Mecanismos" . Sender Policy Framework (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1. IETF . pág. 17. sec. 4.6.2. doi : 10.17487/RFC7208 . RFC 7208 .   
  18. ↑ Atkins, Steve (14 de marzo de 2016). "SPF: La regla de diez" . wordtothewise.com . Consultado el 23 de septiembre de 2019 .
  19. ↑ Steve Bellovin expresa dudas. Archivado el 13 de abril de 2004 en Wayback Machine (enero de 2004).
  20. ↑ "Crea una política de bloqueo de entrada MIMECAST para DETENER la suplantación de identidad por correo electrónico" . Archivado del original el 26 de agosto de 2017. Consultado el 25 de agosto de 2017 .
  21. ↑ "Evite los mensajes falsificados con la detección de remitentes falsificados" . Consultado el 25 de agosto de 2017 .
  22. ↑ "Cómo funciona la protección contra la suplantación de identidad en Office 365" . 23 de febrero de 2016. Consultado el 25 de agosto de 2017 .
  23. ↑ "Complemento SPF Qpsmtpd" . GitHub . 2013.{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  24. ↑ "SPF - Encuesta de todos los dominios" . 2017. Consultado el 7 de noviembre de 2017 .
  25. ↑ "Informe de investigación de Nokia sobre la adopción de SPF" . Fit.Nokia.com . Nokia . 19 de septiembre de 2011. Archivado del original el 20 de septiembre de 2011. Consultado el 5 de abril de 2016 .
  26. ↑ Liu, Cricket (enero de 2007). "Limitando las nuevas extensiones y aplicaciones DNS" . ONLamp. Archivado del original el 26 de septiembre de 2007. Consultado el 4 de octubre de 2007 .
  27. ↑ "Autenticación SPF: SPF-all vs ~all" . EasyDMARC . 4 de diciembre de 2020. Consultado el 8 de abril de 2021 .
  28. ↑ "Kit de herramientas de seguridad de correo electrónico de BITS" (PDF) . BITS. Abril de 2007. Archivado del original (PDF) el 15 de mayo de 2008. Consultado el 13 de junio de 2008 .
  29. ↑ Crocker, Dave (marzo de 2008). "La confianza en el correo electrónico comienza con la autenticación" (PDF) . MAAWG. Archivado del original (PDF) el 29 de enero de 2013. Recuperado el 28 de julio de 2011 .
  30. ↑ "Resumen ejecutivo de las mejores prácticas de comunicación para remitentes de MAAWG" (PDF) . MAAWG. 7 de octubre de 2011. Consultado el 27 de abril de 2012 .
  31. ↑ "Mejores prácticas comunes para remitentes de M3AAWG" (PDF) . MAAWG. 1 de febrero de 2015. Consultado el 1 de septiembre de 2016 .
  32. ↑ "Directrices para remitentes de correo electrónico - Ayuda para administradores de Google Workspace" .

  • IETF RFC4408: Marco de políticas del remitente (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1 EXPERIMENTAL (2006)
  • IETF RFC6652: Informe de fallos de autenticación del Sender Policy Framework (SPF) mediante el formato de informe de abuso, NORMA PROPUESTA (2012)
  • IETF RFC7208: Marco de políticas del remitente (SPF) para autorizar el uso de dominios en el correo electrónico, versión 1, ESTÁNDAR PROPUESTO (2014)
  • libspf2 – Una implementación de código abierto del protocolo SPF (2010)
  • SenderPolicyFramework.com : herramienta para la búsqueda, generación y validación de registros SPF.