Se in Microsoft 365 le e‑mail di un utente vengono respinte con l’avviso “mittente non riconosciuto/sospetto spam”, questa guida spiega cause, procedura di sblocco in Defender (Restricted entities), checklist operative, best practice (SPF/DKIM/DMARC, throttling) e come prevenire ricadute.
Blocco dell’invio di e‑mail in Microsoft 365 (“mittente non riconosciuto”)
Panoramica del problema
Un utente (ad esempio, sales) ha inviato un mail‑merge a circa 50 contatti. Dal giorno successivo tutte le sue e‑mail – persino quelle interne – vengono rifiutate con un errore simile a:
«This message couldn’t be delivered because the sending email address was not recognized as a valid sender … suspected of sending spam».
In pratica, Microsoft 365 ha classificato l’account come mittente sospetto e ha imposto un blocco in uscita. Il blocco è di identità (utente/entità) e può colpire anche la posta interna. Tipicamente si tratta dell’inserimento dell’account nelle Restricted entities di Microsoft Defender per Office 365.
Cause principali
| Fattore | Dettagli operativi |
|---|---|
| Protezione antispam | L’account è finito fra le Restricted entities di Microsoft Defender per sospetto spam. Fino a rimozione/manual review, l’utente non può inviare. |
| Volumi/burst | Anche se i limiti formali (es. ~10.000/die, ~30/min) non risultano superati, l’invio simultaneo di molti messaggi identici (stesso oggetto/testo) può innescare i filtri. |
Che cosa significa “mittente non riconosciuto”
Non indica che l’indirizzo non esiste, ma che al momento non è autorizzato a inviare per motivi di sicurezza/abuso. Questo avviene quando i modelli di invio (pattern), il contenuto o la reputazione dell’utente/dominio/IP fanno salire il punteggio di rischio oltre la soglia di Defender/EOP. Il sistema previene lo spam‑out e blocca l’uscita.
Soluzione indicata dai moderatori (procedura di sblocco)
Passo 1 — Coinvolgere l’amministratore globale Microsoft 365
- Accedere al Defender portal con privilegi adeguati.
- Seguire il percorso: Email & collaboration → Review → Restricted entities.
- Individuare l’utente bloccato (es. sales@azienda.tld) e rimuoverlo dalla lista di restrizione.
Passo 2 — Se l’utente stesso è admin
- Dal Microsoft 365 Admin Center aprire: Support → Get support.
- Descrivere il caso (blocco in uscita, “sender not recognized”, account/tenant) e aprire un ticket per la ri‑abilitazione manuale.
Passo 3 — Propagazione e test
- Attendere la propagazione delle modifiche (da pochi minuti a qualche ora, variabile per tenant).
- Eseguire un test con un messaggio interno (verso un collega) e poi uno verso un contatto esterno noto.
Nota pratica: UI e diciture possono cambiare nel tempo; se non trovi “Restricted entities” controlla la sezione Review o avvia una ricerca dalla barra interna del portale Defender.
Diagnostica rapida (10 minuti)
Prima o durante lo sblocco, verifica i segnali fondamentali per confermare la causa e prevenire ricadute.
Checklist essenziale
- Stato utente: l’account è presente in Restricted entities? Sì → rimuovi e passa alla sezione “Prevenzione”.
- Tracce di messaggio: verifica cosa risulta nei Message trace per gli invii recenti (eventi Failed / Blocked / FilteredAsSpam).
- Politiche in uscita: controlla l’Outbound spam filter del tenant (azioni, soglie, eccezioni).
- Autenticazioni: SPF/DKIM/DMARC del dominio sono corretti e allineati?
- Pattern: c’è stato un burst (es. decine di e‑mail quasi identiche in pochi minuti)?
Comandi e verifiche utili (amministratori)
Per chi utilizza PowerShell con Exchange Online, può essere utile ispezionare in tempi brevi i tracciati di invio dell’utente:
# Connessione (modulo ExchangeOnlineManagement)
Connect-ExchangeOnline
Trace ultimi 2 giorni per il mittente
Get-MessageTrace -SenderAddress [sales@azienda.tld](mailto:sales@azienda.tld) ` -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |`
Sort-Object Received -Descending | Select-Object -First 20
Dettagli per un singolo messaggio
Get-MessageTraceDetail -MessageTraceId -RecipientAddress <[destinatario@dominio.tld](mailto:destinatario@dominio.tld)> Nel portale, usa Mail flow → Message trace per una lettura “a colpo d’occhio”. Se vedi molti fail ravvicinati in uscita, è coerente con un blocco per rischio spam.
Buone pratiche preventive
- Throttle le campagne: invia in lotti graduali (ad es. 6–10 messaggi/minuto su campagne “fredde”) con pause randomizzate e finestre orarie distribuite.
- Autenticazione solida: SPF corretto (include i sistemi autorizzati e termina con
~allo-all), DKIM attivo, DMARC almenop=quarantineper i domini di invio. - Diversifica i template: oggetti e corpi leggermente diversi riducono l’impronta ripetitiva; evita URL/CTA identici serializzati senza personalizzazione.
- Preferisci piattaforme dedicate (marketing automation, transactional email) per campagne massive, lasciando M365 per la posta person‑to‑person.
- Warm‑up di domini/IP/identità: aumenta gradualmente i volumi su nuovi mittenti.
- Monitoraggio costante: usa i report Threat protection status e i log di Mail flow per intercettare spike anomali.
Blocchi ricorrenti segnalati da altri utenti aziendali
Problema
Più alias collegati allo stesso tenant vengono periodicamente bloccati pur rispettando i limiti apparenti.
Azioni consigliate
- Rivedi l’Outbound spam filter in Defender e definisci eccezioni per mittenti affidabili (es. ruoli aziendali con flussi approvati).
- Controlla IP & reputazione nella sezione Mail flow → Threat tracker: segnali di reputazione bassa o blacklist suggeriscono azioni correttive.
- Warm‑up progressivo per nuovi domini/IP e per nuovi mittenti “freddi”.
- Apri un ticket se i blocchi persistono: allega Message ID, header completi, orari UTC e risultati dei trace.
Suggerimento: valuta l’adozione di sottodomini dedicati (es. notify.azienda.tld, news.azienda.tld) per separare reputazioni e politiche.
Impatto professionale (ritardo in candidature)
Scenario
Un utente segnala danni dovuti al blocco durante l’invio di CV e candidature.
Suggerimenti rapidi
- Conserva i log di errore e le evidenze (screenshot, orari, destinatari) per eventuali rivendicazioni.
- Usa un account alternativo (ad es. un provider esterno) per le comunicazioni critiche finché l’account principale non è ripristinato.
- Valuta consulenza legale se ci sono danni economici dimostrabili (contratti persi, scadenze saltate).
- Prepara un messaggio di cortesia per spiegare il ritardo a HR/recruiter, con richiesta di una nuova finestra di invio.
Linee guida sintetiche per evitare futuri blocchi
- Segmenta e personalizza: invii mirati con testi diversi riducono il punteggio di spam.
- Rispetta i ritmi: non superare ~30 messaggi/min; meglio <10/min per campagne “fredde”.
- Monitoraggio continuo: consulta regolarmente i report Threat protection status e Mail flow.
- Autenticazione del dominio: SPF con
~allo-all, DKIM attivo e DMARC almenop=quarantine. - Formazione utenti: diffondi linee guida su volumi ammessi, contenuti consentiti e strumenti dedicati per invii massivi.
Seguendo la procedura di sblocco e le best practice sopra, l’account viene normalmente riattivato entro poche ore e il rischio di blocchi futuri si riduce drasticamente.
Playbook operativo “zero‑to‑green”
Quando scatta il blocco
- Congela gli invii dell’utente (ferma eventuali mail‑merge in corso).
- Verifica Restricted entities & Message trace.
- Sblocca l’utente dal portale Defender (o apri ticket a Supporto).
- Test invii interni → esterni a contatti fidati.
- Rivedi Outbound spam policy e safe exceptions per mittenti affidabili.
- Correggi SPF/DKIM/DMARC se non allineati.
- Pianifica un warm‑up di rientro: invii piccoli, personalizzati, con pause.
Ruoli e responsabilità (RACI)
| Attività | Utente | IT Helpdesk | Global Admin/SecOps |
|---|---|---|---|
| Segnalazione blocco, raccolta prove | R | A/C | I |
| Verifica trace/Restricted entities | I | R | A |
| Sblocco dal portale / Ticket a supporto | I | C | R/A |
| Revisione policy e prevenzione | I | R/C | A |
| Monitoraggio post‑evento | I | R | A |
Progettare campagne “a basso rischio” in M365
Parametri consigliati (indicativi)
| Contesto | Ritmo iniziale | Incrementi | Note |
|---|---|---|---|
| Nuovo mittente “freddo” | 5–8/min | +2 ogni 2–3 giorni | Randomizza 15–30% le pause. |
| Mittente “tiepido” (storia recente buona) | 8–12/min | +3 ogni 2 giorni | Personalizza oggetti e saluti. |
| Mittente “caldo” (reputazione solida) | 12–18/min | +3–5/settimana | Evita allegati ripetitivi di grandi dimensioni. |
Accorgimenti di contenuto
- Evita parole/strutture spammy (tutto MAIUSCOLO, molteplici punti esclamativi, claim eccessivi).
- Evita URL accorciati seriali; privilegia domini noti dell’azienda.
- Prediligi plain‑text + HTML con layout semplice; troppe immagini identiche aumentano la ripetitività.
SPF, DKIM, DMARC: configurazioni essenziali
SPF (Sender Policy Framework)
Definisce chi è autorizzato a inviare per il tuo dominio. Esempio tipico per tenant Microsoft 365 (adatta ai tuoi sistemi):
dominio.tld. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
Alternativa più permissiva in fase di migrazione:
dominio.tld. IN TXT "v=spf1 include:spf.protection.outlook.com ~all"
DKIM (DomainKeys Identified Mail)
Firma le e‑mail con chiavi pubblica/privata. In M365 si attiva dal portale creando due CNAME, ad esempio:
selector1.domainkey.dominio.tld. CNAME selector1-dominio-tld.domainkey.tenant.onmicrosoft.com.
selector2.domainkey.dominio.tld. CNAME selector2-dominio-tld.domainkey.tenant.onmicrosoft.com.
DMARC (Domain‑based Message Authentication, Reporting & Conformance)
Definisce la policy quando SPF/DKIM non allineano. Valori di partenza consigliati:
_dmarc.dominio.tld. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@dominio.tld; ruf=mailto:dmarc@dominio.tld; fo=1; pct=100; aspf=s; adkim=s"
Una volta stabilizzata la reputazione, valuta p=reject per massima protezione (dopo analisi accurata dei report).
Come leggere rapidamente gli header
Authentication-Results: mx.dominio.tld;
spf=pass (sender IP is ...) smtp.mailfrom=dominio.tld;
dkim=pass header.d=dominio.tld;
dmarc=pass action=none header.from=dominio.tld
Pass su tutti e tre è l’ideale. Se SPF o DKIM non sono aligned con header.from, DMARC può risultare fail o applicare la policy di quarantena/rifiuto.
Outbound spam policy: cosa controllare
- Action when user is detected as spamming: verifica la risposta (ad es. Restrict user) e il tempo di restrizione.
- Limitazioni su inoltri esterni automatici: preferisci regole rigorose per ridurre il rischio di compromissioni che generano spam‑out.
- Eccezioni mirate per utenti/ruoli che devono inviare comunicazioni transazionali legittime (con audit).
Matrici di troubleshooting
| Segnale | Possibile causa | Contromisura |
|---|---|---|
| Bounce interno + esterno | Utente in Restricted entities | Rimozione dal portale; ticket a Supporto se necessario |
| Molti messaggi identici in pochi minuti | Burst anomalo da mail‑merge | Throttle, lotti, randomizzazione, personalizzazione |
| Header con SPF/DKIM pass ma DMARC fail | Allineamento mancante (domain alignment) | Allinea header.from al dominio autenticato |
| Blocchi ricorrenti multi‑utente | Policy troppo aggressive o reputazione IP | Rivedi Outbound policy, Threat tracker, warm‑up |
Domande frequenti (FAQ)
Perché anche le e‑mail interne sono respinte?
Il blocco è sull’entità mittente, non solo sul canale verso l’esterno: l’utente non è autorizzato a inviare finché non viene rimosso dalla restrizione.
Quanto dura la propagazione dopo lo sblocco?
Da minuti a qualche ora, variabile per area geografica e stato dei servizi. Esegui un test interno ed esterno dopo lo sblocco.
Se rispetto i limiti 10k/die e 30/min, perché vengo bloccato?
Perché contano anche pattern, ripetitività dei contenuti, allegati, URL, reputazione e cronologia. Non basta la mera soglia numerica.
Meglio “~all” o “-all” nello SPF?-all è più severo (rifiuto), ~all più permissivo (softfail). In migrazioni o scenari ibridi si usa spesso ~all, per poi passare a -all quando la mappatura delle sorgenti di invio è completa.
Posso evitare i blocchi con liste di “mittenti attendibili”?
Le eccezioni aiutano, ma vanno usate con parsimonia e audit; la prevenzione principale resta comportamento di invio, autenticazioni e qualità del contenuto.
Esempio: piano di ripartenza per l’utente “sales”
- Sblocco da Restricted entities + test interno.
- Giorno 1: 40 invii totali in 4 lotti (10+10+10+10) con 10–15 minuti tra i lotti; soggetti e saluti variati.
- Giorno 2: 80 invii in 6 lotti (<15/min); continua personalizzazione; nessun allegato ripetitivo.
- Giorno 3–5: incremento graduale (≤20%) monitorando tassi di risposta/bounce.
- Stabile: consolidare a 8–12/min per campagne fredde; per volumi maggiori migrare a piattaforma di marketing.
Comunicazioni di cortesia (modelli)
Verso HR/Recruiter
Oggetto: Reinvio candidatura — problema tecnico risolto
Buongiorno ,
a causa di un problema temporaneo del nostro sistema di posta, è possibile che la mia precedente candidatura
non sia stata recapitata. Ho ripristinato il servizio e reinvio in allegato.
Grazie per la comprensione,
Verso clienti/partner
Oggetto: Aggiornamento: invio precedente non recapitato
Gentile ,
alcune comunicazioni inviate ieri potrebbero non essere arrivate per un blocco tecnico ora risolto.
Se non ha ricevuto i dettagli, sono lieto di rinviarli su richiesta.
Cordiali saluti,
Errori comuni da evitare
- Invii massivi “one‑shot” senza riscaldamento e senza personalizzazione.
- Accodare allegati pesanti identici a centinaia di destinatari.
- Trascurare SPF/DKIM/DMARC o lasciare record incoerenti tra domini/sottodomini.
- Non monitorare i report di sicurezza o i trace post‑campagna.
Checklist finale
- ✔ Utente rimosso da Restricted entities.
- ✔ Ticket a Supporto aperto (se richiesto) con Message ID e log.
- ✔ Test interno ed esterno superato.
- ✔ Outbound spam policy rivista; eccezioni mirate dove sensato.
- ✔ SPF/DKIM/DMARC configurati e allineati.
- ✔ Piano di warm‑up e throttling applicato.
- ✔ Monitoraggio programmato (Threat protection status, Mail flow, alert).
- ✔ Linee guida interne diffuse agli utenti (volumi, contenuti, strumenti).
Conclusioni
Il messaggio “mittente non riconosciuto” in Microsoft 365 è quasi sempre un esito di protezioni antispam che scattano per prevenire abusi in uscita. La soluzione pratica è rimuovere l’utente dalle Restricted entities, verificare trace e politiche, quindi ripristinare gli invii con un piano di warm‑up ed email hygiene accurata. Con autenticazioni solide e una gestione disciplinata di volumi e contenuti, si ottiene una consegna stabile e si minimizzano drasticamente i blocchi futuri.