Establecer qué servicio DNS controla el cambio
La publicación de un registro de autenticación es un cambio en la configuración de confianza de un dominio. Comience identificando el servicio autorizado delegado, el equipo correcto de DigitalOcean y la zona exacta que contiene el nombre del propietario previsto. Un sitio web que se ejecuta en un Droplet no establece dónde está alojado DNS de su dominio. Una cuenta que muestra un dominio tampoco prueba que la delegación pública apunte allí.
Límites DNS de DigitalOcean distinguir su alojamiento DNS del registro de dominio. También documentan un TTL de registro mínimo de treinta segundos y afirman que sus servidores de nombres no admiten dominios habilitados para DNSSEC. Trate una delegación firmada existente como una decisión de compatibilidad para el propietario del dominio, no como una invitación para desactivar la protección durante un ejercicio de configuración de correo electrónico. Esta guía asume una zona alojada en DigitalOcean compatible y ya aprobada; no migra delegación ni altera DNSSEC.
Defina el cambio deseado antes de abrir el editor. Para cada registro propuesto, identifique el servicio de envío que lo proporcionó, el flujo de negocios que respalda, el propietario esperado y el tipo de registro, y el aprobador. Mantenga los registros web, de correo entrante y de verificación no relacionados fuera del cambio, a menos que una dependencia específica requiera revisión.
Preservar un punto de partida utilizable
El proveedor documenta una opción de descarga de zona en Redes, Dominios y el menú Más del dominio. Es instrucciones de exportación de zona describir un archivo de texto plano que contiene los registros de la zona. Utilice una exportación autorizada como insumo para un plan de recuperación, acompañada de la diferencia propuesta, la propiedad del registro y los criterios de restauración aprobados. Una exportación no es prueba de que exista un botón de restauración o de que se pueda recuperar un estado anterior sin afectar los cambios posteriores.
En la hoja de evidencia propuesta, proporcione al nombre del propietario previsto su propia columna. El tipo de registro y el valor pertenecen a columnas separadas. Esto evita un error de revisión común: una política que de otro modo sería correcta se adjunta al nombre DNS incorrecto porque el propietario completo, la etiqueta relativa y el valor de texto se trataron como cadenas intercambiables.
Utilice el modelo de editor documentado
La corriente guía de gestión de registros enruta a los operadores a través de Redes, Dominios y el dominio seleccionado, luego Crear un récord. Para TXT , el campo Nombre de host acepta el marcador de vértice @ o un prefijo de subdominio, mientras que Valor TXT contiene el texto. Describe SPF y directo DKIM publicación de claves a través de TXT y admite registros NS para delegación de subdominios.
Traducir deliberadamente un propietario totalmente calificado solicitado al modelo de entrada de esa zona. Para una zona ficticia example.com , el relativo DMARC la etiqueta _dmarc representa _dmarc.example.com . Esta es una explicación de la construcción del nombre, no un valor de póliza propuesto ni una afirmación de que se guardó algún registro. El propietario público esperado debe comprobarse independientemente de cómo lo muestre el formulario.
Utilice el material actual y específico de la cuenta del servicio de envío para una Selector DKIM, clave pública o destino delegado. Un host DNS no elige la identidad de firma del remitente. Si el servicio requiere un CNAME en lugar de una clave TXT directa, conserve esa distinción e inspeccione al propietario exacto en busca de dependencias existentes antes de aprobar el reemplazo. Nunca infieras un objetivo faltante a partir de la captura de pantalla de configuración de otro cliente.
Mantenga los registros de autenticación lógicamente separados
RFC 7208 secciones 3.2 y 3.3 distinguir múltiples candidatos Registros SPF de múltiples cadenas dentro de un registro. No agregue una segunda póliza SPF competidora para un nuevo servicio. Las comillas o la división de cadenas en una visualización no indican, por sí solas, si se evaluarán uno o varios registros. Inspeccione los límites del registro devuelto y el valor concatenado resultante.
Para DKIM , RFC 6376 sección 3.1 vincula la búsqueda de claves con el selector y el dominio de firma. La publicación por sí sola no puede demostrar que la aplicación seleccionó esa clave o firmó el mensaje deseado. La configuración del remitente y el material DNS público deben hacer referencia a la misma identidad planificada.
DMARC pertenece al propietario _dmarc correspondiente, no a donde resida el registro SPF . RFC 9989 secciones 4.1 y 4.4 describir la política y alineación relación. Un resultado de solo DNS no es evidencia de un correo alineado exitosamente y un mecanismo de autenticación de paso para un dominio no relacionado no es suficiente.
Verificar la publicación y el uso real como resultados diferentes
Un plan de verificación autorizado debe capturar respuestas autorizadas antes y después de la edición aprobada, incluido el servidor, la marca de tiempo, el propietario, el tipo, el TTL y el conjunto de registros completo. Mantenga una respuesta ausente distinguible de un tiempo de espera o una consulta enviada al servidor equivocado. Al comparar solo una captura de pantalla del panel con otra captura de pantalla del panel se omite el paso de publicación pública.
A continuación, obtenga un mensaje controlado a través del flujo de aplicación real y conserve los resultados del receptor confiable. Compare su dominio visible, identidad del sobre, dominio de firma DKIM y selector con la configuración aprobada. Registre la autenticación y la alineación por separado de la entrega o la ubicación de la carpeta. Una búsqueda DNS exitosa no debería llenar una celda de prueba de mensaje vacía.
Si el propietario o el valor observado difiere del plan, pausar cambios adicionales e identificar la acción de recuperación aprobada más pequeña. Un caché puede preservar una respuesta anterior, por lo que una observación de recuperación necesita tiempo y contexto en lugar de una promesa de coherencia global inmediata. Mantenga el registro de incidentes lo suficientemente específico como para distinguir un error de entrada de datos obsoletos o una configuración de envío inactiva.
Reseña ficticia y evidencia destacada.
Un revisor ficticio recibe un borrador que contiene un valor DMARC que parece válido en la cúspide de example.com . El revisor detecta que el propietario no coincide antes del envío y cambia el propietario propuesto a _dmarc . La hoja de trabajo aún no contiene respuestas autorizadas antes/después ni ningún mensaje recibido. Es una revisión en papel, no un recorrido exitoso por DigitalOcean.
El requisito original exacto permanece abierto: un tutorial de publicación actual de DigitalOcean con consultas autorizadas antes y después y un mensaje verificado de forma independiente. La puerta de puesta en servicio es: Confirmar la identidad actual del producto y la documentación propiedad del proveedor; probar un mensaje real o registros publicados. Indique honestamente las características de dominio personalizado no admitidas. La documentación respalda este flujo de trabajo propuesto, pero la aplicabilidad del inquilino, las pruebas originales, la revisión técnica de las PYME, la verificación visual en vivo y la aprobación de la publicación del propietario siguen sin resolverse. No se ha realizado ninguna operación de cuenta o DNS .