Se l’invio da Microsoft 365 verso domini esterni fallisce con “554 5.7.1 … blocked using bl.spamcop.net”, è probabile che un IP del pool di uscita (es. 40.107.20.0/24) sia finito nella block‑list SpamCop. Qui trovi come riconoscere il problema, risolverlo rapidamente e prevenire nuove ricadute.
Cos’è il blocco SpamCop sugli IP di Microsoft 365
SpamCop è una block‑list in tempo quasi reale che include indirizzi IP segnalati per invii sospetti o spam. Quando un IP di uscita di Microsoft 365 entra in questa lista, i server destinatari che consultano bl.spamcop.net possono rifiutare la connessione SMTP in fase di delivery. Poiché Microsoft utilizza infrastrutture condivise, il blocco può interessare più tenant contemporaneamente, specialmente se la segnalazione riguarda più IP della stessa subnet (ad esempio l’intera 40.107.20.0/24).
Sintomi e messaggi di errore tipici
Il segnale più evidente è un NDR (Non‑Delivery Report) generato subito o poco dopo il tentativo d’invio. Esempi realistici di messaggi d’errore:
554 5.7.1 Service unavailable; Client host [40.107.20.45] blocked using bl.spamcop.net; See: bl.spamcop.net
Talvolta l’NDR riporta ulteriori indicazioni del server destinatario, ma il punto chiave resta l’uso di bl.spamcop.net per bloccare la sorgente. Altri indizi utili:
- Incremento improvviso del tasso di rimbalzo (bounce rate) verso domini che consultano SpamCop.
- Distribuzione del problema su più mittenti o gruppi di distribuzione, non limitata a un singolo account.
- Assenza di pattern specifici di contenuto: il rifiuto avviene prima della consegna, spesso in base all’IP source.
Perché accade
Segnalazioni di spam e reclami recenti
SpamCop inserisce un IP in lista quando riceve un certo numero di reclami recenti o rileva invii verso trappole antispam. Le segnalazioni possono accumularsi velocemente se un attore compromesso invia grandi volumi o se inoltri automatici verso l’esterno trasferiscono messaggi indesiderati (o phishing) originati altrove.
Infrastruttura condivisa dei pool Microsoft
Gli IP coinvolti fanno parte di pool di uscita condivisi. Ciò comporta due conseguenze cruciali:
- Il singolo tenant non controlla l’IP e non può richiedere il delisting direttamente a SpamCop come proprietario dell’intervallo.
- Un abuso generato da un altro tenant che transita sullo stesso IP può influenzare la reputazione e causare rimbalzi anche ai tuoi messaggi perfettamente legittimi.
Impatto operativo e rischi per il business
Anche un blocco di poche ore può:
- Interrompere comunicazioni critiche con clienti e partner.
- Innescare re‑invii manuali, duplicazioni e disallineamenti tra sistemi.
- Generare perdita di fiducia commerciale se il destinatario associa i tuoi invii allo spam.
- Amplificare il rischio di ricaduta se non si rimuove la causa (compromissione, inoltri abusivi, dispositivi o app SMTP esposti).
Come verificare rapidamente se il tuo tenant è coinvolto
Prima di aprire un ticket, alcune verifiche interne accorciano drasticamente i tempi di diagnosi:
- Trace dei messaggi nell’Exchange admin center (EAC) per un intervallo che copra almeno le ultime 24–48 ore. Filtra per Status = Failed e cerca la stringa
spamcopnegli errori. - Quarantine & Explorer (Defender for Office 365) per rilevare attività anomale, picchi di invio o pattern di spam outbound.
- Log applicativi di eventuali dispositivi o applicazioni che usano SMTP AUTH (scanner, ERP, CRM, servizi di notifica).
- Revisioni delle regole di posta utente: inoltri automatici esterni, regole “reply‑with” non desiderate, redirect verso caselle pubbliche.
Esempi utili di comandi PowerShell
Se preferisci verificare via PowerShell (Exchange Online Management), questi esempi possono aiutare:
# Cerca errori con riferimenti a SpamCop nelle ultime 48 ore
$start = (Get-Date).AddHours(-48)
$end = Get-Date
Get-MessageTrace -StartDate $start -EndDate $end -Status Failed |
Where-Object { $_.ErrorMessage -match "spamcop|bl\.spamcop\.net" } |
Format-Table Received, SenderAddress, RecipientAddress, Subject, ErrorMessage -Auto
Ottieni maggior dettaglio per un singolo messaggio
Get-MessageTraceDetail -MessageTraceId -RecipientAddress
Controlla la modalità di inoltro esterno nella policy antispam in uscita
Get-HostedOutboundSpamFilterPolicy | Format-List Name, AutoForwardingMode
Verifica se SMTP AUTH è disabilitato globalmente (buona pratica)
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Esempio per disabilitare SMTP AUTH per un utente specifico (valutare prima l'impatto)
Set-CASMailbox -Identity -SmtpClientAuthenticationDisabled $true Procedura operativa consigliata
Questa è la sequenza di azioni che massimizza la probabilità di un rientro rapido, allineata al funzionamento dei pool di uscita Microsoft.
| Passo | Cosa fare | Perché serve |
|---|---|---|
| 1. Verifica interna | Controllare log di invio, report Quarantine/Explorer e configurazione antispam per escludere che il proprio tenant stia originando spam o bulk mail non conformi. | Se la causa è un’infezione o un inoltro non autorizzato, la lista si ripeterà dopo l’eventuale rimozione. |
| 2. Aprire un ticket a Microsoft 365 | Come Global Admin, aprire una richiesta di supporto (service request) nell’interfaccia di amministrazione Microsoft 365. | Solo Microsoft può contattare SpamCop in veste di proprietaria dell’intervallo IP e fornire le prove necessarie per la cancellazione. |
| 3. Fornire dati al supporto | Allegare: ID messaggi, header NDR completi, intervallo temporale, eventuali IP coinvolti, numero di rimbalzi. | Riduce il tempo di diagnosi e consente al back‑end di correlare l’evento con altre segnalazioni. |
| 4. Escalation back‑end | Il supporto Microsoft passa il caso al team di Deliverability, che coordina con SpamCop la rimozione dell’intera subnet o dei singoli IP. | La rimozione manuale da parte di un utente non è possibile su IP di proprietà Microsoft. |
| 5. Monitoraggio | Continuare a monitorare NDR e report di recapito per 24–48 ore; la de‑list può richiedere fino a qualche ora dopo la conferma. | SpamCop cancella automaticamente dopo ~24 h senza nuovi reclami, ma un’escalation accelera il processo. |
Come aprire una richiesta di supporto efficace
Nell’Admin Center, crea un ticket con una descrizione chiara e orientata ai dati. Esempio di traccia che puoi adattare:
Oggetto: Blocchi outbound su bl.spamcop.net da IP Microsoft 365
Descrizione sintetica:
- Da <data/ora UTC> stiamo ricevendo NDR "554 5.7.1 ... blocked using bl.spamcop.net".
- IP osservati nei bounce: 40.107.20.45, 40.107.20.56 (pool 40.107.20.0/24).
- Volume stimato rimbalzi: <numero> in <ore>.
- Verifiche interne: nessuna evidenza di invii anomali, no picchi da Explorer/Quarantine, inoltri esterni limitati.
Richiesta:
- Verifica reputazione IP a livello Microsoft e coordinamento con SpamCop per delisting dell’IP/subnet.
Allegati:
- 5 NDR completi (con header).
- CSV con ID messaggi e orari (UTC).
- Eventuali screenshot di trace/Explorer.
Cosa aspettarsi dopo l’escalation
- Il team di Deliverability verifica pattern di reclami e l’aderenza del pool alle policy, quindi apre un canale diretto con SpamCop.
- Se l’evento è circoscritto, può essere rimosso un singolo IP; in caso di impatto ampio, si valuta l’intera subnet.
- Una volta rimosso il blocco, la normale consegna può riprendere con gradualità: non è insolito vedere un mix di esiti per alcune ore.
Mitigazioni temporanee da valutare con cautela
Quando l’impatto è critico, potresti voler ridurre il danno mentre l’escalation procede. Queste opzioni comportano pro e contro:
- Contattare i destinatari chiave per concordare un canale alternativo temporaneo (PEC, portale, SFTP, ticketing) per documenti urgenti. Pro: zero impatto sulla reputazione. Contro: overhead operativo.
- Richiedere agli amministratori destinatari un’eccezione temporanea (allowlist) per i tuoi domini/indirizzi. Pro: sblocco selettivo. Contro: non sempre possibile e non risolve altri domini.
- Instradare parte del traffico tramite uno smart host di terze parti. Pro: può aggirare il blocco. Contro: richiede aggiornare SPF, gestire DKIM/DMARC in quel provider ed è facile introdurre disallineamenti, aumentando i rimbalzi altrove. Usalo solo se hai già una piattaforma di invio transazionale affidabile e ben integrata.
Nota: non esistono IP “dedicati” di Microsoft 365 per l’uscita standard del tenant; l’uso di connettori outbound verso terzi sposta su di te la responsabilità di autenticazione e reputazione.
Analisi forense minima indispensabile
Per evitare ricadute, esegui una breve indagine tecnica:
- Account compromessi: controlla anomalie di login (origini geografiche inattese), spike di invii, regole di inoltro aggiunte di recente. Forza il reset delle credenziali e la sign‑out dalle sessioni.
- App e dispositivi: inventaria gli “SMTP submitter” (scanner multifunzione, IoT, software legacy). Verifica se usano SMTP AUTH con password deboli o hard‑coded.
- Inoltri esterni: riduci o blocca l’auto‑forwarding non necessario; i flussi di inoltro sono tra le principali cause di segnalazioni indirette.
- Contenuti: se usi sistemi automatici (newsletter, notifiche), rivedi frequenza, target e igiene delle liste. Rimbalzi cronici e reclami pesano sulla reputazione dei pool.
Buone pratiche per prevenire ricadute
Autenticazione dei domini
- SPF: includi correttamente l’host di Microsoft 365 (es. record con
include:spf.protection.outlook.com) ed evita catene di include troppo profonde. Termina con un-allo~allconsapevole. - DKIM: abilita la firma sui domini di invio e verifica la rotazione periodica delle chiavi. Assicurati che eventuali smart host esterni non rimuovano o alterino la firma.
- DMARC: imposta una policy coerente con la tua maturità (
p=noneper monitoraggio,quarantineorejectquando sei pronto). Usa i report aggregati (rua) per analizzare abusi e allineamenti.
Controllo dei flussi di inoltro
- Riduci l’automazione verso caselle esterne. Dove necessario, usa policy esplicite e allowlist puntuali.
- Monitora i volumi di inoltro per utente e genera avvisi quando superano soglie fisiologiche.
Protezione da compromissione account
- Abilita MFA per tutti gli utenti, inclusi service account e account di automazione.
- Disabilita o limita i protocolli legacy e l’uso di SMTP AUTH dove non strettamente necessario.
- Applica Conditional Access e risk‑based policies per bloccare login anomali.
- Imposta alert su picchi di invio e su creazione/modifica di regole di inoltro.
Revisione di permessi, deleghe e app SMTP
- Rivaluta send‑as/send‑on‑behalf ampie: più ampio il perimetro, maggiore il rischio di abuso.
- Segrega gli account delle applicazioni su OU/gruppi dedicati, con credenziali ruotate e inventariate.
Policy antispam in uscita
- Configura la Hosted Outbound Spam Filter Policy con limiti ragionevoli di invio e azioni chiare in caso di superamento.
- Abilita le notifiche agli amministratori quando un utente è spostato nel pool a rischio o viene limitato.
Esempi di header e come leggerli
Quando alleghi gli NDR al ticket, includi sempre gli header completi. Alcuni campi utili e cosa osservare:
- Received: identifica i passaggi SMTP e l’IP sorgente visto dal destinatario.
- Diagnostic-Code: contiene il testo “blocked using bl.spamcop.net”.
- Message-ID: utile per correlare indagini tra sistemi.
- Authentication-Results: se presenti, aiutano a escludere problemi di allineamento SPF/DKIM/DMARC non correlati alla lista.
Final-Recipient: rfc822; destinatario@esempio.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx.esempio.com
Diagnostic-Code: smtp; 554 5.7.1 Service unavailable; Client host [40.107.20.45] blocked using bl.spamcop.net
Runbook operativo per helpdesk e SOC
Usa questa check‑list come procedura rapida ogni volta che emergono NDR riferiti a SpamCop:
- Identificazione: raccogli 3–5 NDR recenti da domini diversi; estrai IP, orario UTC, mittente, destinatario, Diagnostic‑Code.
- Conferma d’impatto: esegui un trace su 24–48 ore per quantificare il numero di fallimenti con riferimento a
bl.spamcop.net. - Verifica interna: controlla inoltri esterni, account anomali, app SMTP e volumi outbound.
- Ticket a Microsoft: apri la richiesta con allegati e descrizione standardizzata.
- Comunicazione: informa gli stakeholder interni (IT, supporto, funzioni business) con stato, domini impattati e workaround temporanei.
- Follow‑up: documenta tempi di ripristino, cause radice e azioni preventive adottate.
KPI e osservabilità
Stabilisci indicatori per reagire prima che i clienti ti segnalino il problema:
- Tasso di rimbalzo per dominio e per ora.
- Numero di NDR 5.7.1 che menzionano
spamcop. - Volumi di inoltro esterno per utente e per reparto.
- Alert su picchi di invio outbound oltre soglia.
Errori comuni da evitare
- Agire direttamente su SpamCop: come tenant non proprietario dell’IP, la richiesta non verrà presa in carico.
- Ignorare la causa: anche se Microsoft ottiene il delisting, inoltri abusivi o account compromessi innescheranno nuove segnalazioni.
- Bypass permanenti: creare eccezioni troppo ampie lato destinatario o usare in modo indiscriminato smart host esterni può peggiorare la reputazione generale.
Domande frequenti
È possibile che il problema riguardi solo alcuni destinatari?
Sì. Il blocco impatta i domini che consultano bl.spamcop.net. Altri domini potrebbero continuare a ricevere.
Posso scegliere un IP di uscita diverso all’interno di Microsoft 365?
No, l’assegnazione IP è gestita dai pool Microsoft e non è configurabile dal tenant standard.
Quanto dura mediamente il blocco?
Se cessano le segnalazioni, SpamCop può rimuovere in circa 24 ore; l’escalation Microsoft di solito accelera i tempi.
Il problema è sempre causato da noi?
Non necessariamente. Su infrastrutture condivise, anche attività non riconducibili al tuo tenant possono influenzare l’IP. Tuttavia, resta essenziale escludere responsabilità interne.
Checklist di prevenzione pronta all’uso
- SPF pubblicato e testato; DKIM abilitato su tutti i domini di invio; DMARC con report attivi.
- SMTP AUTH disabilitato per tutti, ri‑abilitato solo dove strettamente necessario e con credenziali robuste.
- Auto‑forwarding esterno disabilitato di default; eccezioni documentate e monitorate.
- MFA obbligatoria, policy di accesso condizionale, alert su comportamenti di invio anomali.
- Outbound spam policy con soglie, azioni e notifiche chiare; revisione trimestrale.
- Inventario degli applicativi di invio (scanner, ERP, CRM) con proprietari, credenziali, server e volumi attesi.
- Processo di post‑incident con lesson learned e piani di remediation tracciati.
Comunicazione verso gli utenti interni
Quando l’impatto è esteso, invia un messaggio sintetico ai team interessati. Ecco un modello adattabile:
Oggetto: Rallentamenti/rimbalzi invio email verso alcuni domini
Stato: incidente in gestione con Microsoft
Dettagli: alcuni messaggi possono fallire con errore "554 5.7.1 ... bl.spamcop.net".
Azione: abbiamo aperto un ticket a Microsoft per il delisting dell’IP. Non inviare re‑try in massa; usare il canale <alternativo> per urgenze.
Aggiornamenti: prossimo update alle <ora> UTC.
In sintesi
Il blocco su SpamCop non richiede azioni dirette sul sito SpamCop da parte del singolo tenant: è Microsoft a dover gestire la richiesta di delisting come proprietaria dei pool IP. Come amministratore, ciò che puoi e devi fare subito è aprire un ticket strutturato, fornire gli NDR completi e i log necessari, mentre in parallelo verifichi che il tuo ambiente non stia contribuendo — anche indirettamente — alla reputazione negativa dell’IP, ad esempio tramite inoltri automatici o account compromessi. Una volta rimosso il blocco, continua a monitorare per 24–48 ore e applica le buone pratiche descritte per ridurre al minimo il rischio di nuove segnalazioni.
Appendice: comandi e controlli rapidi
# 1) Individua rapidamente gli errori SpamCop
$start = (Get-Date).AddHours(-24)
$end = Get-Date
Get-MessageTrace -StartDate $start -EndDate $end -Status Failed |
Where-Object { $_.ErrorMessage -match "bl\.spamcop\.net|spamcop" } |
Select-Object Received, SenderAddress, RecipientAddress, ErrorMessage |
Export-Csv .\NDRSpamCopultime24h.csv -NoTypeInformation -Encoding UTF8
2) Elenco utenti con inoltro esterno attivo
Get-Mailbox -ResultSize Unlimited |
Get-InboxRule | Where-Object { $.RedirectTo -or $.ForwardTo -or $_.ForwardAsAttachmentTo } |
Select-Object MailboxOwnerId, Name, RedirectTo, ForwardTo, ForwardAsAttachmentTo
3) Verifica smart host o connettori outbound
Get-OutboundConnector | Format-Table Name, ConnectorType, SmartHosts, Enabled
4) Stato SMTP AUTH a livello tenant
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
5) Stato SMTP AUTH per un set di utenti
Get-CASMailbox -ResultSize Unlimited |
Select-Object UserPrincipalName, SmtpClientAuthenticationDisabled |
Export-Csv .\SMTPAuthStatus.csv -NoTypeInformation -Encoding UTF8 Applicando questo runbook avrai tempi di risposta più rapidi, comunicazioni più chiare con stakeholders e supporto Microsoft, e un perimetro tecnico più robusto contro gli abusi che portano al blocco su bl.spamcop.net.