MENU
  1. Accueil
  2. Microsoft 365
  3. Erreur 5.7.520 « Access denied » Exchange Online : autoriser le transfert externe en toute sécurité

Erreur 5.7.520 « Access denied » Exchange Online : autoriser le transfert externe en toute sécurité

Microsoft 365

Vos utilisateurs voient le NDR « 5.7.520 Access denied » lors d’un transfert automatique vers l’externe ? Voici une procédure claire, outillée et sécurisée pour diagnostiquer et corriger le blocage dans Exchange Online / Microsoft 365.

Sommaire

Symptôme et message d’erreur

Le transfert automatique (par règle de boîte de réception, redirection ou paramètre de boîte) vers une adresse externe échoue et retourne un NDR indiquant que l’organisation n’autorise pas le transfert sortant.

5.7.520 Access denied, Your organization does not allow external forwarding. AS(7555)

Ce code provient d’Exchange Online Protection (EOP/Defender) : par défaut, Microsoft applique une posture « Secure by Default » qui bloque le transfert automatique externe, afin de limiter l’exfiltration de données via comptes compromis ou règles malicieuses.

Ce que signifie réellement le blocage

  • Stratégie anti‑spam sortante : si l’option Automatic forwarding rules est Off ou Automatic (System‑controlled) (équivalent à Off dans l’état actuel), EOP refuse tout transfert automatique vers des domaines externes.
  • Domaine distant : s’il n’autorise pas l’auto‑transfert (AutoForwardEnabled = False), le rejet survient, quel que soit le réglage anti‑spam sortant.
  • Règles de transport : une « Mail Flow Rule » peut explicitement bloquer les transferts automatiques.
  • Connecteurs hybride : en environnement hybride, un connecteur sortant inadapté peut empêcher la remise à Internet.
  • Autres contrôles : limites de flux, politiques DLP/étiquetage, blocages sur domaine/expéditeur, etc.

Feuille de route en un coup d’œil

Pour résoudre l’erreur AS(7555), suivez la séquence ci‑dessous : commencez par la politique Outbound, vérifiez son périmètre, puis le domaine distant, ensuite les règles de transport et, si hybride, les connecteurs. Terminez par un test ciblé et un message trace pour valider.

ÉtapeActionDétails / CmdletsOù regarder & latence
1Vérifier la stratégie anti‑spam sortanteCentre d’administration > Protection/Defender > Politiques & règles > Anti‑spam outbound policy > Automatic forwarding rules. Get-HostedOutboundSpamFilterPolicy | ft Name,AutoForwardingMode
Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On Off = toujours bloqué. Automatic (System‑controlled) = se comporte comme Off depuis 2023. On = autorise le transfert externe.		Admin Defender (ou EAC modern). Propagation ≈ 5‑30 min.
2Confirmer le périmètre de la politiqueLa politique doit cibler l’utilisateur (règle associée au groupe/l’utilisateur). Get-HostedOutboundSpamFilterRule | ft Name,Priority,State,HostedOutboundSpamFilterPolicy,From,FromMemberOf,ExceptIfFrom,ExceptIfFromMemberOfSi la règle ne couvre pas le compte, la politique « On » n’a pas d’effet. Propagation ≈ 5‑30 min.
3Contrôler les domaines distantsGet-RemoteDomain | Select Name,DomainName,AutoForwardEnabled
Set-RemoteDomain -Identity "Default" -AutoForwardEnabled $true		EAC > Paramètres d’organisation > Domaines distants. Effet quasi immédiat (quelques minutes).
4Examiner les règles de fluxUne règle de transport peut bloquer le type Auto‑forward. Get-TransportRule | where {$_.MessageTypeMatches -like "*AutoForward*"} | ft Name,State,Mode,PriorityEAC > Flux de messagerie > Règles. Changement actif en quelques minutes.
5Vérifier les connecteurs (hybride)Get-OutboundConnector | ft Name,ConnectorType,Enabled,RecipientDomains,SmartHosts,TlsSettings
Get-InboundConnector | ft Name,ConnectorType,Enabled,TlsSenderCertificateName		Admin Exchange > Flux de messagerie > Connecteurs. Effet quasi immédiat.
6Tester un transfert manuelDepuis la même boîte, envoyer un mail manuel à l’adresse externe. Si ça passe, le blocage est spécifique à l’auto‑transfert.Permet de distinguer politique/transport vs problème de remise/destinataire.
7Consulter les journaux de suiviGet-MessageTrace -SenderAddress user@contoso.com -StartDate (Get-Date).AddHours(-48) -EndDate (Get-Date) -PageSize 500
Get-MessageTraceDetail -MessageTraceId <ID> -RecipientAddress destinataire@externe.com		EAC > Rapports > Suivi des messages : repérez la règle/raison exacte du rejet AS(7555).

Vérifications détaillées et bonnes pratiques

Politique anti‑spam sortante : comprendre le paramètre clé

La bascule Automatic forwarding rules pilote le sort des transferts automatiques. Trois valeurs existent :

  • Off : blocage total du transfert externe. C’est la posture recommandée par défaut.
  • Automatic (System‑controlled) : alignée sur Off dans la posture « Secure by Default ».
  • On : autorise le transfert externe.

Pour visualiser et modifier en PowerShell :

# Se connecter à Exchange Online
Connect-ExchangeOnline

# Lister les politiques et l'état voulu

Get-HostedOutboundSpamFilterPolicy | ft Name,AutoForwardingMode

# Activer l'autorisation (à l'échelle de la politique ciblée)

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On

# Vérifier quelle règle applique cette politique à vos expéditeurs

Get-HostedOutboundSpamFilterRule | ft Name,HostedOutboundSpamFilterPolicy,Priority,State,From,FromMemberOf,ExceptIfFromMemberOf

# Se déconnecter

Disconnect-ExchangeOnline

Important : si vous préférez un modèle zéro‑trust, créez une politique spécifique « On » et attachez‑la seulement à un groupe d’utilisateurs autorisés (voir plus bas un exemple de mise en place granulaire).

Périmètre de la politique : bien couvrir l’utilisateur

Une politique « On » qui ne s’applique pas au compte expéditeur n’a aucun effet. Vérifiez la ou les règles associées et leurs conditions :

# Exemple : vérifier cibles et exceptions
Get-HostedOutboundSpamFilterRule | 
  Select Name,Priority,State,HostedOutboundSpamFilterPolicy,From,FromMemberOf,ExceptIfFrom,ExceptIfFromMemberOf | 
  Format-Table -Auto

Dans l’interface, confirmez que la règle vise l’utilisateur (ou son groupe). Laissez 5 à 30 minutes pour la propagation côté service.

Domaines distants : le coupe‑circuit historique

Le paramètre AutoForwardEnabled au niveau du domaine distant peut bloquer l’auto‑transfert, même si votre politique Outbound est « On ». Vérifiez au minimum le domaine Default et, si vous avez défini des domaines spécifiques, inspectez‑les aussi.

# Lister les domaines distants et le statut de l'auto-forward
Get-RemoteDomain | Select Name,DomainName,AutoForwardEnabled

# Autoriser l'auto-forward côté domaine "Default"

Set-RemoteDomain -Identity "Default" -AutoForwardEnabled $true

Règles de transport : priorité et exceptions

Les règles de flux (transport rules) peuvent interdire l’auto‑forward explicitement via la condition « Message Type = Auto‑forward » ou des correspondances de sujet/adresse. Elles priment souvent sur les politiques anti‑spam. Recherchez, documentez et, si nécessaire, positionnez une exception granulaire pour le groupe autorisé.

# Cibler les règles impliquant l'auto-forward
Get-TransportRule | where {$_.MessageTypeMatches -like "*AutoForward*"} | 
  ft Name,State,Mode,Priority,Comments

# Inspecter une règle précise

Get-TransportRule -Identity "Règle blocage auto-forward" | fl

Environnements hybrides : les connecteurs à la loupe

Dans une topologie hybride, les messages sortants peuvent transiter par des connecteurs spécifiques (SmartHost on‑prem, exigence TLS/certificat). Une configuration trop restrictive ou désactivée peut empêcher la sortie Internet d’un message transféré automatiquement.

# Vue d'ensemble des connecteurs
Get-OutboundConnector | ft Name,ConnectorType,Enabled,RecipientDomains,SmartHosts,TlsSettings
Get-InboundConnector  | ft Name,ConnectorType,Enabled,TlsSenderCertificateName

Contrôlez que le connecteur effectif pour Internet est Enabled, que le TLS/certificat correspond, et qu’aucune restriction de domaine ne filtre par inadvertance le destinataire externe de test.

Test manuel et suivi des messages

Un envoi manuel vers la même adresse externe permet d’isoler le problème. Si l’e‑mail manuel réussit mais pas l’auto‑forward, vous confirmez que la pile de sécurité cible précisément le transfert automatique.

# Trace rapide sur 48h, en filtrant l'expéditeur
Get-MessageTrace -SenderAddress user@contoso.com `
  -StartDate (Get-Date).AddHours(-48) -EndDate (Get-Date) -PageSize 500

# Détails du message rejeté (avec son MessageTraceId)

Get-MessageTraceDetail -MessageTraceId  -RecipientAddress [destinataire@externe.com](mailto:destinataire@externe.com)

Le Message Trace mettra en évidence la règle ou la politique ayant déclenché le rejet AS(7555).

Points d’attention supplémentaires

  • Sécurité : Microsoft active « Secure by Default ». L’option Automatic (System‑controlled) est équivalente à Off pour réduire les risques d’exfiltration via comptes compromis.
  • Propagation : attendez jusqu’à 30 minutes après tout changement de politique/règle. Le cmdlet Start-ManagedFolderAssistant peut accélérer certains traitements côté boîte (rétention/clean‑up), mais n’influence pas directement l’application des politiques EOP.
  • Limitation partielle : autorisez le transfert externe uniquement pour un sous‑ensemble d’utilisateurs via une politique Outbound dédiée et une règle ciblant un groupe Azure AD.
  • Autres blocages courants : quotas de débit/volume, domaine externe sur liste de blocage interne, contrôles DLP ou étiquettes de confidentialité empêchant l’envoi externe, connecteurs mal priorisés.

Modèle de configuration granulaire recommandé

Plutôt que d’ouvrir l’auto‑forward pour tout le monde, créez une politique dédiée et limitez‑la à un groupe autorisé.

# 1) Créer une politique Outbound autorisant l'auto-forward
New-HostedOutboundSpamFilterPolicy -Name "Allow-AutoForward-Scoped" -AutoForwardingMode On

# 2) Cibler uniquement un groupe AAD autorisé (prérequis : groupe mail-enabled)

New-HostedOutboundSpamFilterRule `  -Name "Allow-AutoForward-Scoped-Rule"`
-HostedOutboundSpamFilterPolicy "Allow-AutoForward-Scoped" `
-FromMemberOf "G_TransfertExterne_Autorise"

# 3) Vérifier la prise en compte

Get-HostedOutboundSpamFilterRule -Identity "Allow-AutoForward-Scoped-Rule" | fl

Cette approche minimise l’exposition tout en satisfaisant les cas d’usage légitimes.

Audit complet côté boîte aux lettres

Pour diagnostiquer précisément l’origine du transfert (règle de boîte, redirection de boîte ou application tierce), combinez ces vérifications :

# Règles de boîte aux lettres (y compris cachées)
Get-InboxRule -Mailbox user@contoso.com -IncludeHidden | 
  Select Name,Enabled,ForwardTo,ForwardAsAttachmentTo,RedirectTo | Format-Table -Auto

# Paramètres de transfert au niveau de la boîte

Get-Mailbox -Identity [user@contoso.com](mailto:user@contoso.com) |
Select PrimarySmtpAddress,ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward | Format-List

# Dernières modifications administratives visibles en audit (si activé côté Purview)

# (à conduire dans le portail d'audit Microsoft Purview)

Cette collecte vous indique qui transfère, comment et vers quelle adresse cible, ce qui facilite la mise en conformité.

Script d’audit prêt à l’emploi

Ce script lit les paramètres critiques pour un utilisateur et affiche un résumé exploitable. Exécutez‑le dans un PowerShell Exchange Online (module EXO V2+).

param(
  [Parameter(Mandatory=$true)][string]$UserPrincipalName,
  [string]$TestRecipient = ""
)

Write-Host "== Connexion EXO ==" -ForegroundColor Cyan
Connect-ExchangeOnline -ShowBanner:$false

Write-Host "`n== Politique Outbound ==" -ForegroundColor Cyan
$pols = Get-HostedOutboundSpamFilterPolicy | Select Name,AutoForwardingMode
$rules = Get-HostedOutboundSpamFilterRule |
Select Name,HostedOutboundSpamFilterPolicy,Priority,State,From,FromMemberOf,ExceptIfFrom,ExceptIfFromMemberOf

$pols | ft -Auto
$rules | ft -Auto

Write-Host "`n== Domaines distants ==" -ForegroundColor Cyan
Get-RemoteDomain | Select Name,DomainName,AutoForwardEnabled | ft -Auto

Write-Host "`n== Règles transport (AutoForward) ==" -ForegroundColor Cyan
Get-TransportRule | where {$_.MessageTypeMatches -like "*AutoForward*"} |
Select Name,State,Mode,Priority,Comments | ft -Auto

Write-Host "`n== Boîte aux lettres / Transfert ==" -ForegroundColor Cyan
Get-Mailbox -Identity $UserPrincipalName |
Select PrimarySmtpAddress,ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward | fl

Get-InboxRule -Mailbox $UserPrincipalName -IncludeHidden |
Select Name,Enabled,ForwardTo,ForwardAsAttachmentTo,RedirectTo | ft -Auto

if ($TestRecipient -ne "") {
Write-Host "`n== MessageTrace (48h) ==" -ForegroundColor Cyan
  Get-MessageTrace -SenderAddress $UserPrincipalName `
-StartDate (Get-Date).AddHours(-48) -EndDate (Get-Date) -PageSize 200 | ft -Auto
}

Disconnect-ExchangeOnline

Scénarios de décision

ContexteAction conseilléeBénéfice
Besoin ponctuel pour un petit groupePolitique Outbound « On » ciblée sur un groupe autoriséSurface d’attaque minimale, conformité maîtrisée
Organisation très réguléeLaisser globalement « Off », puis exceptions case‑by‑case et journalisationAlignement sécurité, traçabilité renforcée
Hybride avec routage sortant on‑premValider connecteur sortant, TLS/certificats et listes de domaines autorisésÉvite les faux positifs côté transport
Blocages persistants après ouvertureInspecter transport rules, DLP, domaine distant, puis exécuter un message traceIsolation rapide de la règle responsable

FAQ opérationnelle

La valeur « Automatic (System‑controlled) » suffit‑elle ?
Non : dans la posture actuelle, elle se comporte comme Off. Utilisez On (ou une politique dédiée « On ») si vous devez autoriser le transfert externe.

Faut‑il activer l’auto‑forward pour tout le tenant ?
Évitez. Préférez une politique granulaire limitée à un groupe. Ajoutez des exceptions dans les transport rules au lieu de désactiver des contrôles globaux.

Le domaine distant « Default » suffit‑il ?
Dans la majorité des cas, oui. Si vous avez créé des domaines distants spécifiques (par ex. pour des partenaires), vérifiez leur champ AutoForwardEnabled.

Pourquoi un envoi manuel fonctionne mais pas l’auto‑forward ?
Parce que la pile de sécurité traite différemment les messages générés automatiquement. Les politiques/transport rules ciblent spécifiquement le message type « Auto‑forward ».

Quid des limites de flux ?
Les plafonds de débit/volume par boîte et par organisation peuvent aussi empêcher des transferts massifs. Réduisez la volumétrie ou étalez dans le temps, puis retestez.

Méthode express de dépannage

  1. Activez On dans Automatic forwarding rules sur la politique qui s’applique à l’utilisateur (ou créez une politique dédiée « On » et une règle limitée à un groupe autorisé).
  2. Assurez‑vous que Set-RemoteDomain -Identity "Default" -AutoForwardEnabled $true est en place.
  3. Contrôlez qu’aucune mail flow rule ou connecteur ne bloque le transfert.
  4. Retestez et, en cas d’échec, exploitez l’ID de message via le Message Trace pour identifier la règle/limite en cause.

Exemples concrets de corrections

Cas A : ouverture ciblée pour un service client
Créez un groupe G_TransfertExterne_Autorise (mail‑enabled). Mettez en place la politique Allow‑AutoForward‑Scoped (voir plus haut) et la règle associée sur ce groupe. Ajoutez une exception dans toute règle de transport qui bloque l’auto‑forward, limitée à ce groupe. Testez ensuite avec un compte membre du groupe.

Cas B : rejet persistant vers un domaine partenaire
Vérifiez Get-RemoteDomain : si un domaine distant spécifique au partenaire a AutoForwardEnabled = False, activez‑le uniquement pour ce domaine : Set-RemoteDomain -Identity "partner.com" -AutoForwardEnabled $true. Réduisez l’exposition en gardant Default strict.

Cas C : hybride, routage via on‑prem
Confirmez que le connecteur sortant vers Internet (sur on‑prem ou dans EXO) est Enabled et correctement priorisé. Validez TLS et le certificat CN/SAN attendu. Faites un message trace pour repérer où le message est stoppé (cloud vs on‑prem).

Checklist finale avant clôture d’incident

  • Politique Outbound : On sur le périmètre utilisateur, ou politique dédiée + règle ciblée.
  • Domaine distant par défaut : AutoForwardEnabled = True.
  • Transport rules : pas de règle bloquante sans exception adaptée.
  • Connecteurs : pas d’anomalie en hybride, TLS/cert OK.
  • Message trace : ID collecté, cause identifiée, test de non‑régression réussi.

Conclusion

L’erreur 5.7.520 AS(7555) indique un choix sécurité volontaire de Microsoft 365 : c’est à l’administrateur de décider où et pour qui l’auto‑forward est acceptable. En combinant politique Outbound « On » de manière granulaire, domaine distant autorisé, règles de transport maîtrisées et validation via le Message Trace, vous rétablissez le transfert externe tout en conservant une posture de sécurité raisonnable.

Résumé opérationnel

  1. Activez « On » dans Automatic forwarding rules et vérifiez que la politique cible l’utilisateur.
  2. Contrôlez que AutoForwardEnabled est True sur le domaine distant Default (et sur tout domaine concerné).
  3. Vérifiez qu’aucune mail flow rule ni aucun connecteur n’empêche le transfert.
  4. Retestez ; si l’erreur persiste, récupérez l’ID via le Message Trace pour isoler la règle/limite et ajuster.
Microsoft 365
PowerShell Microsoft 365 Exchange Online Transfert automatique EOP AS(7555)
Sommaire