Confirmar que TransIP tiene autoridad
Esta es una guía de publicación DNS , no una guía de incorporación del servicio de correo TransIP. Se puede registrar un dominio en TransIP mientras su autoridad servidores de nombres están en otra parte. Verifique la delegación pública del dominio e identifique la zona autorizada antes de editar. No cambie de servidor de nombres sólo para hacer accesible un formulario DNS . Obtenga los nombres, tipos y valores exactos de los registros del remitente, junto con la exportación de zona existente y un alcance de cambio aprobado.
Ingrese nombres y valores correctamente
Seleccione el dominio en el panel de control y abra la configuración DNS . La edición personalizada requiere que la configuración automática de TransIP esté desactivada. Volver a habilitar esas configuraciones puede sobrescribir registros personalizados y servidores de nombres. El campo Nombre utiliza @ para el vértice de la zona y nombres relativos para los subdominios. Un externo CNAME El objetivo necesita su nombre completo y un punto final. Estas reglas de interfaz están documentadas en la fuente del panel de control de TransIP a continuación.
Para un TXT DKIM clave, la fuente DKIM indica a los usuarios que omitan las comillas circundantes y las barras invertidas innecesarias. Utilice la clave pública del remitente, nunca una muestra generada. A selector en un subdominio de envío necesita ese subdominio en el nombre del propietario relativo. Utilice CNAME solo cuando el remitente realmente haya emitido una delegación CNAME . La publicación de una clave no hace que el servicio de envío comience a firmar.
Hoja de trabajo original de mapeo de registros
El siguiente es un ejercicio de mapeo ficticio para la zona example.org , no una configuración de producción. Una review._domainkey.news.example.org completa del propietario DKIM mapas para revisar. _domainkey.news en el campo Nombre. A DMARC el propietario _dmarc.news.example.org se asigna a _dmarc.news. El SPF propietario news.example.org se asigna a noticias. Marque el nombre completo esperado en el ticket de cambio para que un revisor pueda detectar un sufijo accidental example.org.example.org .
Mantenga SPF y DMARC como políticas TXT con sus nombres de propietario correctos. No coloque una línea completa del archivo de zona, incluida la clase y el tipo, en el campo Valor. Múltiple Registros TXT pueden coexistir para fines no relacionados, pero dos políticas SPF en un nombre evaluado no son válidas. Los valores DKIM largos requieren un manejo cuidadoso: las páginas TransIP recuperadas no establecen un procedimiento universal de división de cadenas largas. Si el panel rechaza el valor total del proveedor, deténgase y obtenga la guía TransIP actual en lugar de truncarla.
Verificar la publicación antes de probar el correo.
Consulte en cada servidor autorizado los nombres completos SPF , DMARC y selector. Compare los valores completos, incluidas las cadenas TXT concatenadas donde se devuelven. Para una clave delegada, verifique el destino CNAME y la respuesta TXT final. Repita a través de un solucionador recursivo y conserve las observaciones TTL. Una visualización correcta en el panel de control con una respuesta pública ausente puede indicar una autoridad incorrecta o datos no guardados, no simplemente una propagación lenta.
Solo entonces activa un mensaje controlado a través del servicio de envío. La reversión del lado DNS debería restaurar los registros modificados, no volver a habilitar la configuración automática ni restaurar una zona antigua completa sin comparar cambios no relacionados.
Demostrar la identidad en el receptor.
Utilice un buzón externo controlado y envíe a través del flujo de trabajo de producción, con contenido inofensivo y sin datos de clientes. Guarde el mensaje sin formato, la marca de tiempo y el sistema receptor. Authentication-Results. Ignore las afirmaciones de autenticación insertadas por un remitente que no es de confianza. Registre el dominio visible Desde, Return-Path o identidad del sobre autenticado, y cada par DKIM d= y s=. Un nombre para mostrar o una dirección de respuesta no es la identidad DMARC .
El pase SPF autoriza al servidor de conexión para la identidad del sobre evaluado. El pase DKIM valida una firma para su dominio de firma. DMARC necesita un método de paso cuyo dominio se alinee con lo visible De: estricto alineación requiere el mismo dominio; la alineación relajada permite la relación aplicable entre el dominio y la organización. Una firma propiedad del proveedor puede pasar sin autenticar su De visible. Uno pasando alineado firma DKIM puede satisfacer DMARC incluso cuando falla otra firma. Estas reglas de protocolo provienen de RFC 7208 , RFC 6376 y RFC 9989, que se enumeran a continuación.
Verifique DNS autorizado antes de diagnosticar los cachés. Solicite a un servidor autorizado el nombre y tipo exactos, luego compare un solucionador recursivo después de su vida útil en caché. Para DKIM , siga cualquier CNAME hasta su respuesta TXT de clave pública. Nunca publique una clave privada. Mantenga una política SPF en cada nombre evaluado y verifique el límite de diez términos que causan búsquedas de DNS en inclusiones anidadas. No reemplace una política SPF compartida con un ejemplo de proveedor.
Recuperación y aceptación
Pause el flujo de trabajo afectado si las pruebas muestran una nueva regresión. Compare el registro modificado con la versión guardada y deshaga solo ese cambio después de verificar otros remitentes. Vuelva a verificar DNS y reenvíe después de la recuperación; revertir un valor no elimina todos los solucionadores inmediatamente. Mantenga disponibles los registros de verificación DKIM antiguos mientras los mensajes firmados previamente aún puedan estar en tránsito, a menos que un incidente de seguridad requiera su revocación.
Acepte el cambio solo cuando coincidan DNS , el estado de la aplicación y un mensaje recibido real. Registre el propietario del flujo, la marca de tiempo de la evidencia y el activador de la próxima revisión. La ubicación de la bandeja de entrada por sí sola no es prueba de autenticación y la autenticación exitosa no garantiza la ubicación de la bandeja de entrada. No ajuste la política DMARC de un dominio compartido basándose en la prueba de un proveedor. Primero haga un inventario de las otras fuentes legítimas.
Diagnosticar una entrada que parece correcta en la zona incorrecta
El caso escrito TI-01 supone que el dominio está registrado en TransIP, pero su delegación pública apunta a otro operador DNS . Una entrada guardada del panel TransIP para su revisión. _domainkey.news no establece publicación en review._domainkey.news.example.org . El propietario del dominio debe confirmar el operador autorizado y disponer allí el registro aprobado; cambiar los servidores de nombres o habilitar la configuración automática no es el atajo correctivo. Las respuestas públicas, d=/s= emitidos y los resultados del receptor permanecen desconocidos hasta que se recopilan por separado. Este escenario está estipulado, no es una búsqueda DNS real ni una acción del panel.
Preservar el límite de aplicación
RFC 9989 Sección 7.4 requiere DKIM válido, no solo SPF , para dominios que publican p=reject, y advierte sobre la interoperabilidad del correo indirecto y de las listas de correo. Una sola prueba exitosa de mensajes directos no es prueba de que todas las rutas legítimas estén listas para una política más fuerte. Mantener la protección aprobada existente mientras se diagnostica la brecha real; cualquier cambio de política necesita su propia decisión.