¿Puedo tener dos registros SPF en GoDaddy si uso dos proveedores de correo?

No. Un dominio debe publicar exactamente un registro SPF. La propia guía de GoDaddy indica que los duplicados pueden impedir la entrega del correo. Fusiona todos los remitentes en un solo registro con includes adicionales y un único mecanismo all al final, y mantén el total por debajo del límite de diez consultas DNS que fija el RFC 7208.

¿Por qué mi registro DKIM se ve bien en GoDaddy y aun así falla?

Tres causas habituales. El campo Nombre lleva el nombre de host completo en lugar del prefijo del selector, así que el registro queda un nivel más abajo. El lado del proveedor nunca se activó, por ejemplo nunca se hizo clic en Iniciar autenticación en la consola de Google Workspace. O la llave larga de 2048 bits quedó truncada, algo que Google documenta como consecuencia del límite de 255 caracteres por cadena TXT.

¿Cuánto hay que esperar después de guardar los registros en GoDaddy?

GoDaddy indica que la mayoría de los cambios de DNS se aplican en menos de una hora, con hasta 48 horas para la propagación mundial, y el TTL por defecto de un registro nuevo es de una hora. Antes de asumir que es propagación, consulta tú mismo el nombre de host exacto y manda un mensaje de prueba a una dirección externa para leer la cabecera Authentication-Results.

SPF, DKIM y DMARC en GoDaddy: los registros exactos

Un cliente reenvía un rebote y pregunta por qué Gmail de repente rechaza las facturas que su contadora manda desde hace tres años. El dominio está registrado en GoDaddy, los nameservers siguen siendo los de GoDaddy y en la lista de DNS hay dos registros TXT separados que empiezan con v=spf1. Ese es todo el problema. Se arregla en unos cuatro minutos cuando sabes qué pantalla abrir y qué significa cada campo.

Esta es la versión práctica: los tres registros que necesita la autenticación de correo, con la forma exacta que espera el editor de DNS de GoDaddy, para las tres configuraciones que más vemos en dominios de GoDaddy. Google Workspace, Microsoft 365 y el correo Professional Email del propio GoDaddy.

Dónde viven de verdad tus registros DNS

GoDaddy vende el dominio, el DNS y el buzón como cosas distintas, y la gente confunde los paneles todo el tiempo. Los registros de autenticación van en la zona DNS, no en el producto de correo.

Entra a tu Portafolio de dominios de GoDaddy y selecciona el dominio para abrir su página de configuración.
Elige DNS para ver los registros.
Elige Agregar nuevo registro y selecciona el tipo.

Hay dos detalles de ese editor que deciden si tus registros van a funcionar.

El campo Nombre es un prefijo, no un nombre de host completo. GoDaddy lo documenta como el nombre de host sin el dominio. Escribe @ para el dominio raíz, o un prefijo como _dmarc. GoDaddy le agrega tu dominio, y por eso pegar _dmarc.tudominio.com crea en silencio un registro en _dmarc.tudominio.com.tudominio.com que ningún servidor va a leer.
El TTL viene en una hora. GoDaddy indica que la mayoría de los cambios se aplican en menos de una hora y pueden tardar hasta 48 horas en llegar a todos los resolutores.

Una revisión antes de todo esto: si los nameservers del dominio apuntan a Cloudflare, a tu hosting o a otro proveedor, el editor de DNS de GoDaddy no es la zona que lee internet. Los registros que agregues ahí se van a ver correctos y no van a hacer nada. Confirma primero los nameservers y edita donde apunten.

SPF: un solo registro, y probablemente uno que tú no escribiste

SPF dice qué servidores pueden enviar correo con tu dominio. La regla que más se rompe en GoDaddy es que un dominio lleva exactamente un registro SPF. GoDaddy lo dice sin rodeos en su propia guía de Professional Email: asegúrate de que tu dominio tenga un solo registro SPF, porque los duplicados pueden impedir la entrega del correo. Dos registros no son cobertura doble, son un error permanente, y los servidores que reciben tratan el resultado como inservible.

Así que antes de agregar nada, lee lo que ya está en @. Muchos dominios en GoDaddy traen un SPF que se creó cuando se configuró un buzón, un creador de sitios o un plan de hosting. Si encuentras uno, lo que vas a hacer es fusionar, no agregar.

La base que Google documenta para un dominio que solo usa Workspace:

Tipo:  TXT
Nombre: @
Valor: v=spf1 include:_spf.google.com ~all
TTL:   1 hora

El valor que GoDaddy documenta para su propio Professional Email:

v=spf1 include:secureserver.net -all

Los tenants de Microsoft 365 publican el include de Microsoft, include:spf.protection.outlook.com. Si tu correo está en Microsoft, nuestra guía de autenticación para Microsoft 365 cubre todo el lado del tenant.

Cuando un segundo sistema envía en tu nombre, un CRM, una plataforma de facturación, una tienda, entra en ese mismo registro único como otro include, con un solo mecanismo all al final:

v=spf1 include:_spf.google.com include:_spf.proveedor-ejemplo.com ~all

Usa el include exacto que publique ese proveedor, nunca uno que supongas. Y lleva la cuenta: el RFC 7208 limita la evaluación de SPF a diez términos que consultan DNS, y una implementación que pasa ese límite debe devolver permerror. Pasando de diez, tu SPF no se degrada con elegancia: falla. De eso trata la guía del límite de diez consultas, y se llega más rápido de lo que la gente cree.

DKIM: el registro depende de quién envía tu correo

DKIM firma cada mensaje con una llave privada que guarda tu proveedor de correo, y publica la llave pública en tu DNS. GoDaddy no genera llaves DKIM. Solo guarda lo que te da tu proveedor, así que el primer paso siempre está en la plataforma de correo, no en el dominio.

Google Workspace

En la consola de administración entra a Aplicaciones, luego Google Workspace, luego Gmail, y elige Autenticar correo electrónico. Selecciona el dominio y luego Generar nuevo registro. Elige la llave de 2048 bits si tu proveedor de DNS la admite, y deja el prefijo de selector google que viene por defecto. Google publica una advertencia que conviene tener en cuenta antes de planificar un cambio: después de activar Gmail para la organización puedes tener que esperar de 24 a 72 horas para que la llave DKIM esté disponible en la consola.

El registro es TXT y su Nombre es el selector más _domainkey:

Tipo:  TXT
Nombre: google._domainkey
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkq...   (la llave que generó Google)
TTL:   1 hora

Guárdalo, espera a que resuelva y regresa a la consola para elegir Iniciar autenticación. Saltarse ese último clic es la razón más común de que un DKIM que se ve perfecto no firme nada.

Microsoft 365

Microsoft aloja y rota las llaves por ti, así que publicas dos registros CNAME en lugar de una llave. Microsoft Learn los documenta con esta forma, donde la primera parte se deriva de tu dominio de correo y el destino termina en el dominio inicial onmicrosoft.com de tu tenant:

Tipo:  CNAME
Nombre: selector1._domainkey
Valor: selector1-contoso-com._domainkey.contoso.onmicrosoft.com

Tipo:  CNAME
Nombre: selector2._domainkey
Valor: selector2-contoso-com._domainkey.contoso.onmicrosoft.com

Se publican los dos. El segundo existe para que Microsoft pueda rotar llaves sin cortar el servicio, y un tenant que solo publica selector1 se rompe el día que ocurre la rotación.

Professional Email de GoDaddy

El buzón propio de GoDaddy también usa dos registros CNAME, con los nombres secureserver1._domainkey y secureserver2._domainkey, apuntando a los destinos que aparecen durante la configuración en el panel de correo. Cópialos de esa pantalla y no de un artículo, incluido este, porque esos valores son específicos de tu cuenta.

Una nota práctica para los tres casos: una llave de 2048 bits es una cadena larga, y la propia guía de solución de problemas de Google señala el límite de 255 caracteres por cadena TXT como causa de llaves truncadas o desordenadas. Si tu registro se guarda pero nunca valida, revisa lo que realmente resuelve, no lo que pegaste.

DMARC: el registro que le da sentido a los otros dos

SPF y DKIM responden preguntas técnicas. DMARC es el que protege el nombre que tus clientes sí ven, la dirección del campo De, y es el registro que le dice a quien recibe qué hacer cuando un mensaje falla. Empieza siempre aquí, por muy seguro que te sientas:

Tipo:  TXT
Nombre: _dmarc
Valor: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com
TTL:   1 hora

p=none no cambia nada en la entrega. Pide que te manden reportes, y esos reportes son la forma de descubrir los cuatro sistemas que envían con tu dominio y que nadie recordaba. La palabra clave aquí es alineación. Las directrices de remitentes de Google exigen que el dominio del campo De esté alineado con el dominio de SPF o con el de DKIM, así que un mensaje puede pasar SPF contra la ruta de retorno de un proveedor y aun así fallar DMARC. Esto pasa tanto con proveedores de buzón como con plataformas de marketing, y por eso normalmente DKIM es la pata que sostiene la alineación.

Lee un par de semanas de reportes, corrige los remitentes que aparezcan sin alinear, y después sube la política a quarantine y finalmente a reject. La guía de endurecimiento trae el orden y los tiempos, y la guía de reportes descifra el XML. Si envías volumen esto deja de ser opcional: Google pide a los remitentes masivos, definidos como los que envían del orden de 5,000 mensajes diarios o más a cuentas de Gmail, autenticar con SPF, DKIM y DMARC, ofrecer baja con un clic en el correo de marketing y mantener la tasa de spam que reporta Postmaster Tools por debajo de 0.30 por ciento.

Propagación, y cómo verificar de verdad

Lo que dice GoDaddy es menos de una hora en la mayoría de los casos y hasta 48 horas a nivel mundial. En la práctica, el patrón que te quita una tarde es otro: el registro resuelve bien y la configuración sigue mal. Tres revisiones, en orden.

¿El registro resuelve donde crees? Consulta el nombre de host exacto, con selector incluido, y confirma que hay un solo TXT con v=spf1 en la raíz.
¿El proveedor está de acuerdo? Google Workspace debe mostrar la autenticación iniciada y Microsoft 365 la firma DKIM habilitada. Un registro publicado que el proveedor no activó no firma nada.
¿Pasa un mensaje real? Manda uno a una dirección externa, abre las cabeceras completas y lee la línea Authentication-Results. Nuestro analizador de cabeceras hace esa parte por ti, y es la única prueba que recorre el camino que toma el correo de un cliente.

Los errores que seguimos encontrando en dominios de GoDaddy

Dos registros SPF. Normalmente uno del producto de correo y otro que alguien agregó después para un CRM. Fusiona los includes en uno solo y borra el otro.
El nombre de host completo en el campo Nombre. GoDaddy agrega el dominio, así que el registro queda un nivel más abajo y no hace nada.
DKIM publicado y autenticación nunca iniciada. Muy común con Google Workspace, porque la mitad del DNS ya se ve terminada.
Editar la zona equivocada. El dominio está en GoDaddy, los nameservers no, y cada cambio se guarda en un archivo que nadie consulta.
Saltar directo a p=reject. Brincarse la fase de reportes es la forma de que un lunes dejen de entregarse las facturas, los recordatorios de citas y el escáner de la oficina.
Un DMARC sin rua. Una política sin reportes te deja con la aplicación y sin visibilidad, que es el peor cambio posible en todo este tema.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, y la entregabilidad de correo es lo que más hacemos. Si tu dominio está en GoDaddy y el correo cae en spam o rebota, el primer paso útil es un diagnóstico y no una reescritura: qué está publicado hoy, qué remitentes están realmente alineados y en qué orden cambiar las cosas para que nada se caiga entre semana. Nuestro diagnóstico de correo y el analizador DMARC son gratis y te dan casi todo eso en un minuto. Si prefieres delegarlo, mira cómo trabajamos o agenda una llamada corta y trae un rebote contigo.

Configurar SPF, DKIM y DMARC en GoDaddy (con Workspace, Microsoft 365 o correo de GoDaddy)