Mise à jour de la configuration requise pour smtp Relay via Exchange Online

Cet article explique comment mettre à jour vos exigences pour le relais SMTP via Exchange Online. Si votre organisation n’utilise pas le connecteur entrant de type OnPremises, cette modification ne vous affecte pas.

Configuration requise actuelle

Pour relayer les e-mails via Exchange Online, les conditions suivantes doivent être vraies :

1. L’un des éléments suivants est un domaine accepté de votre organisation, si :

   1. Domaine de certificat SMTP sur la connexion SMTP ; ou
   2. Le domaine de l’expéditeur d’enveloppe SMTP se trouve dans la commande MAIL FROM (domaine de l’expéditeur P1) ; ou
   3. Domaine de l’expéditeur d’en-tête SMTP, comme indiqué dans les clients de messagerie (domaine de l’expéditeur P2).

2. L’adresse IP de l’hôte d’envoi ou le domaine de certificat sur la connexion SMTP correspond au connecteur entrant de type OnPremises de votre locataire.

Nouvelles exigences

Le 1er novembre 2023, la condition correspondante pour le domaine de l’expéditeur SMTP P2 est supprimée. Voici les nouvelles conditions requises pour le relais de courrier électronique via Exchange Online :

1. L’un des éléments suivants est un domaine accepté de votre organisation, si :

   1. Domaine de certificat SMTP sur la connexion SMTP ; ou
   2. Domaine de l’expéditeur de l’enveloppe SMTP dans la commande MAIL FROM (domaine de l’expéditeur P1).

2. L’adresse IP ou le domaine de certificat de l’hôte expéditeur sur la connexion SMTP correspond au connecteur entrant de votre organisation de type OnPremises.

Si l’une des conditions ci-dessus n’est pas remplie, la tentative de relais de votre environnement local vers Exchange Online est rejetée.

Cette modification peut affecter le routage ou la remise des e-mails de votre organisation. Les scénarios possibles qui sont affectés par cette modification sont notamment les suivants :

1. Votre organisation héberge les e-mails locaux et vous devez relayer les rapports de non-remise (NDR) générés par votre système local via Exchange Online. Dans ce scénario, les NDR ont souvent null comme expéditeur d’enveloppe SMTP (expéditeur P1), mais le domaine de l’expéditeur d’en-tête SMTP (domaine de l’expéditeur P2) est le domaine de votre organisation.

2. Votre organisation utilise une application hébergée localement pour envoyer des messages électroniques, et le domaine de l’expéditeur d’enveloppe SMTP (domaine de l’expéditeur P1) n’est pas un domaine accepté dans Exchange Online.

3. Vous utilisez un service cloud tiers pour relayer des messages en créant un connecteur entrant de type OnPremises. Par exemple, lorsque vous utilisez une plateforme de service cloud pour relayer des e-mails via Exchange Online, le domaine de l’expéditeur d’enveloppe SMTP (domaine de l’expéditeur P1) est le domaine du service tiers (peut-être pour le suivi des rebonds), mais le domaine d’en-tête SMTP (domaine de l’expéditeur P2) est le domaine de votre organisation.

Vérifiez si votre organisation est affectée par cette modification

Vous pouvez utiliser le type de rapport étendu nouvellement créé pour générer le rapport pour votre organisation en exécutant Start-HistoricalSearch. Il génère un rapport étendu spécifique à ce scénario. Voici quelques exemples et remplacez la valeur de NotifyAddress dans les exemples par votre adresse e-mail d’administrateur pour générer un rapport.

Exemple 1 :

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report all emails using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com

Exemple 2 :

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails using a specific sender domain (non accepted domain) as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -SenderAddress *@MyDomain.com

Notes

Le SenderAddress doit être un domaine accepté de votre organisation.

Exemple 2 :

Start-HistoricalSearch -EndDate "2023/09/22" -StartDate "2023/09/18" -ReportTitle "Report on emails for a recipient domain using non accepted domains as the sender" -ReportType "P2SenderAttribution" -NotifyAddress admin@mydomain.com -RecipientAddress *@mycustomer.com

Notes

Peut RecipientAddress contenir n’importe quel domaine auquel votre organisation envoie des e-mails.

Vous pouvez utiliser Get-HistoricalSearch pour signaler l’état du travail de rapport étendu.

Utilisez Get-HistoricalSearch -JobId xxxx, où xxxx est l’ID du travail.

Si le résultat du travail (ReportStatusDescription) est « Terminé - Aucun résultat trouvé », cela signifie que votre organisation n’est pas affectée par le scénario.

Réduire les effets de cette modification

1. Si vous avez besoin de relayer des e-mails locaux via Exchange Online et que certains de ces e-mails s’appliquent aux scénarios indiqués ci-dessus, vous devez mettre à jour votre connecteur entrant de type OnPremises pour utiliser un domaine de certificat (au lieu d’adresses IP). En outre, vous devez ajouter le domaine de certificat en tant que domaine accepté de votre organisation. Pour plus d’informations, consultez Configurer un connecteur basé sur un certificat pour relayer des messages électroniques via Microsoft 365.

2. Si vous devez utiliser un service complémentaire tiers pour traiter les messages électroniques envoyés par votre organisation, puis les relayer via Exchange Online, le service tiers doit prendre en charge un certificat unique pour votre organisation, et le domaine de certificat doit être un domaine accepté de votre organisation. Par exemple, votre organisation utilise un service de signature pour ajouter une signature/exclusion de responsabilité pour chaque e-mail envoyé par votre organisation. Par exemple, votre organisation utilise un service cloud CRM tiers pour envoyer des e-mails au nom de votre organisation aux boîtes aux lettres de votre entreprise ou à d’autres utilisateurs externes. Pour plus d’informations, consultez Scénario : Intégrer Exchange Online à un service complémentaire de messagerie.