[ DNS y dominios ]

Colgar DKIM CNAME después de que un proveedor sea dado de baja

Retire los alias DKIM administrados por proveedores con comprobaciones de selectores activos, rotación en espera, mensajes retrasados, control de objetivos y acceso restante.

Por el equipo de investigación EmailAuth · 8 minutos de lectura

[Puntos clave]

  • Un alias DKIM , una configuración de firma y las credenciales del proveedor son dependencias independientes.
  • Verifique los selectores en espera y los mensajes en curso antes de retirar las búsquedas de claves públicas.
  • No infiera la reclamabilidad del objetivo o la revocación global instantánea de un cambio DNS .
En esta página

[ Llevar ]

Cierre la relación de firma real, conserve solo las dependencias de mensajes justificadas y verifique la autenticación de reemplazo y retiro de DNS por separado.

[ Por rol ]

¿Qué significa esto para ti?

Elija su función para conocer los próximos pasos prácticos.

Administrador de TI/correo

Retirar selectores por evidencia

Los ejemplos de mensajes recientes no revelan todas las rotaciones o dependencias de colas.

Próximos pasos

  1. Inventario de objetivos exactos d=/s= y alias.
  2. Consulta los selectores de espera y los mensajes programados o retrasados.
  3. Verifique el firmante de reemplazo y el estado DNS de retiro.

CISO / Operaciones de seguridad

Revisar el control de claves continuo

Un objetivo de clave pública externa sigue siendo una dependencia de confianza hasta que se retira adecuadamente.

Próximos pasos

  1. Valide los controles del ciclo de vida del proveedor sin reclamar objetivos.
  2. Coordinar el retiro de acceso y cualquier decisión urgente de revocación.
  3. Evite afirmar que las claves almacenadas en caché desaparecen inmediatamente.

Fundador / No técnico

Finalizar la baja de proveedores en todos los equipos

El cierre del contrato no detiene automáticamente los flujos de trabajo ni elimina los registros DNS .

Próximos pasos

  1. Confirme qué aplicaciones aún dependen del proveedor.
  2. Aprobar la migración y un plazo de jubilación justificado.
  3. Requerir el cierre del propietario de DNS , tareas de configuración y acceso.

[ Preguntas frecuentes ]

Preguntas frecuentes

¿Eliminar una cuenta de proveedor elimina sus CNAME DKIM ?

No lo asumas. La publicación DNS del cliente y la configuración de la cuenta del proveedor son responsabilidades separadas; verificar ambos lados de la relación de baja.

RFC6376

¿Es seguro eliminar un selector ausente del correo reciente?

No necesariamente. Selectores activos y en espera de rotación de documentos Microsoft 365 . Verifique el modelo admitido del proveedor real y otros flujos de trabajo antes de retirarlo.

Microsoft: configurar DKIM para dominios personalizados

¿Un CNAME en sí mismo permite que alguien firme el correo?

No. La firma requiere una clave privada. El alias dirige el descubrimiento de la clave pública, por lo que el control de su objetivo sigue siendo una dependencia que debe evaluarse por separado.

RFC6376

¿Un objetivo perdido demuestra un servicio DKIM recuperable?

No. Una clave u objetivo faltante no establece una reasignación de proveedor o un comportamiento de validación de propiedad. Mantenga esa incertidumbre y busque evidencia de proveedores autorizados.

Microsoft: Evite las entradas DNS pendientes y evite la adquisición de subdominios

¿Cuánto tiempo debe permanecer publicada la clave antigua?

No existe un intervalo universal en esta guía. Base la decisión en los mensajes reales en cola y ya firmados, el comportamiento del servicio y la decisión de riesgo del propietario de la seguridad.

RFC6376

¿Debe una clave comprometida permanecer disponible para mensajes retrasados?

No. Un incidente de seguridad puede justificar una revocación más rápida a pesar de la interrupción de la entrega. El propietario del valor responsable debe decidir y coordinar esa respuesta.

RFC6376

¿Eliminar el CNAME lo revoca en todas partes al instante?

No. Los solucionadores recursivos pueden conservar alias almacenados en caché o datos clave. Verifique la eliminación autorizada y registre las observaciones del caché sin prometer una desaparición global inmediata.

RFC1034

¿Qué prueba que la ruta de reemplazo está lista?

Conserve un mensaje recibido controlado con la identidad de firma deseada y una ruta de paso alineada con el De visible. Un guardado DNS o una insignia de proveedor por sí solos no son suficientes.

RFC9989

[ Fuentes ]

Fuentes

  1. RFC1034

    Secciones §3.6 Alias ​​y nombres canónicos · §4.2 Cómo se divide la base de datos en zonas · §4.3.4 Almacenamiento en caché de respuesta negativa

  2. RFC2308

    Secciones §2. Respuestas Negativas · §5. Almacenamiento en caché de respuestas negativas

  3. RFC9989

    Secciones Alineación de identificadores · Descubrimiento de políticas DMARC

  4. RFC6376

    Secciones §3.5 Campo de encabezado DKIM-Signature · §3.6 Gestión y representación de claves · §5. Acciones del firmante · §6. Acciones del verificador

  5. Microsoft: Evite las entradas DNS pendientes y evite la adquisición de subdominios

    Secciones ¿Qué es la adquisición de subdominios? · Prevenir entradas DNS colgantes · Remediar entradas DNS colgantes

  6. Microsoft: configurar DKIM para dominios personalizados

    Secciones Sintaxis para registros DKIM CNAME · Rotar claves DKIM · Configuración de firma DKIM para dominios personalizados

[ Glosario ]

Glosario

Selector
El valor de firma DKIM utilizado con el dominio de firma para localizar la clave pública aplicable.

RFC6376

Selector de espera
Un selector retenido para la futura rotación de claves admitida por un proveedor en lugar de la firma actual.

Microsoft: configurar DKIM para dominios personalizados

Plazo de jubilación
El punto aprobado para eliminar una búsqueda obsoleta después de revisar las dependencias de los mensajes y los riesgos de seguridad.

RFC6376

Dependencia del descubrimiento de claves
La relación de búsqueda DNS a través de la cual un receptor obtiene la clave pública para una firma DKIM .

RFC6376

Procedencia de la empresa

Por qué las principales instituciones financieras y gobiernos retiraron sus paneles de seguridad de correo electrónico.

Las plataformas tradicionales de autenticación de correo electrónico le venden un panel y piden a sus ingenieros que hagan el trabajo. En entornos de alto riesgo, la supervisión manual significa retrasos en la aplicación, cambios en la configuración y dominios en la sombra no monitoreados.

EmailAuth es la plataforma de procedencia de correo electrónico agente. Nuestros agentes hacen cumplir p=reject, mantenga alineados a los remitentes externos y mueva sus dominios al máximo RFC 9989 cumplimiento, el nuevo estándar DMARC , con auditabilidad humana.

Gobiernos Grandes empresas Instituciones financieras de primer nivel

SaaS · Arrendamiento dedicado · Air-gapped on-premise · Cifrado BYOK

Base de conocimientos