¿Qué es un registro SPF o sender policy framework?

La seguridad en el correo electrónico es un factor crucial para cualquier persona o negocio que quiera proteger su reputación y garantizar la entrega adecuada de sus mensajes. Hoy en día, vemos muchísimos casos de suplantación de identidad, mensajes fraudulentos y pérdidas económicas derivadas de la mala configuración de los sistemas de email. Por eso, resulta esencial conocer qué es SPF (Sender Policy Framework) y cómo puede ayudarte a reforzar la legitimidad de tus envíos. 

¿Qué es el SPF o Sender Policy Framework?

El SPF o Sender Policy Framework es un protocolo de autenticación del correo electrónico. Nació con el fin de verificar y validar que los servidores responsables de enviar los emails en nombre de un dominio están realmente autorizados para hacerlo. Dicho de otro modo, gracias a este sistema, un receptor puede consultar si un email entrante proviene de una dirección IP que tu dominio ha declarado como legítima. Si coincide, se asume que el mensaje es auténtico; si no, se marca con un alto riesgo de ser correo no deseado o directamente se descarta.

Este método actúa en conjunto con otros mecanismos de seguridad. Sin embargo, destaca por ofrecer un nivel de protección muy orientado a prevenir la falsificación de direcciones de email, que se conoce comúnmente como spoofing. Con un registro SPF correctamente configurado, se dificulta mucho que alguien envíe correos aparentando ser tu dominio sin permiso.

¿Por qué es importante contar con un registro SPF bien configurado?

SPF aporta un sello de confianza hacia tus destinatarios y proveedores de correo, ya que:

• Verifica que el mensaje sea enviado a través de un servidor de correo autorizado.
• Protege tu reputación de dominio, al reducir considerablemente la probabilidad de que un ciberdelincuente se haga pasar por ti.
• Facilita la llegada de tus correos a la bandeja de entrada, porque si tu dominio respeta políticas de autenticación, los filtros de spam suelen tratarte con más benevolencia.
• Ayuda a cumplir con otras pautas de seguridad, ya que se integra muy bien con mecanismos adicionales como DKIM y DMARC.

Cómo funciona el protocolo SPF

SPF se integra en el DNS (Sistema de Nombres de Dominio), donde declaras una política que especifica cuáles direcciones IP, hosts o servidores pueden enviar correo en nombre de tu dominio.

Cuando un correo llega al servidor del destinatario, este consulta la política SPF asociada al dominio del remitente. Dicho de otro modo, el servidor de destino revisa tu DNS para ver si la IP que envía el correo está listada como autorizada. De ser afirmativa la respuesta, el email pasa la validación SPF. Si no lo está, recibe una marca de rechazo o se clasifica como spam, dependiendo de la configuración.

En términos más concretos:

• El servidor receptor extrae el dominio del remitente (ejemplo: midominio.com).
• Busca el registro TXT o SPF en el DNS de ese dominio.
• Lee la lista de IP o servidores autorizados.
• Compara la IP del servidor que intenta entregar el correo con las IP definidas.
• Decide si pasa la validación (si hay coincidencia) o si falla (si no está dentro de la política).

Elementos clave de un registro SPF

Los registros SPF se ubican en la zona DNS del dominio, usualmente como un registro tipo TXT. Si abres el DNS de tu dominio, podrías encontrarte con algo como esto:

Este es un ejemplo básico. El registro SPF cuenta con varios componentes y palabras clave. Algunos términos relevantes son los llamados mecanismos y los modificadores.

Mecanismos principales

Los mecanismos son las declaraciones dentro del registro SPF que ayudan a especificar qué hacer con ciertas IP o dominios. Entre los más usados, se destacan:

• include: Sirve para indicar que confías en la política SPF de otro dominio o subdominio. Por ejemplo, si usas un servicio externo y deseas autorizarlo para enviar emails como si fueras tú, se usa “include:”.
• ip4 / ip6: Especifica las direcciones IP que están permitidas para enviar correo en tu nombre.
• a: Autoriza la IP asociada al registro A (host principal) del dominio o subdominio.
• mx: Permite que los servidores MX (los encargados de recibir correo en tu dominio) también sean válidos para el envío.
• all: Suele colocarse al final con un calificador que define la acción a tomar con correos que no coinciden con las reglas anteriores.

Calificadores y su impacto

Los mecanismos suelen llevar un calificador antes, que puede ser “+”, “-”, “~” o “?”. Cada uno dicta qué pasa cuando se cumple la condición:

• + (Pass): La IP coincide con ese mecanismo y se considera como válida.
• – (Fail): La IP coincide con ese mecanismo y se rechaza.
• ~ (SoftFail): La IP coincide, pero se señala como sospechosa; el correo suele marcarse como spam, no se rechaza de inmediato.
• ? (Neutral): No se toma decisión.

En el ejemplo v=spf1 include:mailserver.tu-dominio.com -all, el “-all” quiere decir que cualquier servidor que no haya sido aprobado en la parte previa, debe ser marcado como no válido. Es la forma más estricta, pero también la más segura.

Modificadores

Aunque se usan con menos frecuencia, los modificadores aportan información adicional a la política SPF. Uno de los más comunes es “redirect=”, que le dice a los receptores que deben consultar la política de otro dominio para validar. Esto es útil cuando quieres mantener una sola política SPF y redirigir a todos tus subdominios a esa misma definición central. Por ejemplo:

De esta manera, no tienes que duplicar políticas. Simplemente el servidor receptor irá a verificar el registro SPF en “otro-dominio.com” para ver si se autoriza o no la IP.

Beneficios de usar SPF en correos electrónicos

Instalar un registro SPF no solo te ayuda con la deliverabilidad, sino que aporta otros beneficios:

• Menos spam saliente: Si tu dominio se compromete y un atacante quiere mandar correos fraudulentos, lo tendrá mucho más difícil.
• Mayor credibilidad: Tus contactos o clientes verán que tus mensajes pasan filtros de validación, lo cual incrementa la confianza en tu marca y en tus comunicaciones.
• Complemento con otras tecnologías: Por sí mismo, el SPF no lo hace todo, pero se combina de maravilla con DKIM y DMARC, fortaleciendo notablemente la estrategia de seguridad y la tasa de entrega de emails.
• Reducción de riesgos legales: En ciertos contextos, la suplantación de identidad puede acarrear problemas legales, además de dañar tu imagen. Con SPF disminuyes esa exposición y te cuidas de incidentes graves.
• Más control: Al definir con precisión qué servidores pueden enviar correos de tu dominio, tienes un panorama más claro de tu infraestructura de email.

Como crear y configurar el registro SPF

La implementación de un registro SPF pasa por varios puntos, pero la buena noticia es que no necesitas ser un experto en redes para lograrlo. Si eres nuevo en esto, sigue estos lineamientos generales (sin usar listados numéricos, iremos por cada aspecto con fluidez):

En primer lugar, es imprescindible identificar todos los servicios que envían correos desde tu dominio. Por ejemplo, si en tu sitio web tienes formularios de contacto que disparan emails, un sistema de marketing por correo y tu propio servidor de hosting, cada uno debe reflejarse en la política SPF. Caso contrario, esos envíos podrían terminar siendo marcados como no válidos.

Luego, debes ingresar al panel DNS de tu dominio. Dependiendo de tu proveedor, encontrarás una opción para añadir un registro TXT. En esa sección, redactarás la política SPF. Ten en cuenta la sintaxis oficial: siempre debe iniciar con “v=spf1”. A partir de ahí, añades los mecanismos y modificadores que correspondan. Por ejemplo, si usas un servidor principal con registro A, podrías añadir “a”. Si cuentas con un servidor secundario con IP específica, podrías agregar “ip4:1.2.3.4”. Si utilizas un servicio de envíos masivos, a menudo ellos te proporcionan un “include” para que lo incorpores.

Es muy recomendable optar por la versión más restrictiva para los correos no identificados, es decir, terminar con “-all”. Aunque existen variantes como “~all” o “?all”, lo ideal es que si un servidor no está definido explícitamente, sea rechazado. Eso cierra brechas de seguridad. Sin embargo, si no estás seguro al 100% de tener todo bien configurado, podrías empezar con una versión menos restrictiva (SoftFail con ~all) para observar el comportamiento y luego endurecer la regla.

Tras guardar los cambios en el DNS, es recomendable hacer una comprobacion usando alguna herramienta en línea de verificación de SPF (hay muchas gratuitas, pero recordemos que no vamos a recomendar marcas específicas aquí). Estas herramientas consultan la política que acabas de añadir y te indican si tu configuración es sintácticamente correcta y si tus mecanismos están funcionando.

Una vez confirmada la validez, conviene esperar algunas horas, pues los cambios en DNS no siempre se propagan de manera instantánea. Después, podrías hacer pruebas enviándote correos a diferentes proveedores (si lo deseas, aunque sea de tu propia cuenta personal) para evaluar si pasa o no la validación SPF. Si ves algún fallo, regresa y revisa las direcciones IP o los “include”.

Errores comunes al configurar el registro SPF

Muchas personas olvidan actualizar su SPF cuando agregan nuevas herramientas de email marketing o cambian de servidor. Si no integras esa IP o ese dominio en tu registro, tus envíos futuros podrían fallar la autenticación. También suele pasar que se mezclan varios registros SPF en el DNS, lo cual es un error típico. Recuerda que solo debe haber un registro SPF válido por cada dominio. Si deseas agregar nuevos proveedores o direcciones, hazlo dentro de la misma línea de la política, en lugar de crear un registro SPF adicional.

Otro problema frecuente radica en el mal uso del “redirect=”. Si tu intensión es unir políticas de varios subdominios, debes hacerlo con precisión y no confundirlo con “include”. De lo contrario, podrías crear un bucle de verificaciones. Además, el “redirect” reemplaza completamente la política actual, así que si lo usas, todo lo que definas previamente en la misma política quedará ignorado.

Un caso no tan raro es poner la calificación incorrecta en “-all”, “~all”, “?all” o “+all”. Por ejemplo, si se te olvida el guion y dejas “+all”, estarás permitiendo cualquier IP, lo cual anula la protección que buscabas y, en realidad, perjudica la confianza en tus correos.

Finalmente, algunos novatos no revisan los límites de consultas DNS. SPF tiene un tope de diez búsquedas DNS por cada verificación. Si incluyes demasiados “include” que a su vez generan más sub-includes, podrías romper este límite, ocasionando que el receptor se acoja a la política por defecto y marque el correo como fallo. En esos casos, conviene optimizar, usando registros IP directos, o condensar dominios en un “include” único si el proveedor lo admite.

Relación de SPF con DKIM y DMARC

Aunque el SPF es muy útil de forma independiente, suele recomendarse complementarlo con otras dos tecnologías fundamentales:

• DKIM (DomainKeys Identified Mail): Se basa en un sistema de cifrado de claves públicas y privadas para firmar el contenido del mensaje y verificar que no haya sido alterado en tránsito.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): Es una política que combina SPF y DKIM para reforzar el control de autenticación y, además, generar reportes.

El SPF verifica la fuente del envío, mientras que DKIM corrobora la integridad del contenido y DMARC te ayuda a decidir qué hacer cuando algo no coincide. Cuando las tres se configuran adecuadamente, se logra una protección muy sólida contra el phishing y el spam. Para muchos administradores de correo, implementar SPF es el primer paso de un sistema de autenticación más amplio.

SPF y la prevención de phishing

El phishing se centra en engañar a los usuarios para que entreguen información sensible (contraseñas, datos bancarios, etc.) mediante correos que simulan ser legítimos. Para conseguirlo, los atacantes suelen falsificar direcciones de remitente, emulando la identidad de empresas o personas de confianza. 

Al implementar SPF, pones una barrera a esta técnica. Claro, si el receptor también hace la respectiva verificación de SPF, cuando llegue un mensaje que indique ser de tu dominio pero en realidad venga de un servidor no autorizado, el filtro lo marcará o rechazará. Así, reduces de manera drástica la eficacia de cualquier intento de phishing que pretenda usar tu nombre.

Sin embargo, si la configuración es laxa (con “~all” o “?all”), algunos correos podrían ser catalogados como sospechosos pero no forzosamente bloqueados. Y si la víctima no presta atención y fuerza la apertura, el engaño puede seguir. Por esto, muchos administradores optan por la calificación “-all”, siendo estrictos. También conviene avisar a tus clientes que verifiquen aspectos básicos, y que estén atentos a si un correo no pasa sus controles de autenticación, ya que normalmente los proveedores muestran alertas como “Este mensaje podría no ser de quien dice ser”.

Casos en los que SPF no basta por sí solo

El SPF trabaja en la capa de autenticación del remitente, pero no inspecciona el contenido del mensaje. Tampoco protege si alguien reenvía un correo por medio de otro sistema (lo que se conoce como forward), ya que el reenvío podría cambiar la IP emisora y romper la cadena SPF. Por eso, algunos correos legítimos acaban siendo marcados como spam cuando pasan a través de servidores de reenvío que no reescriben el “envelope-from” adecuadamente.

Además, si el atacante controla un servidor IP que está “autorizado” en tu registro SPF, o si logra vulnerar tu servicio de email legítimo, podría mandar correos fraudulentos sin que SPF lo bloquee. Para cubrir estos huecos, se recurre a DKIM y a DMARC, que agregan capas de validación y reportes.

El punto a destacar es que, aunque SPF no soluciona todo, es un cimiento que no debes ignorar. Configurarlo de manera apropiada te ofrece un entorno mucho más confiable, dificultando el spoofing e incentivando la limpieza de tu reputación.

¿Cómo lidiar con varios servicios de envío de email a la vez?

En el panorama actual, es muy frecuente emplear varios servicios al mismo tiempo para distintas finalidades: uno para notificaciones de tu aplicación web, otro para newsletters, quizás otro para recibos de compra, entre otros. Esto complica un poco el SPF, porque cada proveedor puede requerir un “include” diferente.

La clave está en recopilar todos los dominios o IP que necesitas autorizar. Por ejemplo, supongamos que uno de tus servicios te indica: “Agrega ‘include:servidor-a.com’ en tu SPF”. Otro te dice algo distinto: “Debes usar ‘include:servidor-b.com’”. Y tu servidor de correo interno se basa en la IP 1.2.3.4. Para unificarlos, tu registro SPF podría lucir así:

Con eso, cubres los tres orígenes. Lo importante es no sobrepasar el límite de 10 consultas DNS. Cada “include” puede disparar varias consultas, según cómo esté configurado ese dominio. Si topas con el límite, tendrás que pensar en soluciones como agrupar IP manualmente, reducir la cantidad de “include”, o usar subdominios especializados con sus propias políticas SPF.

El peligro de subdominios sin protección

A veces, las empresas se centran tanto en el dominio principal que olvidan los subdominios. Y es bastante común que los atacantes busquen enviar correos desde “sub.tu-dominio.com” porque notan que no hay registro SPF configurado allí.

Existen dos enfoques. El primero consiste en declarar políticas SPF independientes para cada subdominio que envía correos. Es decir, si “ventas.tu-dominio.com” envía correos desde una IP distinta, necesitas un registro SPF separado. El segundo, más sencillo, es el uso de la directiva “redirect” para que todos los subdominios hereden la política principal, salvo que quieras especificar excepciones.

Por ejemplo:

El límite de 10 consultas en SPF: cómo evitar problemas

Uno de los retos técnicos más comunes es el límite de 10 consultas DNS en las políticas SPF. Cada vez que tu registro usa mecanismos como “include”, “a” o “mx”, se genera una consulta DNS adicional (o incluso más, dependiendo de la cantidad de registros implicados). Cuando añades muchos servicios externos, fácilmente superas ese tope.

Si tu registro excede el límite, el resultado de la verificación puede ser “permerror” (error permanente) y, por ende, un fallo total en la autenticación. Para mitigar esto, se pueden usar técnicas como:

• Reducir o agrupar las IP en bloques, en vez de depender de “include”.
• Usar subdominios distintos, de modo que cada uno tenga su propio SPF, y no sobrecargues la política principal.
• Revisar si tus “include” se solapan. A veces tienes múltiples “include” que apuntan a la misma política.
• Preguntar a tu proveedor si ofrece un “include” unificado o una IP fija que puedas configurar directamente.

Realizar esta optimización es clave para que tu SPF siga siendo funcional, especialmente si manejas varios servicios simultáneamente.