Erreur 550 5.7.520 AS(7555) : activer l’auto‑transfert Outlook vers Gmail dans Microsoft 365 (guide complet)

Votre transfert automatique d’Outlook vers Gmail ne fonctionne pas ? Si vous voyez l’erreur 550 5.7.520 AS(7555), c’est (presque) toujours une politique au niveau du tenant Microsoft 365 qui bloque l’auto‑transfert sortant. Voici un guide clair, complet et directement actionnable.

Sommaire

Impossible d’auto‑transférer les e‑mails d’Outlook vers Gmail : vue d’ensemble

Scénario typique : une boîte aux lettres Outlook/Exchange Online (compte pro) est configurée pour transférer automatiquement tous les messages vers Gmail (compte perso). Dans l’interface Outlook, le transfert apparaît « activé », mais aucun message n’arrive côté Gmail. L’envoi manuel (vous cliquez sur Transférer) fonctionne, de même qu’un envoi direct depuis Outlook vers Gmail. Les tentatives via une « règle » Outlook/OWA (Transférer ou Rediriger) échouent aussi. Un NDR (rapport de non‑remise) contient : 550 5.7.520 – Your organization does not allow external forwarding. AS(7555).

La cause réelle : une politique anti‑spam sortante au niveau Microsoft 365

Le blocage ne vient ni de Gmail, ni d’un « bug » d’Outlook. Il provient d’une stratégie anti‑spam sortante (Hosted Outbound Spam Filter Policy) configurée au niveau du tenant Microsoft 365. Cette stratégie interdit l’auto‑transfert vers l’externe, ce qui déclenche l’erreur 5.7.520 AS(7555). À l’inverse, un transfert manuel (action utilisateur) n’est pas classé comme auto‑transfert système et passe donc sans être bloqué.

Pourquoi les règles Outlook ne suffisent pas ?

Qu’il s’agisse d’une règle Transférer / Rediriger dans Outlook ou du paramètre Mail > Forwarding (au niveau de la boîte), Exchange Online marque ces messages comme auto‑transfers. Les politiques anti‑spam sortantes contrôlent précisément ce type de messages. Si l’auto‑transfert externe est Désactivé au niveau du tenant, ils sont bloqués en sortie, d’où le NDR 550 5.7.520 AS(7555).

Symptômes, indice et interprétation

Symptôme	Indice visible	Interprétation la plus probable
Transfert automatique Outlook → Gmail ne fonctionne pas	NDR 5.7.520 AS(7555)	Blocage par la Hosted Outbound Spam Filter Policy
Transfert manuel (bouton « Transférer »)	Le message arrive sur Gmail	Normal : non considéré comme auto‑transfert
Règles Outlook/OWA « Transférer/Rediriger »	Aucun e‑mail reçu côté Gmail	Classés « auto‑transfers », donc bloqués
Message trace côté Microsoft	Événement « Dropped/Blocked »	Preuve du blocage avant d’atteindre Gmail

Ce qu’il faut faire (administrateur Microsoft 365)

Deux approches possibles : modifier la stratégie par défaut ou créer une stratégie dédiée et ciblée. La seconde est recommandée pour maîtriser la surface de risque.

Activer l’auto‑transfert externe dans Microsoft 365 Defender

Ouvrez le portail Microsoft 365 Defender.
Accédez à Email & collaboration → Policies & rules → Threat policies → Anti‑Spam.
Ouvrez Anti‑Spam outbound policies (Default), puis cliquez sur Edit protection settings.
Dans la section Automatic forwarding rules, sélectionnez On – Forwarding is enabled (ou Automatic – system controlled si vous acceptez le comportement piloté par Microsoft).
Enregistrez (Save) et patientez quelques minutes le temps de la propagation.

Important : Automatic – system controlled peut, selon le contexte, se comporter comme un blocage restrictif. Si vous souhaitez une autorisation explicite, choisissez On.

(Recommandé) Créer une stratégie dédiée et ciblée

Évitez d’ouvrir l’auto‑transfert à toute l’organisation. Créez une policy anti‑spam sortante spécifique (auto‑transfert autorisé) et ciblez-la uniquement sur les utilisateurs ou groupes qui en ont besoin. Assurez-vous que cette policy a une priorité plus élevée que la Default.

Dans Anti‑Spam, créez une nouvelle Outbound policy avec Automatic forwarding rules = On.
Assignez‑la via la règle associée (Hosted Outbound Spam Filter Rule) aux utilisateurs/groupes concernés.
Positionnez la priorité de la règle au-dessus de la Default (un nombre plus petit = plus prioritaire).

Vérifier que tout est bien pris en compte

Depuis la boîte affectée, relancez un test d’auto‑transfert (par exemple en vous envoyant un message).
Si nécessaire, exécutez un Message trace dans le nouvel Exchange Admin Center (EAC) pour confirmer la remise côté Microsoft, ou identifier un éventuel blocage côté destinataire.

Vous n’êtes pas administrateur ? Contactez votre équipe IT / l’administrateur Microsoft 365. Aucune règle côté Outlook (OWA/desktop) ne peut contourner le blocage locataire.

Procédure détaillée : Message Trace dans le nouvel EAC

Ouvrez le nouvel EAC puis allez dans Mail flow > Message trace.
Lancez une recherche sur l’expéditeur concerné (la boîte qui auto‑transfère), plage récente (15–60 minutes), et incluez les Failed/Deferred.
Ouvrez un événement relatif à un message auto‑transféré : vous verrez typiquement un statut Dropped/Blocked avec une référence à 5.7.520 ou un libellé indiquant que l’auto‑transfert externe est interdit.
Si le message est Delivered, vérifiez ensuite côté Gmail (répertoire Spam et Filtres et adresses bloquées).

Contrôles rapides & conseils de dépannage

Confirmer l’erreur 5.7.520 AS(7555) : c’est l’indicateur qu’une policy locataire bloque l’auto‑transfert externe.
Tester une autre adresse externe (ex. Outlook.com) : si l’auto‑transfert échoue partout, le blocage est global (tenant), pas spécifique à Gmail.
Gmail : au besoin, inspectez Filtres et adresses bloquées et le dossier Spam, mais dans ce scénario l’erreur est émise avant que Gmail ne voie le message.
Traçabilité : utilisez le Message trace pour prouver où le message s’arrête.
Propagation : après changement de policy, testez à nouveau quelques minutes plus tard.

Bonnes pratiques de sécurité (sans sacrifier le besoin métier)

L’auto‑transfert externe augmente le risque d’exfiltration. Pour rester pragmatique :

Autorisez‑le uniquement pour des utilisateurs précis ou des groupes.
Ajoutez une règle de flux de messagerie (mail flow rule) qui limite l’auto‑transfert à une liste de domaines approuvés.
Surveillez via les traces, l’audit et, si nécessaire, mettez en place des alertes.
Revoyez périodiquement la liste des comptes autorisés et justifiez‑la par un besoin métier vivant (clôturez ce qui n’est plus nécessaire).

Exemple de règle de mail flow (restriction par domaine)

Dans le nouvel EAC, ouvrez Mail flow > Rules puis + Add a rule.
Condition principale : Message type matches → Auto‑forward.
Condition complémentaire : Recipient domain is not → ajoutez la liste de domaines autorisés (ex. exemple.com, partenaire.org).
Action : Reject the message avec une explication claire pour l’expéditeur.
Option : ajoutez une Exception pour un service ou un groupe d’utilisateurs piloté.

Cette règle permet d’activer globalement l’auto‑transfert (policy Outbound sur On) tout en forçant un périmètre de domaines de confiance.

PowerShell pour administrateurs (vérifier, activer, cibler)

Vérifier l’état actuel

# Se connecter à Exchange Online (si nécessaire)
Connect-ExchangeOnline

# Voir le mode d'auto-transfert pour toutes les policies sortantes

Get-HostedOutboundSpamFilterPolicy | Format-Table Name, AutoForwardingMode

Activer l’auto‑transfert sur une policy existante

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On
# ou sur une policy dédiée
Set-HostedOutboundSpamFilterPolicy -Identity "AllowAutoForward" -AutoForwardingMode On

Créer une policy dédiée + règle de ciblage

# Créer une nouvelle policy autorisant l'auto-transfert
New-HostedOutboundSpamFilterPolicy -Name "AllowAutoForward_Sales" -AutoForwardingMode On

# Associer la policy à une règle (ciblez des utilisateurs ou des groupes)

# Exemple indicatif : affecter la policy à un groupe

New-HostedOutboundSpamFilterRule -Name "AllowAutoForward\_Sales" `  -HostedOutboundSpamFilterPolicy "AllowAutoForward_Sales"`
-FromMemberOf "Groupe-Sales"

# Ajuster la priorité (0 = plus prioritaire)

Set-HostedOutboundSpamFilterRule -Identity "AllowAutoForward\_Sales" -Priority 0

Note : adaptez les noms et cibles à votre environnement. Le couplage Policy ↔ Rule permet d’appliquer précisément l’autorisation d’auto‑transfert.

Inventorier les boîtes avec transfert actif au niveau mailbox

# Lister les utilisateurs ayant un transfert configuré côté mailbox
Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited `
  | Where-Object { $_.ForwardingSmtpAddress -ne $null -or $_.DeliverToMailboxAndForward -eq $true } `
  | Select-Object DisplayName, PrimarySmtpAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

Cas particuliers et points d’attention

Boîtes partagées : le mécanisme est identique. Les auto‑transferts de boîtes partagées sont aussi soumis à la policy sortante.
Redirection vs Transfert côté Outlook/OWA : pour l’anti‑spam sortant, ces messages sont tout de même classés « auto‑forward » et donc bloqués si interdit.
Connecteurs sortants, DLP, transport rules : une autre règle peut également bloquer (journalisation, DLP). Si l’auto‑transfert reste bloqué malgré la policy Outbound sur On, inspectez vos mail flow rules et politiques de conformité.
« Automatic – system controlled » : ce mode vise un équilibre sécurité/compatibilité mais peut rester restrictif selon l’évaluation Microsoft. Si vous devez absolument autoriser, passez en On.
POP/IMAP Pull côté Gmail : alternative de contournement (Gmail « Consulter les messages d’autres comptes ») parfois empêchée par la sécurité (IMAP/POP désactivés, exigences MFA/Modern Auth). Préférez corriger à la source via la policy sortante.

Checklist d’implémentation

Valider le besoin : l’auto‑transfert externe est‑il justifié ? Pour combien d’utilisateurs ?
Choisir l’approche : activer globalement (risqué) ou créer une policy ciblée (recommandé).
Configurer la Hosted Outbound Spam Filter Policy (Automatic forwarding = On).
Assigner via la Hosted Outbound Spam Filter Rule aux personnes/équipes autorisées.
Tester (auto‑transfert réel, pas simple envoi manuel).
Tracer dans le nouvel EAC si un doute persiste.
Encadrer avec des règles de mail flow (liste blanche de domaines, exceptions, message de rejet explicite).
Surveiller (audits périodiques, revue des comptes autorisés, vérification que la pratique reste nécessaire).

FAQ rapide

« Je vois l’option Transférer dans Outlook, pourquoi ça ne marche pas ? »

Parce que l’option côté boîte et les règles Outlook/OWA génèrent des messages classés auto‑transfers. S’ils sont interdits au niveau du tenant, ils seront bloqués en sortie (5.7.520 AS(7555)).

« Pourquoi le transfert manuel marche‑t‑il ? »

Car il s’agit d’une action explicite de l’utilisateur. Exchange ne le classe pas comme auto‑transfert. Il n’est donc pas concerné par la restriction de la policy sortante.

« Et si je ne veux autoriser que certains domaines de destination ? »

Laissez la policy Outbound sur On puis ajoutez une règle de mail flow qui bloque Auto‑forward sauf vers la liste de domaines approuvés. Vous combinez ainsi fonctionnalité et maîtrise du risque.

« Combien de temps pour que ça prenne effet ? »

Les changements de policy prennent effet rapidement, mais laissez quelques minutes et refaites un test réel d’auto‑transfert.

« Puis‑je tout faire sans droits d’admin ? »

Non. Sans droits d’administrateur Microsoft 365, vous ne pouvez ni modifier les policies sortantes ni créer des règles d’assignation. Contactez l’IT.

Exemples concrets de tests

Test 1 : depuis la boîte A (Outlook pro), envoyez un e‑mail à elle‑même. Si l’auto‑transfert vers Gmail (B) est actif et autorisé, B le reçoit. Sinon, NDR 5.7.520 côté A.
Test 2 : changez temporairement la policy Outbound de A en On (ciblée sur le seul compte A), attendez 5–10 minutes, refaites le Test 1.
Test 3 : remplacez Gmail par un autre domaine externe. Si tout échoue en auto‑transfert, c’est bien la policy (et non le destinataire) qui bloque.

Modèle de communication à l’utilisateur final

Pour limiter les tickets récurrents, vous pouvez diffuser un message type :

Objet : À propos du transfert automatique d’e‑mails vers des adresses externes
Message : Par défaut, l’auto‑transfert vers des adresses externes (ex. Gmail) est bloqué pour des raisons de sécurité (prévention des fuites). Si votre activité l’exige, l’IT peut l’autoriser de façon ciblée sur demande justifiée. Les transferts manuels restent possibles.

Résumé opérationnel

L’erreur 550 5.7.520 AS(7555) signifie que votre organisation n’autorise pas l’auto‑transfert externe.
La correction consiste à activer l’auto‑transfert dans la Hosted Outbound Spam Filter Policy, idéalement via une policy dédiée et ciblée.
Les règles Outlook/OWA n’y changeront rien tant que la policy locataire interdit l’auto‑transfert.
Après activation (ou création d’une policy ciblée), la fonction Outlook → Gmail refonctionne normalement.

Guide pas‑à‑pas (condensé) pour l’administrateur

Aller à Microsoft 365 Defender > Email & collaboration > Policies & rules > Threat policies > Anti‑Spam.
Ouvrir Anti‑Spam outbound policies (Default ou nouvelle policy) > Edit protection settings.
Régler Automatic forwarding rules sur On.
(Recommandé) Créer une policy dédiée + rule ciblant uniquement les utilisateurs/groupes autorisés. Placer la priorité de cette règle au‑dessus de la Default.
Valider via un test réel et un Message trace.
Encadrer avec des règles de mail flow (liste blanche de domaines) si besoin.

Conclusion

Dans un tenant Microsoft 365 moderne, l’auto‑transfert externe est fréquemment bloqué par défaut. Cela explique l’impossibilité d’auto‑transférer d’Outlook vers Gmail malgré des réglages côté Outlook qui « semblent » corrects. La solution est locataire : ajustez la Hosted Outbound Spam Filter Policy (en On) et, idéalement, limitez cette autorisation à un périmètre maîtrisé. Une fois appliqué, l’auto‑transfert Outlook → Gmail fonctionne à nouveau, tout en restant sous contrôle.

Annexe : tout‑en‑un (copier/coller rapide)

💡 À faire (admin M365)
1) Defender > Email & collaboration > Policies & rules > Threat policies > Anti‑Spam
2) Anti‑Spam outbound policies (Default) > Edit protection settings
3) Automatic forwarding rules = On (ou policy dédiée ciblée)
4) Tester et tracer dans le nouvel EAC
5) Option : mail flow rule pour limiter aux domaines approuvés

🧪 PowerShell (extraits)
Connect-ExchangeOnline
Get-HostedOutboundSpamFilterPolicy | ft Name, AutoForwardingMode
Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On
New-HostedOutboundSpamFilterPolicy -Name "AllowAutoForward\_Sales" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "AllowAutoForward\_Sales" -HostedOutboundSpamFilterPolicy "AllowAutoForward\_Sales" -FromMemberOf "Groupe-Sales"
Set-HostedOutboundSpamFilterRule -Identity "AllowAutoForward\_Sales" -Priority 0

👀 Vérifier

* NDR 550 5.7.520 AS(7555) = blocage auto‑forward sortant
* Message trace = Delivered ou Dropped/Blocked
* Gmail : Spam et Filtres (pour lever un doute)

Résultat : après activation de l’auto‑transfert externe au niveau de la stratégie anti‑spam sortante (ou création d’une stratégie dédiée, prioritaire et ciblée), l’auto‑transfert Outlook → Gmail fonctionne normalement, sans exposer le tenant à un risque d’exfiltration incontrôlé.