GoDaddy: publicar SPF, DKIM y DMARC en la zona DNS

Tipo: TXT
Host: @
Valor: v=spf1 include:_spf.google.com ~all

Publicar los registros DKIM

DKIM se publica bajo un selector proporcionado por el servicio de envío. La forma del registro depende del proveedor: algunos dan un CNAME (delegación), otros una clave pública en TXT. En ambos casos, el campo Host recibe el selector sin el dominio:

Tipo: CNAME
Host: sel._domainkey
Valor: sel.dkim.proveedor.example.

Los valores DKIM en TXT son largos (una clave de 2048 bits). GoDaddy acepta esos valores largos en su interfaz; históricamente, algunas zonas exigían dividir en segmentos de 255 caracteres, pero la entrada por la interfaz lo gestiona hoy. El valor debe pegarse exactamente, sin espacio ni salto de línea parásito — una clave DKIM truncada o alterada no se verifica, y el síntoma (DKIM ausente de los informes) es el mismo que el de una clave nunca publicada.

Publicar el registro DMARC

El registro DMARC es un TXT bajo el subdominio _dmarc:

Tipo: TXT
Host: _dmarc
Valor: v=DMARC1; p=none; rua=mailto:informes@ejemplo.es

GoDaddy no ofrece un asistente DMARC dedicado: a diferencia de algunos registros de correo que un menú puede rellenar previamente, el registro _dmarc se añade siempre a mano, como un TXT ordinario. No es una carencia — un registro DMARC se reduce a su valor — pero explica por qué no se encuentra bajo un botón «activar DMARC»: hay que componerlo uno mismo. Se empieza siempre en p=none: la política no impone nada, pero la dirección rua= desencadena el envío de los informes agregados, que servirán para verificarlo todo antes de endurecer. Los ejemplos de registros DMARC comentados detallan las etiquetas disponibles (sp, adkim, aspf, pct eliminada bajo DMARCbis) y los valores que conviene conservar según el contexto. Bajo DMARCbis, la pertenencia de los subdominios se determina mediante el DNS Tree Walk, sin cambiar la forma de publicar el registro en GoDaddy.

El caso del correo vendido por GoDaddy

GoDaddy no solo aloja DNS: también revende ofertas de mensajería, y es una fuente de confusión. Coexisten dos productos: el antiguo «Workspace Email» (herencia de GoDaddy, cuyo include SPF es include:secureserver.net) y Microsoft 365 revendido por GoDaddy (cuyo include es include:spf.protection.outlook.com). Un dominio cuyo correo parte de uno de estos productos debe usar el include correspondiente — y no el otro.

La trampa clásica: un dominio migrado de Workspace Email a Microsoft 365 que conserva el antiguo include:secureserver.net en su SPF. El include ya no corresponde al servicio emisor real, y SPF falla. Verificar qué producto de mensajería está efectivamente activo — y alinear el include con él — forma parte de la puesta a punto de un dominio alojado en GoDaddy.

Verificar que la zona la gestiona realmente GoDaddy

Antes de introducir nada, una comprobación evita el error más frustrante: asegurarse de que la zona DNS del dominio la gestiona realmente GoDaddy. Un dominio puede estar registrado en GoDaddy pero tener sus servidores de nombres (NS) delegados en otro sitio — otro alojador, un proveedor de infraestructura, un CDN. En ese caso, la interfaz DNS de GoDaddy sí muestra una zona, pero ya no es la autoritativa: los registros que se añaden ahí no se sirven nunca, y el dominio queda sin protección pese a horas pasadas en la interfaz correcta — en el lugar equivocado.

La comprobación es rápida: los servidores de nombres efectivos del dominio se leen en una consulta NS. Si apuntan a GoDaddy (ns*.domaincontrol.com), la zona de GoDaddy es la autoritativa y los registros ahí cuentan. Si apuntan a otro sitio, es en esa otra interfaz donde hay que publicar SPF, DKIM y DMARC. Esta comprobación previa es el primer reflejo de todo diagnóstico «publiqué DMARC pero no llega nada».

Propagación y TTL

Una modificación de zona en GoDaddy no es instantánea para el resto del mundo. Cada registro lleva un TTL (tiempo de vida) que indica cuánto tiempo pueden los resolutores guardar el valor antiguo en caché. GoDaddy aplica por defecto un TTL de una hora: tras una modificación, hay que esperar a veces hasta ese plazo antes de que los servidores destinatarios vean el nuevo valor.

Dos consecuencias prácticas. Primero, no concluir demasiado pronto que un registro «no funciona» unos minutos después de ponerlo: la propagación puede no haber terminado, y una primera comprobación negativa no es un veredicto. Segundo, antes de una modificación sensible — una rotación de clave DKIM, un cambio de política — bajar el TTL de antemano (a cinco minutos, por ejemplo) reduce la ventana durante la cual el valor antiguo y el nuevo coexisten en las cachés. Una vez el cambio estable y verificado, el TTL puede volver a subir.

Los errores de entrada habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Introducir el dominio completo en el campo Host. La trampa número uno, descrita más arriba: _dmarc.ejemplo.es en lugar de _dmarc crea un registro con el nombre desplazado, imposible de encontrar.

Publicar dos registros SPF. GoDaddy deja crear un segundo TXT v=spf1; dos registros SPF invalidan SPF por completo. Hay que fusionar los include en uno solo.

Pegar una clave DKIM truncada. Un valor incompleto o con un espacio parásito no se verifica; el síntoma engaña, porque el registro existe pero es inválido.

Endurecer la política demasiado pronto. Pasar a p=reject antes de confirmar con los informes que todo el tráfico legítimo se alinea equivale a rechazar los propios mensajes — el orden p=none, luego observación, luego endurecimiento no tiene nada de específico de GoDaddy, pero sigue siendo la única secuencia segura.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la pantalla de GoDaddy, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados confirma primero que el registro se lee de verdad — si se nombró mal (la trampa del campo Host), no llega ningún informe, lo que es en sí una señal.

Basta una cadencia sencilla: una primera lectura unos días después de la publicación, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. Se verifica que cada fuente legítima — el servicio de correo, el ESP, las aplicaciones — se alinea, y solo entonces se endurece. Una vez confirmada esa cobertura durante varios días, el paso a p=reject se hace sin riesgo. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.