Confirmar que Dynadot tiene autoridad
Un dominio registrado en Dynadot puede utilizar DNS de otra empresa. Empiece por comprobar el delegado servidores de nombres e identificar la cuenta que controla la zona autorizada. Si el dominio utiliza servidores de nombres externos, publíquelo allí. Cambiar los servidores de nombres de los registradores simplemente para usar el editor Dynadot es una migración DNS , no una edición ordinaria de registros de autenticación.
Recopile el tipo de registro exacto de la plataforma de envío, el nombre completo del propietario y el valor, además de la configuración de zona existente. Esta guía explica la publicación, no qué remitente debe estar autorizado. El administrador de correo debe suministrar y aprobar la SPF política, DKIM grabar o DMARC política antes de que el operador DNS la guarde.
Traducir propietarios a los campos del editor.
Dynadot documenta Mis dominios > Administrar dominios, selección del dominio, Acción > Configuración DNS y la opción DNS de Dynadot. Para datos TXT de Apex, utilice Registro de dominio con TXT y coloque el valor en Dirección IP/Destino. Indica a los usuarios que omitan las comillas circundantes. instrucciones TXT
Sus reglas de nombre de propietario son importantes: una instrucción @ significa la sección Registro de dominio, no una etiqueta @ literal. Un propietario que no pertenece a Apex pertenece al registro de subdominio y a un nombre completo proporcionado se le debe eliminar el sufijo de zona antes de ingresar el prefijo. Por ejemplo, el propietario ilustrativo _dmarc.example.com en la zona example.com se convierte en _dmarc . Un propietario DKIM como selector1._domainkey.example.com se convierte en selector1. _domainkey . Estos son ejemplos de sintaxis, no valores de cuenta reales.
Guarde con Guardar configuración y luego verifique el propietario publicado completo. No asuma que un envío exitoso del formulario significa que el nombre DNS es correcto. Ingresar todo el dominio donde solo se espera un prefijo puede generar un sufijo duplicado y dejar vacío el propietario requerido.
Preservar la configuración raíz requerida
La guía TXT de Dynadot dice que su configuración DNS también requiere una raíz A, AAAA, CNAME o entrada de reenvío. Esta es una restricción del editor del proveedor, no una regla DNS general. Preservar la configuración raíz real y aprobada del dominio. No invente una dirección de marcador de posición ni cambie el sitio web solo para cumplir con el formulario. Si un diseño solo para correo no tiene una entrada raíz adecuada, solicite a Dynadot una configuración compatible antes de guardarlo.
Para un DKIM CNAME , utilice el área Registro de subdominio con el archivo suministrado selector etiqueta, tipo CNAME y destino. Dynadot Tutorial CNAME utiliza un ejemplo de sitio web; sustituya el selector de correo real en lugar de copiar www o el destino de reenvío de muestra. Evite un CNAME a un propietario que ya tenga otro servicio activo.
Verificar el registro que consultarán los receptores
Método de verificación original: conserve respuestas autorizadas antes y después para cada propietario y tipo exacto. Para SPF , verifique el dominio de sobre aplicable y asegúrese de que solo exista una política SPF candidata. Para DKIM , consulte el selector proporcionado por la plataforma de envío y siga su CNAME si está presente. Para DMARC , consulte al propietario _dmarc previsto y compare la política con el cambio aprobado.
Utilice el control de verificación de la plataforma de envío a continuación y luego envíe un mensaje inofensivo a través de la ruta prevista. Registre los resultados de la autenticación del receptor y compare el dominio SPF o DKIM que pasa con el dominio De visible. Publicación DNS , verificación de proveedor y mensaje. alineación son observaciones diferentes; conservar los tres en lugar de tratar cualquier indicador verde como concluyente.
Recuperar el registro exacto
Error ilustrativo: _dmarc.example.com se escribió en un campo de solo prefijo, lo que generó un sufijo duplicado. Corregir al propietario después de comprobar lo que realmente se publicó; No cree varias políticas DMARC en el propietario previsto como solución alternativa. Preservar no relacionado Registros TXT como tokens de verificación de servicio.
En caso de falla, restaure el registro afectado a su estado anterior aprobado y permita el almacenamiento en caché. Vuelva a verificar después de una migración del servidor de nombres o una limpieza de registros. La documentación se revisó el 8 de noviembre de 2026. Aquí no se probó ninguna cuenta Dynadot, cambio DNS en vivo ni mensaje entregado.
Prepare una tarjeta de traducción del nombre del propietario
Para cada registro, conserve la instrucción del servicio de envío, el propietario completo DNS previsto, el sufijo de zona, el campo del editor, la etiqueta ingresada, el tipo de registro y el resultado autorizado. Por ejemplo, _dmarc.example.com en la zona example.com se asigna a la etiqueta del subdominio _dmarc ; el ápice se asigna al registro de dominio. Compare el propietario completo reconstruido antes de guardar. Si la interfaz actual difiere del modelo documentado, deténgase y confirme la semántica del campo en lugar de adivinar.