Una aplicación que envía a través de Microsoft 365 necesita una ruta de correo compatible, así como una autenticación correcta. El envío SMTP del cliente, la retransmisión SMTP basada en conector y el envío directo utilizan diferentes modelos de confianza y destinatario.
Identificar la ruta antes de cambiar SPF, DKIM o DMARC. DNS puede describir una dependencia de envío, pero no puede convertir una ruta no admitida en una retransmisión autorizada ni hacer que Direct Send se entregue a destinatarios externos.
Registre lo que la aplicación debe hacer
Identifique la ubicación de alojamiento de la aplicación, la identidad del remitente, los destinatarios previstos y las funciones de autenticación y transporte admitidas. Registrar el servicio comercial responsable y el administrador.
Distinga un dispositivo dentro de la organización de una aplicación alojada por terceros. Consulte la guía actual de Microsoft para ese modelo de alojamiento en lugar de asumir que todos los productos pueden usar el mismo conector.
Incluya una prueba separada para los destinatarios externos cuando formen parte del flujo de trabajo empresarial. Un éxito solo interno no establece una ruta de entrega externa.
Compara las rutas admitidas
La guía de configuración actual de Microsoft distingue los siguientes enfoques:
El envío SMTP del cliente utiliza un buzón de correo en la nube autenticado y admite destinatarios internos y externos.
La retransmisión SMTP utiliza un conector entrante y puede retransmitir externamente cuando se cumplen sus requisitos previos.
El envío directo es una entrega interna al destinatario, no una retransmisión por Internet.
El correo electrónico de gran volumen es un servicio independiente para destinatarios internos que utiliza una cuenta HVE, no una alternativa de entrega externa.
Trate esta comparación como una ayuda para la selección, no como la configuración completa o la especificación de licencia. Vuelva a verificar el soporte de autenticación aplicable, el acceso a la red, los límites y los requisitos previos en las instrucciones originales actuales.
No habilite un método de autenticación obsoleto o inadecuado sólo porque una guía de dispositivo anterior lo muestra. Elija una ruta que la aplicación y el servicio actual realmente admitan.
Comprenda la confianza del conector antes de usar la retransmisión SMTP
Microsoft documenta la autenticación basada en certificados o en IP pública para su sistema de retransmisión SMTP . Los requisitos de red y alojamiento son importantes.
Una ruta basada en certificados necesita la relación de dominio aceptado adecuada en la configuración del certificado. Una ruta basada en IP depende de la dirección pública visible para Microsoft, no de una dirección privada que se muestra en el dispositivo.
La guía actual de Microsoft excluye las aplicaciones alojadas por terceros, como los servicios alojados en Azure, de este acuerdo de retransmisión SMTP . Cuando se utiliza autenticación IP, la dirección debe ser estática y no compartirse con otra organización. Revise atentamente las restricciones de alojamiento y direcciones compartidas. La creación de un conector IP para una infraestructura compartida fuera de la organización puede crear un alcance de confianza diferente al previsto por el administrador.
Utilice el punto final MX generado o verificado por Microsoft y el procedimiento de conector actual. No invente un punto final a partir de un nombre de dominio abreviado ni copie la configuración de otro inquilino.
No confundas el Envío Directo con el relé externo
Direct Send no proporciona entrega a destinatarios fuera de la organización basada en la nube. La guía de Microsoft lo trata como una opción para clientes avanzados con responsabilidades relevantes en el servidor de correo y limitaciones adecuadas.
En un ejemplo sintético, un escáner envía correctamente a un empleado pero falla cuando el flujo de trabajo agrega la dirección externa de un cliente. Ese síntoma es consistente con una ruta cuyo alcance de destinatario no incluye retransmisión externa.
Agregar una inclusión de SPF no puede cambiar el alcance del destinatario. Vuelva a evaluar la ruta y los requisitos de la aplicación antes de editar registros no relacionados.
Verificar identidad después de la ruta seleccionada
Referencias: RFC 9989 §4.4.
Una vez configurada la ruta admitida, inspeccione los mensajes recibidos de la aplicación real. Registre el origen visible, la identidad SPF evaluada, las firmas DKIM relevantes y el resultado DMARC confiable.
La aceptación de una conexión por parte de un conector y el resultado de autenticación alineado de un destinatario establecen cosas diferentes. Una puerta de enlace de salida o un relé adicional también pueden afectar el resultado final.
Utilice la guía de autenticación Microsoft 365 para la configuración del dominio y alineación diagnóstico de una discrepancia en el pase sin procesar.
Conservar un registro de aceptación de ruta específica
Mantenga el método elegido, el modelo de alojamiento, el mecanismo de confianza, el alcance del destinatario, el propietario y los resultados representativos. Incluya las instrucciones exactas del proveedor y la fecha de configuración para que los administradores posteriores puedan identificar los requisitos modificados.
Registre los errores de autenticación y entrega por separado. Una conexión rechazada, una ruta de destinatario no admitida y un mensaje recibido que no se alinea pueden requerir diferentes correcciones.
El resultado completo es una ruta de aplicación compatible con confianza responsable y mensajes verificados, no simplemente una ruta válida. registro TXT o una prueba interna exitosa.