Formato de registros SPF: comillas y espacios que silenciosamente rompen el correo

noviembre 13, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 7

¿Te fue útil?

El correo falla de la manera más insultante: “funciona en su mayoría” hasta que un día deja de hacerlo, y entonces tus directivos aprenden la frase SPF permerror por un mensaje de rebote a las 6:12 a.m.

Esto trata sobre las fallas tontas: las trampas de comillas y espacios en los registros TXT SPF que convierten una política perfectamente válida en un fallo silencioso, un fallo intermitente o una orgía de culpar al proveedor. Si administras sistemas en producción, no necesitas un vago “revisa tu DNS”. Necesitas una lista de verificación, un protocolo de diagnóstico rápido y una opinión firme sobre dónde no se debería permitir que humanos tecleen comillas dobles.

Por qué el formato rompe SPF (incluso cuando el texto parece correcto)

SPF es texto. DNS es texto. A los humanos les encanta el texto. Ese es el problema.

SPF lo evalúan receptores y pasarelas que analizan un registro TXT en una secuencia de mecanismos y modificadores. Las reglas de parseo son estrictas en las maneras aburridas y sorprendentemente permisivas en las maneras confusas. El resultado: un registro puede verse bien en la interfaz del proveedor DNS, verse bien en una captura de pantalla y aun así ser interpretado de forma diferente entre resolvers, librerías y receptores de correo.

Los errores de formato caen en unos pocos cubos:

Presentación DNS vs formato wire del DNS: herramientas como dig muestran comillas; los proveedores DNS almacenan cadenas; las librerías unen “character-strings”. Las personas copian las comillas en el valor y publican comillas literales por accidente.
Espacios en blanco y tokenización: los mecanismos SPF se separan por espacios. Los espacios extra suelen tolerarse, pero no siempre donde crees. Tabs, espacios no separables y el “formateo inteligente” de las UIs pueden crear tokens que no se parsean como esperas.
División entre cadenas: el RDATA TXT de DNS puede contener múltiples character-strings. Muchos proveedores dividen valores largos. El procesamiento SPF las concatena sin añadir espacios. Si la división ocurre en el lugar equivocado, puedes soldar dos tokens en uno inválido.
Varios registros SPF: más de una política SPF en el mismo nombre es error de protocolo. No es “escoge uno”. Es “algunos receptores lo tratan como permerror y fallan SPF”.
Búsquedas e redirects: no es formato, pero aparece en la misma cola de incidentes. Includes/redirects explotan el conteo de búsquedas DNS y SPF devuelve permerror. La gente suele “arreglar” esto aplanando, lo que introduce nuevos peligros de formato.

Otra razón por la que duele: los fallos SPF no siempre rebotan el correo. Muchos receptores tratan SPF como una señal, no como una puerta rígida, especialmente cuando la política DMARC es laxa. Así que no verás una caída limpia: solo “problemas de entregabilidad”, colocación en carpeta de spam y una pérdida lenta de confianza.

Protocolo de diagnóstico rápido (primero/segundo/tercero)

Cuando estás de guardia y un directivo reenvía “¿Por qué este proveedor dice que nuestro correo está suplantado?” no necesitas filosofía. Necesitas un orden de triage que converja.

Primero: verifica lo que realmente está publicado (no lo que muestra la UI de tu DNS)

Consulta TXT en el dominio exacto usado en MAIL FROM / Return-Path (a menudo un subdominio). Muchas organizaciones editan example.com pero el remitente usa bounces.example.com.
Cuenta registros SPF: si hay más de un valor TXT con v=spf1, trátalo como un incendio hasta demostrar lo contrario.
Busca artefactos de comillas: caracteres de comilla al inicio o al final dentro de la cadena publicada, y “comillas escapadas” que vinieron de copiar/pegar.

Segundo: evalúa cómo lo parsearán los receptores

Une cadenas TXT divididas y vuelve a comprobar las fronteras de los tokens (especialmente alrededor de include:, ip4:, redirect= y calificadores como ~all).
Ejecuta una evaluación SPF contra una IP conocida del remitente (o al menos valida la sintaxis). No asumas que “se ve bien” significa “se parsea bien”.
Comprueba el conteo de búsquedas DNS si estás cerca del límite; un include nuevo puede empujarte por encima de 10.

Tercero: confirma qué falló en la práctica

Obtén una cabecera real de un destinatario que falló mostrando Authentication-Results. Eso es el receptor diciéndote cómo interpretó tu SPF.
Compara entre receptores (Gmail vs Microsoft vs una pasarela de seguridad). Si uno dice “permerror” y otro dice “none”, probablemente tienes múltiples registros, división o problemas de resolver.
Revisa propagación y caché antes de seguir cambiando registros como una tragamonedas.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla, todo el tiempo”. Los fallos de formato SPF son solo la versión con sabor a correo de esa verdad.

Hechos y contexto histórico (las cosas raras que importan)

SPF nació como “Sender Permitted From” a principios de los 2000, creado para combatir la suplantación y el spam desenfrenado; más tarde pasó a llamarse “Sender Policy Framework”. Los nombres importan menos que la mecánica DNS.
SPF se publica en registros TXT del DNS en gran parte por compatibilidad retroactiva. Hubo un tipo de RR dedicado a SPF, pero TXT ganó la guerra de despliegue.
Los registros TXT de DNS pueden contener múltiples “character-strings” (fragmentos). Las herramientas los muestran con comillas, lo que engaña a humanos haciéndoles pensar que las comillas son parte del valor.
SPF tiene un límite estricto de 10 búsquedas DNS durante la evaluación (para mecanismos como include, a, mx, ptr, exists y redirect). Una herramienta de marketing entusiasta puede condenarte.
SPF verifica el dominio del remitente de sobre (envelope sender) (MAIL FROM / Return-Path), no el encabezado “From:” que ven los usuarios. Por eso SPF puede pasar mientras el phishing sigue funcionando.
DMARC depende de la alineación entre SPF (dominio del sobre) y el From del encabezado, o de la alineación DKIM. SPF puede estar perfecto y aun así fallar DMARC si los dominios no se alinean.
Algunos receptores tratan múltiples registros SPF como permerror y efectivamente “fallan” SPF. Otros eligen uno o los mezclan; de cualquier manera, es lo suficientemente indefinido como para ser peligroso.
El espacio en blanco en DNS no existe; el espacio en blanco en SPF sí. DNS almacena bytes. SPF interpreta bytes como tokens. Confundir esas capas causa los errores exactos de este artículo.
Mecanismos SPF antiguos como PTR se usaban mucho y ahora se desaconsejan porque son lentos y frágiles. Todavía los encuentras escondidos en registros heredados como un cron olvidado.

Cómo SPF es parseado: lo que realmente evalúan los receptores

Aclaremos el modelo mental, porque la mayoría de los errores de formato SPF provienen de tener uno equivocado.

Dos capas: codificación TXT del DNS vs parseo del texto SPF

Capa DNS: un registro TXT es una o más cadenas. Los proveedores pueden almacenarlo como una cadena larga o dividirlo. En la red, es una lista de fragmentos con longitud prefijada. Los resolvers devuelven los fragmentos; los clientes típicamente los concatenan.

Capa SPF: una vez concatenado, SPF es una sola cadena que empieza con v=spf1, seguida de mecanismos y modificadores separados por espacios. Cada mecanismo puede tener un calificador opcional: + (pass), - (fail), ~ (softfail), ? (neutral).

Lo que ve el receptor (simplificado)

El receptor recibe una conexión desde una IP. Lee el dominio remitente del sobre (a veces se usa el nombre HELO para cheques de identidad HELO, pero el grande es MAIL FROM). Consulta TXT para ese dominio. Selecciona el registro SPF (si hay exactamente uno). Evalúa mecanismos hasta que uno coincide. Si no puede evaluar (error de sintaxis, errores DNS, demasiadas búsquedas), obtienes permerror o temperror.

Permerror no es “medio fallado”

permerror significa que la política publicada está rota o viola límites. Muchos receptores tratan permerror como fail o como “sin señal”, dependiendo de su política. Esa inconsistencia es por qué los errores de formato son tan dolorosos: no obtendrás un modo de fallo limpio único.

Comillas y espacios: modos de fallo que puedes reproducir

1) Copiar comillas desde `dig` al DNS

dig imprime cadenas TXT entre comillas. La gente ve:

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example ~all"

Luego pegan todo—incluidas las comillas—en una UI DNS que ya trata el valor como cadena cruda. Resultado: el valor publicado se vuelve "v=spf1 ... ~all" (con caracteres de comilla literales). Algunos parseadores SPF fallan inmediatamente; otros ignoran las comillas iniciales y luego tropiezan más adelante. Es una excelente forma de crear un problema que solo ocurre en un proveedor de correo.

Qué hacer: publica el texto sin comillas alrededor a menos que tu UI DNS lo requiera específicamente (y la mayoría de las modernas no lo hacen). Si la UI muestra comillas en la vista previa, usualmente es solo presentación.

2) “Comillas inteligentes” y espacios no separables desde sistemas de tickets

SPF espera espacios ASCII y puntuación ASCII. Pegar desde un correo formateado o una herramienta de chat puede dejarte con:

espacios no separables (U+00A0) en lugar de espacios
comillas curvas (“ ”) en lugar de comillas rectas («)
guiones largos (–) en lugar de guiones (-) en raros casos (usualmente en nombres de dominio copiados en prosa)

Los receptores varían en cómo tratan esto. Muchos tratarán todo el registro como inválido.

3) Dividir un registro en múltiples cadenas TXT en el lugar equivocado

Esto es el rompedor más común de “parece bien”. DNS permite:

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example"
" ~all"

Esas dos cadenas se concatenan en:

v=spf1 ip4:203.0.113.10 include:_spf.vendor.example ~all

Eso está bien porque la segunda cadena comienza con un espacio.

Pero si tu proveedor divide así:

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.ex"
"ample ~all"

Eso se concatena a include:_spf.vendor.example ~all, aún bien.

Y si lo divide así:

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example"
"~all"

Ahora obtienes include:_spf.vendor.example~all que es un único token. Eso es basura. Algunos parseadores lo tratan como un mecanismo desconocido; otros como error de sintaxis. De cualquier forma, no estás haciendo cumplir lo que crees.

Regla: si un registro se divide, asegura que la frontera esté en un límite de token y que los espacios se conserven. Si dudas, empieza explícitamente la siguiente cadena con un espacio.

4) Varios registros TXT que contienen cada uno `v=spf1`

Esto es clásico. Alguien añade un proveedor y “simplemente agrega otro registro SPF” porque la UI DNS permite múltiples entradas TXT en el mismo nombre.

SPF dice: un registro. Si publicas dos, muchos evaluadores devuelven permerror. Algunos elegirán uno, lo cual es peor porque “funciona” hasta que un resolver cambia de comportamiento.

5) Espacios extra y tabs: no siempre inocuos

Multiples espacios entre mecanismos típicamente están bien. Tabs, retornos de carro o espacios raros pegados no son confiables. También: un espacio final al final de un fragmento puede combinarse mal cuando se concatena con el siguiente fragmento.

6) Escape que parece escaping

Los archivos de zona TXT a veces usan barras invertidas para escapar comillas. Las UIs de proveedores varían: algunas esperan texto crudo; otras esperan estilo zone-file. Si pegas \"v=spf1 ...\" puedes publicar literalmente barras invertidas, comillas y tristeza.

Broma #1: SPF es el único sitio donde un solo espacio faltante puede hundir ingresos y aun así contar como “solo un registro de texto”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas de campo: ejecuta el comando, interpreta la salida, toma una decisión. Hazlas en orden cuando depures, o elige las que coincidan con tus síntomas.

Tarea 1: Identificar el dominio de identidad SPF desde un mensaje real

Comando: extrae Return-Path y Authentication-Results de un mensaje almacenado (ejemplo usando un correo raw guardado).

cr0x@server:~$ grep -E '^(Return-Path|Authentication-Results):' -n sample.eml
12:Return-Path: <bounces@mail.example.com>
45:Authentication-Results: mx.google.com; spf=permerror (google.com: domain of bounces@mail.example.com has multiple SPF records) smtp.mailfrom=bounces@mail.example.com

Qué significa: SPF se evalúa contra mail.example.com (o posiblemente el subdominio bounces), no necesariamente contra example.com.

Decisión: consulta TXT para el dominio exacto en smtp.mailfrom=. No “arregles” el apex si el correo usa un subdominio.

Tarea 2: Consultar registros TXT tal como los ve el mundo

cr0x@server:~$ dig TXT mail.example.com +noall +answer
mail.example.com.  300 IN TXT "v=spf1 include:_spf.vendor.example ~all"

Qué significa: hay un registro TXT y contiene una cadena (en esta respuesta).

Decisión: procede a validar sintaxis y conteo de búsquedas; si hay múltiples respuestas o múltiples cadenas v=spf1, detente y arregla eso primero.

Tarea 3: Detectar múltiples políticas SPF en un mismo nombre

cr0x@server:~$ dig +short TXT mail.example.com | grep -i 'v=spf1'
"v=spf1 include:_spf.vendor.example ~all"
"v=spf1 ip4:203.0.113.10 ~all"

Qué significa: dos registros SPF. Esto es un error de protocolo y probablemente produce permerror en algún lugar.

Decisión: fusiona mecanismos en un único registro SPF; elimina el extra.

Tarea 4: Verificar comillas literales dentro de la cadena publicada

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

Qué significa: la cadena TXT incluye caracteres de comilla reales al principio y al final (escapados para la visualización). Eso frecuentemente rompe el parseo.

Decisión: edita el registro DNS para quitar las comillas internas; publica v=spf1 ... como texto plano.

Tarea 5: Detectar división multi-cadena TXT y verificar fronteras

cr0x@server:~$ dig TXT example.com +noall +answer
example.com. 300 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.vendor.example" "~all"

Qué significa: dos character-strings. Se concatenarán sin insertar un espacio, resultando en ...vendor.example~all.

Decisión: corrige la división para que la segunda cadena empiece con un espacio, o mantenlo como una sola cadena si tu proveedor lo soporta.

Tarea 6: Comparar resultados desde múltiples resolvers (caché/proxy)

cr0x@server:~$ dig @1.1.1.1 +short TXT mail.example.com
"v=spf1 include:_spf.vendor.example ~all"
cr0x@server:~$ dig @8.8.8.8 +short TXT mail.example.com
"v=spf1 include:_spf.vendor.example" "~all"

Qué significa: diferentes resolvers están devolviendo distinto chunking TXT (aun potencialmente equivalente), o estás viendo propagación parcial o una mala configuración DNS multi-proveedor.

Decisión: si el chunking cambia fronteras de tokens (como arriba), trátalo como roto; de lo contrario, vigila TTL/propagación y verifica que tus servidores autoritativos sean consistentes.

Tarea 7: Pregunta directamente a los servidores de nombres autoritativos

cr0x@server:~$ dig NS example.com +short
ns1.dns-provider.example.
ns2.dns-provider.example.
cr0x@server:~$ dig @ns1.dns-provider.example TXT mail.example.com +noall +answer
mail.example.com. 300 IN TXT "v=spf1 include:_spf.vendor.example ~all"
cr0x@server:~$ dig @ns2.dns-provider.example TXT mail.example.com +noall +answer
mail.example.com. 300 IN TXT "v=spf1 include:_spf.vendor.example" "~all"

Qué significa: tus servidores autoritativos discrepan. Eso no es “propagación”. Es inconsistencia.

Decisión: deja de editar SPF y arregla la canalización de publicación DNS (push de zona, sincronización de proveedores o split-brain). Los receptores de correo consultarán cualquiera.

Tarea 8: Validar sintaxis SPF con un parser local (sanity rápido)

Instala una herramienta (el nombre del paquete varía según la distro; aquí se muestra como si ya estuviera instalada) y valida el texto del registro que planeas publicar.

cr0x@server:~$ spfquery --scope mfrom --id bounces@mail.example.com --ip 203.0.113.10
pass: domain of bounces@mail.example.com designates 203.0.113.10 as permitted sender

Qué significa: para esta IP, la política SPF devuelve pass. La sintaxis al menos es parseable para esta herramienta.

Decisión: si esto devuelve permerror, arregla formato o límites de búsqueda antes de perseguir otra cosa.

Tarea 9: Forzar un chequeo de permerror evaluando registros con muchas búsquedas

cr0x@server:~$ spfquery --scope mfrom --id bounces@mail.example.com --ip 198.51.100.25
permerror: too many DNS lookups

Qué significa: excediste el límite de 10 búsquedas DNS de SPF. Esto suele ocurrir tras “solo un include más”.

Decisión: reduce includes/redirects, elimina a/mx si no son necesarios, o rediseña la arquitectura de envío (subdominios dedicados por proveedor). No lo tapes con flattening aleatorio a menos que controles el proceso de actualización.

Tarea 10: Inspeccionar bytes del texto en busca de espacios no ASCII

Extrae el registro TXT y mira los bytes. Esto detecta espacios no separables y otros saboteos invisibles.

cr0x@server:~$ dig +short TXT mail.example.com | tr -d '\n' | hexdump -C | head
00000000  22 76 3d 73 70 66 31  c2 a0 69 6e 63 6c 75  |"v=spf1..inclu|
00000010  64 65 3a 5f 73 70 66  2e 76 65 6e 64 6f 72  |de:_spf.vendor|
00000020  2e 65 78 61 6d 70 6c  65 20 7e 61 6c 6c 22  |.example ~all"|

Qué significa: c2 a0 es un espacio no separable (UTF-8). Eso no es un espacio ASCII normal.

Decisión: reescribe el registro en un editor de texto plano o en la UI DNS sin espacios especiales. Trata cualquier cosa no ASCII como sospechosa.

Tarea 11: Confirma qué usa tu MTA como remitente de sobre

Ejemplo Postfix: verifica que smtpd_sender_restrictions no reescriba, y revisa canonical maps si se usan.

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|sender_canonical|smtp_generic_maps'
myhostname = mx1.internal.example
mydomain = example.com
sender_canonical_maps =
smtp_generic_maps =

Qué significa: no hay reescritura canónica configurada aquí (al menos en este fragmento). Si esperabas una dirección bounce en un subdominio, puede estar configurada en tu aplicación o ESP, no en Postfix.

Decisión: identifica el dominio MAIL FROM real en mensajes realmente enviados (Tarea 1) y publica SPF allí.

Tarea 12: Extrae el registro SPF autoritativo y normalízalo en una línea

Esto facilita detectar tokens soldados por la división.

cr0x@server:~$ dig @ns1.dns-provider.example TXT mail.example.com +short | tr -d '\n' | sed 's/" "/ /g'
"v=spf1 include:_spf.vendor.example ~all"

Qué significa: después de una normalización ingenua, puedes ver si falta un espacio entre fragmentos.

Decisión: si ves patrones como example~all o cominclude:, corrige las fronteras de los fragmentos.

Tarea 13: Verifica que no se colaron puntos y comas o comas accidentalmente

Los puntos y comas no son separadores válidos en SPF. Algunos humanos “formatean” SPF como un archivo de configuración.

cr0x@server:~$ dig +short TXT mail.example.com | tr -d '\n' | grep -E '[;,]'
"v=spf1 ip4:203.0.113.10; include:_spf.vendor.example, ~all"

Qué significa: tienes separadores que SPF no entiende. Muchos evaluadores devuelven permerror.

Decisión: quita la puntuación; los mecanismos deben estar separados por espacios.

Tarea 14: Comprueba la alineación DMARC cuando SPF “pasa” pero DMARC falla

cr0x@server:~$ grep -i '^Authentication-Results:' -n sample.eml
45:Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounces.vendor-mail.example; dmarc=fail (p=reject) header.from=example.com

Qué significa: SPF pasó para bounces.vendor-mail.example, pero DMARC falló porque el From del encabezado es example.com y el dominio SPF no está alineado (y tal vez DKIM tampoco está alineado).

Decisión: arregla la alineación (dominio MAIL FROM personalizado para el proveedor bajo tu dominio, o alineación DKIM), no el formato SPF.

Broma #2: Las UIs DNS que auto-envuelven registros TXT son como becarios con sudo—a veces útiles, muchas veces confiados y siempre sin supervisión.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

Eran una empresa mediana con una configuración normal: correo interno, un CRM y un par de herramientas SaaS que enviaban en su nombre. Marketing quería añadir una nueva plataforma de eventos antes del lanzamiento del producto, porque por supuesto lo querían.

El ingeniero que hizo el cambio supuso que el proveedor DNS quería el valor SPF “tal cual aparece en dig”. Es una suposición razonable si has pasado años mirando archivos de zona y no el tiempo suficiente mirando editores DNS basados en navegador. Pegó el registro incluyendo las comillas circundantes. La UI lo aceptó. Nadie gritó. El cambio se publicó.

A la mañana siguiente, la entregabilidad se veía… rara. Gmail mostró permerror SPF para algunos destinatarios, mientras que una pasarela de seguridad usada por socios mostró SPF none. El proveedor de la plataforma insistía en que sus IPs eran correctas. El equipo de correo interno insistía en que sus servidores salientes estaban bien. Mientras tanto, los comerciales reenviaban capturas de pantalla de rebotes como si fueran informes de incidente. No estaban equivocados.

La corrección tomó cinco minutos una vez que alguien extrajo el registro y notó que la cadena TXT publicada literalmente empezaba con un carácter de comilla. El diagnóstico tomó tres horas porque todos confiaron en lo que la vista previa de la UI DNS mostraba, y porque el equipo no tenía un protocolo estándar de “consultar autoritativos y hexdump si es necesario”.

La lección: nunca confíes en lo que la UI renderiza. Confía en lo que el resolver devuelve. Y no aceptes ediciones SPF sin verificar con una consulta por línea de comandos.

Mini-historia 2: La optimización que salió mal

Otra compañía había hecho crecer su registro SPF hasta convertirlo en un monstruo: cinco includes, un par de mecanismos mx y a “por si acaso”, y un redirect para correo legacy. Coqueteaban con el límite de 10 búsquedas. A veces pasaba; a veces daba permerror, dependiendo de timeouts DNS y cómo los receptores expandían includes.

Alguien propuso una optimización: “Aplanemos SPF. Resolveremos todos los includes, los convertiremos en entradas ip4: y ip6:, y publicaremos un registro sin búsquedas.” En papel, genial: evaluación más rápida, menos dependencias DNS, menos riesgo de permerror.

En la práctica, su script de flattening emitió una cadena larga que la UI del proveedor DNS auto-envuelvió en múltiples character-strings. Los puntos de wrap fueron arbitrarios. Un wrap cayó entre ip4:198.51.100.0/ y 24. Otro cayó entre include: y el dominio. Un tercero eliminó un espacio límite.

El registro quedó sintácticamente roto, y ahora todos los receptores lo veían. Antes de la “optimización”, solo algunos receptores encontraban permerror cuando las búsquedas fallaban por timeout. Después de la “optimización”, el registro era simplemente inválido. Su monitorización (que solo comprobaba un resolver) no lo detectó porque ese resolver casualmente devolvía un chunking distinto que enmascaraba uno de los bugs de frontera en su verificador simplista.

Se recuperaron revirtiendo y luego implementando el flattening correctamente: fronteras de chunk controladas, espacios iniciales explícitos en cadenas de continuación y validación automatizada contra múltiples resolvers antes de publicar. El flattening puede funcionar, pero ahora es una cadena de suministro de software. Trátalo como tal.

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

Una organización del área financiera tenía la cultura de “la autenticación de correo es producción”, algo más raro de lo que debería. Tenían una práctica simple: cualquier cambio SPF requería ejecutar un pequeño runbook y estaban prohibidas las capturas de pantalla. Solo comandos reales. También tenían una política: cada sistema de envío importante obtiene su propio subdominio con su propio registro SPF.

Cuando procurement metió una nueva herramienta de RRHH que necesitaba permisos de envío, el equipo no tocó example.com. Crearon hrmail.example.com para ese sistema, publicaron un SPF mínimo allí y configuraron al proveedor para que lo usara como dominio de rebote. El SPF del apex se mantuvo estable y el caos de marketing quedó contenido.

Dos meses después, el proveedor rotó su infraestructura y actualizó su include objetivo. Muchos clientes vieron permerrors SPF intermitentes debido a cadenas de búsquedas y timeouts. Esta organización no. ¿Por qué? Su registro SPF tenía solo un include y nada más. Mucho presupuesto de búsquedas disponible y una ruta de evaluación limpia.

La parte aburrida—segmentación por subdominio, además de un paso obligatorio de validación por línea de comandos—hizo que el incidente nunca llegara a su pager. Solo llegó a su revisión semanal de “cambios de proveedores”, donde asintieron, no actualizaron nada y volvieron al trabajo real.

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

1) Síntoma: SPF permerror “múltiples registros SPF”

Causa raíz: Más de un registro TXT en el mismo nombre contiene v=spf1 (frecuentemente creado al añadir un proveedor “registro SPF” en lugar de actualizar el existente).

Solución: Consolida en exactamente una política SPF. Elimina entradas TXT SPF adicionales. Si necesitas políticas separadas, usa subdominios separados y configura a los proveedores para que los usen como MAIL FROM.

2) Síntoma: SPF permerror “dominio inválido encontrado” o “mecanismo inválido”

Causa raíz: Soldadura de tokens debido a concatenación de fragments TXT sin espacio (p. ej., include:_spf.vendor.example~all), o una división a mitad de token.

Solución: Asegura que las divisiones ocurran en límites de token e incluye un espacio inicial en el fragmento subsiguiente. Republícalo y verifica con dig mostrando la separación de tokens prevista.

3) Síntoma: SPF falla en Gmail pero “funciona” en otros

Causa raíz: Diferentes evaluadores manejan espacios/comillas malformadas de forma distinta; o algunos eligen un registro SPF mientras otros devuelven permerror; o inconsistencia DNS entre servidores autoritativos.

Solución: Consulta múltiples resolvers y servidores autoritativos. Elimina comillas literales. Elimina múltiples registros SPF. Normaliza a una sola cadena limpia (o divide con cuidado).

4) Síntoma: SPF permerror intermitente “demasiadas búsquedas DNS”

Causa raíz: El conteo de búsquedas depende del orden de expansión de includes y de timeouts DNS; estás cerca del techo de 10 búsquedas.

Solución: Reduce includes, elimina a/mx/ptr, y segmenta por subdominio. Si aplanas, automatízalo y valida fronteras de tokens y chunking.

5) Síntoma: SPF es “neutral” o “none” inesperadamente

Causa raíz: Registro SPF no encontrado en el dominio MAIL FROM (actualizaste el nombre equivocado), o el registro empieza con caracteres basura debido a comillas/pegado.

Solución: Confirma el dominio de identidad desde las cabeceras. Publica SPF allí. Asegúrate de que el registro empiece exactamente con v=spf1 (sin comillas iniciales, sin BOM, sin espacio extraño).

6) Síntoma: SPF pasa pero DMARC falla (y aún así terminas en spam)

Causa raíz: Falla de alineación: el dominio SPF no está alineado con el From del encabezado, y DKIM no está alineado (o falta).

Solución: Configura un dominio de rebote personalizado bajo tu dominio para el proveedor, o arregla la alineación DKIM. No sigas “afinando” el formato SPF.

7) Síntoma: SPF falla solo para remitentes IPv6

Causa raíz: Añadiste entradas ip4: pero olvidaste ip6:, o dependiste de mecanismos a/mx que no cubren IPv6 como esperabas; a veces combinado con errores de división alrededor de tokens ip6:.

Solución: Añade mecanismos explícitos ip6: donde proceda, valida la tokenización del registro y prueba con una IP remitente IPv6.

Listas de verificación / plan paso a paso

Lista de verificación: publicar un registro SPF sin romperlo

Decide los dominios de identidad: lista cada dominio MAIL FROM usado (apex, subdominios de marketing, subdominios de rebotes de proveedores).
Un dominio, un registro SPF: asegura exactamente un valor TXT que contenga v=spf1 por dominio de identidad.
Escribe el registro en un editor de texto plano: nada de texto enriquecido, ni formato de sistemas de tickets.
Manténlo simple: prefiere ip4:/ip6: explícitos para tus MTAs; usa include: solo cuando sea necesario.
Evita mecanismos legacy: no uses ptr. Ten cautela con a y mx; queman búsquedas y cambian cuando cambia el DNS.
Planifica el límite de 10 búsquedas: cuenta includes y redirects, y asume que los proveedores tienen sus propios includes.
Si debes dividir cadenas TXT: divide solo en límites de token y comienza las cadenas de continuación con un espacio.
Publica y verifica desde los NS autoritativos: consulta cada servidor autoritativo directamente.
Verifica desde múltiples resolvers públicos: captura rarezas de propagación/caché.
Valida con un evaluador SPF: prueba al menos una IP remitente buena y una mala conocida.
Captura evidencia: guarda el texto exacto del registro, salidas de consulta y el ticket de cambio. Lo necesitarás después.

Paso a paso: fusionar dos registros SPF de forma segura

Extrae todos los registros TXT y aísla los que contienen v=spf1.
Copia mecanismos a un único registro, preservando el orden para que las coincidencias más específicas vayan primero.
Mantén exactamente un mecanismo all al final (p. ej., ~all o -all según la madurez de tu política).
Publica el registro fusionado y elimina los duplicados.
Ejecuta validación de conteo de búsquedas y chequeos SPF reales (Tarea 8/9).

Paso a paso: arreglar un registro TXT dividido roto

Consulta el registro y observa el chunking exacto (dig ... +answer).
Concatena las cadenas mentalmente (o con un script rápido) y busca tokens soldados.
Edita el registro para que cada cadena de continuación empiece con un espacio, salvo que continúe deliberadamente un token (raro y arriesgado).
Vuelve a consultar los servidores autoritativos y verifica tanto el chunking como el texto reconstruido.
Reprueba la evaluación SPF desde una IP remitente conocida.

Preguntas frecuentes

1) ¿Necesito comillas alrededor de mi registro SPF en DNS?

Usualmente no. Las comillas suelen ser solo cómo las herramientas muestran cadenas TXT. Si tu UI DNS pide un campo de valor, introduce v=spf1 ... sin comillas circundantes a menos que la UI documente explícitamente que las requiere.

2) ¿Por qué `dig` muestra comillas entonces?

Porque los registros TXT son cadenas y las comillas son una convención segura de visualización. No son necesariamente parte de lo que se almacena como datos en la forma en que lo piensas.

3) ¿Es válido dividir un registro SPF a través de múltiples cadenas TXT?

Sí, siempre que el texto concatenado resultante sea un SPF válido. La trampa: la concatenación no inserta espacios. Si tu división elimina un espacio entre tokens, rompes el registro.

4) ¿Cuál es el registro SPF “más seguro” y sencillo?

Para un dominio que solo envía a través de una fuente conocida, algo como v=spf1 ip4:203.0.113.10 -all es limpio y robusto. Los entornos reales son más enmarañados; el principio es mantener el conjunto de mecanismos mínimo y explícito.

5) ¿Por qué comenzó a fallar SPF tras añadir un include de un proveedor?

Probablemente alcanzaste el límite de 10 búsquedas DNS, o la nueva cadena de includes introdujo timeouts. Los receptores pueden devolver permerror cuando no pueden completar la evaluación. Valida el conteo de búsquedas antes y después de cualquier cambio de include.

6) ¿Puedo publicar SPF en el apex y ya está?

Sólo si todos tus remitentes usan el dominio apex como MAIL FROM y puedes mantener la política dentro de los límites. En la práctica, usar subdominios por proveedor es más limpio: radio de daño separado, cambios más fáciles, menos conflictos accidentales.

7) ¿Por qué SPF pasa pero el correo sigue en spam?

SPF es una señal. Si DMARC falla (alineación), DKIM falta/está roto, o tu reputación de envío es mala, aún puedes acabar en spam. No confundas “SPF pass” con “entregabilidad resuelta”.

8) ¿Qué significa operativamente SPF permerror?

Tu política SPF publicada no es evaluable (error de sintaxis, múltiples registros, demasiadas búsquedas, etc.). Trátalo como un bug de configuración en producción. Arréglalo como arreglarías una regla de firewall rota: con cuidado, validación y un plan de rollback.

9) ¿Son siempre aceptables los espacios extra en SPF?

Los espacios ASCII extra entre tokens normalmente sí. Tabs, espacios no separables y divisiones de cadenas que eliminan espacios requeridos no lo son. Si depuras un registro que “parece bien”, revisa los bytes.

10) ¿Debemos aplanar SPF para evitar límites de búsqueda?

A veces. Aplanar cambia búsquedas DNS en tiempo de ejecución por una canalización de mantenimiento que debe permanecer correcta a medida que los proveedores rotan IPs. Si aplanas, automatiza actualizaciones, valida sintaxis y fronteras de chunk, y supervisa la deriva. De lo contrario, reemplazas un modo de fallo por otro más costoso.

Próximos pasos que puedes implementar esta semana

Si solo haces tres cosas, haz estas:

Inventaria tus dominios MAIL FROM a partir de cabeceras reales, no de memoria tribal. Publica SPF donde realmente se evalúa.
Aplica “un v=spf1 por nombre” y añade una comprobación DNS lint en tu proceso de cambios. Múltiples registros SPF son autolesivos.
Adopta un ritual de verificación: consulta servidores autoritativos, verifica fronteras de chunk y ejecuta una evaluación SPF para al menos una IP remitente antes de declarar victoria.

SPF no es difícil. Es simplemente implacable en los lugares donde a los humanos les gusta ser casuales: espacios en blanco, comillas y “pequeñas ediciones”. Trátalo como configuración de producción, porque tus correos de ingresos ya lo son.