Esquema de reescritura del remitente (SRS) en Microsoft 365
Número de KB original: 4490129
Nota:
Próximos cambios:
- A partir de julio de 2021, empezaremos a implementar un nuevo grupo de direcciones IP de retransmisión, lo que puede afectar al comportamiento actual de reescritura de SRS. Srs no reescribirá los mensajes que cumplan los requisitos para este grupo de retransmisión y se enviarán fuera de las direcciones IP que no formarán parte del registro SPF de Microsoft 365 en su lugar. El cambio principal es para los mensajes que producen un error en las comprobaciones de SPF cuando se envían a Microsoft 365. SRS ya no corregirá estos errores. Para obtener más información, consulte la publicación sobre el cambio del grupo de retransmisión en el Centro de mensajes o consulte Grupos de entrega salientes.
- A partir de noviembre de 2021, empezaremos a usar SRS para volver a escribir todos los mensajes reenviados mediante el reenvío SMTP o buzón de correo. Esto consolidará el comportamiento para usar SRS para todo el reenvío en el servicio. Debido a cambios en el comportamiento, pueden producirse interrupciones. Por ejemplo, los mensajes enviados al entorno local ya no se volverán a escribir. Para obtener más información, vea Esquema de reescritura del remitente Próximos cambios.
Resumen
La funcionalidad esquema de reescritura de remitentes (SRS) se agregó a Microsoft 365 para resolver un problema en el que el reenvío automático no es compatible con SPF. La característica SRS vuelve a escribir la dirección P1 From (también conocida como dirección Envelope From) para todos los mensajes aplicables que se envían externamente desde Microsoft 365. Es importante tener en cuenta que el encabezado From (también conocido como la dirección Mostrar desde o la dirección P2 De) que muestran los clientes de correo electrónico permanece sin cambios.
Este cambio de SRS mejora la entrega de los mensajes aplicables que pasan las comprobaciones del Marco de directivas de remitente (SPF) cuando llegan desde el remitente original, pero que, a continuación, producen un error SPF en el destino externo final después de que se reenvíen.
SRS vuelve a escribir la dirección P1 From en el escenario siguiente:
- Mensajes que se reenvía automáticamente (o se redirigen) en Microsoft 365 mediante cualquiera de los métodos siguientes para reenviar un mensaje a un destinatario externo:
- Reenvío SMTP*
- Redireccionamiento de regla de buzón (o regla de bandeja de entrada)
- Redirección de reglas de transporte
- Grupos o DL que tienen miembros externos
- Reenvío de contactos de correo
- Reenvío de usuarios de correo
- Mensajes que se desplazan automáticamente (o se redirigen) desde los entornos locales de nuestro cliente y se retransmiten a través de Microsoft 365.
*Algunos mensajes reenviados con el reenvío SMTP no se volverán a escribir con SRS, ya que ya se han reescrito.
Nota:
La reescritura de SRS no soluciona el problema de que DMARC pase para los mensajes reenviados. Aunque ahora se pasará una comprobación SPF mediante una dirección P1 From reescrita, DMARC también requiere una comprobación de alineación para que el mensaje pase. En el caso de los mensajes reenviados, DKIM siempre produce un error porque el dominio DKIM firmado no coincide con el dominio de encabezado From . Si un remitente original establece su directiva DMARC para rechazar los mensajes reenviados, los agentes de transferencia de mensajes (MGA) rechazan los mensajes reenviados que respetan las directivas de DMARC.
Este cambio hace que los informes de no entrega (NDR) vuelvan a Microsoft 365 en lugar del remitente original, como harían si no se usara SRS. Por lo tanto, parte de la implementación de SRS es redirigir los NDR devueltos al remitente original si no se puede entregar un mensaje.
Nota:
La reescritura de SRS se usa para evitar la suplantación de dominios no comprobados. Se recomienda a los clientes enviar mensajes solo desde los dominios que poseen y para los que han comprobado su propiedad a través de la lista Dominios aceptados. Para obtener más información sobre los dominios aceptados en Microsoft 365, consulte el siguiente tema de TechNet:
Más información
Reenvío automático de correos electrónicos para un buzón hospedado en Microsoft 365
Un mensaje que se actualiza automáticamente para un buzón hospedado mediante mecanismos como el reenvío SMTP o el redireccionamiento de reglas de buzón o el redireccionamiento de la regla de transporte tienen la dirección P1 From reescribida antes de que el mensaje salga de Microsoft 365. La dirección se vuelve a escribir con el siguiente patrón:
<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>
Ejemplo:
Se envía un mensaje desde Bob (bob@fabrikam.com) al buzón de John en Microsoft 365 (john.work@contoso.com). Juan ha configurado el autoforwarding en la dirección de correo electrónico principal (john.home@example.com).
| Mensaje original | Mensaje autoforwarded | |
|---|---|---|
| Destinatario | john.work@contoso.com | john.home@example.com |
| P1 de | bob@fabrikam.com | john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com |
| Desde el encabezado | bob@fabrikam.com | bob@fabrikam.com |
Nota:
La reescritura de SRS hace que la parte del nombre de usuario de una dirección de correo electrónico aumente de longitud. Sin embargo, la dirección de correo electrónico tiene un límite de 64 caracteres. Si la dirección de correo electrónico implica la reescritura de SRS y supera los 64 caracteres, la dirección de SRS reescrita tendrá la forma de "rebotes" a continuación.
Retransmisión desde el servidor local de un cliente
Un mensaje que se retransmite desde el servidor local o la aplicación de un cliente a través de Microsoft 365 desde un dominio no comprobado tiene la dirección P1 From reescrita antes de salir de Microsoft 365. La dirección se vuelve a escribir con el siguiente patrón:
bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>
Importante
Para recibir NDR para mensajes retransmitidos reescritos por SRS, se debe crear un buzón (hospedado o local) mediante el nombre de usuario de "bounces" y haciendo que el dominio se establezca como el dominio aceptado predeterminado del cliente.
Ejemplo
Se envía un mensaje desde Bob (bob@fabrikam.com) al buzón de John (john.onprem@contoso.com) en el propio servidor de la empresa que ejecuta Exchange Server. Juan ha configurado el reenvío automático a la dirección de correo electrónico principal (john.home@example.com).
| Tipo | Mensaje original | Mensaje retransmitido recibido por Microsoft 365 | Mensaje retransmitido enviado desde Microsoft 365 |
|---|---|---|---|
| Destinatario | john.onprem@contoso.com | john.home@example.com | john.home@example.com |
| P1 de | bob@fabrikam.com | bob@fabrikam.com | bounces+SRS=44ldt=IX@contoso.com |
| Desde el encabezado | bob@fabrikam.com | bob@fabrikam.com | bob@fabrikam.com |
Mensajes reenviados enviados al servidor local de un cliente
De forma predeterminada, SRS considera que los servidores locales están dentro del límite de confianza y no reescribir los mensajes reenviados enlazados al entorno local. Sin embargo, algunos clientes tienen configuraciones de enrutamiento complejas que usan sus servidores locales para enrutar mensajes a Internet. Por lo tanto, los mensajes reenviados no se volverán a escribir y se rechazarán debido a un error de SPF. Para solucionar este problema, hemos agregado una configuración que permite a los administradores habilitar la reescritura de SRS para el tráfico que fluye a través de un conector de salida local. Para obtener más información sobre este nuevo parámetro del conector, vea Esquema de reescritura del remitente Próximos cambios.
Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Dicha información de contacto puede cambiar sin notificación previa. Microsoft no garantiza la precisión de esta información de contacto de terceros.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de