¿Qué son los datos SMTP de Office 365 y cómo afectan al correo de una aplicación?

Los detalles de SMTP de Office 365 describen varias rutas

La documentación de Microsoft 365 y Office 365 distingue el envío SMTP de clientes, el relay SMTP y Direct Send. El envío de clientes se autentica como un buzón de Exchange Online y envía a través de smtp.office365.com. El relay SMTP trata la aplicación o el dispositivo como un servidor de correo de la organización y autentica la conexión con un conector de entrada. Direct Send envía de forma anónima al endpoint MX de Microsoft 365 del tenant, para destinatarios de la organización. Son productos operativamente distintos detrás de comandos SMTP similares. No copie un nombre de host y un puerto de un foro sin decidir qué ruta pretende usar. Anote primero el tenant, los dominios aceptados, el administrador, la carga de trabajo, las identidades de remitente, la red de origen, el alcance de destinatarios, el método de autenticación, la política de TLS, el volumen y el responsable de los fallos. El transporte SMTP no autoriza el evento de negocio que origina el envío, no establece el consentimiento del destinatario ni hace duradera la cola de una aplicación.

Configuración del envío SMTP de clientes

La guía de configuración actual de Microsoft documenta smtp.office365.com como el nombre DNS para el envío de clientes e indica que no debe sustituirse por una dirección IP. Recomienda el puerto TCP 587, permite el puerto 25 en el escenario documentado y exige TLS 1.2 o TLS 1.3 con STARTTLS habilitado. La aplicación se autentica como un buzón con licencia de Microsoft 365 u Office 365 y puede enviar a destinatarios internos y externos dentro de los límites documentados. Use la dirección del buzón como identidad explícita y pruebe los permisos Send As cuando el From visible sea distinto. Guarde las credenciales o los tokens en un gestor de secretos del servidor. Un inicio de sesión correcto en la cuenta no demuestra que el From visible esté permitido, que el destinatario sea válido ni que el mensaje vaya a llegar a una bandeja de entrada. El envío de clientes es una ruta limitada a un buzón, así que la suspensión del usuario, los cambios de licencia, las decisiones de acceso condicional y la configuración de SMTP AUTH pueden interrumpir una aplicación que no haya cambiado.

Use OAuth y habilite SMTP AUTH de forma restringida

Microsoft recomienda la autenticación moderna con OAuth para el envío SMTP de clientes. Su documentación de OAuth define el ámbito SMTP.Send y el formato SASL XOAUTH2, con flujos delegados y orientados a aplicaciones sujetos al registro en Microsoft Entra y a los permisos de Exchange. Trate los tokens de acceso y de actualización como secretos, solicite solo los permisos necesarios, valide la vinculación con el tenant y el buzón, rote las credenciales de la aplicación y elimine las concesiones que no se usen. Microsoft también recomienda deshabilitar SMTP AUTH para la organización de Exchange Online y habilitarlo solo en los buzones que todavía lo necesiten. Existen tanto una configuración para toda la organización como una excepción por buzón, y la configuración del buzón puede tener prioridad. Los valores predeterminados de seguridad (Security defaults) deshabilitan SMTP AUTH. No desactive una base de seguridad de todo el tenant solo para mantener un dispositivo heredado. Prefiera un conector, un cliente moderno compatible, un relay local u otro servicio documentado cuando la carga de trabajo no pueda cumplir los requisitos de OAuth y TLS.

Los límites del envío de clientes afectan al diseño de la aplicación

La comparación actual de Microsoft documenta un límite de throttling para el envío SMTP de clientes de 10.000 destinatarios por día y 30 mensajes por minuto. Trátelos como límites de servicio actuales que pueden cambiar y que pueden interactuar con otros límites de Exchange Online. Cuente destinatarios, no solo mensajes, sumando To, Cc, Bcc, reintentos y envíos en abanico. Coloque los controles de frecuencia de la aplicación, equidad entre tenants, concurrencia, intentos y antigüedad en la cola por debajo del techo del servicio. Una ruta de buzón compartido puede generar conflictos entre el uso humano y el automatizado, mientras que una misma credencial usada por muchas aplicaciones oculta quién es el responsable. Supervise el margen de frecuencia y de destinatarios, pero nunca eluda un límite rotando buzones o dominios de remitente. Si la carga de trabajo se acerca con regularidad a los límites de envío por buzón, evalúe el relay mediante conectores, High Volume Email para el tráfico interno que cumpla los requisitos, Azure Communication Services Email para la entrega desde aplicaciones u otro transporte diseñado para ese fin, según las indicaciones vigentes de Microsoft.

Datos del relay SMTP basado en conectores

El relay SMTP de Microsoft 365 usa el endpoint MX del tenant, en lugar de smtp.office365.com, y un conector de entrada que identifica el sistema de envío de la organización. Microsoft recomienda autenticar el conector con un certificado TLS, y documenta una dirección IP pública estática como otro método de identificación. La aplicación se conecta por el puerto TCP 25 y puede enviar desde direcciones de un dominio aceptado sin necesitar un buzón con licencia para cada remitente. Este patrón se adapta a servidores de correo, appliances o gateways controlados, con una responsabilidad estable sobre el certificado y la red. Exige más administración: el alcance del conector, el ciclo de vida del certificado, los cambios de IP pública, el DNS inverso, la política de dominios aceptados, la prevención de abusos y el monitoreo de listas de bloqueo. Nunca cree un relay abierto. Restrinja qué sistemas internos, tenants, remitentes, destinatarios y clases de mensaje acepta el gateway. Un conector reconoce la conexión como perteneciente a la organización; no verifica que una entrada arbitraria de la aplicación sea legítima.

Direct Send es entrega a destinatarios internos, no un relay general

Direct Send envía al endpoint MX del tenant como un servidor SMTP externo, sin autenticarse como buzón ni como conector. Microsoft lo documenta para la entrega a destinatarios de la organización de Microsoft 365 u Office 365, no como una ruta hacia direcciones externas arbitrarias. El dispositivo o la aplicación necesita acceso al puerto TCP 25 y debe usar un remitente de un dominio aceptado. Como la ruta es anónima desde la perspectiva del servicio expuesto a Internet, importan la reputación del remitente, el DNS, la IP de origen y las decisiones contra la suplantación. No exponga un gateway de Direct Send a redes no confiables ni lo use para eludir la autenticación de buzones. Tenga en cuenta los informes de no entrega y quién se encarga del soporte, porque una impresora o una aplicación quizá no reciba los mensajes de rebote de forma segura. Si necesita entrega externa, elija el envío de clientes, el relay mediante conectores, Azure Communication Services Email u otro método compatible, después de evaluar la identidad y el volumen.

Mantenga separadas la identidad del sobre, el From visible y la autenticación

Cada ruta lleva un remitente del sobre SMTP y comandos de destinatario, además de los encabezados visibles del RFC 5322. El remitente del sobre controla los rebotes de transporte y suele ser la identidad de SPF; el From visible controla lo que ven los lectores y es la identidad central de DMARC. La autenticación de buzón con OAuth, la identidad del conector o la aceptación por IP de origen no crean automáticamente la alineación SPF, DKIM o DMARC para cada dominio From personalizado. Inventaríe los valores exactos de MAIL FROM, From, Reply-To, el dominio d= y el selector de DKIM y la IP que se conecta, en muestras controladas recibidas. Publique una única política SPF válida para el dominio que corresponda, configure la firma DKIM donde se admita y evalúe la alineación DMARC. No agregue un segundo registro SPF ni relaje la política DMARC de la organización para arreglar un solo dispositivo. En los modelos de estado, separe la aceptación por Microsoft, la aceptación por el servidor de destino, los rebotes posteriores, el filtrado del buzón, la llegada a la bandeja de entrada y la acción humana.

Implemente un límite de aplicación duradero

Coloque el SMTP de Microsoft 365 detrás de un worker de servidor autorizado o de un relay controlado. Persista un evento de negocio antes de conectarse, con una clave de idempotencia estable, el tenant, la clase de mensaje, la revisión de la plantilla, el remitente y los destinatarios aprobados, la base de consentimiento o de necesidad, el estado de supresión y el historial de intentos. Aplique las reglas de remitente y destinatario por tenant antes de generar comandos SMTP. Limite el tamaño del mensaje, el envío en abanico a destinatarios, los adjuntos y los valores de encabezado. Guarde los tokens, las contraseñas, las claves privadas de los certificados y la administración de los conectores fuera del código fuente, los logs, la analítica, los tickets y los prompts. Defina tiempos de espera finitos y clasifique las respuestas 4xx como candidatas a un reintento acotado y las 5xx como permanentes para ese intento, usando el diagnóstico extendido completo y las indicaciones de Microsoft. Una desconexión después de DATA pero antes de la respuesta final es ambigua; conserve el intento y concílielo antes de reenviar. SMTP no ofrece ninguna garantía de entrega exactamente una vez a nivel de producto.

Pruebe la configuración y los modos de fallo antes del despliegue

Use destinatarios controlados dedicados y una red de origen similar a la de producción. Verifique la resolución DNS, la accesibilidad del puerto, la negociación de STARTTLS, el nombre de host y la cadena del certificado, la obtención y el ámbito del token OAuth, la configuración de SMTP AUTH de la organización y del buzón, la autorización Send As, la coincidencia del conector, los dominios aceptados y la selección del endpoint MX. Envíe muestras en texto sin formato, HTML, con adjuntos, con Unicode, de rebote y con el volumen esperado. Registre los encabezados sin procesar, el Authentication-Results de confianza, las respuestas SMTP, los identificadores de seguimiento y la evidencia del seguimiento de mensajes (message trace), sin conservar contenido de clientes. Las pruebas negativas deben cubrir tokens revocados, certificados de conector vencidos, cambios de IP pública, SMTP AUTH deshabilitado en el buzón, Security defaults, un From no válido, un destinatario externo mediante Direct Send, límites por minuto y de destinatarios, aplazamientos temporales, rechazos permanentes y pérdidas de conexión alrededor de DATA. Ensaye cómo pausar la carga de trabajo y mover los trabajos duraderos sin saltarse los fallos permanentes de política o de destinatario.

Use la guía actual de Microsoft y pruebe su tenant

La configuración SMTP de Microsoft 365 depende de las políticas, identidades, conectores y entorno de red del tenant. Use la documentación actual de Microsoft Learn y pruebe la ruta seleccionada en su tenant antes de confiar en ella para correo de producción.

Preguntas frecuentes

Fuentes

• Configurar un dispositivo multifunción o una aplicación para enviar correo con Microsoft 365 u Office 365 — Microsoft Learn
• Autenticar una conexión IMAP, POP o SMTP mediante OAuth — Microsoft Learn
• Habilitar o deshabilitar el envío SMTP autenticado de clientes en Exchange Online — Microsoft Learn
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor
• RFC 3207: extensión del servicio SMTP para SMTP seguro sobre TLS — RFC Editor
• RFC 7489: autenticación, informes y conformidad de mensajes basados en dominios (DMARC) — RFC Editor