Guida operativa e di strategia per bloccare mittenti spam e tentativi di impersonation in Exchange Online/Microsoft 365 usando Microsoft Defender: dalla creazione di una policy anti‑spam Inbound, alla protezione contro spoof e impersonation, fino a regole di trasporto, autenticazione e awareness utenti.
Contesto e obiettivo
La minaccia più insidiosa in posta elettronica non è solo lo spam “rumoroso”, ma il phishing mirato che imita nomi, domini o stili comunicativi di colleghi e dirigenti. In molte organizzazioni, i messaggi arrivano da mittenti che sembrano interni ma non lo sono, oppure da domini appena creati che imitano quelli legittimi con typosquatting (es. cont0so.com invece di contoso.com). L’obiettivo di questa guida è fornire un percorso chiaro e ripetibile per bloccare rapidamente indirizzi e domini ostili in ingresso, limitare gli attacchi di impersonation e preservare la continuità del business.
Perché usare una policy anti‑spam Inbound
In Microsoft 365 esistono più modi per fermare mittenti sgraditi. Due in particolare vengono spesso confusi: la policy anti‑spam (Inbound) e la Tenant Allow/Block List (TABL). Comprendere la differenza evita sorprese in produzione.
| Opzione | Ambito d’azione | Pro | Contro | Quando preferirla |
|---|---|---|---|---|
| Policy anti‑spam (Inbound) | Solo posta in ingresso | Granularità per utenti/gruppi; azioni flessibili (reject, quarantine, junk); non modifica la posta in uscita | Richiede gestione di priorità e destinatari | Blocco di indirizzi/domìni ostili senza impattare l’uscita |
| Tenant Allow/Block List | Valida per l’intero tenant | Centralizzata e rapida da applicare | Le voci in block impediscono anche l’invio verso quegli indirizzi/domìni | Uso puntuale, temporaneo o per IOC noti a livello tenant |
| Mail flow rules (Transport Rules) | Pipeline di Exchange | Estrema flessibilità su condizioni e azioni | Manutenzione più complessa; rischio di sovrapposizioni | Casi d’uso speciali e pattern non coperti dalle policy |
Conclusione pratica: per bloccare spam e phishing di falsi mittenti che colpiscono i tuoi utenti, la strada primaria e consigliata è una anti‑spam policy Inbound in Microsoft Defender. La TABL resta utile per esigenze specifiche a livello tenant; le regole di trasporto per scenari particolari.
Procedura rapida nel Microsoft Defender portal
Di seguito la sequenza operativa consigliata da Microsoft per bloccare mittenti o interi domini in ingresso, limitando i rischi di spam e impersonation e senza toccare la posta in uscita.
| Passo | Azione nel Microsoft Defender portal (security.microsoft.com) |
|---|---|
| 1 | Navigare a Email & Collaboration ▸ Policies & Rules ▸ Threat policies ▸ Anti‑spam. |
| 2 | Clic su Create ▸ Inbound per avviare il nuovo anti‑spam policy wizard. |
| 3 | Compilare i dettagli della policy (nome, priorità, utenti/gruppi destinatari). |
| 4 | In Create block entries for domains and email addresses, aggiungere: • singoli indirizzi (es. truffatore@domain.com)• domini interi (es. @domain.com). |
| 5 | Salvare e attivare la policy. Gli invii dai mittenti bloccati verranno rifiutati o reindirizzati in base alle azioni scelte. |
Perché non limitarsi alla Tenant Allow/Block List
- Le voci di blocco nella TABL impediscono anche ai vostri utenti di spedire messaggi verso quegli indirizzi o domini (effetto bidirezionale non sempre desiderato).
- La policy anti‑spam Inbound filtra solo la posta in ingresso, lasciando inalterata l’uscita e riducendo rischi operativi.
Come funziona il blocco in una policy anti‑spam
Una policy anti‑spam Inbound agisce dopo i controlli di reputazione e autenticazione e prima del recapito in mailbox. In base alla configurazione, i messaggi provenienti da indirizzi o domini bloccati possono:
| Azione | Effetto sull’utente | Note operative |
|---|---|---|
| Reject (NDR) | Il messaggio non arriva, il mittente riceve un Non‑Delivery Report (es. 5.7.1) | Scelta netta e trasparente verso l’esterno |
| Quarantine | Il messaggio è trattenuto in quarantena | Consigliata se si vogliono esaminare false positività; governare tramite “Quarantine policy” |
| Move to Junk | Consegna in Posta indesiderata | Meno severa, ma lascia residui di rumore nelle cassette |
| Redirect | Inoltro a una mailbox di analisi | Utile per investigazioni o per SOC |
Best practice: per blocchi definitivi di domini/indirizzi noti malevoli, usa Reject o Quarantine. Per campagne dubbie o transitorie, la quarantena consente di verificare prima di scartare.
Progettare una policy robusta
- Ambito preciso: assegna la policy a gruppi di sicurezza o a destinatari specifici (es. “All Users”, “VIP”, “Finance”). Evita assegnazioni all’intera organizzazione se non necessario.
- Priorità coerente: in presenza di più policy, la priorità determina quale si applica. Mantieni un naming chiaro (es. AS‑INB‑Block‑Domains‑VIP‑P10).
- Eccezioni controllate: separa i “mittenti consentiti” (allow) in una policy specifica con priorità più alta; documenta il motivo.
- Pattern del dominio: per bloccare un’intera radice, inserisci il dominio come indicato nella procedura (es.
@domain.com). Prevedi varianti e typosquatting. - Auditing e ownership: registra chi crea/modifica le policy, con change log e ticket associati.
- Quarantine policy dedicata: definisci chi può vedere, rilasciare o solo visualizzare i messaggi in quarantena per questa policy.
- Fail‑safe: evita di mescolare troppi criteri nella stessa policy: una per blocchi fissi, una per campagne temporanee, una per eccezioni.
Raccomandazioni complementari
Impersonation e spoof protection
Oltre al blocco diretto, riduci la superficie d’attacco abilitando in Anti‑phishing le funzionalità di Spoof intelligence e le regole di Impersonation per domini e personalità chiave (CEO, CFO, HR, IT). Imposta azioni severe (quarantena o reject) per i tentativi di impersonation ad alto rischio. Mantieni aggiornata la lista dei “soggetti” protetti e usa mailbox intelligence ove disponibile per valutare relazioni di invio tipiche.
Autenticazione e-mail
Implementa e verifica DKIM e DMARC per i domini interni ed esterni gestiti. Questo riduce la probabilità che domini esterni possano fingere d’essere i tuoi e offre segnali più affidabili ai motori anti‑phishing. Dove applicabile, assicurati che SPF sia allineato ai tuoi flussi di invio. Imposta DMARC almeno in quarantine per i domini sensibili quando sei pronto, passando a reject dopo la fase di tuning.
Mail flow rules
Per casi specifici crea regole di trasporto su criteri come mittente, header o parole chiave, con azioni delete, quarantine, prepend subject o redirect. Esempi:
| Condizione | Azione | Uso tipico |
|---|---|---|
| Mittente combacia con pattern di typosquatting | Quarantine + notifica al SOC | Bloccare campagne vive con domini appena registrati |
Header Authentication‑Results indica DMARC fail per domini critici | Reject o Quarantine | Protezione aggressiva su brand ad alto rischio |
| Subject o body contiene parole chiave di BEC (es. “bonifico urgente”) | Prepend [Possibile Phishing] + Quarantine | Ridurre Business Email Compromise |
User awareness
La tecnologia regge solo metà del peso. Programma comunicazioni periodiche su come riconoscere il phishing e su come inoltrare i messaggi sospetti al team sicurezza (es. tramite componente aggiuntivo di Report Message). Considera campagne di attack simulation per allenare i comportamenti.
Guida dettagliata alla creazione della policy
- Accesso al portale: apri il Microsoft Defender portal e verifica di avere un ruolo adeguato (es. Security Administrator, Exchange Administrator o ruolo personalizzato con permessi sulle threat policies).
- Sezione anti‑spam: vai in Email & Collaboration ▸ Policies & Rules ▸ Threat policies ▸ Anti‑spam.
- Nuova policy Inbound: Create ▸ Inbound. Assegna un nome descrittivo e imposta la priorità in modo che la policy si applichi prima o dopo altre esistenti.
- Destinatari: specifica utenti, gruppi o domini interni su cui la policy avrà effetto. Filtra i reparti più a rischio (Finance, HR, Procurement) se stai procedendo a fasi.
- Mittenti e domini da bloccare: nella sezione Create block entries for domains and email addresses inserisci indirizzi e domini ostili, ad es.
truffatore@domain.come@domain.com. - Azioni di recapito: scegli tra Reject, Quarantine, Move to Junk o Redirect. Per blocchi conclusivi preferisci Reject o Quarantine.
- Quarantine policy: collega una policy di quarantena che stabilisca chi può rilasciare, con o senza motivazione, e quali notifiche inviare.
- Salva e attiva: conferma e attiva la policy. Prendi nota dell’ora di attivazione per correlare i messaggi nei message trace.
Validazione, monitoraggio e falsi positivi
- Test di convalida: se possibile, chiedi al contatto esterno (non malevolo) di inviare un messaggio di prova da un dominio simile ma legittimo per escludere collisioni. Verifica che non sia impattato.
- Message trace: usa il tracciamento messaggi per confermare che i messaggi dai domini bloccati risultino rifiutati/quarantinati.
- Quarantena: monitora con regolarità le code; analizza i rilasci per capire se servono eccezioni o regole più fini.
- Metriche: registra numero di messaggi bloccati, rilasci, tempo medio di analisi e tasso di falsi positivi. Queste metriche aiutano a giustificare la postura di sicurezza e a tarare le azioni.
Automazione e PowerShell
Per ambienti grandi o per integrazione con i flussi del SOC, automatizza creazione e aggiornamento delle policy via PowerShell. Esempi indicativi (adattali alla tua realtà):
# Connessione (modulo Exchange Online Management)
Connect-ExchangeOnline
Creazione di una content filter policy dedicata al blocco
New-HostedContentFilterPolicy -Name "AS-INB-BlockDomains" ` -BlockedSenders @("truffatore@domain.com")`
-BlockedSenderDomains @("domain.com")
Regola che assegna la policy ai destinatari interessati
New-HostedContentFilterRule -Name "AS-INB-BlockDomains-R" ` -HostedContentFilterPolicy "AS-INB-BlockDomains"`
-RecipientDomainIs @("contoso.com")
Modifica: aggiungere un nuovo dominio ostile
Set-HostedContentFilterPolicy -Identity "AS-INB-BlockDomains" \`
-BlockedSenderDomains @{Add="nuovodominio-ostile.com"} Nota: nomi e parametri possono variare in base al modulo e all’ambiente. Versiona gli script in un repository e proteggine l’accesso.
Errori comuni e come evitarli
- Bloccare via TABL senza considerare l’uscita: il blocco diventa bidirezionale e i tuoi utenti non potranno più scrivere a quei destinatari. Valuta prima se è davvero ciò che vuoi.
- Policy senza quarantena appropriata: i messaggi finiscono in code non presidiate, con rallentamenti o perdite informative. Associa sempre una quarantine policy e un processo di revisione.
- Priorità incoerenti: una policy di allow con priorità più alta può vanificare il blocco. Documenta l’ordinamento e verifica la policy result nei report.
- Regole di trasporto ridondanti: troppe eccezioni complicano la catena decisionale. Mantieni la logica nel minor numero possibile di policy e regole.
- Assenza di tuning DMARC/DKIM: senza segnali di autenticazione robusti, il motore anti‑phish rende più difficile distinguere spoof legittimi (es. inoltri) da reali attacchi.
Piano operativo di messa in sicurezza
- Raccolta IOC: domini, indirizzi, pattern, hash/URL ricorrenti della campagna in corso.
- Creazione policy anti‑spam Inbound: con blocco degli IOC noti e azione quarantena o reject.
- Abilitazione anti‑phishing: spoof intelligence attiva e profili di impersonation su domini/dirigenti sensibili.
- Mail flow rules mirate: su header e keyword specifiche della campagna (durata limitata).
- Autenticazione: verifica SPF, attiva DKIM e DMARC, monitora i report per il tuning.
- Awareness: comunicazione a tutti gli utenti su come segnalare email sospette.
- Monitoraggio e risposta: trace, quarantena, eventuale aggiunta di domini/indirizzi emersi.
- Lessons learned: pulizia delle regole temporanee, aggiornamento dei playbook, metriche.
FAQ pratiche
Bloccare un dominio con @domain.com blocca anche i sottodomini?
Dipende dalla logica di matching adottata nelle impostazioni. Come regola prudenziale, aggiungi anche i sottodomini critici noti (es. @mail.domain.com). Mantieni una lista aggiornata.
È meglio quarantena o reject?
Per comunicazioni certamente malevole usa Reject. Per campagne dubbie o in tuning preferisci Quarantine per consentire analisi e rilasci controllati.
Ho bloccato via TABL e ora non spediamo più a quel dominio, cosa fare?
Valuta se spostare il blocco nella policy anti‑spam Inbound; in alternativa, rimuovi dalla TABL e replica la logica nella policy Inbound.
Le policy si applicano a tutti immediatamente?
La propagazione può richiedere un breve intervallo. Pianifica la finestra di attivazione e monitora trace/quarantena poco dopo.
Come gestire i dirigenti molto esposti?
Proteggili con regole di Impersonation, monitora più frequentemente la loro quarantena e imposta alert mirati.
Checklist pronta all’uso
- Ruoli e permessi confermati per la gestione di Threat Policies.
- Lista IOC consolidata e validata.
- Policy anti‑spam Inbound creata con mittenti/domìni bloccati.
- Quarantine policy associata e proprietario definito.
- Anti‑phishing: spoof intelligence e impersonation attivi su domini/VIP.
- Mail flow rules temporanee per pattern specifici (con data di scadenza).
- DKIM/DMARC operativi per i domini interni; SPF aggiornato.
- Canale di segnalazione utenti funzionante (add‑in o indirizzo dedicato).
- Monitoraggio: message trace, report quarantena, metri chiave.
- Piano di revisione periodica e rimozione delle eccezioni inutilizzate.
Ulteriori raccomandazioni utili
- Impersonation & spoof protection
Abilitare le funzionalità di Anti‑phishing ▸ Spoof intelligence e creare regole di Impersonation per proteggere domini e dirigenti sensibili. - Autenticazione e‑mail
Implementare DKIM e DMARC per ridurre le probabilità che domini esterni possano fingere d’essere i vostri. - Mail flow rules (Transport Rules)
Per casi specifici si possono creare regole con criteri su mittente, header o parole chiave, applicando azioni come delete, quarantine o prepend subject. - User awareness
Informare periodicamente gli utenti su come riconoscere tentativi di phishing e come inoltrare i messaggi sospetti al team sicurezza.
Conclusioni
Bloccare mittenti e domini spam in Exchange Online/Microsoft 365 è efficace se inserito in una strategia coerente: una policy anti‑spam Inbound per i blocchi mirati, anti‑phishing con spoof e impersonation per fermare i casi più subdoli, autenticazione DKIM/DMARC per rinforzare i segnali, mail flow rules per eccezioni e campagne, e soprattutto awareness degli utenti. Con questi elementi—e con una buona disciplina su priorità, quarantena e metriche—le email provenienti dagli indirizzi o domini indicati verranno fermate prima di raggiungere le cassette, riducendo drasticamente il rischio di spam e impersonation senza limitare la posta in uscita.
Appendice: differenze chiave in sintesi
| Criterio | Anti‑spam Inbound | Tenant Allow/Block List | Mail flow rules |
|---|---|---|---|
| Direzione impatto | Ingresso | Ingresso + potenziale impatto su uscita | Ingresso/uscita in base alla condizione |
| Granularità destinatari | Alta | Bassa (tenant‑wide) | Altissima |
| Manutenibilità | Buona | Ottima per IOC globali | Media/complessa |
| Uso ideale | Blocchi mirati per utenti/gruppi | IOC globali, temporanei | Pattern personalizzati e casi limite |
Suggerimento finale: conserva una matrice che mappi ogni blocco alla ragione (ticket, incidente, scadenza) e alla sede (policy Inbound, TABL, regola). Questo evita sovrapposizioni e mantiene la postura pulita nel tempo.