Guía de configuración de registros SPF en GoDaddy para 2026

Ya tiene el registro en GoDaddy, se envió la última campaña y Gmail sigue tratando la mitad de sus envíos como si vinieran de un extraño. Luego, alguien añade un CRM, una herramienta de boletines y una plataforma transaccional, y toda la configuración empieza a comportarse como un montón de cables sueltos. Ahí es donde un registro SPF de GoDaddy deja de ser una simple casilla de verificación y se convierte en lo que mantiene la capacidad de entrega de sus correos.

La parte dolorosa es que los fallos de SPF rara vez se anuncian claramente. Se añade un remitente, se edita el DNS una vez y, semanas después, el equipo nota que los correos llegan a spam, errores de autenticación o que una plataforma funciona mientras otra desaparece de la lista. Si esto le resulta familiar, está lidiando con la propiedad del DNS, la estructura de registros y el límite de 10 búsquedas, no solo con “problemas de correo electrónico”.

Por qué su registro SPF de GoDaddy es más importante de lo que cree

El concepto de SPF es simple, pero su práctica es brutal. Un servidor receptor verifica la política publicada del dominio en el DNS y luego pregunta si el servidor de envío tiene permiso para enviar correos en nombre de ese dominio. Si la respuesta no coincide, el mensaje puede ser tratado como no autorizado, incluso cuando el remitente es legítimo.

Es por eso que un registro SPF de GoDaddy roto duele más de lo que muchos piensan. Tanto Microsoft 365 como Google Workspace dependen de señales de autenticación que los proveedores de buzones evalúan tras bambalinas, por lo que un registro SPF faltante o mal formado puede afectar la llegada a la bandeja de entrada mucho antes de que alguien note un fallo visible. La diferencia entre hardfail y softfail importa aquí, porque el calificador final le indica a los receptores si el correo no autorizado debe ser rechazado directamente o tratado con sospecha.

La parte que la mayoría de los equipos pasa por alto

SPF no solo dice: “¿es este dominio suyo?”. Dice: “¿está este remitente en la lista aprobada publicada en el DNS?”. Ahí es donde la alineación SPF empieza a importar, porque DMARC verifica más tarde si el dominio visible del remitente (From) coincide con la fuente autenticada.

Regla práctica: si se añadió un remitente a la pila después de que se creó el registro SPF original, ese remitente probablemente se ha convertido en el problema a menos que el registro DNS también se haya revisado.

La propia guía de GoDaddy refleja el enfoque moderno, donde el SPF se publica como un registro TXT en lugar de un registro de tipo SPF, y el flujo de trabajo se centra en la edición de DNS dentro de la cartera de dominios. Esa configuración suena común, pero es exactamente la razón por la que el SPF se rompe tan a menudo. Es fácil añadir el registro una vez y olvidarlo después de que se aprueba la siguiente herramienta.

Cómo añadir su primer registro SPF en el DNS de GoDaddy

Comience en la Cartera de dominios, abra DNS y añada un registro como TXT. La ayuda de GoDaddy muestra esta ruta para la configuración de SPF, con la política SPF introducida en el campo Valor y el host establecido en la raíz cuando la política se aplica a todo el dominio, mientras que el TTL permanece en Predeterminado en el ejemplo documentado para registros de correo relacionados Ayuda de registros SPF de GoDaddy Campos de registro DNS de GoDaddy para autenticación de correo.

Los campos que importan

El Tipo debe ser TXT, no SPF. La documentación de GoDaddy utiliza TXT porque es el formato de publicación estándar para SPF en el DNS moderno, y esa elección evita ambigüedades entre los validadores.

El Nombre suele ser @ para una política de dominio raíz. Eso le indica a GoDaddy que el registro pertenece a la parte superior del dominio en lugar de a un subdominio. El Valor es donde reside la cadena SPF, así que ahí es donde debe pegar la política en sí.

El TTL puede permanecer en Predeterminado si sigue la configuración documentada de GoDaddy, especialmente cuando no está en medio de una resolución de problemas. Es fácil pasar por alto los nombres exactos de los campos, pero marcan la diferencia entre un registro que reside en la raíz del dominio y uno que se encuentra en un lugar inútil.

Un ejemplo de correo gestionado por GoDaddy se ve como v=spf1 include:secureserver.net -all, que es la forma que muestra GoDaddy para el alojamiento de correo. Si solo está autorizando una fuente de envío, esa es la forma que desea: un registro, una política, un lugar.

Para una variante específica de Gmail, esta guía de SPF para usuarios de Gmail muestra la misma lógica de “TXT primero” en la práctica.

Si escribe el tipo de registro como algo distinto a TXT, o deja el host en blanco cuando la política necesita estar en la raíz, el registro puede existir en la interfaz de usuario pero fallar en la capa DNS.

Más adelante en el proceso, la propia interfaz de GoDaddy se vuelve menos importante que la zona DNS autorizada, pero el primer paso es conseguir que el registro se introduzca en el campo correcto, con el tipo correcto y en el host correcto.

Sintaxis SPF para los remitentes que utiliza

Muchas organizaciones no utilizan un solo remitente. Utilizan un buzón principal, una plataforma de marketing, un CRM y un sistema transaccional. El registro SPF es la declaración única que los autoriza a todos, por lo que el trabajo real consiste en elegir los mecanismos correctos y mantener la lista lo suficientemente corta para validarla antes de que el DNS de GoDaddy empiece a jugar en su contra.

Cadenas SPF listas para copiar para pilas de remitentes comunes

Configuración del remitente	Valor SPF	Búsquedas utilizadas
Google Workspace	v=spf1 include:_spf.google.com -all	Un include, luego la verificación de política final
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	Un include, luego la verificación de política final
Google Workspace más una herramienta de marketing	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	Dos includes, más cualquier búsqueda anidada dentro de los registros incluidos
Microsoft 365 más un remitente transaccional	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	Dos includes, más cualquier búsqueda anidada dentro de los registros incluidos

Estas cadenas son útiles porque muestran el patrón: un registro, una política, un lugar para controlarlo en GoDaddy. Si su pila comienza con Google Workspace o Microsoft 365 y luego crece hacia correos de marketing y transaccionales, el registro suele dejar de tratarse de sintaxis y empieza a tratarse de cuántas búsquedas DNS gasta cada proveedor tras bambalinas.

Qué hacen los mecanismos

include indica que se debe verificar la política SPF de otro dominio y heredar su autorización. Ese es el caballo de batalla para Google Workspace, Microsoft 365, Mailchimp, SendGrid y plataformas similares.

ip4 es para direcciones de envío fijas, lo cual ayuda cuando usted controla la IP de origen y no quiere depender de la cadena de políticas de otro proveedor. all al final establece la regla para todo lo que no esté ya autorizado, y el calificador decide cuán estricto debe ser el fallo.

Regla práctica: utilice un final más estricto cuando su lista de remitentes sea estable, y un final más suave solo mientras todavía esté limpiando la pila.

Una perspectiva externa útil sobre la planificación de remitentes es el consejo para campañas de correo electrónico de pequeñas empresas, ya que los equipos de campaña a menudo añaden herramientas sin verificar su impacto en el DNS.

La parte que hace tropezar a las configuraciones reales de GoDaddy es el presupuesto de búsqueda. Cada include adicional gasta ese presupuesto, y un registro puede parecer limpio mientras sigue fallando porque la cadena se vuelve demasiado profunda. Construya la sintaxis en torno a la pila que utiliza, no a la que desearía utilizar.

Combinación de múltiples remitentes sin alcanzar el límite de búsqueda

El gran modo de fallo con un registro SPF de GoDaddy no es la sintaxis, es la acumulación. Un dominio comienza con un remitente, luego marketing añade otro, luego ventas añade un CRM, luego operaciones añade una plataforma transaccional, y nadie nota que el SPF ahora está intentando validar más sistemas de los que permite el estándar.

La regla es directa y no se dobla. Nunca publique más de un registro SPF con el mismo nombre. Si existen dos registros TXT de SPF para el mismo dominio, los receptores pueden tratar el resultado como inválido o ambiguo, lo que significa que el registro que pensaba que estaba ayudando podría ser el que está rompiendo la autenticación.

Cómo funciona el proceso de combinación

Comience enumerando cada remitente legítimo. Luego, agrúpelos en una política TXT, utilizando declaraciones include donde el proveedor gestione su propia infraestructura de envío. Si ya tiene un registro en GoDaddy, edite ese en lugar de crear una segunda copia.

La segunda trampa es el anidamiento. Un solo include puede ocultar varias búsquedas más dentro de la propia política SPF del proveedor, y es por eso que los dominios pueden quedarse sin presupuesto más rápido de lo que el equipo espera. La guía centrada en GoDaddy advierte a los usuarios que se mantengan por debajo del límite de 10 búsquedas de mecanismos DNS, y ese límite se aplica durante la evaluación, no después del hecho Mejores prácticas de configuración SPF para dominios de GoDaddy Guía SPF 2026 para dominios de GoDaddy.

Un modelo operativo más limpio

• Audite a cada remitente primero: elimine las herramientas antiguas que ya no envían correos, porque los includes obsoletos siguen consumiendo presupuesto.
• Consolide en una sola política: mantenga toda la autorización en un único registro TXT con el nombre correcto.
• Verifique el recuento de búsquedas antes de guardar: un registro que parece ordenado aún puede fallar si los includes anidados lo empujan por encima del límite.

Mail Merge for Gmail encaja perfectamente en esta lógica. Se envía a través de la infraestructura autenticada de Google, por lo que no necesita su propio include separado y no añade nada al presupuesto SPF cuando ya está autorizando a Google Workspace.

La razón por la que esto importa tanto es simple. Un equipo puede mantenerse por debajo del límite durante meses, luego un nuevo proveedor empuja el registro más allá del límite y el SPF comienza a fallar sin ningún error DNS obvio en la interfaz de usuario de GoDaddy.

Verificación de que su registro realmente funciona

Guardar el registro en GoDaddy no es prueba de nada. Solo significa que el cambio se introdujo, no que la zona autorizada lo esté sirviendo, no que las cachés se hayan actualizado y no que la política se analice correctamente.

Tres verificaciones, tres respuestas diferentes

La primera verificación es una búsqueda DNS contra la zona en vivo. Una consulta dig o nslookup le dice lo que están devolviendo los servidores de nombres autorizados, lo cual importa porque la interfaz de GoDaddy puede mostrar un valor antes de que finalice la propagación, y no le dirá si otro host DNS posee la zona en su lugar.

La segunda verificación es un analizador SPF como la verificación SPF de MXToolbox. Ese tipo de herramienta es útil porque lee la sintaxis y cuenta las búsquedas al mismo tiempo, que es exactamente donde aparecen los includes anidados y las cadenas que exceden el límite.

La tercera verificación es la evidencia a nivel de mensaje. Envíe una prueba a Gmail, abra el mensaje original e inspeccione los encabezados. La línea Authentication-Results generalmente mostrará si el SPF pasó o falló para el dominio de envío, lo que le indica cómo evaluó el mensaje un proveedor de buzón, no solo lo que dice el DNS.

Regla práctica: si el DNS parece correcto pero los encabezados siguen fallando, el problema suele estar en la capa de validación, no en la interfaz de usuario de GoDaddy.

También existe una realidad de propagación que los equipos ignoran bajo su propio riesgo. El comportamiento del TTL de GoDaddy suele ser rápido, pero los cambios de DNS en casos extremos aún pueden tardar en asentarse en los resolutores. Si está moviendo registros entre proveedores, confirme primero los servidores de nombres autorizados y luego valide contra la zona real, no contra el panel de control que haya utilizado. Para rastrear mensajes de principio a fin, esta guía de rastreo de correos es el complemento más limpio.

Del SPF Pass a la autenticación de correo electrónico completa

Un SPF pass se siente tranquilizador, pero no resuelve todo el problema. El SPF solo autoriza las fuentes de envío, no firma el mensaje y no impide que un mensaje sea alterado después de que sale del remitente. Es por eso que el SPF por sí solo aún puede dejar casos extremos de reenvío y agujeros de suplantación.

Dónde encajan DKIM y DMARC

DKIM añade una firma criptográfica al mensaje en sí. En el DNS gestionado por GoDaddy, eso suele significar un registro TXT bajo el host selector, y Google Workspace utiliza comúnmente google._domainkey como parte de esa configuración.

DMARC se sitúa sobre el SPF y DKIM. Indica a los sistemas receptores qué hacer cuando la autenticación falla y a dónde enviar los informes, generalmente a través de un registro TXT en _dmarc en el dominio. Sin DMARC, los proveedores de buzones no tienen una política compartida que seguir cuando el SPF o DKIM no coinciden.

La conclusión clave es que el SPF es solo una capa de confianza. Un mensaje falsificado aún puede explotar una alineación débil si DKIM no está en su lugar, y un mensaje reenviado aún puede comportarse de manera diferente a un envío original incluso cuando el SPF estaba limpio en el origen.

La pila práctica es sencilla. SPF autoriza al remitente, DKIM firma el mensaje y DMARC indica a los receptores cómo actuar cuando los dos no están de acuerdo. La sección anterior sobre verificación importa aquí porque no querrá endurecer la política antes de saber que cada remitente legítimo se está autenticando.

Para un recorrido más profundo por toda la pila, esta guía de autenticación de correo electrónico conecta SPF, DKIM y DMARC en un solo flujo de trabajo.

Mantener el SPF limpio durante campañas reales de Mail Merge

Una campaña de Mail Merge pone el trabajo de DNS bajo presión rápidamente. Los equipos de ventas, reclutamiento o eventos pueden enviar una secuencia limpia desde Gmail un día y luego culpar al contenido la semana siguiente cuando las respuestas disminuyen, aunque el problema más profundo sea la deriva de la autenticación.

Mail Merge for Gmail se envía a través de la infraestructura autenticada de Google, por lo que no crea un remitente separado que necesite su propio include de SPF. El mayor riesgo es que la pila circundante cambie, el propietario del dominio añada otra plataforma y los proveedores de buzones comiencen a evaluar un historial de mensajes que ya no parece consistente.

Una lista de verificación previa a la campaña que realmente ayuda

• Confirme que el SPF pasa para la cuenta de Google que envía: pruebe el buzón exacto que enviará la campaña, no un alias aleatorio.
• Confirme que DKIM esté habilitado en el administrador de Google Workspace: el SPF por sí solo es demasiado frágil para correos reenviados o reenvueltos.
• Confirme que DMARC esté al menos en p=none con informes activados: eso le da visibilidad antes de endurecer la política.

Un resultado SPF verde por sí solo no significa que la campaña sea segura para lanzarse. Solo significa que el remitente coincidió con la política DNS actual en ese momento.

El mejor hábito es tratar el registro SPF como si fuera fontanería. Revíselo antes de la campaña, revíselo cuando se añada un nuevo remitente y revíselo de nuevo cuando una plataforma cambie su ruta de envío. Así es como evita que un registro SPF de GoDaddy envejezca hasta convertirse en un problema de capacidad de entrega.

---

Mail Merge for Gmail ayuda a los equipos a enviar campañas personalizadas desde Gmail mientras mantiene la ruta de envío vinculada a Google Workspace, lo que hace que el SPF sea más fácil de razonar cuando la pila de dominios se llena. Si está limpiando una configuración DNS de GoDaddy antes de su próxima ronda de divulgación, visite Mail Merge for Gmail y revise cómo encaja en un flujo de trabajo que ya depende de que el SPF, DKIM y DMARC se mantengan limpios.