Outlook (Microsoft 365) non inoltra verso Gmail e ricevi l’NDR “550 5.7.520 Access denied, Your organization does not allow external forwarding. AS(7555)”? Qui trovi causa, soluzione amministrativa passo‑passo, verifiche e alternative sicure.

Panoramica del problema

Un utente con cassetta postale in Microsoft 365 (Outlook) desidera inoltrare automaticamente tutti i messaggi verso il proprio indirizzo Gmail personale. L’inoltro è stato attivato da Impostazioni › Posta › Inoltro dell’utente, l’indirizzo di destinazione è corretto, ma nessuna e‑mail arriva su Gmail. Il server di Microsoft 365 genera un NDR con l’errore:

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

Questo messaggio indica che nel tenant è attiva una protezione che impedisce l’auto‑forwarding verso domini esterni. Non si tratta quindi di un problema dell’utente, ma di una impostazione amministrativa.

Cosa significa l’errore 550 5.7.520 AS(7555)

Il codice 5.7.520 viene restituito quando l’organizzazione ha disabilitato l’inoltro automatico verso destinatari esterni al dominio. La ragione è di sicurezza: prevenire la fuoriuscita involontaria di dati (data loss) e l’uso di cassette postali compromesse come sorgente di spam. Il blocco agisce a monte del messaggio: anche se la regola di inoltro è presente nella cassetta postale, il sistema scarta la consegna verso l’esterno.

Causa accertata

Nel tenant è abilitata la protezione predefinita Anti‑Spam Outbound Policies (Default) di Microsoft 365 Defender/Exchange Online Protection, che blocca per impostazione prudenziale l’inoltro automatico verso domini esterni. È una scelta sensata per ridurre i rischi; tuttavia, se l’inoltro è necessario e ammesso dalle policy aziendali, l’amministratore può modificarla o applicare un’eccezione mirata.

Soluzione amministrativa, passo‑passo (UI moderna)

Prerequisiti: servono diritti amministrativi adeguati (ad es. Security Administrator o Exchange Administrator). Gli utenti finali non possono cambiare le impostazioni anti‑spam di organizzazione.

1. Accedere al portale Microsoft 365 Defender: https://security.microsoft.com/
2. Aprire Email & collaboration › Policies & rules › Threat policies › Anti‑Spam.
3. Selezionare Anti‑Spam outbound policies (Default) e fare clic su Edit protection settings.
4. Nella sezione Automatic forwarding rules scegliere:
   • On – Forwarding is enabled (abilita l’auto‑forwarding), oppure
   • Automatic – system controlled (controllo automatico gestito dal sistema).
   Per una sblocco esplicito e prevedibile si consiglia On. L’opzione Automatic può variare in base a criteri Microsoft e non sempre consente l’inoltro verso tutti i domini.
5. Salvare le modifiche e attendere la propagazione (di solito pochi minuti).
6. Eseguire un test: inviare una e‑mail verso la cassetta postale che inoltra e verificare che il messaggio arrivi su Gmail.

Consiglio operativo: se l’inoltro deve valere solo per pochi utenti, crea una nuova outbound policy con l’inoltro su On e assegnala esclusivamente a quegli utenti/gruppi (sezione Assignments). Mantieni la policy Default più restrittiva per tutti gli altri.

Procedura alternativa: policy mirata per un sottoinsieme di utenti

Per rispettare il principio del least privilege, invece di sbloccare globalmente l’inoltro, puoi creare una policy outbound dedicata:

1. Nel portale Microsoft 365 Defender vai su Anti‑Spam › Policies › Outbound e seleziona Create policy.
2. Assegna un nome chiaro (es.: Allow External Forwarding – Marketing).
3. Imposta Automatic forwarding rules = On.
4. Nella sezione Assignments, seleziona Users, groups o domains a cui applicare l’eccezione.
5. Salva. La nuova policy ha priorità più alta rispetto al Default e sbloccherà l’inoltro solo per i soggetti assegnati.

Verifica e diagnostica: come capire dove si ferma il messaggio

Message Trace in Exchange Admin Center

1. Apri Exchange admin center (EAC) dal portale di amministrazione.
2. Vai a Mail flow › Message trace.
3. Imposta un intervallo temporale breve (es. ultime 24 ore) e cerca per mittente o destinatario originario.
4. Analizza i risultati: quando il blocco è dovuto all’auto‑forwarding, vedrai esiti in cui il messaggio viene scartato o non recapitato per policy di sicurezza. Il dettaglio dell’evento e il delivery status aiutano a confermare la causa.

Controlli lato Gmail

• Verifica la cartella Spam e le schede (Principale, Social, Promozioni): i messaggi inoltrati potrebbero essere classificati in modo diverso.
• In Impostazioni › Filtri e indirizzi bloccati controlla se esistono regole che Eliminano o Ignorano Posta in arrivo per il mittente o il dominio.
• Se i messaggi non arrivano, torna al Message trace: se l’NDR 5.7.520 è a monte, è inutile cercare solo in Gmail, perché il blocco avviene prima che il messaggio lasci Microsoft 365.

Tabella di riepilogo: responsabilità, motivazioni, verifiche e alternative

Aspetto	Dettagli
Chi può intervenire	Solo un amministratore del tenant Microsoft 365 può modificare le policy anti‑spam. Gli utenti finali devono contattare l’IT/Help Desk.
Perché esiste la policy	Riduce il rischio di data exfiltration e l’abuso di cassette postali compromesse come relay di spam; inoltre facilita la conformità a normative e linee guida interne.
Verifiche utili prima di aprire un ticket	• Esegui un Message Trace dall’EAC per vedere se il messaggio è bloccato. • Controlla in Gmail eventuali filtri che spostano o cancellano i messaggi. • Assicurati che la regola di inoltro dell’utente sia configurata correttamente (indirizzo, mantieni copia in cassetta, ecc.).
Alternative se l’azienda non sblocca l’auto‑forward	• Recupero da Gmail via POP/IMAP (solo se protocolli abilitati e conformi alle policy). Nota: in molte organizzazioni POP/IMAP sono disattivati o limitati. • Inoltro verso caselle interne (stesso dominio/tenant) e accesso a quella casella da Gmail con modalità consentite dall’IT (es. client/app o account delegato).

Passi concreti per l’IT: dalla diagnosi alla soluzione

1. Riproduci il problema: crea o identifica una cassetta postale con regola di inoltro attiva verso Gmail; invia un messaggio di prova.
2. Raccogli evidenze: salva NDR 5.7.520 e screenshot della regola dell’utente (senza dati sensibili).
3. Conferma la causa: esegui Message trace e verifica che il blocco sia attribuibile all’Outbond Anti‑Spam.
4. Decidi la strategia:
   • Necessità permanente e legittima per un team ristretto → crea policy mirata per quel gruppo.
   • Esigenza transitoria → valuta una eccezione temporanea con revisione programmata.
   • Organizzazione non compatibile con inoltro esterno → adotta un’alternativa (accesso condiviso, caselle interne, client approvati).
5. Implementa: abilita On nella policy corretta (Default o mirata) e salva.
6. Verifica end‑to‑end: nuovo invio di test, controllo arrivo su Gmail e trace pulito.
7. Documenta: annota chi, cosa e perché; imposta un review date per eventuali eccezioni.

PowerShell: verifica e modifica rapide

Per amministratori che preferiscono la shell, ecco comandi utili in Exchange Online PowerShell (dopo Connect-ExchangeOnline):

# Elenca policy outbound anti‑spam e lo stato di AutoForwarding
Get-HostedOutboundSpamFilterPolicy | Format-Table Name, AutoForwardingMode

Abilita l'auto-forwarding sulla policy Default

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode On

Opzione alternativa: controllo automatico

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode Automatic 

Nota: per una gestione granulare, crea una nuova policy (New-HostedOutboundSpamFilterPolicy) e assegnala a utenti/gruppi tramite interfaccia; in ambienti complessi è consigliabile gestire priorità e ambiti con attenzione, mantenendo il Default restrittivo.

Controlli avanzati in caso di esito ancora negativo

• Regole di flusso posta (Transport Rules): l’organizzazione potrebbe avere regole che bloccano inoltri verso domini specifici. Rivedi Mail flow › Rules.
• Remote Domains: in rari casi l’impostazione del Remote domain “Default” può disabilitare gli inoltri automatici. Verifica che non sia impostato un blocco.
• Tipo di regola utente: distingui tra forwarding a livello di cassetta postale e regola Inbox; entrambe sono soggette al blocco, ma è utile sapere cosa stai testando.
• Loop e inoltri a catena: accertati che non si creino cicli (Gmail → altra casella → di nuovo verso l’organizzazione), altrimenti l’invio può essere interrotto o classificato come anomalo.
• Throttling/limitazioni: volumi elevati di inoltri possono attivare protezioni aggiuntive; se il caso d’uso prevede un alto volume, valuta alternative architetturali.

Alternative pragmatiche quando l’inoltro esterno non è consentito

Non tutte le organizzazioni vogliono (o possono) abilitare l’auto‑forwarding esterno. Ecco approcci comunemente accettati:

1. Casella secondaria interna: inoltra verso una cassetta interna (stesso tenant). L’utente può accedervi dai client supportati o da Gmail come account aggiuntivo solo se l’IT lo consente.
2. Recupero da Gmail via POP/IMAP (con forti caveat):
   • In Gmail: Impostazioni › Account e importazione › Controlla la posta da altri account (POP3) → Aggiungi un account.
   • Server POP tipico per Microsoft 365: outlook.office365.com, porta 995, SSL obbligatorio.
   • Importante: questa strada è praticabile solo se l’organizzazione consente POP/IMAP e le modalità di autenticazione compatibili con il servizio di recupero di Gmail. In molti tenant moderni i protocolli legacy sono disabilitati o limitati.
3. Accesso delegato o condivisione: anziché inoltrare, abilita l’accesso a una cassetta tecnica/di team direttamente dai client aziendali o approvati.

Sicurezza e conformità: buone pratiche

• Principio del minimo privilegio: crea eccezioni solo per utenti/gruppi che ne hanno effettivo bisogno; usa policy mirate, non modifiche globali indiscriminate.
• Revisione periodica: imposta una data di scadenza e un controllo trimestrale per le eccezioni di inoltro.
• Monitoraggio: attiva alert su regole di inoltro create/modificate, in particolare se puntano a domini esterni.
• Formazione: spiega ai dipendenti i rischi di inoltro esterno e quando è vietato dalle policy interne.
• DLP e sensibilità: abbina l’eccezione a criteri DLP e etichette di riservatezza; valuta la rimozione di allegati sensibili in inoltro.

FAQ

Posso abilitare l’inoltro solo verso Gmail e bloccarlo verso altri domini?

Sì, creando una policy dedicata e limitandone l’ambito a specifici utenti e, se serve, combinandola con regole di flusso posta che consentono solo determinati domini di destinazione.

Quanto tempo impiega la modifica a propagarsi?

Di norma pochi minuti. In ambienti estesi possono volerci diversi minuti in più. Esegui un nuovo invio di test dopo aver salvato la policy.

Serve davvero abilitare “On” anziché “Automatic”?

“On” garantisce esplicitamente l’abilitazione dell’auto‑forwarding. “Automatic” lascia al sistema la gestione; in alcuni tenant potrebbe non consentire l’inoltro verso tutti i domini. Se devi risolvere subito, usa “On”.

L’utente può cambiare qualcosa da solo?

No. L’errore 5.7.520 è dovuto a una policy di organizzazione. Solo un amministratore può sbloccare o creare un’eccezione.

Checklist veloce

• ☑ Confermato NDR 550 5.7.520 AS(7555).
• ☑ Eseguito Message trace e identificata la policy di blocco.
• ☑ Deciso ambito (globale vs mirato per utenti/gruppi).
• ☑ In Anti‑Spam outbound policies impostato Automatic forwarding rules = On (o Automatic).
• ☑ Test riuscito con messaggio recapitato su Gmail.
• ☑ Documentata l’eccezione e impostata revisione periodica.

Glossario minimo

• NDR: Non‑Delivery Report, notifica di mancata consegna.
• Auto‑forwarding: inoltro automatico dei messaggi in arrivo verso un altro indirizzo.
• EOP: Exchange Online Protection, livello di protezione anti‑spam/anti‑malware di Microsoft 365.
• Outbound policy: criteri che regolano la posta in uscita dall’organizzazione.

Esito del caso reale

Dopo aver abilitato l’auto‑forwarding nella Anti‑Spam outbound policy, l’utente ha confermato: “That worked!”. Altri partecipanti, colpiti dallo stesso errore 5.7.520, hanno risolto con la medesima procedura. La lezione appresa: se Outlook non inoltra verso Gmail e compare 5.7.520, occorre intervenire sulla policy anti‑spam in Microsoft 365 Defender.

In sintesi (per chi ha fretta)

Problema: l’inoltro automatico da Outlook (Microsoft 365) verso Gmail non funziona; NDR 550 5.7.520 AS(7555).

Causa: blocco per impostazione della Anti‑Spam Outbound Policy (Default).

Fix: da Microsoft 365 Defender › Anti‑Spam › Outbound, impostare Automatic forwarding rules su On (o Automatic), quindi testare.

Best practice: preferire policy mirate per gruppi/utenti, con revisione periodica e monitoraggio.

---

Nota finale per i team IT: quando abiliti eccezioni di forwarding, abbina sempre il cambiamento a log e controlli: chi può inoltrare, verso quali domini, per quanto tempo. Meno è meglio: concedi solo ciò che serve, a chi serve, per il tempo necessario.