Varios registros SPF: por qué tener dos rompe tu correo (y cómo fusionarlos)

Introducción

Has añadido un segundo servicio de correo a tu dominio, has seguido su guía de configuración, has pegado el registro SPF que te daba y ahora los correos que antes llegaban bien acaban en spam.

La causa casi siempre es la misma: tu dominio tiene ahora dos registros SPF, y tener dos es peor que no tener ninguno.

Esta guía explica cómo detectarlo, cómo fusionarlos correctamente y el error que lleva a la mayoría por el camino equivocado: meter en el SPF un servicio que no pinta nada ahí.

Un registro por dominio. Sin excepciones.

El RFC 7208 no deja margen: un dominio publica exactamente un registro TXT que empiece por v=spf1.

Cuando un servidor receptor encuentra dos, no elige el mejor, ni los combina, ni se queda con el primero. Devuelve permerror y la comprobación SPF falla, aunque el servidor que envió estuviera correctamente listado en uno de ellos.

Eso es lo que hace el problema tan desconcertante: añadir un registro válido para tu nuevo proveedor rompe el proveedor que ya funcionaba.

Mal — dos registros TXT separados:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.brevo.com ~all

Bien — un registro con los dos includes:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

Cómo comprobar qué tienes realmente

Los paneles de DNS hacen que esto pase desapercibido, porque cada registro se ve correcto en su propia fila. Hay que mirar el dominio en conjunto.

dig +short TXT tudominio.com | grep spf1

Si devuelve más de una línea, ahí está el problema.

Comprobar tu registro SPF →

Fusionar dos registros en uno

La mecánica es sencilla. El cuidado está en qué conservas.

1. Reúne todos los include: e ip4:/ip6: de ambos registros.

2. Escribe un único registro, empezando por v=spf1 y terminando con un solo mecanismo all:

v=spf1 include:_spf.google.com include:spf.brevo.com ip4:203.0.113.10 ~all

3. Deja solo un all. Dos registros significan dos mecanismos all, y todo lo que vaya después del primero se ignora. Si no coincidían (~all en uno, -all en el otro), decide a conciencia: ~all (softfail) mientras verificas, -all (hardfail) cuando tengas la certeza de que la lista está completa.

4. Elimina el segundo registro TXT. No lo dejes desactivado ni renombrado: bórralo.

5. Verifica tras la propagación, normalmente en menos de una hora.

El orden no afecta a la corrección, pero conviene poner primero el remitente de mayor volumen: la evaluación SPF se detiene en la primera coincidencia, lo que ahorra consultas.

El error que comete casi todo el mundo

Este es el que cuesta días, y la razón por la que un "fusiona los registros" a secas se queda corto.

SPF solo autoriza servidores que envían correo como tu dominio. Los servicios que únicamente reciben o reenvían no deben estar ahí.

La configuración que hace tropezar a tanta gente es esta:

• Un dominio registrado en un proveedor como GoDaddy o 123-reg
• Un servicio de reenvío —ImprovMX, por ejemplo— para que tu@tudominio.com llegue a Gmail
• Una plataforma de marketing o transaccional como Brevo, Mailchimp o SendGrid para las campañas de salida

El servicio de reenvío publica instrucciones de SPF en su documentación, así que se añade. Pero si solo te entrega correo a ti, nunca envía nada como tu dominio, y su include no hace más que consumir una de tus diez consultas DNS.

Hazte una sola pregunta con cada include: ¿este servicio envía correo que muestra mi dominio en el remitente?

• Envía como tu dominio → va en el SPF
• Solo recibe o reenvía hacia ti → no va
• Solo te envía a ti (avisos, notificaciones) → no va

Equivocarse aquí sale caro dos veces: desperdicia consultas que puedes necesitar más adelante y oculta el motivo real por el que falla tu correo.

Vigila el presupuesto de consultas

Fusionar los registros resuelve el permerror, pero puede llevarte directo al siguiente límite. SPF permite 10 consultas DNS, y cada include: cuenta, más todos los que vengan anidados dentro.

Dos proveedores fusionados en un registro no suele dar problemas. Con cuatro o cinco la cosa se aprieta: solo Google Workspace consume varias.

Si ya andabas cerca del límite, lee Registro SPF: demasiadas consultas DNS antes de añadir nada más.

Qué le hace esto a DMARC

Que falle SPF no siempre significa que falle DMARC, y entenderlo evita sustos innecesarios.

DMARC pasa si SPF o DKIM pasan con alineación. Así que un dominio con el SPF roto y el DKIM bien configurado puede seguir pasando DMARC, que es justo la razón por la que el problema pasa desapercibido durante meses. El correo llega casi siempre, la entregabilidad se degrada en silencio y nada apunta al registro duplicado.

Aparece el día que subes la política de p=none a quarantine o reject, o cuando un receptor da más peso del habitual a SPF.

Los informes agregados lo enseñan antes que tus usuarios: indican qué pasó SPF, qué pasó DKIM y qué alineó, por cada origen. Esa es la diferencia entre suponer y saber.

Lista de comprobación

• dig +short TXT tudominio.com | grep spf1 devuelve exactamente una línea
• El registro empieza por v=spf1 y tiene un único all
• Cada include: pertenece a un servicio que envía como tu dominio
• Los servicios de reenvío y de solo recepción están fuera
• El total de consultas DNS se queda en 10 o menos
• El correo de prueba de cada proveedor pasa SPF

Siguientes pasos

1. Busca duplicados y cuenta consultas: Verificador de SPF →
2. Construye un registro fusionado y limpio: Generador de registros SPF →
3. Verifica el conjunto: Puntuación del dominio →
4. Comprueba qué está fallando de verdad: Empieza gratis → — los informes agregados muestran los resultados de SPF y DKIM por origen de envío, así encuentras un registro roto antes que tus destinatarios.

---

Artículos relacionados:

• Registro SPF: demasiadas consultas DNS (cómo solucionarlo)
• SPF, DKIM y DMARC: la guía completa
• Por qué tus correos van a spam
• Fallo de alineación DMARC: cómo solucionarlo