Alcance y requisitos previos
Identifique el canal saliente activo del Creador antes de cambiar DNS . El superadministrador gestiona los canales; La autenticación de dominio requiere un plan pago.
Configurar la ruta documentada
- Paso 1. Para la entrega integrada, verifique la dirección del remitente. Abra operaciones, administración de correo electrónico, canales de correo electrónico salientes y administre dominios en el correo electrónico integrado.
- Paso 2. Valida el dominio, copia su SPF y DKIM instrucciones, publicar los registros y validar nuevamente. La finalización requiere el estado de autenticación completado y el estado activo.
- Paso 3. Antes de cambiar a ZeptoMail, verifique los dominios allí por separado y pruebe cada remitente requerido.
- Paso 4. Sólo un canal está activo. La eliminación de una configuración de canal externo activa y eliminable activa la entrega integrada. El correo electrónico integrado y ZeptoMail no se pueden eliminar; En su lugar, ZeptoMail debe disociarse. Verifique la operación de recuperación aplicable y el respaldo antes de cambiar algo.
Riesgos específicos del producto
La autenticación debe seguir el canal de entrega, no solo el nombre de la aplicación. Cree un inventario de prueba de notificaciones de flujo de trabajo, mensajes programados y acciones activadas por el usuario, con el remitente elegido por cada uno. Si una acción se realiza correctamente en Creator pero no llega ningún correo, separe la ejecución de la aplicación de la aceptación SMTP y la entrega al destinatario. Las migraciones de canales también cambian las dependencias operativas, como las credenciales y las cuotas; dar a su propietario una decisión clara de reversión sin registrar secretos en el ticket de evidencia.
Probar la ruta en el extremo receptor.
Utilice un buzón de correo externo aprobado y guarde el mensaje sin procesar completo con su marca de tiempo y su identificador de mensaje. En esta guía no se afirma ninguna prueba de inquilino vivo. La siguiente es una hoja de trabajo de aceptación para completar durante la implementación, no un récord de los resultados observados.
- Campo de evidencia: Visible desde; Qué registrar: dirección y dominio reales; Pregunta de aceptación: ¿Es esta la identidad del remitente previsto?
- Campo de evidencia: Sobre; Qué grabar: Return-Path y dominio SPF informado por el receptor; Pregunta de aceptación: ¿Qué dominio autenticó realmente SPF ?
- Campo de evidencia: SPF ; Qué registrar: resultado del receptor confiable e identidad evaluada; Pregunta de aceptación: ¿Pasó y se alinea esa identidad?
- Campo de evidencia: DKIM ; Qué registrar: Cada d= dominio, s= selector y resultado del receptor; Pregunta de aceptación: ¿Se alinea al menos una firma aprobada?
- Campo de evidencia: DMARC; Qué registrar: resultado del receptor y política aplicable; Pregunta de aceptación: ¿Existe un camino de paso alineado?
- Campo de evidencia: Ruta; Qué registrar: Producto, cuenta y tipo de mensaje; Pregunta de aceptación: ¿La prueba utilizó la ruta de producción?
DMARC necesita al menos una ruta alineada que pase SPF o DKIM . No basta con pasar la firma de un dominio de servicio no relacionado. Estricto alineación requiere igualdad de dominio exacta; La alineación relajada utiliza la relación de dominio organizacional aplicable. Verifique la configuración de alineación real del dominio antes de declarar el éxito. Un subdominio no es una coincidencia estricta automática. SPF utiliza la identidad SMTP , no el nombre para mostrar o Responder a. Consulta el glosario de alineación al registrar la decisión.
Usar Authentication-Results del sistema receptor en el que confía, no de un encabezado proporcionado por un remitente arbitrario. Capture todas las firmas en lugar de detenerse ante el primer error. Para el correo reenviado, compare una prueba directa con una copia reenviada: el reenvío puede cambiar la evaluación SPF o alterar el contenido firmado. No diagnostique esos efectos agregando la dirección del transportista a su autorización de proveedor.
Diagnosticar fallos sin ampliar el acceso
Primero compare DNS autorizado con los nombres exactos de los registros configurados y luego verifique la visibilidad recursiva y la validación del servicio. Un nombre incorrecto, clave truncada o conflictiva CNAME no se soluciona esperando cachés. Mantenga solo una política SPF por propietario y verifique el límite de diez términos de búsqueda de DNS en las inclusiones y redirecciones evaluadas antes de fusionar otro remitente. Los selectores DKIM pertenecen a configuraciones de firma individuales; no sobrescriba el registro de otra aplicación para forzar un resultado de validación.
Si la autenticación se realiza pero la entrega es deficiente, inspeccione la respuesta del destinatario, la reputación, el contenido y los permisos de envío por separado. El pase DMARC no promete aceptación ni ubicación en la bandeja de entrada. Si ninguna ruta se alinea, detenga la expansión y corrija la configuración real del remitente. No debilite la política DMARC de todo el dominio para ocultar una sola falla del producto.
Entrega y recuperación
Guarde la diferencia DNS aprobada, los resultados de la búsqueda pública, el estado del servicio y la hoja de trabajo de mensajes recibidos redactados con un propietario designado. Mantenga las credenciales y claves privadas fuera de los tickets. En caso de error, suspenda el trabajo de envío afectado o utilice una ruta previamente probada bajo el control del propietario del servicio. Restaurar sólo los registros modificados que pertenecen a esta integración; mantener las claves públicas necesarias para los mensajes en vuelo. Vuelva a realizar la prueba después de una reversión, rotación de claves, migración de dominio o un cambio en la retransmisión saliente. Cierre el cambio solo cuando el propietario del producto y el administrador de correo puedan explicar la cadena de identidad observada.
Confirmar el límite del proveedor
La página actual también documenta Microsoft 365 , Outlook personal, Gmail y canales SMTP personalizados. Este artículo cubre la autenticación integrada y la aceptación de cambios de canal, no el aprovisionamiento completo de credenciales para esos servicios. Utilice la configuración de cuenta autorizada actual, los alias de remitente y los controles de seguridad por separado. Crear una configuración no la activa. El estado de verificación integrado completado después de la verificación de la dirección difiere del estado de autenticación completado y el estado activo después de la validación DNS .
Trabajar a través de un caso de diagnóstico ficticio.
Solo caso escrito ficticio: CR-01 supone que la eliminación de una configuración de canal SMTP personalizado activa hace que una cuenta paga de Creador use notifications@mailer.zohocreatormail.com en lugar de alerts@shop.example . Se desconocen los resultados de la autenticación. El superadministrador debe verificar el respaldo activo, la autenticación de dominio integrada y los flujos de trabajo requeridos antes de reanudarlos. Una muestra de canal externo que pasó anteriormente no puede cerrar la ruta modificada. En este caso no se ejerció ningún inquilino, DNS , comando de servidor o mensaje.
Planificar el respaldo antes de cambiar el canal activo
Las identidades de remitentes integradas y documentadas son notifications@mailer.zohocreatormail.com para usuarios pagos y notifications@trial.zohocreatormail.com para pruebas cuando no hay autenticación personalizada. Los dominios de ZeptoMail deben verificarse nuevamente allí; la integración crea un agente de correo predeterminado del creador y cambia el envío a un sistema basado en créditos. La disociación restaura los límites diarios basados en el plan y elimina el acceso a las funciones de seguimiento, rebote y registro de la integración; se requiere una nueva verificación. Revocar la autorización de un canal activo detiene la entrega hasta que se vuelva a autorizar, mientras que eliminar una configuración de canal externo activa y eliminable activa la entrega integrada. El correo electrónico integrado y ZeptoMail no se pueden eliminar. ZeptoMail utiliza en su lugar la disociación; no trate esa operación como eliminación de canal. Elija explícitamente la acción de recuperación prevista y capture todos los remitentes necesarios antes de cambiar nada.
Separar un mensaje pasajero de la preparación para hacer cumplir la ley
RFC 9989 La sección 7.4 requiere DKIM válido para la publicación de un dominio p=reject y advierte sobre la interoperabilidad del correo indirecto. Un único resultado alineado SPF no justifica por sí solo la implementación de una política de rechazo. Revise todas las rutas legítimas y la propiedad de la política por separado de la configuración de este proveedor.