Dos registros SPF = permerror: la trampa del duplicado

La sanción exacta: permerror, y lo que DMARC hace con él

Un permerror no es un simple fallo: es el veredicto «configuración ininterpretable», reservado a los errores permanentes que un nuevo intento nunca corregirá —por oposición al temperror de un DNS momentáneamente inaccesible—. Lo que cubre exactamente ese veredicto, junto con sus demás causas posibles, merece un artículo entero; aquí importa la traducción operativa: SPF no vuelve a producir un «pass» para el dominio, sea cual sea la fuente emisora.

Del lado de DMARC, la consecuencia es mecánica. DMARC valida un mensaje si SPF o DKIM produce un resultado positivo alineado con el dominio visible del remitente. Como el permerror no es un pass, la pata SPF de DMARC desaparece pura y simplemente: toda la autenticación descansa desde ese momento solo en DKIM. Los flujos que firman DKIM con un dominio alineado sobreviven; todos los demás —una herramienta transaccional sin firma, un servidor de aplicaciones, una impresora multifunción— caen en fallo DMARC completo. Bajo p=quarantine o p=reject, eso significa carpeta de spam o rechazo directo, y algunos receptores penalizan además el permerror en sí mismo, con independencia de DMARC.

Lo más insidioso: el duplicado rompe retroactivamente. El segundo registro no se suma al primero, también lo anula —las autorizaciones históricas dejan de leerse en el mismo instante que las nuevas—. En p=none no ocurre nada visible y solo los informes delatan el problema; en p=reject es un incidente de producción inmediato para todos los flujos que solo se sostenían por SPF.

El diagnóstico en dos minutos: dig y los informes

El control de primera intención cabe en un comando:

dig +short TXT ejemplo.es
"v=spf1 include:spf.protection.outlook.com -all"
"v=spf1 include:sendgrid.net ~all"

El recuento es el diagnóstico: dos líneas que empiezan por v=spf1 significan que el duplicado está ahí, y cada comprobación del dominio devuelve permerror. Una sola línea: la causa está en otra parte. En Windows, nslookup -type=TXT ejemplo.es presta el mismo servicio. El método completo para comprobar un registro SPF detalla las variantes del comando y las trampas de lectura.

Los informes agregados DMARC ofrecen el segundo ángulo, valiosísimo cuando el duplicado va y viene o ya se corrigió: un permerror SPF que golpea todas las fuentes a la vez es la firma de un problema de dominio, no de un remitente concreto. El histórico da incluso la fecha exacta del vuelco —el día en que todas las líneas pasan de pass a permerror es el día en que se publicó el segundo registro—. Un último detalle de paciencia: tras la corrección, las cachés DNS siguen sirviendo ambos registros hasta que expira el TTL; un diagnóstico lanzado justo después del cambio puede mentir durante unas horas.

La fusión correcta: un solo registro, un solo all

La reparación no consiste en elegir un registro y borrar el otro —los dos suelen contener autorizaciones legítimas—, sino en fusionarlos en uno solo. El método: inventariar los mecanismos de ambos registros (include:, ip4:, ip6:, a, mx), reunirlos detrás de un único v=spf1 de cabecera, eliminar los duplicados y cerrar con un único all. Sobre el ejemplo anterior, el registro consolidado queda así:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Tres reglas de fusión evitan las malas sorpresas. Primera: el all final es único y termina la evaluación —todo lo que sigue al primer all encontrado es ignorado por los verificadores; un include colocado detrás sería letra muerta—. Segunda: si los dos registros terminaban de forma distinta (-all en uno, ~all en el otro), la elección del calificador debe ser deliberada: ~all durante una fase de observación, -all cuando el inventario de fuentes ha madurado. Tercera: los mecanismos se leen de izquierda a derecha; colocar en cabeza las fuentes de mayor volumen ahorra algunas resoluciones inútiles en cada comprobación.

La fusión es también el buen momento para hacer limpieza: un include de un proveedor abandonado hace dos años no pinta nada en el registro consolidado. Y una vigilancia imperativa: sumar dos registros suma sus resoluciones DNS, y el techo de las diez consultas DNS se aplica al registro fusionado —rebasar ese límite recrearía un permerror por otro camino, justo el que la fusión acababa de cerrar—.

Varias cadenas dentro de un mismo TXT: el falso duplicado que es válido

Una salida de dig puede alarmar sin motivo:

"v=spf1 include:spf.protection.outlook.com " "include:sendgrid.net -all"

Dos bloques entre comillas, pero en la misma línea: se trata de un solo registro TXT, compuesto por varias cadenas de caracteres. El DNS limita cada cadena a 255 bytes; la RFC 7208 prevé explícitamente que un registro pueda contener varias, que el verificador concatena —sin insertar espacio alguno— antes de la evaluación. Es el mecanismo estándar para superar los 255 caracteres, tratado en detalle en el artículo dedicado al límite de longitud de un registro SPF.

La distinción visual es, por tanto, sencilla: dos líneas que empiezan por v=spf1 son dos registros, luego permerror; dos cadenas entre comillas en una misma línea son un registro, luego perfectamente válido. El segundo caso encierra una única trampa propia: como la concatenación se hace sin separador, un espacio olvidado al final de una cadena pega dos mecanismos en un token absurdo (…outlook.cominclude:…), un error de sintaxis que, a su vez, también acabaría en permerror.

La prevención: una revisión con cada nueva herramienta

Como el duplicado es casi siempre de origen procedimental, la parada también lo es. La regla de oro cabe en una frase: «añadir un proveedor de envío» no significa nunca «añadir un registro», sino siempre «modificar el registro existente». Escrita en el procedimiento de integración de cada nueva herramienta, esa sola frase elimina la causa número uno del permerror por duplicado.

Tres hábitos completan el dispositivo. Un propietario único de la zona DNS —o, como mínimo, una revisión sistemática de los cambios— para que marketing y sistemas dejen de publicar cada uno por su lado. Una comprobación con dig tras cada modificación de la zona, con un coste de diez segundos. Y una vigilancia continua de los informes DMARC: un permerror que surge simultáneamente en todas las fuentes es una alarma de duplicado, detectable el mismo día en lugar de en el momento en que la entregabilidad se hunde. Las organizaciones que mantienen un inventario de sus remitentes autorizados —la base de toda remediación DMARC seria— interceptan además el duplicado antes incluso de publicarlo: la herramienta nueva pasa por el inventario, y el inventario pasa por el registro único.

En resumen

La RFC 7208 tolera un registro SPF por nombre de dominio y ni uno más: desde el segundo v=spf1, todas las comprobaciones devuelven permerror, SPF deja de existir para el dominio y DMARC se sostiene solo sobre DKIM —con, bajo p=reject, un rechazo seco de todos los flujos sin firma—. El duplicado nace casi siempre de una documentación de proveedor seguida al pie de la letra, de una migración inacabada o de dos equipos que publican sin hablarse. El diagnóstico cabe en un dig TXT —contar las líneas v=spf1— y en los informes, donde un permerror simultáneo en todas las fuentes firma el problema. La reparación es una fusión: un solo registro, mecanismos sin duplicados, un único all final y un ojo puesto en el techo de las diez resoluciones DNS. Las cadenas múltiples dentro de un mismo TXT, en cambio, son válidas: lo que condena a un dominio es el duplicado de registros, no el troceado en cadenas.

Para saber en treinta segundos si un dominio arrastra un duplicado —o cualquier otro defecto SPF, DKIM o DMARC—, el análisis DMARC gratuito devuelve un veredicto inmediato, con los registros decodificados como prueba. Y para que la próxima herramienta conectada por marketing no devuelva el dominio al permerror sin que nadie se dé cuenta, la creación de una cuenta pone en marcha la vigilancia continua de los informes: el duplicado de mañana se detectará el mismo día, no en la próxima caída de entregabilidad.