Correo electrónico: las inclusiones de SPF son un desastre — cómo simplificar sin afectar la entrega de correo

Por qué las inclusiones de SPF se vuelven feas (y por qué importa)

SPF es simple en espíritu: publicar qué hosts están autorizados para enviar correo por un dominio. El problema es cómo SPF expresa esa simplicidad: un lenguaje de políticas que puede desencadenar consultas DNS durante la evaluación, y un techo estricto en cuántas puedes hacer.

Ese techo es el centro de la mayoría del dolor de SPF: el “límite de 10 búsquedas DNS”. Si la evaluación de SPF necesita más de 10 consultas DNS, los evaluadores deberían devolver permerror (error permanente), y muchos receptores interpretan eso como “esta política está rota, así que vamos a ser escépticos”. Escéptico es el término educado del correo para “tu mensaje tomará la ruta panorámica al buzón, si es que llega”.

Aquí está por qué las inclusiones se convierten en un desastre:

• Las inclusiones son transitivas. Cada include: puede a su vez incluir otros registros SPF, cada uno provocando más consultas. No controlas lo que tu proveedor añade después.
• Las inclusiones ocultan trabajo. Tu registro SPF parece corto, pero la política efectiva puede ser una pequeña novela de DNS.
• Los terceros cambian constantemente. Los proveedores modifican infraestructura. Su SPF cambia. A veces añaden más inclusiones anidadas. Heredas su complejidad.
• Tú sigues añadiendo remitentes. Nadie borra herramientas antiguas. Solo “pausan campañas”. Lo cual en lenguaje corporativo significa “volveremos en 18 meses”.

Operativamente, SPF es un problema de grafo de dependencias. No es un problema de cadena. Trátalo como gestión de dependencias: inventario, fija tus requisitos, reduce dependencias opcionales y monitoriza la deriva.

Un chiste corto, como limpieza de paladar: Los registros SPF son como los chats de grupo: cada nuevo “include” parece inofensivo hasta que tu teléfono se incendia.

Cómo se ve realmente “romper el correo”

Rara vez obtienes una caída limpia. Obtienes una hemorragia lenta:

• Los nuevos registros dejan de recibir correo de verificación en ciertos ISP.
• Los correos de ventas empiezan a llegar a spam “de repente” (traducción: llevaba semanas pasando).
• Los informes DMARC muestran aumento de fallos SPF desde fuentes legítimas que habías olvidado.
• Los tickets de soporte llegan con códigos de rebote que varían según el receptor y el humor.

SPF no es la única señal que usan los receptores, pero es una señal fundamental. Si está roto, todo lo demás tiene que trabajar más. Y en correo, “más” significa “menos confiable”.

Hechos interesantes y breve historia

Seis a diez puntos de contexto pequeños, porque entender de dónde viene SPF hace que el desastre actual parezca… inevitable.

1. SPF precede a la dispersión moderna del correo en la nube. Fue diseñado cuando “tus servidores de salida” eran un conjunto pequeño y mayormente estático.
2. El límite de 10 búsquedas es deliberado. Es una protección anti-abuso y anti-DoS: los receptores no deben verse forzados a trabajo DNS sin límite por mensaje.
3. “Include” es efectivamente un salto condicional. include: dice “si el remitente pasa esa otra política, trátalo como un pass aquí”. No es solo una fusión de listas.
4. SPF verifica el dominio del envelope-from, no el encabezado From: Esto sorprende aún a gente en 2026, y es la razón por la que existe DMARC para alinear identidad.
5. SPF puede fallar con el reenvío. El reenvío clásico a menudo rompe SPF porque el host reenviador no está autorizado por el SPF del dominio original.
6. Los receptores discrepan en comportamientos límite. La especificación es clara en muchas cosas, pero el manejo real de permerror, temperror y respuestas DNS ambiguas varía.
7. El TTL de DNS es una palanca operativa. TTL cortos te ayudan a desplegar cambios rápido, pero aumentan el tráfico DNS; TTL largos hacen que los errores perduren.
8. El “aplanamiento” de SPF se volvió una industria casera. Porque las cadenas de include de proveedores se hicieron demasiado profundas, la gente empezó a pre-resolver includes a IP concretas—algunas veces seguro, otras no.
9. SPF está ampliamente desplegado porque es barato. Publicar un registro TXT es más fácil que gestionar claves (DKIM) o forzar alineación (DMARC), así que SPF a menudo se convierte en el control “primero y único”.

Un modelo mental: cómo se evalúa realmente SPF

Cuando un receptor evalúa SPF, está ejecutando un pequeño programa: empieza con el dominio en el sobre SMTP (MAIL FROM) y pide a DNS la política SPF de ese dominio (usualmente vía un registro TXT que empieza con v=spf1). Luego comprueba los mecanismos de izquierda a derecha hasta que uno coincide y devuelve un resultado.

Los mecanismos que importan para las inclusiones

• include: obliga al evaluador a obtener y evaluar el SPF del dominio incluido. Eso cuesta consultas DNS (al menos una consulta TXT, además de lo que desencadene el registro incluido).
• a y mx también pueden provocar búsquedas. Si tu registro usa mx, la evaluación de SPF necesita consultar MX y luego resolver A/AAAA para cada objetivo MX.
• exists provoca búsquedas, y puede ser abusado. Trátalo como sospechoso a menos que tengas una razón muy buena.
• ptr está obsoleto por buenas razones (rendimiento y suplantación). Si aún lo tienes, cargas deuda histórica con interés.
• ip4/ip6 son “gratis” desde la contabilidad de búsquedas DNS. No requieren consultas durante la evaluación. Aun así pueden ser operativamente costosos de mantener.
• redirect= es como “reemplaza toda mi política por la de este otro dominio”. Puede ser útil para centralizar SPF para subdominios.

Por qué el límite de búsquedas golpea más duro de lo que esperas

El límite cuenta ciertos mecanismos y modificadores que causan consultas DNS: include, a, mx, ptr, exists y redirect. Lo que parece “un include” puede ser “un include más cinco MX más ocho resoluciones A/AAAA”.

Además, la evaluación SPF puede implicar tanto consultas A como AAAA. Incluso si no usas IPv6 intencionalmente, tu DNS podría publicar registros AAAA o tu proveedor podría hacerlo, y algunos evaluadores consultan ambos.

Opinión: si no puedes explicar el recuento de búsquedas de tu registro SPF en una pizarra de memoria, no lo posees. Lo estás alquilando al azar.

Una cita de fiabilidad (parafraseada)

Idea parafraseada (Werner Vogels, AWS): “Diseña para esperar fallos, y construye sistemas que sigan funcionando cuando partes fallan.” Las inclusiones SPF son partes.

Guía de diagnóstico rápido

Esto es lo que haces cuando la entregabilidad está en llamas y alguien acaba de pegar un mensaje de rebote en Slack.

Primero: identifica qué identidad está fallando

1. Revisa el dominio MAIL FROM / Return-Path en los encabezados del mensaje fallido (o en la configuración del sistema remitente). SPF se evalúa contra eso, no contra el From visible.
2. Confirma la IP de envío desde los encabezados Received o los logs de tu MTA.
3. Pregunta: ¿es un remitente nuevo o un camino reenviado? Remitente nuevo sugiere brecha de inventario SPF; reenvío sugiere que SPF fallará por diseño y necesitarás estrategia DKIM/DMARC.

Segundo: determina si es “política incorrecta” o “política rota”

1. Consulta el registro TXT SPF y confirma que haya exactamente una política SPF para ese dominio.
2. Cuenta las búsquedas DNS (o al menos identifica la profundidad de la cadena de include). Si estás cerca o por encima de 10, asume permerror en el campo.
3. Revisa problemas DNS: NXDOMAIN, SERVFAIL, timeouts o sorpresas de split-horizon.

Tercero: elige la mitigación menos arriesgada

1. Si el límite de búsquedas es el problema: elimina includes no esenciales, mueve un remitente a un subdominio con su propio SPF, o autoriza temporalmente un rango de IP concreto con ip4/ip6 (con ticket de cambio estricto para eliminarlo después).
2. Si la IP remitente simplemente falta: añade la autorización correcta, pero solo después de verificar que el sistema realmente envía con ese dominio en el envelope-from.
3. Si esto es una rotura por reenvío: no “arregles” SPF autorizando al reenviador; es jugar al gato y al ratón. Usa DKIM/DMARC y/o ARC cuando aplique.

Una regla: no “optimices” mientras diagnosticas. Estabiliza primero, luego simplifica.

Tareas prácticas: comandos, salidas y decisiones

Estas son tareas reales de operador. Cada una incluye un comando, una salida de ejemplo, lo que significa y la decisión siguiente. Ejecútalas desde un host Linux con herramientas estándar. Si no tienes estas herramientas, instálalas en una jump box, no en tus servidores de correo en medio de un incidente.

Task 1: Fetch the SPF record (and see if you have multiple)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
"google-site-verification=abc123"

Qué significa: Hay exactamente una cadena de política SPF (la que comienza con v=spf1). Bien.

Decisión: Si ves más de una cadena v=spf1 devuelta, debes consolidarlas; múltiples registros SPF comúnmente causan permerror.

Task 2: Confirm the envelope-from domain in a message (local MTA)

cr0x@server:~$ postcat -q 1A2B3C4D | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_arrival_time: Tue Jan  2 12:01:09 2026
original_recipient: user@example.net
sender: bounce@mailer.example.com
*** MESSAGE CONTENTS ***
Return-Path: <bounce@mailer.example.com>
From: "Example Billing" <billing@example.com>
To: user@example.net
Subject: Invoice

Qué significa: SPF se evaluará contra mailer.example.com (Return-Path / sender), no contra example.com del From visible.

Decisión: Audita SPF para el dominio de envelope que realmente envía, no el que marketing cree que usa.

Task 3: Get a quick SPF validation signal via OpenSSL (SMTP banner sanity)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx1.receiver.net:25 </dev/null | sed -n '1,15p'
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R3
verify return:1
depth=0 CN=mx1.receiver.net
verify return:1
250 mx1.receiver.net ESMTP ready

Qué significa: No es SPF directamente, pero confirmas que puedes alcanzar un receptor y que la negociación TLS no es el problema real en las pruebas.

Decisión: Si la conectividad/TLS falla, arregla eso antes de culpar a SPF. Las “caídas” de entregabilidad a veces empiezan con tu propia red.

Task 4: Inspect SPF includes recursively (basic)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:74.125.0.0/16 ip4:173.194.0.0/16 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Qué significa: Ese solo include se expande a tres includes más más múltiples rangos IP.

Decisión: Empieza a construir un árbol de includes y un recuento de búsquedas. Si ya estás incluyendo dos proveedores grandes, probablemente estés cerca del límite.

Task 5: Count how many SPF strings exist (guard against accidental duplication)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
1

Qué significa: Un registro SPF. Genial.

Decisión: Si la salida es 2 o más, consolida en uno. Elimina los extras. No intentes “dividir” SPF entre registros; SPF no funciona así.

Task 6: Check if a subdomain already has its own SPF record

cr0x@server:~$ dig +short TXT mailer.example.com
"v=spf1 include:spf.vendor-mail.com -all"

Qué significa: El proveedor ya soporta el envío desde un subdominio delegado con SPF separado.

Decisión: Prefiere mover remitentes de proveedores a su propio subdominio SPF en lugar de inflar el dominio apex.

Task 7: Find MX records (and realize mx can cost you lookups)

cr0x@server:~$ dig +short MX example.com
10 mx01.mailhost.example.net.
20 mx02.mailhost.example.net.

Qué significa: Si tu registro SPF usa mx, la evaluación puede resolver estos nombres y sus registros A/AAAA. Eso son múltiples búsquedas.

Decisión: Evita mx en SPF a menos que realmente envíes desde tus hosts MX de entrada (raro en arquitecturas modernas).

Task 8: Resolve A and AAAA for MX targets (lookup budgeting)

cr0x@server:~$ dig +short A mx01.mailhost.example.net
203.0.113.10
203.0.113.11

cr0x@server:~$ dig +short AAAA mx01.mailhost.example.net
2001:db8:10::10

Qué significa: Múltiples direcciones implican trabajo adicional de resolución para los evaluadores. Algunos consultan ambos A y AAAA.

Decisión: Si planeabas usar mx o a en SPF, considera ip4/ip6 explícitos en su lugar para previsibilidad (con un plan de mantenimiento).

Task 9: Measure DNS response time and detect flaky resolution

cr0x@server:~$ dig example.com TXT +stats | tail -n 5
;; Query time: 142 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Jan  2 12:20:11 UTC 2026
;; MSG SIZE  rcvd: 232

Qué significa: 142 ms no es terrible, pero si tus inclusiones requieren muchas búsquedas, la latencia se compone. Si ves segundos, tienes un problema de DNS.

Decisión: Si DNS es lento o falla, la evaluación SPF se vuelve poco confiable. Arregla la salud DNS (autoritativos, resolvers, timeouts) antes de “simplificar” SPF.

Task 10: Check authoritative vs recursive answers (split-horizon traps)

cr0x@server:~$ dig @ns1.example-dns.net example.com TXT +norecurse +short
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Qué significa: Estás viendo lo que publica el servidor autoritativo. Si esto difiere de la respuesta de tu resolver interno, tienes DNS split-horizon o problemas de caché.

Decisión: Asegúrate de que el registro autoritativo público sea correcto; los receptores usan DNS público, no tu vista interna.

Task 11: Spot a broken include target (NXDOMAIN/SERVFAIL)

cr0x@server:~$ dig +short TXT spf.dead-vendor.example

Qué significa: Salida vacía normalmente significa NXDOMAIN o sin TXT. Ese include fallará la evaluación dependiendo del comportamiento del receptor y la interpretación de la especificación.

Decisión: Elimina includes muertos inmediatamente. Si aún necesitas ese remitente, reemplaza el include por su dominio soportado actual o por IPs explícitas.

Task 12: Detect oversize SPF TXT strings (DNS limits and quoting)

cr0x@server:~$ dig +short TXT example.com | awk 'length($0) {print length($0), $0}'
92 "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
33 "google-site-verification=abc123"

Qué significa: Los registros TXT pueden dividirse en múltiples cadenas entrecomilladas por servidores DNS; algunas herramientas y personas manejan mal esto. Los registros SPF grandes también pueden exceder límites prácticos y quedar dañados.

Decisión: Mantén SPF compacto. Si te acercas a límites de tamaño o ves cadenas divididas, eso es un olor: simplifica por arquitectura, no intentando meter más texto.

Task 13: Validate that a given IP would pass SPF (local check with spfquery)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@mailer.example.com -helo mailer.example.com
pass

Qué significa: Para este dominio de envelope e IP, SPF debería pasar.

Decisión: Si falla, arregla SPF o la configuración del remitente. Si pasa localmente pero falla en receptores, sospecha propagación DNS, límites de búsquedas o diferencias de resolvers.

Task 14: Check DMARC alignment clues (to avoid “fixing” the wrong layer)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@reports.example.com; adkim=s; aspf=s"

Qué significa: Se requiere alineación estricta tanto para DKIM como para SPF. Si tu dominio de envelope difiere del dominio From, SPF puede pasar pero aun así no alinear.

Decisión: Al simplificar SPF, ten en cuenta la arquitectura de identidades: alinea remitentes al subdominio correcto o asegúrate de que DKIM esté alineado.

Task 15: Check recent mail logs for “SPF permerror” patterns (Postfix example)

cr0x@server:~$ sudo grep -i "spf" /var/log/mail.log | tail -n 8
Jan  2 12:12:41 mx postfix/smtpd[22191]: warning: SPF: permerror (too many DNS lookups) identity=mailfrom; client-ip=198.51.100.77; helo=mailer.example.com; envelope-from=bounce@mailer.example.com; receiver=mx
Jan  2 12:13:02 mx postfix/smtpd[22191]: warning: SPF: fail identity=mailfrom; client-ip=203.0.113.55; envelope-from=noreply@example.com

Qué significa: Tienes tanto una violación del límite de búsquedas como un fallo directo para otra identidad. Dos problemas distintos, misma semana. Clásico.

Decisión: Prioriza permerror primero; puede hundir la entregabilidad incluso para tráfico legítimo. Luego maneja remitentes individuales faltantes.

Task 16: Verify TXT changes propagate (watch TTL and caching)

cr0x@server:~$ dig example.com TXT +noall +answer
example.com.  300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Qué significa: TTL es 300 segundos (5 minutos). Eso es amable con incidentes.

Decisión: Para migraciones planificadas, baja el TTL un día antes si puedes. Para operaciones estables, súbelo para reducir carga en resolvers y mejorar cache hits.

Estrategias de simplificación que no rompen producción

El objetivo no es “SPF corto”. El objetivo es “SPF predecible que se mantenga bajo los límites, sobreviva a cambios de proveedores y coincida con cómo sale realmente el correo”. Ser corto es un efecto secundario.

1) Deja de tratar el dominio apex como cajón de sastre

Coloca a los remitentes de terceros en subdominios siempre que sea posible. Este es el movimiento de mayor palanca. Ejemplos:

• mailer.example.com para automatización de marketing
• support.example.com para ticketing
• notify.example.com para notificaciones de producto

Luego publica registros SPF separados por subdominio. Tu SPF del apex se mantiene ligero: solo la infraestructura que realmente envía mail como @example.com.

Compromiso: Debes garantizar que los dominios visibles From y DKIM se alineen con tu política DMARC, o arreglarás SPF y aun así fallarás DMARC.

2) Prefiere redirect= para consistencia across una flota de subdominios

Si posees muchos subdominios que deberían compartir el mismo SPF, centralízalo:

• v=spf1 redirect=_spf.example.com
• Y luego define la política real en _spf.example.com

Esto no reduce búsquedas por arte de magia, pero reduce errores administrativos. Es una simplificación del plano de control, no del plano de datos.

3) Sé implacable eliminando remitentes obsoletos

La mayoría de organizaciones mantienen includes para proveedores que dejaron de usar hace años. Las inclusiones te cuestan presupuesto de búsquedas y aumentan el radio de impacto de cambios del proveedor.

Movimiento operativo: exige un “propietario” para cada include con una re-certificación trimestral. Sin propietario, no hay include.

4) Evita mx y a a menos que realmente los necesites

mx en SPF es un truco clásico legado: “si puede recibir nuestro correo, puede enviarlo también”. En entornos modernos, entrada y salida son separadas. Usar mx en SPF suele autorizar hosts que nunca deberían enviar como tú.

Recomendación: Si tienes un pool de salida pequeño y estable, usa ip4/ip6 explícitos. Si no, usa subdominios e includes de proveedores. No uses mx como atajo perezoso.

5) Aplanamiento: útil, arriesgado, a veces necesario

“Aplanar” significa reemplazar includes por los rangos IP resultantes (ip4/ip6) para que la evaluación SPF no necesite tantas consultas DNS. Esto puede ser efectivo para mantenerse bajo el límite de 10 búsquedas.

Pero el aplanamiento tiene aristas:

• Los rangos IP de proveedores pueden cambiar sin aviso. Tu registro aplanado queda obsoleto y fallas correos legítimos.
• Listas IP grandes hacen registros TXT largos y más propensos a errores al editar.
• Puedes autorizar por accidente más de lo debido si aplanas demasiado amplio.

Cuándo el aplanamiento es aceptable: para remitentes con rangos IP publicados y estables y con un proceso de control de cambios en tu lado para actualizarlos regularmente. Trátalo como actualizar reglas de firewall: programado, revisado y monitorizado.

Segundo chiste corto: Aplanar SPF es como preparar comidas: ahorra tiempo durante la semana, hasta que lo olvidas en la nevera y se convierte en un proyecto de ciencia.

6) Haz de SPF un producto: versionarlo, probarlo y estrenarlo por etapas

Los cambios SPF deben pasar por la misma disciplina que la configuración de producción:

• Mantén el registro en git (como texto, más un comentario que explique en el repo).
• Tener un arnés de pruebas que cuente búsquedas y valide sintaxis.
• Usar un despliegue en etapas mediante TTL reducido, luego desplegar y monitorizar informes DMARC y patrones de rebote.

7) Alinea la arquitectura de identidades con DMARC, no en su contra

Los equipos a menudo intentan arreglar la entregabilidad metiendo más cosas en SPF, cuando el problema real es la desalineación de identidad. Si tu política DMARC es estricta, debes asegurar o bien:

• SPF pasa y se alinea (el dominio de envelope se alinea con el dominio From), o
• DKIM pasa y se alinea (d= dominio se alinea con From)

Eso frecuentemente te empuja hacia “cada remitente usa su propio subdominio, con DKIM alineado”, lo que además reduce la complejidad SPF en el apex. Qué curioso que buena arquitectura resuelva varios problemas a la vez.

Tres microhistorias corporativas desde las trincheras SPF

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana enviaba correo desde tres lugares: Google Workspace para humanos, un proveedor transaccional para correo de producto y una plataforma de marketing para campañas. Su SPF en el apex ya era pesado, pero aún pasaba la mayoría de las veces, que es la forma en que el correo fomenta el mal comportamiento.

Se lanzó una nueva integración: “Enviar invitaciones desde tu dominio de empresa”. Ingeniería asumió que eso significaba añadir una clave DKIM y firmar como example.com. Suposición razonable. El equipo de integración configuró al proveedor para usar bounce@vendor.example.net como remitente del sobre porque era el valor por defecto, y nadie preguntó qué “identidad SPF” se evaluaría.

Dos semanas después, las invitaciones de clientes empezaron a rebotar en un gran receptor. La razón del rebote hacía referencia a fallos SPF para vendor.example.net, no para example.com. Soporte escaló a SRE. SRE miró el SPF del apex durante diez minutos antes de darse cuenta de que era irrelevante para este fallo. Dominio equivocado. Identidad equivocada.

La solución no fue “añadir otro include”. Fue mover el remitente del proveedor a mailer.example.com y publicar un SPF dedicado para ese subdominio. La alineación DKIM se actualizó para coincidir. El incidente terminó rápido, pero el postmortem fue claro: no puedes razonar sobre autenticación de correo mirando solo el encabezado From y vibras.

Microhistoria 2: La optimización que salió mal

Un equipo de TI empresarial decidió “limpiar DNS”. Notaron que su registro SPF usaba include: para un proveedor que, al inspeccionarlo, se expandía a muchos rangos ip4. Habían oído hablar del aplanamiento SPF, y sonó como una mejora de rendimiento. Así que lo aplanaron manualmente.

Al principio, se vio genial: menos búsquedas DNS, cadena de includes más corta, menos tickets intermitentes de temperror desde receptores con timeouts estrictos. Declararon victoria y siguieron. Un mes después, una goteo lento de reportes “restablecimiento de contraseña no llegó” empezó a aparecer, desde un subconjunto de proveedores de correo de consumo.

El proveedor había añadido nuevas IPs de envío. El include se actualizó. El registro aplanado no. El correo no fallaba en todas partes; fallaba lo suficiente como para ser costoso y difícil de probar. Nadie quería revertir porque el SPF aplanado se había presentado como una mejora de seguridad. No era mentira, pero no era toda la verdad.

Eventualmente reconstruyeron el enfoque: el aplanamiento se automatizó con refresco programado, los cambios se diffearon y revisaron, y la lista se limitó sólo a los servicios del proveedor realmente en uso. El problema no fue aplanar en sí. Fue aplanar sin tratarlo como una dependencia viva.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía global tenía reputación de ser “lenta” para cambios de correo. Cada actualización SPF requería un propietario, un ticket, un plan de rollback y un periodo de observación de 24 horas. La gente se quejaba. Marketing se quejaba más fuerte. Es el orden natural de las cosas.

Una mañana, un proveedor conocido tuvo una caída de DNS. Su dominio include SPF devolvía intermitentemente SERVFAIL. Muchos clientes vieron temperror durante la evaluación SPF. Algunos receptores diferían el correo. Otros lo trataron como sospechoso. Caos, pero caos educado.

Esta compañía tenía dos ventajas: (1) su SPF del apex tenía sólo un include de terceros, porque casi todo el correo de proveedores usaba subdominios delegados, y (2) tenían monitorización que muestreaba resolución SPF desde múltiples resolvers públicos y alertaba sobre SERVFAIL y anomalías en el recuento de búsquedas.

La respuesta fue aburrida: enrutar temporalmente el correo transaccional crítico a través de un proveedor secundario ya autorizado en un subdominio, y esperar la recuperación del DNS del proveedor. No hubo ediciones de pánico al SPF del apex. No hubo “simplemente añade este include” a las 9 a.m. El post-incident review fue igualmente aburrido: documentaron la dependencia del proveedor y mantuvieron la arquitectura. Aburrido, en sistemas productivos, es un cumplido.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: fallos intermitentes, a veces “permerror”

Causa raíz: demasiadas búsquedas DNS debido a includes anidados, más mecanismos mx/a dentro de cadenas de include.

Solución: reduce dependencias: mueve proveedores a subdominios, elimina includes obsoletos, evita mx/a en SPF, considera aplanamiento gestionado con refresco.

2) Síntoma: “SPF fail” pero juras que el dominio From es correcto

Causa raíz: estás mirando el encabezado From; SPF está comprobando el dominio envelope-from (Return-Path).

Solución: inspecciona encabezados/logs para encontrar MAIL FROM. Corrige la configuración del dominio de envelope o publica SPF para el dominio de envelope real.

3) Síntoma: SPF se rompe de repente tras una “pequeña limpieza DNS”

Causa raíz: existen múltiples registros SPF (múltiples cadenas TXT v=spf1), o alguien editó comillas/espacios y rompió el parseo.

Solución: publica exactamente una política SPF por dominio; valida con herramientas; mantén SPF en control de versiones.

4) Síntoma: el reenvío de correo causa fallos SPF

Causa raíz: los reenviadores envían desde sus propias IPs; el SPF del dominio original no los autoriza.

Solución: no autorices al mundo. Usa DKIM firmado con alineación, más DMARC. Para reenviadores/receptores que lo soporten, ARC puede preservar resultados de autenticación.

5) Síntoma: SPF pasa pero DMARC falla

Causa raíz: SPF pasa para un dominio de envelope que no se alinea con el From bajo DMARC (especialmente con alineación estricta).

Solución: alinea identidades: usa un dominio de envelope coincidente (a menudo un subdominio del From) y/o asegura que DKIM d= se alinee con From.

6) Síntoma: SPF funciona para remitentes IPv4, falla misteriosamente en algunos receptores

Causa raíz: estás enviando sobre IPv6 desde algunos hosts, pero SPF solo autoriza IPv4, o la cadena de includes se comporta distinto con consultas AAAA y timeouts.

Solución: inventaría las IPs reales de envío incluyendo IPv6; autoriza ip6: según sea necesario; asegura que los MTAs salientes no estén filtrando caminos IPv6 inesperados.

7) Síntoma: el correo de un proveedor falla solo para algunas regiones

Causa raíz: aplanaste SPF y perdiste nuevos pools de IP del proveedor, o el proveedor tiene múltiples dominios include para diferentes productos y incluiste el equivocado.

Solución: revierte al include del proveedor si puedes permitirte el presupuesto de búsquedas, o implementa refresco automatizado del aplanamiento con revisión; verifica que usas el include correcto para el nivel de producto.

8) Síntoma: los receptores reportan “temperror” en SPF

Causa raíz: timeouts DNS, SERVFAIL o servidores autoritativos inestables para tu dominio o para algún include.

Solución: endurece DNS (redundancia autoritativa, salud de resolvers), reduce el recuento de búsquedas para gastar menos tiempo en DNS, monitoriza desde múltiples resolvers públicos.

Listas de verificación / plan paso a paso

Paso a paso: simplificar inclusiones SPF de forma segura

1. Inventario de remitentes. Lista cada sistema que envía correo usando tu marca: buzones humanos, transaccional, marketing, soporte, finanzas, monitorización, CI y “invitaciones de producto”. Asigna propietario a cada uno.
2. Para cada remitente, captura identidades. Dominio From, dominio envelope-from, dominio DKIM d=, rangos IP de envío (v4/v6) y si soporta return-path personalizado.
3. Dibuja el grafo de dependencias SPF actual. SPF del apex más todos los includes, y los includes dentro de esos includes. Cuenta las búsquedas DNS estimadas.
4. Decide la estrategia de dominios. ¿Qué remitentes realmente necesitan enviar como @example.com? Todo lo demás va a subdominios delegados.
5. Mueve un remitente a la vez a un subdominio. Configura al proveedor para usar bounce@mailer.example.com (o similar), publica SPF para ese subdominio y asegura alineación DKIM.
6. Mantén el SPF del apex mínimo. Usualmente: proveedor de correo corporativo + proveedor transaccional principal, y solo si deben usar el dominio apex.
7. Elimina includes obsoletos. Si una herramienta “no está activa”, elimínala. Si alguien se queja después, pueden re-autorizarlas intencionalmente con diseño apropiado.
8. Baja el TTL antes de cambios grandes. Haz esto al menos un día antes si puedes. Sube el TTL después de estabilizar.
9. Valida sintaxis y presupuesto de búsquedas. Ejecuta pruebas de evaluación SPF para IPs e identidades representativas.
10. Despliega y observa. Observa informes DMARC agregados y rebotes entrantes. Espera latencia por cachés y cadencia de reportes.
11. Documenta el contrato. Para cada include/subdominio, escribe: propietario, proveedor, por qué existe, qué autoriza y cómo rotarlo.
12. Monitorea la deriva. Las inclusiones pueden cambiar bajo tu espalda. Rastrea recuento de búsquedas y salud DNS como señal continua.

Checklist operativo: antes de añadir cualquier nuevo include:

• ¿Realmente necesita envío desde el dominio apex, o puede ser un subdominio?
• ¿Cuál es el envelope-from del proveedor y soporta return-path personalizado?
• ¿Cuál es nuestro presupuesto actual de búsquedas y qué costará este include cuando se expanda?
• ¿Quién es el propietario de este remitente y se re-certificará trimestralmente?
• ¿Tenemos alineación DKIM que satisfará DMARC?
• ¿Cuál es el rollback si este include causa permerror?

Checklist de emergencia: “Tuvimos permerror”

• Confirma permerror (too many DNS lookups) en logs o feedback del receptor.
• Identifica el último cambio SPF (diff de tus registros DNS).
• Elimina temporalmente el/los include(s) menos críticos para bajar del límite.
• Si la eliminación rompe un remitente crítico, muévelo a un subdominio con su propio SPF como solución real.
• Después de estabilizar, realiza un inventario completo de remitentes y simplifica correctamente.

FAQ

1) ¿Por qué existe el límite de “10 búsquedas DNS” en SPF?

Porque los receptores deben evaluar SPF para enormes volúmenes de correo. Sin un límite, SPF podría ser usado para forzar trabajo DNS excesivo por mensaje, convirtiendo la recepción de correo en una prueba de estrés para DNS.

2) ¿Agregar entradas ip4: cuesta búsquedas DNS?

No. Los mecanismos ip4/ip6 no requieren consultas DNS durante la evaluación SPF. Son baratos para los receptores, pero tú pagas el coste de mantenimiento.

3) ¿Son “malos” a y mx en SPF?

No inherentemente, pero a menudo se usan con pereza y pueden inflar las búsquedas. También tienden a autorizar más hosts de los que pretendías. En 2026, las IP explícitas o subdominios de proveedores suelen ser más seguros.

4) ¿Cuál es la diferencia entre include: y redirect=?

include: dice “si la política incluida pasa, trátala como un match aquí” y la evaluación continúa si no pasa. redirect= dice “usa la política de ese otro dominio como la política para este dominio” (típicamente como el modificador final).

5) ¿Puedo tener múltiples registros TXT SPF para evitar longitud o complejidad?

No. Publicar múltiples registros v=spf1 es un error común y a menudo produce permerror. Necesitas exactamente una política SPF por dominio.

6) Si usamos DMARC, ¿seguimos necesitando SPF?

Sí. DMARC se apoya en que SPF y/o DKIM pasen y se alineen. SPF sigue siendo una entrada primaria, y muchos receptores usan resultados SPF más allá de la evaluación DMARC.

7) ¿Por qué el reenvío rompe SPF y qué hacemos al respecto?

Los reenviadores re-envían desde sus propias IPs, que no están en tu SPF. La solución duradera es firmar con DKIM alineado, más DMARC. En algunos ecosistemas, ARC puede ayudar a preservar autenticación a través del reenvío.

8) ¿Debemos usar ~all o -all?

Usa -all cuando estés seguro de que tu inventario es correcto y estás aplicando. Usa ~all durante migraciones si necesitas telemetría y quieres reducir fallos duros. Pero no dejes ~all para siempre; se vuelve indecisión permanente en DNS.

9) ¿Cuál es la mejor forma de simplificar SPF sin aplanar?

Delegar. Mueve correo de terceros a subdominios con SPF dedicado y DKIM alineado. Mantén el SPF del apex solo para los pocos sistemas que deben enviar como el dominio apex.

10) ¿Cómo monitorizamos la deriva de includes SPF con el tiempo?

Resuelve periódicamente tu registro SPF, recorre las inclusiones y sigue el recuento de búsquedas y fallos DNS desde múltiples resolvers. Alerta sobre cambios, especialmente nuevas inclusiones anidadas o mecanismos como exists.

Conclusión: pasos prácticos siguientes

Si tu registro SPF es un montón de includes, no tienes un registro SPF. Tienes un grafo de dependencias que no estás gestionando. La salida no es kung fu heroico de DNS; es arquitectura y propiedad.

1. Hoy: extrae tu SPF actual, confirma que tienes exactamente un v=spf1 y determina si estás coqueteando con el límite de 10 búsquedas DNS.
2. Esta semana: inventaría remitentes y mueve al menos un remitente importante de terceros a un subdominio delegado con su propio SPF y DKIM alineado.
3. Este mes: establece propiedad por remitente/include, implementa una canalización ligera de validación (síntaxis + presupuesto de búsquedas) y añade monitorización para fallos DNS y desviaciones inesperadas en includes.

SPF no necesita ser perfecto. Necesita ser operable. Manténlo bajo el límite de búsquedas, alineado con cómo sale realmente el correo de tus sistemas y deja de tratar DNS como lugar para esconder complejidad. Tus bandejas de entrada —y tu sueño— mejorarán.