Restringir las instrucciones a la firma de SpamTitan Gateway
TitanHQ publica una configuración específica DKIM en el procedimiento SpamTitan Gateway. Este artículo sigue ese límite de producto. No se asume que SpamTitan Cloud, Skellig, una implementación solo entrante o cada edición de servicio administrado exponga los mismos controles. Confirme la versión instalada, las capacidades con licencia y la ruta de salida real antes de aprobar un cambio de firma. Un dominio listado para recibir correo no es, por sí solo, evidencia de que los mensajes salientes atraviesen la puerta de enlace o reciban una firma de dominio del cliente.
El Procedimiento de puerta de enlace contiene los pasos de firma DKIM y una discusión separada sobre el registro de políticas de DomainKeys heredadas. Esa combinación es un límite de implementación importante. El flujo de trabajo moderno de claves de firma se puede explicar desde la fuente, pero el paso de la política heredada requiere la confirmación del producto actual. No convierta silenciosamente la antigua terminología de DomainKeys en una DMARC Requisito o afirmación de que la publicación de una política o= establece una protección de dominio moderna.
Identificar la retransmisión del dominio y la propiedad de la clave.
La navegación documentada es Configuración del sistema, Retransmisión de correo, DKIM . La página enumera retransmisiones de dominio. Edite el dominio deseado y abra la pestaña CLAVE DE DOMINIO. El procedimiento solicita una selector nombre que distingue esta clave de otras claves de dominio. Elija una etiqueta a través del proceso de denominación aprobado por la organización y verifique el uso existente antes de publicarla. Una etiqueta predecible no es un secreto, pero reutilizar un selector ocupado puede sobrescribir una dependencia que otro remitente todavía necesita.
La fuente describe la generación de un nuevo par de claves y también ofrece un campo de clave privada existente. Esta guía no solicita, recopila ni recomienda copiar una clave privada en un ticket o documento compartido. La generación o importación de claves es una acción administrativa autorizada separada. La guía enumera 1024 bits y 2048 bits opciones y recomienda la opción más larga. Confirmar la configuración admitida y los requisitos criptográficos actuales para el producto implementado; no baje la versión simplemente porque un editor DNS muestra un valor público largo de manera inconveniente.
Publicar la clave pública generada sin copiar el ejemplo
Después de Generar, la fuente dirige al administrador a la pestaña OPCIONES y al material DNS TXT . Publique la clave pública real en el nombre formado a partir del selector seleccionado, _domainkey y el dominio de firma. La gran clave pública impresa en la documentación es una ilustración, no un registro reutilizable. Registre el propietario elegido y una referencia controlada al valor público emitido en la solicitud de cambio. Ningún material privado pertenece al DNS público.
TitanHQ analiza la eliminación de formatos superfluos de la pantalla copiada. Interprete esto como un manejo de la presentación del editor, no como una edición arbitraria de bytes clave. RFC 6376 , sección 3.6.2.2 especifica registros de recursos TXT para el almacenamiento de claves. Una herramienta DNS puede mostrar varias cadenas entre comillas dentro de una sola registro TXT; eso es diferente de múltiples registros en competencia o comillas literales insertadas en el valor. Haga que el administrador DNS verifique el registro lógico real y el nombre completo del propietario en lugar de aceptar una captura de pantalla de un cuadro de entrada como evidencia final.
Mantenga la política heredada y el modo de prueba separados de DMARC
El procedimiento del proveedor también describe un registro TXT en _domainkey seguido del dominio, con valores o=- u o=~ , en Registros de políticas. Llama explícitamente a esta política DomainKeys. Esta no es la ubicación de la política DMARC y no reemplaza una clave pública del selector DKIM . Debido a que el procedimiento combina estos elementos históricos, confirme si ese paso de política es aplicable a la versión actual exacta de Gateway antes de agregarlo. Preservar la pregunta no resuelta en el registro de publicación en lugar de inventar un requisito moderno.
La guía describe por separado un indicador de prueba DKIM , t=y, en el registro clave. No confunda eso con una instrucción para poner una implementación DMARC en modo de prueba o con una prueba de que los destinatarios aceptarán todo el correo. DKIM , DMARC y el manejo del receptor local tienen una semántica distinta. RFC 9989 , sección 4.4 explica el alineación requerido entre una identidad de autenticación de paso y el dominio del autor. Una declaración de política heredada de que el correo está firmado no establece que una firma en particular se valide o alinee.
Verificar antes de habilitar y planificar la rotación deliberadamente
El flujo de trabajo de OPCIONES de TitanHQ utiliza Verificar para recuperar el registro TXT DNS y compararlo con la información configurada de la puerta de enlace. Una vez que la verificación se realiza correctamente, Habilitar activa la firma DKIM para el dominio. Trátelos como puntos de control separados. Una clave publicada no prueba que la firma esté habilitada, mientras que una opción de firma seleccionada no puede validar un registro público faltante o que no coincida. Preservar el resultado de la verificación y su tiempo sin describirlo como una prueba de aceptación del receptor.
La documentación recomienda la rotación periódica de claves. Un plan de rotación práctico necesita más que un intervalo de calendario: identificar selectores activos, claves generadas, mensajes en cola, almacenamiento en caché DNS , operadores autorizados y condiciones de reversión. No elimine el registro público anterior simplemente porque se generó una clave de reemplazo. Determine qué superposición necesita la ruta de correo real y conserve la evidencia que respalda esa decisión. Este manuscrito no ha medido la duración de las colas ni ha probado el comportamiento de transición del producto instalado, por lo que esos detalles de implementación permanecen abiertos.
Verifique el mensaje saliente final en lugar de la etiqueta de filtrado
Un ejercicio de aceptación autorizado por separado debería distinguir entre tránsito de pasarela, firma, validación y alineación. Revise los campos d= y s= de la firma, el dominio de autor visible y los resultados de autenticación del receptor confiable. RFC 6376 , sección 3.5 define los campos de firma. Verifique las clases de mensajes que pueden tomar diferentes rutas, como el correo ordinario del buzón, las notificaciones de aplicaciones y el tráfico reenviado. El hecho de que SpamTitan haya escaneado un mensaje entrante no dice nada concluyente sobre cómo se firmó un mensaje de aplicación saliente.
SPF es una revisión separada. RFC 7208 , secciones 2.4 y 4.6.4 describir su CORREO DE Límites de evaluación dependientes de identidad y DNS. Esta fuente no proporciona una inclusión de SPF saliente universal para cada implementación de SpamTitan, por lo que no se inventa nada aquí. Obtenga la infraestructura de envío autorizada real y revise una política completa para esa identidad. El éxito de la autenticación sigue siendo distinto de la ubicación en la bandeja de entrada, la seguridad del contenido o la aprobación del destinatario de una solicitud de pago.
Diagnóstico ficticio y hoja de trabajo de aceptación en blanco.
Una empresa de ingeniería ficticia, Alder Instruments, publica una nueva clave de selección pero deja la firma deshabilitada mientras espera una ventana de mantenimiento. Su lista de verificación interna marca que DKIM está completo porque Verify tuvo éxito. Una revisión posterior encuentra que la lista de verificación combinaba el acuerdo DNS con la firma activa. La corrección propuesta es separar la aprobación para habilitar, el estado de configuración observado y la evidencia futura del receptor. No es para publicar la clave de ejemplo de la documentación ni agregar un registro de política heredado como sustituto. No hay ningún sistema, mensaje o búsqueda DNS real detrás de este escenario.
- Producto de puerta de enlace, versión, ruta de salida y retransmisión de dominio: ______
- Propiedad del selector y dependencias existentes: ______
- Referencia de valor/propietario público generado y cambio DNS aprobado: ______
- Decisión de custodia de clave privada, sin material secreto: ______
- Decisión de aplicabilidad de la política Legacy DomainKeys: ______
- Verificar resultado y posterior Habilitar aprobación/estado: ______
- Superposición de rotación, retroceso y retención del selector anterior: ______
- Firma confiable del mensaje recibido y evidencia de alineación: ______
- Excepciones restantes, revisor y propietario de la versión: ______
La evidencia de implementación original, la aplicabilidad de las fuentes actuales, la revisión humana del tema, la aceptación de la ruta de producción, la accesibilidad visual y la autorización del propietario permanecen abiertas. No se generó ninguna clave, no se cambió la configuración, no se publicó ningún registro DNS ni se envió ningún mensaje. El requisito de implementación más amplio del catálogo no puede considerarse completo únicamente a partir de este flujo de trabajo documental.