En 2014, una pequeña empresa de comercio electrónico se despertó para descubrir que alguien había enviado 50,000 correos de phishing a sus clientes—todos aparentando venir de su dominio oficial. Los correos parecían legítimos. La dirección From era correcta. Los clientes hicieron clic, introdujeron los datos de su tarjeta de crédito, y la empresa pasó los siguientes seis meses reconstruyendo la confianza que les había llevado años ganarse.
El ataque fue posible por un único registro DNS que faltaba: SPF.
SPF—Sender Policy Framework—es una de esas cosas que suena técnica y aburrida hasta que entiendes lo que realmente hace. Es la diferencia entre que cualquiera pueda enviar correo como si fueras tú y que solo tus servidores autorizados tengan ese privilegio. Es el equivalente digital de un portero revisando identificaciones en la entrada.
El problema que resuelve SPF
Esta es una verdad incómoda sobre el correo electrónico: la dirección 'From' que ves es esencialmente auto-declarada. Cuando recibes un correo de [email protected], no hay nada inherente al protocolo de correo que demuestre que realmente provenga de los servidores de Big Company. El remitente simplemente… afirma que sí.
Es como si cualquiera pudiera escribir cualquier dirección de remitente en una carta física. Podrías enviar una carta afirmando ser de la Casa Blanca, y el servicio postal la entregaría sin cuestionarlo. Así funcionó el correo electrónico durante décadas, y por eso el phishing se convirtió en un problema tan grande.
SPF cambia esto permitiendo a los propietarios de dominios publicar una lista de remitentes autorizados. Cuando llega un correo afirmando ser de tu dominio, el servidor receptor puede comprobar: '¿Realmente vino de un servidor autorizado para enviar por este dominio?' Si no, el correo se marca o se rechaza.
Cómo funciona realmente
Veamos qué pasa cuando envías un correo desde tu dominio de empresa, asumiendo que SPF está configurado correctamente.
Redactas un correo en Gmail o en tu cliente de correo y pulsas enviar. Tu correo viaja al servidor de correo de tu empresa (o al servidor de tu proveedor), que se conecta al servidor del destinatario. En este punto, el servidor del destinatario ve dos cosas: la dirección IP del servidor que intenta entregar el correo y el dominio en la dirección 'From'.
El servidor del destinatario entonces realiza una consulta DNS para el registro SPF de tu dominio. Este registro contiene una lista de direcciones IP y dominios autorizados para enviar correo en tu nombre. Si la IP del servidor que se conecta coincide con algo en esa lista, el correo pasa SPF. Si no, falla.
Toda la verificación toma milisegundos. El remitente ni siquiera sabe que ocurrió. Pero esa simple consulta es la diferencia entre que tu correo llegue a la bandeja de entrada y que se marque como posible fraude.
Cómo leer un registro SPF
Los registros SPF viven en tu DNS como registros TXT. Aquí tienes un ejemplo del mundo real:
Esto parece críptico, pero en realidad es sencillo una vez conoces la sintaxis. Vamos a desglosarlo pieza por pieza.
El 'v=spf1' al inicio declara que esto es un registro SPF (versión 1—solo ha existido una versión). Todo lo que viene después es una lista de quiénes pueden enviar.
'include:_spf.google.com' significa 'consulta el registro SPF de Google y confía en los servidores que ellos enumeren.' Así autorizas a Google Workspace a enviar correo por tu dominio sin tener que listar cada IP de Google (que serían cientos).
'include:amazonses.com' hace lo mismo para Amazon SES. Si usas SES para correos transaccionales, esto autoriza sus servidores.
'ip4:203.0.113.42' autoriza directamente una dirección IP específica. Puede que sea tu propio servidor de correo, o un sistema heredado que envía reportes.
El '-all' al final es crucial. Significa 'rechaza todo lo que no coincida con las reglas anteriores.' Esto se denomina 'hard fail.' También puedes ver '~all' (soft fail, que marca los fallos como sospechosos pero no los rechaza) o '?all' (neutral, que esencialmente significa 'no lo sé, haz lo que quieras'). Para una seguridad real, quieres '-all'.
El límite de 10 consultas
Aquí es donde SPF se complica, y donde muchas empresas se topan con problemas.
Cada instrucción 'include' dispara una consulta DNS. Y SPF tiene un límite estricto de 10 consultas DNS por verificación. Si lo excedes, tu registro SPF es inválido—lo que significa que todos tus correos fallan SPF, incluso desde servidores legítimos.
Este límite existe porque las verificaciones SPF ocurren en tiempo real durante la entrega del correo. Si un actor malicioso pudiera crear un registro SPF que disparara cientos de consultas DNS, podría usarlo como un ataque de denegación de servicio contra la infraestructura DNS. El límite de 10 consultas lo evita.
El problema es que las empresas modernas usan muchos servicios que envían correo: Google Workspace, una plataforma de marketing, un servicio de correo transaccional, una herramienta de soporte al cliente, quizás un sistema de RR. HH. Cada uno necesita una instrucción 'include', y cada 'include' puede contener a su vez más 'includes'. El registro SPF de Google por sí solo puede consumir 3-4 consultas.
Si estás alcanzando el límite, tienes varias opciones. Puedes usar servicios de SPF flattening que resuelven todos los includes en direcciones IP directas (aunque esto requiere mantenimiento a medida que las IP cambian). Puedes consolidar el envío de correo en menos proveedores. O puedes usar subdominios—marketing.yourcompany.com para marketing, support.yourcompany.com para soporte—cada uno con su propio registro SPF.
Limitaciones de SPF
SPF es esencial, pero no es una solución completa. Entender sus limitaciones te ayuda a construir una estrategia adecuada de autenticación de correo.
Primero, SPF verifica la dirección 'envelope from' (la dirección de retorno técnica), no la 'header from' (lo que ven los destinatarios). Un atacante puede pasar SPF y aun así mostrar una dirección suplantada al destinatario. Por eso existe DMARC—vincula los resultados de SPF y DKIM con la dirección 'From' visible.
Segundo, SPF se rompe cuando los correos se reenvían. Si alguien reenvía tu correo a otra dirección, la IP del servidor de reenvío no estará en tu registro SPF, por lo que el correo reenviado falla SPF. Esta es una limitación fundamental del protocolo, y por eso DKIM (que firma el contenido del correo) es un complemento importante.
Tercero, SPF solo indica a los servidores receptores qué hacer con los fallos si usas '-all'. Muchos dominios usan '~all' o '?all' porque temen bloquear correos legítimos. Pero esto significa que los atacantes aún pueden enviar correos suplantados—solo se marcarán como sospechosos en lugar de rechazarlos.
Configurar SPF correctamente
Configurar SPF no es difícil, pero hacerlo bien requiere algo de reflexión. Este es el enfoque que funciona.
Empieza auditando cada servicio que envía correo desde tu dominio. Suele ser más de lo que crees. Tu proveedor de correo, obviamente. Pero también tu herramienta de automatización de marketing, tu servicio de correos transaccionales, tu CRM, tu mesa de soporte, tu sistema de facturación, quizá incluso tu impresora (algunas envían scan-to-email). Haz una lista completa.
Para cada servicio, encuentra su instrucción de include de SPF. Normalmente está en su documentación bajo 'email authentication' o 'DNS setup'. Añade cada una a tu registro SPF.
Empieza con '~all' (soft fail) en lugar de '-all' (hard fail). Esto te permite monitorizar problemas sin bloquear correos legítimos. Observa tus informes DMARC (estás recopilando informes DMARC, ¿verdad?) en busca de fallos SPF. Si ves servicios legítimos fallando, añádelos a tu registro.
Una vez que pases unas semanas sin fallos inesperados, cambia a '-all'. Ahí es cuando SPF realmente empieza a protegerte. Hasta entonces, es solo informativo.
Por último, pon un recordatorio en el calendario para revisar tu registro SPF cada trimestre. Los servicios cambian, añades nuevas herramientas, las IP rotan. Un registro SPF desactualizado es casi tan malo como no tener registro SPF.
Frequently asked questions
Mi registro SPF es correcto pero los correos siguen yendo a spam. ¿Por qué?
SPF es solo un factor en la entregabilidad. Los filtros de spam también consideran la reputación de tu dominio, la reputación de la IP, el contenido del correo, las tasas de interacción y si tienes DKIM y DMARC configurados. Que SPF pase no garantiza la entrada en la bandeja de entrada: solo significa que superaste un obstáculo.
¿Puedo tener varios registros SPF para un dominio?
No, y este es un error común. Si tienes múltiples registros TXT que empiezan con 'v=spf1', las verificaciones SPF fallarán. Necesitas exactamente un registro SPF que incluya a todos tus remitentes autorizados.
¿Qué pasa si supero el límite de 10 consultas?
Tu registro SPF se vuelve inválido y todas las verificaciones SPF devuelven 'permerror'. La mayoría de los servidores receptores tratan esto como un fallo de SPF, lo que puede dañar tu entregabilidad. Usa una herramienta de comprobación de SPF para contar tus consultas antes de publicar cambios.
¿Debo usar -all o ~all?
Usa ~all mientras configuras y pruebas. Cuando estés seguro de que tu registro SPF incluye a todos los remitentes legítimos, cambia a -all. El soft fail (~all) no te protege realmente del spoofing: solo marca los correos sospechosos sin rechazarlos.