Hai inviato un’email e poco dopo hai ricevuto un messaggio con oggetto “Delivery Status Notification”, “Undelivered Mail Returned to Sender”, “Mail delivery failed” oppure “Non recapitabile”? Si tratta di una notifica generata automaticamente da un server di posta per comunicare lo stato del tentativo di consegna.
La parte decisiva del messaggio non è l’oggetto, ma il codice SMTP o il codice di stato avanzato riportato nei dettagli tecnici. Da quel codice è possibile capire se l’errore è temporaneo, se il server ritenterà la consegna oppure se il messaggio è stato rifiutato definitivamente.
In breve
Un codice 4.x.x indica normalmente un problema temporaneo e può generare nuovi tentativi automatici. Un codice 5.x.x indica un errore permanente: senza una correzione, il messaggio non verrà consegnato. Il testo che segue il codice specifica la causa effettiva.
Che cos'è una Delivery Status Notification
Una Delivery Status Notification, abbreviata in DSN, è un rapporto strutturato sul risultato di un tentativo di consegna email. Nei sistemi Microsoft la notifica di mancata consegna viene spesso chiamata NDR, Non-Delivery Report. Il messaggio è prodotto da un Mail Transfer Agent o da un gateway di posta e contiene informazioni utilizzabili sia dall’utente sia dall’amministratore.
Una DSN può segnalare:
- consegna riuscita, se il mittente ha richiesto una notifica positiva e il sistema destinatario la supporta;
- consegna ritardata, quando il server non è ancora riuscito a recapitare il messaggio ma continuerà a tentare;
- mancata consegna definitiva, quando il messaggio è stato rifiutato o non può essere recapitato;
- inoltro o trasferimento verso un altro sistema di messaggistica.
Le notifiche di successo non sono normalmente inviate per ogni email. Per questo motivo, non ricevere un errore non equivale a una prova di lettura e non garantisce che il messaggio sia visibile nella posta in arrivo del destinatario: potrebbe essere stato accettato dal server e poi filtrato, messo in quarantena o spostato nella posta indesiderata.
DSN, conferma di recapito e conferma di lettura: differenze
| Meccanismo | Cosa attesta | Limite |
|---|---|---|
| DSN/NDR | Esito tecnico del tentativo di consegna | Non dimostra la lettura e può fermarsi all’accettazione da parte di un server |
| Conferma di recapito | Consegna gestita dal sistema di posta | Dipende dal supporto e dalle policy dei sistemi coinvolti |
| Conferma di lettura | Il client del destinatario segnala l’apertura | Il destinatario o l’organizzazione può rifiutarla o disabilitarla |
Come leggere una notifica di mancata consegna
Prima di inoltrare l’errore all’help desk, individua questi campi:
- Final-Recipient o indirizzo del destinatario interessato;
- Action, ad esempio failed, delayed o delivered;
- Status, normalmente espresso nel formato x.y.z;
- Diagnostic-Code, che contiene il codice SMTP e la spiegazione restituita dal server remoto;
- Remote-MTA o server che ha generato il rifiuto;
- data e ora dell’ultimo tentativo di consegna.
Se il messaggio era indirizzato a più persone, la DSN può contenere un risultato diverso per ciascun destinatario. Un singolo indirizzo errato non implica quindi che l’email sia fallita per tutti.
Codici SMTP 4xx e 5xx: errore temporaneo o permanente
I codici SMTP tradizionali, come 421, 450, 451, 452, 550, 552 o 554, sono spesso affiancati da un codice avanzato a tre gruppi, per esempio 4.2.2 o 5.7.1. La prima cifra definisce la classe dell’esito.
| Classe | Significato | Comportamento | Azione |
|---|---|---|---|
| 2.x.x | Esito positivo | Il server ha accettato o completato l’operazione descritta | Nessuna correzione, salvo verifiche applicative |
| 4.x.x | Errore temporaneo | Il server mittente può ritentare fino alla scadenza della coda | Attendere; se persiste, verificare quota, DNS, reputazione e disponibilità |
| 5.x.x | Errore permanente | Il tentativo è concluso e non verrà risolto da solo | Correggere indirizzo, policy, configurazione o contenuto e reinviare |
Errori Delivery Status Notification più comuni
Mailbox full / quota exceeded
La casella del destinatario ha raggiunto il limite di archiviazione. Con 4.2.2 il problema può essere temporaneo; con 5.2.2 il server considera la consegna definitivamente non riuscita.
Contattare il destinatario con un canale alternativo. Il destinatario o il suo amministratore deve liberare spazio, aumentare la quota o correggere le policy di archiviazione.
Bad destination mailbox address / recipient not found
L’indirizzo non esiste, contiene un errore oppure non è più valido. In ambienti Microsoft 365 può dipendere anche da record MX non aggiornati o da oggetti destinatario configurati in modo errato.
Verificare ortografia, dominio, alias e destinatario. Se il problema riguarda più mittenti o indirizzi, controllare MX, domini accettati e configurazione Exchange Online.
Routing, DNS o server non raggiungibile
Il sistema non riesce a determinare un percorso valido, risolvere il dominio o raggiungere il server destinatario. Un 4.x.x può risolversi; un 5.x.x richiede una correzione.
Controllare DNS, record MX, connettori, smart host, firewall e disponibilità del server remoto. Evitare di reinviare ripetutamente senza aver identificato la causa.
Relaying denied, access denied o policy rejection
Il server ha rifiutato il messaggio per una policy di sicurezza o autorizzazione. Le cause includono relay SMTP non consentito, mittente non autorizzato, gruppo protetto, routing errato, filtro antispam o regola di trasporto.
Leggere l’intero Diagnostic-Code: 5.7.1 è una categoria ampia. Verificare autenticazione del connettore, permessi, policy antispam, regole di trasporto e configurazione del destinatario.
Message too big
Il messaggio supera il limite ammesso dal server mittente, dal destinatario o da un gateway intermedio. Il limite effettivo è quello più restrittivo lungo il percorso.
Ridurre gli allegati, usare un collegamento OneDrive o SharePoint e verificare i limiti configurati su mailbox, connettori e regole di trasporto.
Delivery time expired
Il server mittente ha ritentato la consegna senza successo fino alla scadenza prevista. La notifica finale può arrivare dopo uno o più avvisi di ritardo.
Verificare la raggiungibilità del dominio destinatario, gli MX, i timeout, le code e gli errori precedenti. Reinviare solo dopo la risoluzione.
Errore di autenticazione del dominio
Il messaggio è stato rifiutato perché i controlli SPF, DKIM o DMARC non hanno prodotto un risultato conforme alla policy applicata dal destinatario.
Inventariare tutti i sistemi che inviano per il dominio, correggere SPF, abilitare DKIM, verificare l’allineamento DMARC e analizzare i report prima di applicare policy più restrittive.
Ho ricevuto una DSN per un messaggio che non ho inviato
Una notifica relativa a un’email apparentemente mai inviata non prova, da sola, che la casella sia stata violata. Può trattarsi di backscatter: uno spammer falsifica il tuo indirizzo nel campo mittente e il server destinatario invia la mancata consegna all’indirizzo contraffatto.
La verifica deve distinguere tra spoofing del mittente e compromissione reale dell’account:
- controllare i messaggi inviati, le regole della casella e gli inoltri automatici;
- verificare accessi recenti, dispositivi, applicazioni autorizzate e autenticazioni anomale;
- analizzare le intestazioni complete della DSN e del messaggio originale allegato;
- revocare le sessioni e modificare la password se emergono indicatori di compromissione;
- abilitare MFA e correggere SPF, DKIM e DMARC per ridurre l’abuso del dominio.
Non aprire allegati eseguibili e non usare collegamenti presenti in notifiche inattese prima di aver verificato il messaggio: anche una falsa notifica di consegna può essere usata come esca di phishing.
Procedura rapida per risolvere una mail non consegnata
Identifica il destinatario coinvolto
Con invii multipli, verifica se l’errore riguarda un solo indirizzo o l’intero messaggio.
Leggi il codice completo
Non fermarti a “550” o “5.7.1”: conserva anche il testo dopo il codice e il nome del server remoto.
Classifica l’errore
4.x.x indica in genere un problema temporaneo; 5.x.x richiede una modifica prima del nuovo invio.
Esegui il controllo coerente con la causa
Indirizzo e alias per 5.1.x; quota per 5.2.x; DNS e routing per 5.4.x; policy e autenticazione per 5.7.x.
Verifica il flusso di posta
Negli ambienti Microsoft 365 usa message trace e i dettagli dell’NDR per ricostruire il percorso e il punto di rifiuto.
Reinvia dopo la correzione
Ripetere lo stesso invio senza modifiche può peggiorare code e reputazione senza risolvere il problema.
Come ridurre gli errori di consegna delle email aziendali
Configurare correttamente SPF, DKIM e DMARC
La deliverability non dipende soltanto dalla cifratura della sessione SMTP. SPF autorizza le sorgenti di invio, DKIM applica una firma crittografica al messaggio e DMARC verifica l’allineamento con il dominio visibile nel campo From, definendo inoltre una policy per i messaggi non conformi.
SPF da solo non è sufficiente. Tutti i servizi che inviano per conto del dominio - Microsoft 365, CRM, newsletter, gestionali, scanner e applicazioni - devono essere censiti. Una modifica DMARC deve essere introdotta sulla base dei report e non applicata alla cieca.
Proteggere SMTP e connettori
Utilizzare TLS protegge il trasporto quando supportato dai sistemi coinvolti, ma non migliora automaticamente la reputazione dell’IP e non autentica il dominio del mittente. Per dispositivi e applicazioni legacy occorre scegliere il metodo di invio corretto, limitare il relay, usare autenticazione moderna dove disponibile e monitorare gli abusi.
Monitorare reputazione, blacklist e volumi
Un IP o un dominio con reputazione degradata può subire ritardi, quarantene o rifiuti. Le blacklist sono un indicatore, non una diagnosi completa: vanno correlati log SMTP, tassi di bounce, volumi anomali, autenticazione del dominio, contenuto dei messaggi e feedback dei destinatari.
Usare una piattaforma di posta gestita
Se l’azienda utilizza ancora caselle POP/IMAP o server non più adeguati, una migrazione della posta elettronica a Microsoft 365 consente di centralizzare mailbox, domini, tracciamento e policy di sicurezza su Exchange Online.
Per provider come Aruba, Register o hosting Linux è disponibile una procedura specifica di migrazione IMAP a Microsoft 365; negli ambienti on-premises occorre invece pianificare una migrazione da Exchange 2019 a Microsoft 365 considerando connettori, applicazioni SMTP, DNS e coesistenza.
Troubleshooting in Microsoft 365
In Exchange Online, il Message Trace permette di verificare se il messaggio è stato ricevuto dal servizio, elaborato, consegnato, ritardato, rifiutato o inoltrato. L’analisi deve essere eseguita insieme ai dettagli dell’NDR, alle regole di trasporto, ai connettori e agli eventi di autenticazione del dominio. La guida al Microsoft 365 Admin Center descrive i portali e le principali funzioni amministrative.
Se i problemi di recapito sono ricorrenti, riguardano più domini o coinvolgono applicazioni aziendali, il controllo deve includere almeno: record MX, SPF, DKIM e DMARC; connettori e relay; regole di trasporto; limiti delle mailbox e dei messaggi; stato dei domini; reputazione delle sorgenti; quarantena e policy antispam.
Domande frequenti
Cosa significa Delivery Status Notification (Failure)?
Significa che il sistema di posta non è riuscito a consegnare il messaggio al destinatario indicato. Il codice 5.x.x e il Diagnostic-Code spiegano la causa permanente del rifiuto.
Cosa significa Delivery Status Notification (Delay)?
Indica che la consegna non è ancora riuscita, ma il server può continuare a ritentare. Se il problema persiste fino alla scadenza della coda, verrà generato un errore definitivo.
Che cosa significa errore 550?
550 è un rifiuto SMTP permanente, ma non identifica da solo una causa unica. Il codice avanzato e il testo successivo possono indicare destinatario inesistente, policy di sicurezza, relay negato, spam o altri problemi.
Un’email senza notifica di errore è stata sicuramente consegnata?
No. L’assenza di NDR non dimostra né la presenza nella Inbox né la lettura. Il messaggio può essere stato accettato e successivamente filtrato, messo in quarantena o spostato nello spam.
Una conferma di lettura garantisce che il destinatario abbia letto il contenuto?
No. Dipende dal client e dalle policy del destinatario, può essere rifiutata e segnala al massimo l’apertura gestita dal client, non la comprensione del messaggio.
Perché ricevo errori per email che non ho inviato?
La causa più comune è il backscatter dovuto alla falsificazione dell’indirizzo mittente. Occorre comunque controllare accessi, messaggi inviati, regole e inoltri per escludere la compromissione della casella.
Supporto Nexsys per posta elettronica e Microsoft 365
Nexsys analizza errori di recapito, configurazioni DNS, SPF, DKIM e DMARC, connettori SMTP, Exchange Online e migrazioni da sistemi legacy. Il servizio può essere inserito in un progetto completo di migrazione Microsoft 365 per aziende oppure in un intervento mirato di troubleshooting.