¿Qué es un registro SPF? Sintaxis, límites y fallos

¿Qué es un registro SPF? Es un único registro TXT en el DNS de su dominio que enumera los servidores autorizados a enviar correo usando ese dominio como remitente del sobre. El servidor receptor lee ese registro, compara la IP que se conecta con la lista y devuelve pass, fail, softfail o neutral. SPF autentica la ruta de envío, no el mensaje, y no dice nada sobre la dirección From que lee una persona.

Esa distinción explica casi todos los tickets de SPF que vemos en las trazas.

Un registro SPF es una lista de remitentes autorizados, publicada en DNS

SPF significa Sender Policy Framework y está especificado en la RFC 7208. El registro es una entrada TXT en la raíz del dominio que empieza por v=spf1. Uno mínimo se ve así:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Se lee de izquierda a derecha. El receptor evalúa cada término en orden y se detiene en la primera coincidencia. El último término, all, cubre todo lo que no coincidió antes.

El dominio que se comprueba no es el encabezado From. Es el dominio de MAIL FROM, también llamado remitente del sobre o Return-Path. Si está vacío, como en los rebotes, el receptor recurre al nombre HELO.

Cada término es un mecanismo, con un calificador opcional. Seis cubren casi todos los registros reales:

• ip4: / ip6: coinciden con una dirección literal o un rango CIDR. No cuestan búsquedas.

• a coincide con los registros A/AAAA del dominio. Cuesta una búsqueda.

• mx coincide con los hosts de los registros MX del dominio. Cuesta una búsqueda más una por host.

• include: coincide con lo que coincida el registro SPF de otro dominio. Cuesta una búsqueda, más todo lo anidado dentro.

• exists: coincide con cualquier registro A de un nombre construido. Cuesta una búsqueda.

• ptr coincide con el DNS inverso de la IP que se conecta. Cuesta búsquedas, y la RFC 7208 desaconseja usarlo.

Los calificadores fijan el resultado cuando un término coincide. + es pass y es el valor por defecto, - es fail, ~ es softfail, ? es neutral. Así, -all significa "rechazar todo lo que no esté listado" y ~all significa "aceptar pero marcar".

Prefiera ip4: e ip6: siempre que controle la dirección. No cuestan búsquedas y no se rompen cuando cambia el DNS de otra persona.

El límite de 10 búsquedas DNS rompe los registros reales

La RFC 7208 limita a 10 los términos que lanzan consultas DNS durante una evaluación SPF: include, a, mx, ptr, exists y el modificador redirect. Los includes anidados cuentan. Al superar 10, el resultado es permerror y la comprobación falla de forma permanente, sin volver atrás.

Hay un segundo límite menos citado. Los términos que devuelven una respuesta vacía o NXDOMAIN son búsquedas vacías, y la especificación pide detenerse en dos. Un include: obsoleto que apunta a un proveedor que dejó hace un año es una búsqueda vacía por la que sigue pagando.

Así es como los equipos llegan al techo. Google Workspace aporta un include. Un proveedor transaccional aporta otro. Una plataforma de marketing aporta uno, y dentro anida tres más. Un helpdesk de soporte, un CRM y una herramienta de facturación suman cuatro. Sin haber hecho nada inusual, ya está en 11.

El fallo es silencioso. El correo sigue saliendo, y algunos receptores todavía lo entregan, pero SPF ya no autentica nada por usted. Si depende de la alineación DMARC a través de SPF, esa vía desaparece hasta que aplane el registro o elimine remitentes.

Tres soluciones funcionan, por orden de preferencia:

1. Elimine los remitentes que ya no usa. Audite los includes contra sus informes agregados DMARC de los últimos 90 días.

2. Mueva el tráfico masivo a un subdominio, como mail.example.com, con su propio registro SPF y su propio presupuesto de 10 búsquedas.

3. Aplane los includes en rangos ip4: literales, pero solo con automatización. Los proveedores rotan IPs, y un registro aplanado a mano caduca sin ninguna alerta.

Publique un solo registro SPF por dominio

Un dominio no debe publicar dos registros SPF. Si un receptor encuentra dos entradas TXT con v=spf1, el resultado es permerror, igual que con el límite de búsquedas. Esto pasa cuando una persona añade un registro para una herramienta nueva mientras otra ya tiene uno publicado.

La solución es mecánica. Fusione los términos en un único registro, con un solo v=spf1 al inicio y un solo all al final. Todo lo que la documentación del proveedor le pida añadir va dentro del registro existente como otro include:, nunca como una nueva entrada TXT.

Dos trampas menores. Una cadena TXT de más de 255 caracteres debe partirse en varias cadenas entre comillas dentro del mismo registro, algo que la mayoría de proveedores DNS hace por usted. Y mantenga la respuesta por debajo de unos 450 bytes cuando pueda, porque las respuestas grandes pueden pasar de UDP a TCP y algunos resolvers lo manejan mal.

Softfail o hardfail: elija según lo que pueda ver

El término all es una declaración de política, y el consejo habitual ("use -all") se salta la parte que importa. Un hard fail solo es seguro cuando conoce a todos los remitentes legítimos.

Nuestra regla práctica tras leer trazas:

• ~all mientras sigue inventariando remitentes, o si reenvía correo y no controla la ruta.

• -all cuando los informes DMARC muestren que todas las fuentes legítimas pasan durante algunas semanas.

• Nunca +all, que autoriza a todo Internet, y nunca ?all en un dominio de producción.

En la práctica la diferencia es menor de lo que la gente espera. La mayoría de los grandes receptores tratan SPF como una señal entre varias, y con una política DMARC vigente el veredicto de DMARC es el que decide. Aun así, un -all sobre un registro incompleto es la forma más rápida de perder facturas.

SPF falla con los reenvíos y con la alineación de dominios

SPF valida la IP que se conectó al servidor receptor. Cuando un mensaje se reenvía, una lista de correo lo redistribuye o un servicio de alias lo retransmite, la IP conectada es la del reenviador, no la suya. La comprobación SPF falla aunque usted no haya hecho nada mal.

No puede resolverlo dentro de SPF. Por eso existe DKIM junto a él: una firma sobrevive al salto, una lista de IPs no. Un dominio que depende solo de SPF verá fallos de autenticación en cada mensaje reenviado, y por la misma razón SPF solo no cumple DMARC en el correo reenviado. Planifique que DKIM transporte esos mensajes.

Un mensaje puede pasar SPF y aun así fallar DMARC. DMARC necesita que el dominio que pasó SPF, el dominio de Return-Path, coincida con el dominio visible del From. Muchos proveedores compartidos usan por defecto su propio dominio de rebotes, así que SPF pasa para provider-mail.net y no dice nada sobre example.com.

Compruébelo en las cabeceras originales. En la línea Authentication-Results, mire smtp.mailfrom=. Si no es su dominio ni un subdominio suyo, SPF pasa sin ayudarle.

El remedio es un Return-Path personalizado en un subdominio propio, algo que la mayoría de remitentes serios soporta. Postmark, Resend, Mailgun y SendGrid documentan esta configuración, aunque no siempre viene activada por defecto.

Los proveedores de bandeja ya exigen autenticación a todos los remitentes

Desde febrero de 2024, Google exige que todos los remitentes se autentiquen con SPF o DKIM, y los remitentes que envían más de 5.000 mensajes diarios a Gmail deben tener SPF, DKIM y DMARC. Los detalles están en las directrices de Google para remitentes de correo. Yahoo fijó reglas equivalentes en el mismo periodo.

Esto convirtió SPF de algo "conveniente" en un requisito de entrega. Un registro ausente o roto ya se traduce en rechazos y en spam, no solo en una peor puntuación de reputación.

Según nuestra lectura tras un par de años de trazas, las reglas sobre todo detectan dominios sin ninguna autenticación y remitentes con tasas altas de quejas por spam. Un registro SPF correcto por sí solo no le lleva a la bandeja de entrada, pero uno ausente le mantendrá fuera.

Cómo comprobar y corregir un registro SPF en cuatro pasos

Hágalo en orden y vuelva a comprobar después de cada cambio en el DNS.

1. Consulte el registro actual. Ejecute dig +short TXT example.com y localice la entrada que empieza por v=spf1. Si hay dos, fusiónelos.

2. Cuente las búsquedas. Sume include, a, mx, exists, redirect y todo lo anidado dentro de los includes. Si llega a 8 o más, planifique la limpieza ahora, no en la undécima.

3. Liste los remitentes reales. Use los informes agregados DMARC o las cabeceras Authentication-Results de envíos de prueba. Añada solo las fuentes que aparezcan.

4. Envíe una prueba y lea la cabecera. El resultado debe mostrar spf=pass con smtp.mailfrom en su dominio.

Los cambios en DNS tardan en propagarse, y el TTL de su registro actual decide cuánto sobreviven las respuestas antiguas. Bájelo a 300 segundos un día antes de un cambio planificado.

Un registro de ejemplo para una empresa SaaS con tres remitentes

Tomemos un producto que envía desde Google Workspace, un proveedor transaccional y un helpdesk de soporte. Un registro limpio se ve así:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Son tres includes, y cada uno esconde sus propias búsquedas anidadas. Cuéntelas antes de publicar, porque la longitud visible no dice nada del presupuesto real. Un registro con tres includes puede estar ya en 7 u 8 búsquedas.

Ahora sepárelo por finalidad. Mantenga el correo humano en el dominio raíz. Ponga las notificaciones del producto en notify.example.com con un registro que solo liste al proveedor transaccional. El registro raíz queda corto, el subdominio tiene su propio presupuesto de 10 búsquedas, y un problema de reputación en un flujo ya no arrastra al otro.

Esta división también hace legibles los informes DMARC. Cada flujo tiene su propio dominio de Return-Path, así que un fallo apunta a un remitente concreto en lugar de a un montón.

Lo que SPF no hace

No impide que alguien suplante su dirección From, porque nunca mira esa cabecera. No cifra nada. No le dice por qué un mensaje acabó en spam. Y no escala más allá del presupuesto de 10 búsquedas sin mantenimiento continuo.

Trátelo como uno de tres registros que se publican juntos: SPF para la ruta de envío, DKIM para la integridad del mensaje, DMARC para la política que los vincula con su dominio From. Si solo tiene SPF y nada más, el siguiente paso concreto es publicar un registro DMARC con p=none y leer los informes durante dos semanas.