Un email bounce en 550 5.4.1 chez un client Microsoft 365 alors que l’authentification SPF/DKIM/DMARC affiche PASS : pourquoi ce rejet ? La réponse tient en une phrase. Le code 550 5.4.1 signifie que l’adresse du destinataire n’existe pas dans l’annuaire du serveur qui reçoit le message ou que l’accès y est explicitement refusé. C’est un rejet d’annuaire, distinct des rejets de sender reputation. Le contexte du rejet oriente vers l’une des 4 causes : une adresse isolée et un domaine entier ne se traitent pas de la même façon.
Sur Exchange Online, cette réponse est en général la conséquence du Directory-Based Edge Blocking, un mécanisme qui filtre les adresses invalides avant même que le contenu du message soit examiné. C’est là que beaucoup de campagnes calent : votre CMO demande pourquoi le taux d’ouverture baisse, votre outil d’emailing affiche une configuration technique irréprochable et le NDR (Non-Delivery Report) reste incompréhensible sans savoir lire son texte exact.
Ce que veut dire le code 550 5.4.1
550 est un code de statut permanent (classe 5yz de la RFC 5321, publiée en octobre 2008) : le serveur ne retentera pas l’envoi, contrairement aux erreurs 4xx temporaires, que la même RFC fait retenter pendant au moins 4 à 5 jours. Le sous-code 5.4.1 (Enhanced Status Code au sens de la RFC 3463 de janvier 2003) désigne spécifiquement un problème de routage ou d’accès côté destinataire, distinct d’un problème de contenu ou de blacklist. C’est la différence majeure avec le 550 5.7.1, où le rejet vient d’une politique de filtrage ou d’une réputation d’expéditeur dégradée. Ici, l’échange EHLO puis MAIL FROM s’est déroulé sans accroc, la commande RCPT TO a été acceptée syntaxiquement, puis l’adresse a été rejetée au moment de sa résolution dans l’annuaire. Pour une vue d’ensemble des familles de codes 4xx et 5xx, la taxonomie complète des erreurs SMTP pose le cadre général.
Boîte supprimée ou jamais créée : le cas le plus fréquent
Le NDR affiche « 550 5.4.1 Recipient address rejected: Access denied ». L’adresse n’a jamais existé dans l’annuaire Exchange Online. Elle peut aussi en avoir été supprimée après un départ ou une fermeture de compte. Aucun retry ne changera l’issue : l’objet du message n’existe tout simplement pas côté destinataire.
Le premier réflexe reste de vérifier l’orthographe exacte de l’adresse : un domaine mal recopié suffit à produire ce rejet. Si l’adresse est correcte et que le rejet persiste sur plusieurs jours, l’adresse est morte : elle appartient à un ancien contact ou à un poste supprimé, souvent héritée d’un import CRM jamais mis à jour.
Domaine accepté mal configuré en Internal Relay ou Authoritative
Un symptôme distinctif permet de repérer cette cause : le rejet touche tous les destinataires d’un même domaine et non une seule adresse isolée. Dans Exchange Online, un domaine accepté peut être de type Authoritative (l’annuaire M365 fait foi, toute adresse absente est rejetée par DBEB) ou Internal Relay (une partie des boîtes vit ailleurs, le flux continue vers un autre système via un connecteur).
Le problème survient typiquement en environnement hybride : le tenant Microsoft 365 est configuré en Authoritative alors que des boîtes existent encore sur un serveur Exchange local non entièrement synchronisé. Résultat : Exchange Online rejette des adresses parfaitement valides parce qu’il ignore leur existence côté annuaire. La procédure DBEB garde, selon Microsoft Learn, le domaine accepté en Internal Relay pendant la synchronisation des utilisateurs. Le passage en Authoritative vient seulement une fois tous les destinataires présents dans Microsoft 365.
La correction administrateur classique, quand le domaine est déjà censé être bon mais que des adresses valides bouncent quand même : basculer le domaine accepté d’Authoritative vers Internal Relay dans le centre d’administration Exchange (Flux de courrier > Domaines acceptés), enregistrer, puis revenir à Authoritative. En PowerShell, la même bascule passe par la cmdlet Set-AcceptedDomain et son paramètre -DomainType. Cette bascule force Exchange Online à reprovisionner l’état de l’annuaire et efface un cache d’annuaire périmé.
Directory-Based Edge Blocking : le rejet à la frontière avant tout filtre
« Si l’adresse ne figure pas dans l’annuaire, le service bloque le message avant même que le filtrage ne commence. » (documentation Exchange Online, Microsoft Learn)
DBEB (Directory-Based Edge Blocking) rejette les adresses inconnues au niveau du périmètre réseau du service, avant que le message n’entre dans le pipeline de filtrage anti-spam de Microsoft 365. C’est un mécanisme distinct d’un blocage de relais ou d’un refus de connexion en amont, couvert séparément dans l’article sur l’erreur SMTP 554 5.0.0 : là, la connexion elle-même est refusée. Ici, la connexion aboutit. Seule la résolution de l’adresse échoue ensuite. En environnement hybride, DBEB fonctionne seulement si l’enregistrement MX du domaine pointe vers Microsoft 365, précise la même page. Microsoft estime à 5 à 10 minutes le temps d’activation de DBEB.
Le NDR complet porte souvent un code additionnel : « 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) ». Ce code signe un rejet DBEB. Il confirme que le blocage vient de l’annuaire Exchange Online, sans dire pourquoi l’adresse y manque. Quand il tombe juste après la création d’une boîte en environnement hybride, la cause la plus probable reste un retard de synchronisation entre l’annuaire local (Microsoft Entra Connect, l’ex-Azure AD Connect renommé en 2023) et Exchange Online : la boîte existe côté local, le changement attend sa réplication. L’administrateur force alors un cycle delta avec la commande Start-ADSyncSyncCycle -PolicyType Delta sur le serveur Entra Connect avant de chercher plus loin.
Alias ou liste de distribution morte
Quatrième cas : l’adresse rejetée est un alias ou une liste de distribution désactivée. Un groupe de distribution supprimé et un alias retiré d’une boîte partagée produisent exactement le même symptôme à l’écran. Le cas le plus coriace reste le groupe de distribution dynamique on-premises dans un environnement hybride : structurellement, il ne peut pas se synchroniser vers Exchange Online, quel que soit le délai d’attente.
Le contournement documenté pour ce cas précis consiste à créer un contact mail dans Exchange Online qui reprend l’adresse externe du groupe dynamique local. Pour un simple alias supprimé, il faut recréer l’alias sur la boîte cible ou informer l’expéditeur que l’adresse a changé.
Ce que le 550 5.4.1 révèle sur l’état de la liste
« Mes campagnes finissent en rejet et mon outil d’emailing affiche pourtant une configuration technique nickel » : cette phrase revient souvent chez les responsables growth ou lifecycle qui découvrent le 550 5.4.1 pour la première fois. La tentation est de creuser côté SPF, DKIM, IP warmup, sender reputation, comme pour n’importe quel rejet de délivrabilité classique. Sur ce code précis, ce chantier ne sert à rien : les 4 causes ci-dessus se situent toutes côté destinataire, sur son annuaire.
Le réflexe SPF, DKIM, warmup vient d’une bonne habitude. Aucun ESP ne vérifie par défaut si l’adresse existe encore réellement chez le destinataire, seulement si son format est valide. C’est ce point aveugle qu’une vérification de liste couvre, sans ajouter une couche de plus à surveiller au quotidien.
Une adresse supprimée, un alias mort, un domaine entier mal réglé faute de synchronisation : dans les 4 cas, le point commun est une liste qui contient des entrées mortes. Ces entrées s’accumulent vite. CaptainVerify a vérifié 126 millions d’adresses en 2025, dont seulement 57 % de valides. Une liste perd en plus environ 23 % de ses adresses valides par an, d’après l’analyse de ce que vaut réellement une adresse email.
C’est là qu’une vérification de liste en amont change la donne. Elle agit avant l’envoi : elle supprime la catégorie d’erreur entière, sans toucher au DNS ni à la configuration Exchange. Une adresse qui n’existe plus dans l’annuaire du destinataire se repère au moment de la vérification, avant le bounce sur une campagne déjà partie. Avant le prochain envoi, passer un échantillon de la liste par une vérification suffit à voir combien d’adresses tomberaient en 550 5.4.1, sans avoir chauffé l’IP dessus pour rien. C’est une question de list hygiene, réglée en amont de tout chantier d’infrastructure d’envoi.
Questions fréquentes
Le 550 5.4.1 est-il identique au 550 5.7.1 ? Non. Le 5.4.1 signale un problème de routage ou d’accès à l’adresse dans l’annuaire, le 5.7.1 signale une politique de filtrage ou une réputation d’expéditeur dégradée. Les corrections sont totalement différentes : côté annuaire pour l’un, côté réputation pour l’autre.
Combien de temps attendre après une resynchronisation d’annuaire hybride ? Microsoft Entra Connect synchronise par défaut toutes les 30 minutes, selon Microsoft Learn, puis Exchange Online doit encore prendre le changement en compte. Compter quelques heures avant de conclure à une autre cause : retenter plus tôt reproduit le même rejet.
Un rejet 550 5.4.1 fait-il monter mon taux de hard bounce global ? Oui, chaque occurrence compte comme un hard bounce dans les statistiques de votre outil d’emailing et dans celles des messageries destinataires. Une accumulation de ce type de rejet sur une même liste dégrade la sender reputation même si aucune autre erreur de délivrabilité n’est en cause. Pour un état des lieux plus large sur la hausse de ces rejets, l’article sur les rejets SMTP et leur augmentation détaille la mécanique de dégradation.
