Microsoft 365 « 550 5.7.520 ... does not allow external forwarding » : la solution

Ce que ça veut dire

Quelqu'un dans une organisation Microsoft 365 a configuré un transfert automatique (une règle de boîte de réception ou un transfert de boîte mail) vers une adresse extérieure à l'organisation, par exemple une adresse Gmail personnelle. Quand un message est arrivé et que Microsoft 365 a tenté de le transférer, sa stratégie antispam sortante a bloqué le transfert et envoyé un rebond. Microsoft documente ce texte :

5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555)

Le destinataire du rebond peut prêter à confusion : il est envoyé à l'expéditeur d'origine, qui peut être extérieur à l'organisation et n'a rien fait de mal. La correction se fait toujours du côté de l'organisation qui effectue le transfert.

Pourquoi cela arrive

Le transfert automatique vers des adresses externes est une fuite de données classique : les attaquants qui prennent le contrôle d'une boîte mail ajoutent souvent une règle cachée qui leur copie tous les emails. Microsoft le contrôle donc dans la stratégie de filtrage du spam sortant (outbound spam filter policy), avec trois réglages :

• Automatic - System-controlled (par défaut). Depuis 2021, ce réglage équivaut à « Off » pour les nouvelles organisations et pour la plupart des existantes : le transfert est donc bloqué sauf si quelqu'un l'a autorisé.
• On - Forwarding is enabled : le transfert externe est autorisé.
• Off - Forwarding is disabled : le transfert externe est bloqué et produit le rebond 5.7.520.

Deux autres contrôles peuvent aussi bloquer le transfert : les remote domains (domaines distants, avec l'option « Allow automatic forwarding » par domaine externe) et les règles de flux de messagerie (mail flow rules). Quand un contrôle autorise et qu'un autre bloque, c'est le blocage qui l'emporte.

Comment vérifier

1. Vérifiez que le rebond contient 5.7.520 et AS(7555). Notez la boîte qui transfère, indiquée dans le rebond (c'est le destinataire du message d'origine, pas l'adresse finale).
2. Dans le portail Microsoft Defender, ouvrez Email & collaboration > Policies & rules > Threat policies > Anti-spam, ouvrez la stratégie sortante qui s'applique à cet utilisateur et regardez Automatic forwarding rules. Ou en PowerShell :

   Get-HostedOutboundSpamFilterPolicy | Format-List Name,AutoForwardingMode
   Get-HostedOutboundSpamFilterRule | Format-List Name,HostedOutboundSpamFilterPolicy,From,FromMemberOf

3. Listez qui transfère vers l'extérieur avec le rapport Auto forwarded messages du centre d'administration Exchange, et vérifiez la boîte elle-même :

   Get-Mailbox user@yourdomain.com | Format-List ForwardingSmtpAddress,DeliverToMailboxAndForward
   Get-InboxRule -Mailbox user@yourdomain.com | Where-Object {$_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo}

4. Si personne ne se souvient avoir créé la règle, considérez le compte comme piraté avant toute autre chose : voir un compte email piraté envoie du spam.

Comment corriger

Option 1 : ne pas transférer (souvent la meilleure réponse)

Donnez à l'utilisateur un autre moyen d'accès : l'application Outlook sur son téléphone, une boîte partagée ou une délégation. Le transfert a aussi un coût en délivrabilité : les messages transférés échouent souvent au SPF à destination finale et peuvent finir en spam, comme expliqué dans le transfert d'email casse le SPF.

Option 2 : n'autoriser le transfert que pour ceux qui en ont besoin

Ne passez pas la stratégie par défaut sur « On » pour tout le monde. Créez une stratégie sortante personnalisée qui ne s'applique qu'aux utilisateurs ou au groupe autorisés :

New-HostedOutboundSpamFilterPolicy -Name "Allow forwarding" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "Allow forwarding" `
  -HostedOutboundSpamFilterPolicy "Allow forwarding" -From user@yourdomain.com

Vous pouvez faire la même chose dans le portail Defender (créez une stratégie sortante, choisissez les utilisateurs, réglez Automatic forwarding rules sur On - Forwarding is enabled). Réglez explicitement la stratégie par défaut sur Off plutôt que sur « Automatic », pour que le comportement soit clair.

Option 3 : limiter les destinations possibles

Utilisez les remote domains pour n'autoriser le transfert automatique que vers certains domaines partenaires et le bloquer pour le domaine distant par défaut (*). N'oubliez pas qu'un blocage, où qu'il soit, l'emporte sur une autorisation.

Si vous êtes l'expéditeur extérieur

Vous n'avez rien à changer de votre côté : votre email est bien arrivé dans la boîte du destinataire, seul le transfert a échoué. Prévenez le destinataire (par un autre canal) que sa règle de transfert est bloquée, pour qu'il en parle à son administrateur.

Vérifier que c'est corrigé

• Les changements de stratégie peuvent mettre un moment à s'appliquer. Envoyez ensuite un email de test à la boîte qui transfère depuis une adresse extérieure et vérifiez que la copie arrive à l'adresse externe.
• Pour voir à quoi ressemble la copie transférée aux yeux des filtres, faites pointer temporairement le transfert vers l'adresse unique de la page d'accueil de Delivmail : le rapport indique si SPF, DKIM et ARC survivent au transfert.
• Consultez régulièrement le rapport Auto forwarded messages, pour qu'une règle oubliée ou malveillante ne reste pas active.