Compartilhar via


Esquema de Reescrita do Remetente (SRS) no Microsoft 365

Observação

Em agosto de 2023, será implementada uma alteração nas mensagens reencaminhadas para SMTP ou caixa de correio. Daqui em diante, o SRS será utilizado para reescrever estas mensagens em vez da caixa de correio de reencaminhamento. Isto consolidará os métodos de reencaminhamento para todos utilizarem o SRS no Exchange Online. Embora o SRS tenha sido concebido para evitar interrupções nas mensagens reencaminhadas, alguns casos especiais podem ver problemas. Um dos casos desta alteração é que as mensagens que estão a ser reencaminhadas para a Internet através de servidores no local não serão reescritas com SRS. Para evitar esta alteração de comportamento, veja a nova definição abordada aqui: Alterações Futuras do Esquema de Reescrita do Remetente.

A funcionalidade de conjunto de reencaminhamento foi introduzida no Microsoft 365, o que afeta o comportamento de reescrita do SRS. As mensagens que se qualificam para este conjunto de reencaminhamento não são reescritas pelo SRS e são enviadas de IPs que não fazem parte do registo SPF do Microsoft 365. Isto afeta principalmente as mensagens que falham nas verificações SPF quando estão a entrar no Exchange Online para que o SRS não corrija estas falhas. Para obter mais informações, veja a documentação do conjunto de reencaminhamento aqui: Conjuntos de entrega de saída.

A funcionalidade Esquema de Reescrita do Remetente (SRS) foi adicionada ao Microsoft 365 para resolver um problema em que a substituição automática era incompatível com o SPF. A funcionalidade SRS reescreve o endereço P1 De (também conhecido como o endereço Envelope De) para todas as mensagens aplicáveis que são enviadas externamente do Microsoft 365.

Observação

O cabeçalho De , também conhecido como endereço Apresentar De ou P2 De, que é apresentado pelos clientes de e-mail permanece inalterado.

A funcionalidade SRS melhora a entrega de mensagens aplicáveis que passam verificações do Sender Policy Framework (SPF) quando chegam do remetente original, mas falham nas verificações SPF no destino externo final depois de serem reencaminhadas.

O SRS reescreve o endereço P1 De nos seguintes cenários:

  • Mensagens no Microsoft 365 que são efetuadas automaticamente (ou redirecionadas) para um destinatário externo através de qualquer um dos seguintes métodos:
    • Reencaminhamento SMTP
    • Redirecionamento da Regra de Caixa de Correio (ou regra da Caixa de Entrada)
    • Redirecionamento da Regra de Fluxo de Correio (Transporte)
    • Grupos ou DLs com membros externos
    • Reencaminhamento de Contactos de Correio
    • Reencaminhamento de Utilizadores de Correio
  • Mensagens que são efetuadas automaticamente (ou redirecionadas) a partir do ambiente no local de um cliente e reencaminhadas através do Exchange Online.

É importante ter em atenção que a reescrita SRS é utilizada para impedir o spoofing de domínios não verificados. Deve enviar mensagens apenas a partir de domínios que possui e para os quais verificou a sua propriedade através da lista Domínios Aceites. Para obter mais informações sobre Domínios Aceites no Microsoft 365, consulte Gerir domínios aceites no Exchange Online.

Observação

A reescrita srs não corrige o problema da transmissão de DMARC para mensagens reencaminhadas. Embora uma verificação SPF passe agora devido ao endereço P1 De reescrito, o DMARC também requer uma verificação de alinhamento para que a mensagem passe. Para mensagens reencaminhadas, o DKIM falha sempre porque o domínio DKIM assinado não corresponde ao domínio de cabeçalho De . Se um remetente original definir a política DMARC para rejeitar mensagens reencaminhadas, as mensagens reencaminhadas são rejeitadas pelos Agentes de Transferência de Mensagens (MTAs) que honram as políticas DMARC. A norma ARC foi desenvolvida para resolver os problemas do DKIM com o reencaminhamento e foi implementada no nosso serviço para resolver esses problemas.

Este cenário de falha, juntamente com outras falhas de entrega, faz com que os Relatórios de Entrega Não Entregue (NDRs) sejam devolvidos ao Exchange Online em vez de ao remetente original quando a reescrita srs não é utilizada. Por conseguinte, parte da implementação do SRS é reencaminhar a devolução de NDRs para o remetente original se não for possível entregar uma mensagem.

As secções seguintes apresentam diferentes cenários deforwarding automático e informações sobre como o SRS os processa.

E-mails deforwarding automático para uma caixa de correio alojada no Microsoft 365

Para uma mensagem que é enviada para uma caixa de correio alojada e que é efetuada automaticamente através de mecanismos como reencaminhamento SMTP, redirecionamento de Regra de Caixa de Correio ou redirecionamento de Regras de Transporte, o endereço P1 De é reescrito antes de a mensagem sair do Exchange Online. O endereço é reescrito com o seguinte padrão:

<Forwarding Mailbox Username>+SRS=<Hash>=<Timestamp>=<Original Sender Domain>=<Original Sender Username>@<Forwarding Mailbox Domain>

No exemplo seguinte, é enviada uma mensagem de Bob (bob@fabrikam.com) para a caixa de correio do João no Exchange Online (john.work@contoso.com). O João configurou automaticamente esta caixa de correio para o seu endereço de e-mail de casa (john.home@example.com). Repare como o endereço P1 De é reescrito pelo SRS.

  Mensagem original Mensagem deforwarded automaticamente
Recipiente john.work@contoso.com john.home@example.com
P1 De bob@fabrikam.com john.work+SRS=44ldt=IX=fabrikam.com=bob@contoso.com
Do cabeçalho bob@fabrikam.com bob@fabrikam.com

Quando o SRS reescreve o endereço P1 De , aumenta o comprimento da parte do nome de utilizador do endereço de e-mail. No entanto, o endereço de e-mail tem um limite de 64 carateres. Por isso, se o comprimento do endereço de e-mail reescrito exceder os 64 carateres, assume o seguinte formato:

bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>

em que <Default Accepted Domain> é o nome da predefinição Domínio Aceite configurado para o inquilino.

Reencaminhamento a partir do servidor no local de um cliente

Quando uma mensagem proveniente de um domínio não verificado é reencaminhada a partir do servidor no local de um cliente ou de uma aplicação através do Exchange Online, o endereço P1 De é reescrito antes de sair do Exchange Online. O endereço é reescrito com o seguinte padrão:

bounces+SRS=<Hash>=<Timestamp>@<Default Accepted Domain>

No exemplo seguinte, é enviada uma mensagem de Bob (bob@fabrikam.com) para a caixa de correio do João (john.onprem@contoso.com) que está no servidor da empresa que está a executar o Exchange Server. O João configurou automaticamente esta caixa de correio para o seu endereço de e-mail de casa (john.home@example.com). Repare como o endereço P1 De é reescrito pelo SRS neste cenário. Os clientes são encorajados a definir o domínio predefinido aceite para um dos seus próprios domínios.

Tipo Mensagem original Mensagem reencaminhada recebida pelo Exchange Online Mensagem reencaminhada enviada do Exchange Online
Recipiente 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
Do cabeçalho bob@fabrikam.com bob@fabrikam.com bob@fabrikam.com

Em algumas situações, as mensagens reencaminhadas que são reescritas pelo SRS podem não ser entregues e pode ser gerado um NDR.

Para receber esses NDRs, o administrador inquilino tem de criar uma caixa de correio denominada "devoluções" alojada no Exchange Online ou no local. O domínio para esta caixa de correio tem de ser definido como o domínio predefinido aceite para o inquilino.

Mensagens reencaminhadas enviadas para o servidor no local de um cliente

Por predefinição, o SRS considera que os servidores no local estão dentro do limite de fidedignidade e não reescreve as mensagens reencaminhadas que estão vinculadas ao local. No entanto, para configurações de encaminhamento complexas que utilizam servidores no local para encaminhar mensagens para a Internet, as mensagens reencaminhadas sem a reescrita SRS estão sujeitas a rejeições devido a uma falha do SPF. Para resolver este problema, os administradores podem ativar o SRS para o tráfego que flui através de um conector de saída no local. A definição SenderRewritingEnabled pode ser utilizada para o fazer e é configurável com os cmdlets New-OutboundConnector ou Set-OutboundConnector.

Esta definição não se aplica a conectores de parceiros que processam mensagens para destinatários externos e é obrigatório que estas mensagens tenham o SRS aplicado às mesmas, se necessário. A definição SenderRewritingEnabled será apresentada como verdadeira para os conectores de parceiros e é devolvido um erro para quaisquer tentativas de definir o respetivo valor.

Mensagens redirecionadas do Fluxo de Correio (Transporte)

Dado que uma mensagem pode ser redirecionada por uma regra por qualquer motivo, não apenas por causa de um determinado destinatário, não existe um conceito de caixa de correio de reencaminhamento. Tendo isso em mente, o endereço reescrito SRS assume a seguinte forma:

bouncesEtr+SRS=<Hash>=<Timestamp>=<OrigSenderDomain>=<OrigSenderUser>@<Default Accepted Domain> 

Para receber NDRs, o seu inquilino tem de conseguir receber mensagens endereçadas a um utilizador com o nome "bouncesETR" para que possamos redirecionar a mensagem para o remetente original. Por exemplo, Directory-Based o Bloqueio do Edge pode interferir com a devolução de NDRs se não existir essa caixa de correio no seu inquilino.

Reencaminhamento de conjuntos e a ignorar SRS

A funcionalidade de conjunto de reencaminhamento foi introduzida no Microsoft 365, o que afeta o comportamento de reescrita do SRS. As mensagens que se qualificam para este conjunto de reencaminhamento não são reescritas pelo SRS e são enviadas de IPs que não fazem parte do registo SPF do Microsoft 365. Isto afeta principalmente as mensagens que falham nas verificações SPF quando são enviadas pela primeira vez para o Exchange Online, uma vez que o SRS não deve corrigir estas falhas com a reescrita. Para obter mais informações, veja a documentação do conjunto de reencaminhamento aqui: Conjuntos de entrega de saída