Confirmar que Gandi aloja la zona activa
Un registro de dominio en Gandi no establece por sí solo que Gandi proporcione servicios a su DNS autorizado. Consulta los delegados servidores de nombres primero para el dominio. Gandi dice que los servidores de nombres alojados externamente deben administrarse a través del proveedor externo. Esta guía cubre el editor Gandi LiveDNS documentado, no una migración desde otro host DNS .
Mantenga la configuración del servicio de correo separada de la publicación DNS . Su proveedor de envío proporciona su soporte selector, clave o CNAME objetivo y cualquier requisito de dominio de sobre. Gandi publica esos registros; creando un DKIM registro TXT no hace que un servidor de correo no relacionado comience a firmar. No infieras un Gandi universal SPF incluir para un dominio simplemente porque su DNS está alojado allí.
Identifique al administrador DNS , al propietario del servicio de envío y a la persona autorizada para aprobar la política de dominio. Guarde los conjuntos de registros existentes para todos los nombres afectados. Compruebe si el dominio está vinculado a una zona compartida: los documentos Gandi que cambian a una zona vinculada afectan a todos los dominios vinculados. Por lo tanto, una edición de autenticación aparentemente local puede tener un impacto más amplio.
Utilice un cambio de editor limitado
La ruta documentada es Dominio, el dominio seleccionado y luego Registros DNS . El modo de tabla admite agregar o editar entradas individuales; El modo texto edita toda la zona. Para un pequeño cambio de autenticación, los registros individuales son más fáciles de comparar con la solicitud aprobada. Utilice el modo texto sólo cuando comprenda al editor y haya revisado toda la diferencia propuesta.
Gandi LiveDNS ofrece guardar una copia de seguridad y restaurar. Realice una copia de seguridad antes del cambio, pero no asuma que restaurarla más tarde es inofensivo: una restauración completa puede revertir ediciones no relacionadas realizadas desde esa instantánea. Registre también un plan de recuperación específico para los registros afectados. Si hay una zona compartida involucrada, incluya a los otros propietarios de dominio en ese plan.
Cree una hoja de trabajo de publicación con el propietario completo, la etiqueta del editor, el tipo y el valor. Para un dominio sintético example.com , el vértice es example.com , su DMARC El propietario es _dmarc.example.com y el propietario DKIM podría ser rotation1._domainkey.example.com . Estas etiquetas de ejemplo no son configuraciones generadas por el proveedor. Utilice el selector y el dominio reales del servicio de envío.
Preservar los límites y nombres TXT
La documentación TXT de Gandi usa @ para el dominio básico y una etiqueta relativa para un subdominio. Sus ejemplos de zona de texto representan datos TXT largos como múltiples cadenas entre comillas dentro de un registro, cada una de no más de 255 caracteres. Esto es distinto de crear múltiples registros TXT independientes.
Esa distinción es importante para la autenticación. Una política SPF puede consistir en varias cadenas de caracteres en un único registro de recursos TXT , pero en varios candidatos. Registros SPF al mismo propietario provoca un error SPF . El material de claves DKIM también debe permanecer completo. No cree varias claves o políticas no relacionadas para superar un límite de campo de texto y no inserte saltos de línea visuales en una clave sin comprender cómo los serializa el editor.
Utilice el tipo de registro TXT para SPF . Utilice TXT o CNAME para DKIM según las instrucciones del proveedor de envío, no según sus preferencias personales. Un CNAME en un selector es un alias de otro nombre de dominio, no un contenedor de texto de clave pública. Si un CNAME solicitado choca con datos existentes en ese nombre, resuelva la colisión en lugar de reemplazar el selector activo de otro servicio.
Publicar la política prevista, no una muestra
Una actualización SPF necesita una revisión de todos los remitentes legítimos y las dependencias de búsqueda de DNS. Conserve las autorizaciones necesarias en una política válida en el dominio del sobre correspondiente. Una actualización DMARC necesita una decisión de política deliberada para el dominio De visible y sus subdominios aplicables. Agregar un proveedor no es motivo para agregar otra política DMARC a un propietario donde ya existe una.
No copie una dirección de informes de muestra ni informes puntuales a un tercero sin aprobación. No reemplace una política DMARC aplicada con monitoreo únicamente porque una captura de pantalla de incorporación muestra p=none. Determine si el nuevo remitente tiene una ruta alineada compatible antes de cambiar la protección de todo el dominio.
Si un proveedor solicita registros debajo de una zona secundaria delegada por separado, publíquelos en la zona que realmente tiene autoridad para ese niño. Una entrada atractiva en el editor principal no anula una delegación. Resuelva el límite de propiedad DNS antes de guardar.
Verificar en dos capas técnicas
Consulte en cada servidor autorizado el propietario completo y el tipo de registro. Conserve las respuestas y compare el contenido lógico TXT , no solo el aspecto de las citas en una herramienta. Verifique toda la clave, la etiqueta del selector, cualquier destino de alias y los límites del conjunto de registros. Solo una vez que las respuestas autorizadas sean correctas, debe investigar las respuestas recursivas almacenadas en caché. La estimación de propagación amplia de un proveedor no sustituye el diagnóstico de un nombre de propietario incorrecto.
Luego active o valide el servicio de envío utilizando su propio flujo de trabajo y envíe un mensaje controlado. Registre el origen visible, la identidad del sobre, cada DKIM d= y s=, y los resultados del receptor confiable. SPF autentica la identidad del sobre; DKIM verifica una identidad de firma. DMARC necesita una ruta de paso alineada con el Desde visible en el modo aplicable.
Caso de error sintético: Gandi publica la clave correcta en rotation1._domainkey.example.com , pero el mensaje usa s=rotation2 y d=example.com. El registro de rotación1 publicado no puede validar esa firma. La solución es conciliar el selector del remitente con su publicación requerida, no debilitar DMARC ni agregar una inclusión SPF no relacionada.
Recuperar y cerrar el cambio.
Si la publicación interrumpe una ruta, identifique exactamente al propietario cambiado y restaure el conjunto de registros anterior aprobado. No restaure una zona compartida completa sin comparar los cambios intermedios y los dominios afectados. Conservar las claves anteriores durante el tiempo que lo requiera el plan de rotación del servicio de firma; Se debe coordinar la eliminación DNS y la activación de la firma.
Cierre el trabajo sólo cuando la zona activa, las respuestas DNS previstas, la activación de envío y la autenticación de mensajes observados coincidan. Esta es una guía documental con un caso de falla sintética. No se utilizó ninguna cuenta de Gandi, ninguna consulta DNS autorizada ni ningún mensaje entregado como prueba real. El administrador debe recopilar esas observaciones antes de aprobar la finalización de la producción.
Evitar que una reversión de zona compartida deshaga trabajos no relacionados
El caso escrito GAN-01 supone que example.com y example.net comparten una zona. Se agregó un registro de sitio web aprobado posteriormente después de una copia de seguridad, mientras que el nuevo selector en example.com es incorrecto. Restaurar toda la copia de seguridad anterior también eliminaría ese cambio en el sitio web en todo el ámbito vinculado. Compare los registros actuales, identifique la reparación aprobada solo para el selector y confirme a ambos propietarios del dominio antes de aplicarla. Aquí no se inspeccionó ni ejecutó ninguna zona, copia de seguridad o restauración.
Preservar el límite de aplicación
RFC 9989 La sección 7.4 requiere DKIM válido, no solo SPF , para la publicación de dominios p=rejecty 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.