Google eliminó silenciosamente _netblocks3.google.com de su cadena de registros SPF a principios de 2026, sin anuncio oficial alguno. Para la mayoría de usuarios de Google Workspace, nada cambia. Pero para propietarios de dominios o equipos de TI que codificaron manualmente la estructura SPF interna de Google, esta actualización es una señal para auditar sus registros ahora, antes de que una configuración deficiente cause problemas de entrega.
Qué Cambió Realmente en Google
Cuando inspeccionas _spf.google.com, apunta a sub-registros internos que contienen los rangos de IP de Google para enviar correo. Anteriormente, la cadena incluía tres de estos sub-registros. Google ha eliminado silenciosamente _netblocks3.google.com de esa cadena, lo que simplemente significa que el sub-registro ya no contiene direcciones de envío activas. En términos simples, Google limpió su estructura SPF.
Google no hizo anuncios sonoros sobre esto porque, para la mayoría de dominios, nada se rompe. El problema solo aparece si copiaste manualmente la estructura interna de Google, lo que podría dejar tu registro SPF inválido o apuntando a una referencia innecesaria. Es posible que no interrumpa la entrega de correo inmediatamente, pero hace que tu configuración SPF sea más difícil de mantener.
Quién Realmente Está en Riesgo
La mayoría de usuarios de Google Workspace no necesitan preocuparse por este cambio. Dependen de la entrada estándar include:_spf.google.com, y Google lo gestiona todo entre bastidores. Los registros en este formato continúan funcionando exactamente como se espera.
Quienes usan el include recomendado por Google no enfrentarán problemas. Sin embargo, los propietarios de dominios que copiaron manualmente la estructura interna de Google pueden encontrar inconvenientes. Esto ocurre típicamente cuando un equipo técnico alcanzó el límite de 10 búsquedas DNS e intentó resolverlo codificando referencias de netblock individuales en lugar de usar una herramienta de aplanamiento SPF.
Ese límite de búsquedas no es una preocupación menor. Según RFC 7208, la evaluación de SPF está limitada a 10 búsquedas de mecanismo DNS y 2 búsquedas void por verificación. Exceder cualquiera de estos límites produce un PermError que falla la autenticación en todos los mensajes del dominio. Y ese fallo es silencioso: tus correos no rebotan, simplemente llegan a spam o se rechazan sin ningún error claro que el remitente pueda ver.
El Problema del Presupuesto de Búsquedas DNS
Esta actualización también destaca un problema más amplio para empresas que utilizan múltiples herramientas de envío. Solo include:_spf.google.com de Google usa 4 de tus 10 búsquedas disponibles, dejando solo 6 para todos los demás remitentes. Si también usas SendGrid, que consume 5 búsquedas, el total combinado llega a 9, y agregar solo un remitente más alcanza el límite.
Un dominio que incluye Google, Microsoft, SendGrid y Mailchimp juntos alcanza 12 búsquedas. RFC 7208 limita la evaluación a 10. El servidor de correo receptor devuelve un PermError y cada mensaje del dominio falla la autenticación SPF, independientemente de quién sea realmente el remitente.
Para equipos de crecimiento que ejecutan campañas a través de una plataforma de marketing mientras también envían correo transaccional desde un servicio tercero, esta es una trampa real y común.
Qué Verificar en tu Registro SPF
Si ves entradas de netblock individuales como _netblocks.google.com, _netblocks2.google.com o _netblocks3.google.com en tu registro, elimínalas. Reemplázalas todas con un único include que apunte a _spf.google.com, que mantiene tu configuración limpia y actualizada automáticamente por Google.
Si usas solo Google Workspace para enviar correo, el registro correcto es: v=spf1 include:_spf.google.com ~all
Verificar tu configuración SPF cada pocos meses para detectar entradas obsoletas, referencias duplicadas o includes rotos ayuda a prevenir problemas de alineación y entrega.
Por Qué Esto Importa para tu ROI en Email Marketing
SPF no es solo una tarea de higiene técnica. Se sitúa en la base de tu reputación como remitente. Sin un registro SPF de Google Workspace correctamente configurado, tus correos pueden ser marcados como spam por servidores receptores que no pueden verificar tu dominio. Tu dominio o dirección IP puede incluirse en listas negras, haciendo que la recuperación de entrega sea significativamente más difícil que configurar la autenticación correctamente desde el principio. Y tu reputación de dominio acumula daño a medida que las quejas de spam se componen con el tiempo.
Los requisitos de Google para remitentes masivos, anunciados en octubre de 2023 y aplicados desde febrero de 2024, requieren que cualquier dominio que envíe 5,000 o más mensajes diarios a direcciones de Gmail se autentique con SPF y DKIM, publique un registro DMARC de al menos p=none, mantenga tasas de quejas de spam por debajo del 0,3% e incluya un encabezado de baja con un clic en correo de marketing. Estas reglas se aplican a cada dominio en el encabezado From, y Google ahora rechaza o envía a spam cualquier mensaje de un remitente masivo no compatible.
Hacer esto mal reduce directamente tu alcance entregable, lo que significa tasas de apertura más bajas, tasas de clics más bajas y menor retorno en cada campaña que envíes.
Tres Pasos para Actuar Ahora
SPF solo no es suficiente. Combinarlo con DKIM y DMARC da a los servidores receptores la capacidad de verificar mensajes correctamente y bloquear intentos de phishing usando tu dominio. Herramientas como verificadores de búsqueda SPF, analizadores de DMARC o paneles de seguridad de correo te ayudan a monitorear cambios y detectar problemas de configuración temprano.
Para actuar sobre esta actualización:
- Busca tu registro SPF actual usando una herramienta como MXToolbox o Google Admin Toolbox.
- Si tu registro contiene solo
include:_spf.google.com, no se necesitan cambios. Google gestiona las actualizaciones por ti. - Si ves alguna entrada
_netblocksindividual, consolidalas y verifica que tu conteo total de búsquedas permanezca por debajo de 10.
La limpieza silenciosa de Google de su cadena SPF es un recordatorio de que la infraestructura de autenticación de correo cambia sin previo aviso. Los dominios que dependen de registros construidos manualmente seguirán encontrándose con este problema. Usar referencias de include oficiales y revisar tu configuración regularmente es la forma directa de mantenerte protegido.
