SPF dejó de funcionar tras cambiar de proveedor de correo — la solución de migración (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.

SPF suele romperse tras un cambio de proveedor de correo porque el registro del proveedor nuevo se añadió junto al antiguo. Dos registros v=spf1 son un error permanente — SPF se anula por completo. 1.013.416 dominios — aproximadamente uno de cada 138 de los que intentan SPF — están en ese estado, según el censo de Defaults.Exposed de 261 millones de dominios. Fusiónelos en uno solo.

La solución lleva unos diez minutos: analice el dominio para ver exactamente qué dejó atrás la migración, liste todos los registros SPF en sus servidores de nombres autoritativos, fusiónelos en un único registro que incluya solo a su proveedor nuevo y vuelva a verificar con dig. Esta guía recorre cada paso, más las comprobaciones de DKIM y de servidores de nombres que la mayoría de las migraciones olvida.

¿Por qué se rompió SPF justo después de la migración?

Porque la guía de configuración del proveedor nuevo decía “añada este registro TXT” — y usted lo hizo, junto al antiguo. Eso es precisamente lo único que el estándar SPF no permite. El RFC 7208 (§3.2, con el resultado de error prescrito en el §4.5) permite exactamente un registro v=spf1 por dominio; un receptor que encuentre dos o más debe devolver PermError en lugar de adivinar cuál es el autoritativo. PermError significa que SPF queda anulado: ni el registro antiguo, ni el nuevo, ningún SPF en absoluto.

Y la cosa no acaba ahí. DMARC trata un PermError como un fallo en la pata SPF, así que su correo ahora depende por completo de DKIM. Si el DKIM del proveedor nuevo tampoco está configurado todavía — habitual a mitad de migración — está enviando sin autenticar justo en el momento en que cambió de infraestructura, que es cuando los receptores más lo escrutan.

Este es el copia-y-pega que anula la protección al cambiar de proveedor, y no es raro: 1.013.416 dominios publican dos o más registros SPF ahora mismo — aproximadamente uno de cada 138 de la población de 139 millones que intenta SPF, según el censo de Defaults.Exposed de 261 millones de dominios (datos a fecha de 2026-06-29). Las cifras completas sobre la trampa de los dos registros tienen su propio informe; esta página es la solución procedimental.

¿Qué dejó atrás la migración?

Cinco restos causan casi todos los fallos de SPF posteriores a una migración. Compruébelos en este orden:

Qué quedó atrás	Qué ve usted	La solución
El registro SPF antiguo, todavía en el DNS junto al nuevo (dos registros `v=spf1`)	Los verificadores reportan “multiple SPF records” o PermError; SPF deja de funcionar por completo	Fusione en un solo registro, elimine el resto — pasos más abajo
El `include:` del proveedor antiguo dentro de su único registro	SPF funciona, pero está desperdiciando consultas DNS y los servidores del proveedor antiguo aún pueden enviar como usted	Quítelo cuando el correo se haya vaciado por completo del sistema antiguo
El `include:` del proveedor nuevo nunca se añadió	El correo del proveedor nuevo falla SPF en los receptores	Añádalo al único registro existente — nunca como un registro nuevo
Selectores DKIM sin crear para el proveedor nuevo	`dkim=fail` o firmas con el dominio por defecto del proveedor; DMARC se queda sin segunda pata	Publique los selectores nuevos — paso 6 más abajo
Registro actualizado solo en los servidores de nombres antiguos	Respuestas distintas según a quién pregunte; fallos intermitentes	Corrija la zona en los servidores de nombres autoritativos; verifique ambos conjuntos durante la transición

¿Cómo lo arreglo? La lista de comprobación de la migración

Ejecute primero el análisis gratuito en defaults.exposed. Lee su DNS en vivo y le dice si tiene varios registros SPF, un include ausente o un hueco en DKIM — diagnostique antes de tocar nada.
Liste todos los registros SPF en los servidores de nombres autoritativos. dig +short NS yourdomain.com, y después dig +short TXT yourdomain.com @<nameserver> contra uno de ellos. Cuente las cadenas que empiezan por v=spf1. El único recuento seguro es 1.
Fusione en un único registro. Un registro, que empiece por v=spf1, que contenga el include de su proveedor nuevo y cualquier otro remitente que aún use (herramienta de facturación, CRM, plataforma de boletines), con un único -all o ~all final. Ejemplo — Google Workspace antiguo, Microsoft 365 nuevo, a mitad de vaciado:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Los valores por proveedor y las peculiaridades de cada panel DNS están en las guías de configuración de Google Workspace y Microsoft 365.
Elimine los registros sobrantes. Fusionar sin eliminar no arregla nada — el PermError viene del recuento.
Mantenga el include del proveedor antiguo solo mientras el sistema antiguo siga enviando — informes programados, un conector de CRM antiguo, un buzón olvidado. Cuando el vaciado termine, quítelo: un include obsoleto deja a la infraestructura antigua autorizada a enviar como usted, y cada include cuesta consultas DNS contra el límite estricto de 10 de SPF — al menos 797.263 dominios han anulado su SPF por reventar ese límite (censo, 2026-06-29).
Configure el DKIM del proveedor nuevo — y no borre todavía los selectores antiguos. Los selectores nuevos firman el correo nuevo; los selectores antiguos deben permanecer publicados hasta que todos los mensajes firmados con ellos se hayan entregado y los reenvíos se hayan asentado. Recorrido completo en DKIM falla tras cambiar de herramientas de correo.
Si también cambió de servidores de nombres, compruebe ambos. Las migraciones de DNS suelen ir de la mano de las migraciones de correo. Consulte directamente el conjunto de NS antiguo y el nuevo (dig TXT yourdomain.com @old-ns y @new-ns) — hasta que la delegación del registrador se propague por completo, algunos receptores siguen preguntando a los servidores antiguos, así que el registro corregido debe existir en el conjunto que responda, sea cual sea.
Vuelva a ejecutar el análisis y confirme que SPF muestra un único registro válido con resultado pass.

¿Qué dominio comprueba SPF en realidad?

Los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom) — la dirección de rebote — no contra la cabecera De que ven sus destinatarios. Tras una migración esto importa por partida doble: su proveedor nuevo puede usar su propio dominio de rebote hasta que usted configure uno personalizado, y un SPF que “pasa” sobre un dominio que no es el suyo no se alineará para DMARC. La solución para eso es el DKIM del proveedor nuevo, firmado con su dominio.

¿Migrando y cambiando de marca al mismo tiempo?

¿Cambió también el dominio, además del proveedor? Trátelos como dos trabajos. El dominio nuevo necesita la pila completa — SPF, DKIM, DMARC — desde el primer día; use la lista de comprobación de correo para un dominio nuevo. El dominio antiguo debe seguir autenticado mientras el reenvío o el tráfico de respuestas pase por él, y hay que cerrarlo explícitamente (no simplemente abandonarlo) cuando quede aparcado. Un dominio antiguo con un SPF residual y medio roto es un objetivo de suplantación que lleva puesto su nombre anterior.

Preguntas frecuentes

¿Puedo mantener dos registros SPF mientras migro? No. No hay período de gracia en el estándar — dos registros v=spf1 son un PermError desde el momento en que existe el segundo, y 1.013.416 dominios están en ese estado según el censo (2026-06-29). El patrón seguro para migrar es un único registro que lleve los includes de ambos proveedores durante el solapamiento.

¿Cuánto tiempo debo mantener el include del proveedor antiguo? Hasta que nada envíe a través del proveedor antiguo — normalmente lo que dure su ventana de solapamiento, de días a unas pocas semanas. Vigile el Return-Path de todo lo que siga llegando por el sistema antiguo; cuando ese tráfico se detenga, quite el include y vuelva a comprobar su recuento de consultas.

¿Por qué un verificador sigue mostrando mi registro antiguo después de arreglarlo? La caché DNS respeta el TTL del registro, y si sus servidores de nombres cambiaron, algunos resolutores siguen consultando el conjunto antiguo. Verifique directamente en los servidores de nombres autoritativos con dig TXT yourdomain.com @<ns> — si la respuesta es correcta ahí, la corrección está hecha y las cachés se pondrán al día. Si es incorrecta en uno de los conjuntos de NS, consulte ‘SPF record not found’ — las causas reales.

¿Necesito cambiar DMARC cuando cambio de proveedor? Normalmente no el registro en sí — nombra su buzón de informes y su política, no su proveedor. Pero sus resultados DMARC dependen del SPF y el DKIM que acaba de migrar: espere una caída en los informes durante la transición, y confirme que ambas patas pasan antes de endurecer la política. Empiece por arreglar SPF si el análisis muestra que la pata SPF sigue fallando.

Envíe el informe al propietario

Si está haciendo esta migración para un cliente, termine con pruebas. Vuelva a ejecutar el análisis gratuito cuando la fusión esté activa y reenvíe el informe calificado al propietario del negocio: SPF, DKIM y DMARC pasando en el proveedor nuevo, en lenguaje claro y con fecha. Ese es el documento que archivan para la renovación del ciberseguro y el próximo cuestionario de seguridad de un proveedor — la prueba de que la migración dejó el dominio mejor autenticado que como empezó.

Compruebe su dominio → · DKIM falla tras cambiar de herramientas de correo → · ‘SPF record not found’ — las causas reales → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.