DKIM falla tras cambiar de herramienta de correo: la guía de migración de CNAME y selectores (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. Vea cómo calificamos.

DKIM se rompe tras un cambio de herramienta por dos motivos mecánicos: su panel de DNS estropeó los destinos CNAME de la nueva herramienta — normalmente añadiéndoles su propia zona — o los selectores de la herramienta antigua se eliminaron antes de que su correo se agotara. Solo el 3,87% de los dominios — 10.092.481 — completa la tríada SPF+DKIM+DMARC, según el censo de Defaults.Exposed de 261.086.232 dominios calificados.

El orden del arreglo: analice el dominio y luego compruebe el destino almacenado de cada CNAME nuevo con dig — un destino que termina en su propio nombre de dominio es la prueba definitiva. Repare los registros en los servidores de nombres autoritativos, confirme que la nueva herramienta firma y pasa antes de enrutar correo real a través de ella, y mantenga publicados los selectores de la herramienta antigua hasta que su tráfico se agote.

¿Por qué se rompió DKIM cuando cambió de herramienta?

Nada de DKIM en sí cambió — cambiaron sus selectores. La herramienta antigua firmaba con sus selectores; la nueva firma con otros distintos, normalmente delegados mediante dos o tres registros CNAME añadidos durante el alta. Cuatro trampas explican casi todos los fallos de DKIM posmigración:

Su panel de DNS añadió su zona al destino del CNAME. Muchos paneles tratan cualquier nombre de host pegado como relativo y almacenan en silencio target.provider.com.yourdomain.com en lugar de target.provider.com. El registro existe, el panel muestra una marca verde, y no resuelve a nada.
La confusión del punto final. Algunos paneles exigen un punto final (target.provider.com.) para indicar “absoluto — deje de añadir mi zona”; otros rechazan el punto como inválido y gestionan la condición de absoluto por su cuenta. El mismo valor pegado es correcto en un panel y queda estropeado en el siguiente.
Los selectores de la herramienta antigua se eliminaron el día del cambio. El correo que la herramienta antigua ya firmó permanece en colas de reintento y rutas de reenvío durante días; eliminar sus selectores — o cerrar la cuenta antigua, lo que mata sus CNAME delegados — rompe ese correo retroactivamente.
Verificó en los servidores de nombres equivocados. Si la migración incluyó un cambio de servidores de nombres, los registros corregidos pueden existir en un conjunto de NS mientras los receptores siguen consultando el otro.

Solo el 51,84% de los 261 millones de dominios del censo presenta una clave DKIM localizable en el momento del análisis (datos a fecha de 2026-06-29).

La misma migración suele dejar también restos de SPF — 1.013.416 dominios, aproximadamente 1 de cada 138 de los que intentan SPF, tienen dos registros v=spf1, la señal clásica de que un cambio de proveedor añadió un registro en lugar de fusionarlo. Ese lado de la mudanza tiene su propia guía: SPF dejó de funcionar tras cambiar de proveedor de correo.

¿Cómo detecto un registro CNAME estropeado?

No se fíe del panel — pregunte al DNS qué almacenó realmente. Consulte el destino del CNAME para cada selector que le dio la nueva herramienta. Un ejemplo ilustrativo, imitando un selector delegado al estilo SendGrid (la forma del destino de su proveedor será distinta):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

El proveedor pidió s1.domainkey.u1234567.wl123.sendgrid.net — pero el destino almacenado termina en .yourdomain.com. El panel añadió la zona; ese nombre no resuelve a nada, así que los receptores no encuentran ninguna clave. La versión sana:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Un único punto final en la salida de dig es normal — marca un nombre plenamente cualificado.) Si el destino es correcto, sígalo un salto: dig TXT s1._domainkey.yourdomain.com +short debería devolver la clave del proveedor. Una respuesta vacía con un CNAME correcto significa que el problema está en el lado del proveedor de la delegación — complete su paso de verificación, o vea DKIM “no key for signature” para el diagnóstico a nivel de selector.

El runbook de migración: antes, durante, después

El fallo no suele estar en los registros — está en el orden. Las migraciones de DKIM salen mal en el momento del cambio porque la verificación ocurre después del cambio, cuando el correo real ya está fallando.

Fase	Qué hacer	Condición antes de continuar
Antes del cambio	Añada los CNAME de DKIM de la nueva herramienta (y los registros del dominio de rebote), y luego demuéstrelos: haga `dig` del destino almacenado de cada CNAME desde fuera de su red, complete el paso de verificación de la propia herramienta y envíe una prueba a través de la nueva herramienta a un buzón que controle	El mensaje de prueba muestra `dkim=pass` con `d=` = su dominio — nunca enrute correo real por una herramienta sin verificar
El día del cambio	Mueva el tráfico real a la nueva herramienta. No toque nada de la herramienta antigua: deje vivos sus selectores, CNAME y cuenta	El correo de la nueva herramienta pasa en receptores reales; la antigua sigue pasando para lo que aún fluya por ella
Tras el agotamiento	Vigile los informes agregados de DMARC hasta que los selectores de la herramienta antigua dejen de aparecer (las colas de reintento y los reenvíos corren durante días — dé una semana o más), y luego retire sus registros y su cuenta	Selectores antiguos ausentes de los informes ≥ 7 días antes de eliminarlos

La fila en negrita es donde las migraciones se salvan o se pierden: cada comprobación de esa fila puede hacerse días antes del cambio, con riesgo cero para el correo en producción. La mecánica de retirada de selectores — incluida la razón por la que republicar con un p= vacío es mejor que borrar — se trata en el runbook de rotación; esta tabla trata de secuenciar el cambio de herramienta en sí.

¿Cómo arreglo DKIM después del cambio?

Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Lee sus registros en vivo y muestra lo que los receptores ven realmente — incluidos destinos CNAME a los que se añadió la zona y selectores que no resuelven.
Liste los registros DKIM que espera la nueva herramienta. Desde su consola de administración — para proveedores de correo, las guías de configuración de Google Workspace y Microsoft 365 muestran dónde; las herramientas de boletines y CRM listan sus CNAME bajo autenticación de dominio (vea correos de Mailchimp/Brevo/Klaviyo fallando DMARC).
Compruebe el valor almacenado de cada registro con dig CNAME <name> +short y compárelo carácter a carácter con lo que pidió la herramienta. Un destino que termina en su propio dominio = zona añadida; vuelva a introducirlo, y si el panel sigue añadiendo, agregue el punto final (o quítelo, si el panel rechaza los puntos).
Verifique en los servidores de nombres autoritativos. dig +short NS yourdomain.com, y luego repita las comprobaciones de CNAME con @<that nameserver>. Si la migración cambió los servidores de nombres, compruebe ambos conjuntos — los receptores pueden seguir consultando el antiguo hasta que la delegación se propague.
Vuelva a ejecutar la verificación de la herramienta y envíe un mensaje de prueba. La cabecera Authentication-Results debería mostrar dkim=pass con d= igual a su dominio — un aprobado en el dominio por defecto de la herramienta no está alineado para DMARC.
Deje publicados los selectores de la herramienta antigua hasta que su correo se agote, y luego retírelos deliberadamente. Después vuelva a analizar, y resuelva cualquier otra cosa señalada en la página de arreglar DKIM.

Preguntas frecuentes

¿Necesito el punto final en mi CNAME de DKIM o no? Depende por completo del panel. El punto significa “nombre absoluto — no añada mi zona”; algunos paneles lo exigen, otros lo añaden por usted, otros lo rechazan. La única prueba que importa es la salida de dig CNAME <selector>._domainkey.yourdomain.com +short después de guardar: si el destino termina en su propio dominio, el panel añadió la zona y usted necesita el punto (o un formato de entrada distinto).

¿Puedo borrar los registros DKIM de la herramienta antigua el día del cambio? No. El correo que la herramienta antigua firmó sigue en colas de reintento y rutas de reenvío, y borrar la clave a la que apunta rompe esos mensajes retroactivamente. Mantenga los selectores antiguos activos hasta que dejen de aparecer en sus informes agregados de DMARC — una semana o más — y tampoco cierre la cuenta antigua antes de eso.

Mi panel de DNS y la nueva herramienta dicen ambos “verificado”, pero los receptores siguen fallando DKIM. ¿Cómo? Dos casos comunes: la herramienta verificó contra una comprobación en caché mientras los servidores de nombres autoritativos sirven otra cosa (consúltelos directamente con dig @<ns>), o DKIM pasa pero con el dominio de firma por defecto de la herramienta en lugar del suyo, así que DMARC sigue fallando la alineación. El análisis distingue los dos casos.

¿Pueden coexistir los registros DKIM de ambas herramientas durante el solapamiento? Sí — y deberían. DKIM no tiene una regla de registro único: cada selector es su propio nombre DNS, así que los registros de ambas herramientas conviven sin conflicto, lo que hace que la regla de mantener los selectores antiguos durante el agotamiento salga gratis. (SPF es lo contrario — dos registros v=spf1 lo anulan, y por eso la guía de migración de SPF trata de fusionar.)

Envíe el informe al propietario

Si está ejecutando esta migración para un cliente o para su empresa, ciérrela con evidencia. Cuando la nueva herramienta firme y alinee, vuelva a ejecutar el análisis gratuito y reenvíe el informe calificado al propietario del negocio: una prueba fechada y en lenguaje claro de que el cambio dejó el dominio plenamente autenticado. Es el documento que necesitará para la renovación del ciberseguro y el próximo cuestionario de seguridad de proveedores — convierte “la migración está hecha” de una afirmación en un documento.

Compruebe su DKIM gratis

Vea si los selectores de su nueva herramienta resuelven — y exactamente qué corregir — de forma privada y solo para el propietario.

Compruebe su dominio → · SPF se rompió tras cambiar de proveedor → · Arreglar DKIM → · Configurar DKIM en Google Workspace → · Solo datos agregados. Datos almacenados y procesados en la UE.