Undelivered Mail Returned to Sender e destinatari CC: cosa succede davvero, spiegazione SMTP e guida Outlook

Hai ricevuto “Undelivered Mail Returned to Sender” per il destinatario principale e temi che i contatti in CC non abbiano ricevuto il messaggio? In SMTP ogni destinatario viene gestito separatamente: il fallimento di uno non blocca gli altri. Qui trovi spiegazione tecnica, strumenti di verifica e buone pratiche.

Indice

Panoramica del problema

Scenario tipico: invii un’email a un collega indicato nel campo To e aggiungi altri colleghi in CC. Poco dopo ricevi un avviso di mancata consegna (“Undelivered Mail Returned to Sender”) che riporta soltanto l’indirizzo del destinatario principale. Nessuna traccia dei contatti in copia. Il dubbio è naturale: la consegna ai CC è andata persa oppure è andata a buon fine e la notifica riporta semplicemente solo gli errori?

La risposta, nella stragrande maggioranza dei casi, è rassicurante: solo i destinatari elencati nella notifica non hanno ricevuto il messaggio. Gli altri indirizzi (in To, CC o BCC) continuano il loro percorso di recapito indipendentemente.

Come funziona davvero l’invio SMTP

Per comprendere perché un destinatario può fallire senza coinvolgere gli altri, è utile guardare sotto il cofano del protocollo SMTP.

Messaggio unico, sessioni di recapito distinte. Quando componi un’email con più destinatari (To, CC, BCC), il server mittente genera una singola copia del messaggio ma apre tentativi di consegna separati per ciascun indirizzo. In pratica costruisce una lista destinatari e per ognuno gestisce la negoziazione e l’esito con il server ricevente.
Envelope vs. intestazioni. Gli indirizzi nel campo To/CC/BCC delle intestazioni sono destinati alla lettura umana. A livello di trasporto SMTP, contano i comandi RCPT TO: che rappresentano l’envelope del messaggio. La presenza o assenza di un indirizzo nel testo dell’email non determina l’esito del trasporto: lo fa la sequenza MAIL FROM → RCPT TO → DATA.
Esiti indipendenti. Se un destinatario rifiuta la consegna (ad esempio casella inesistente), la sessione per quell’indirizzo termina in errore. Le altre sessioni proseguono normalmente e possono avere esito positivo.
Notifiche di stato (DSN). Le cosiddette “bounce” o “Delivery Status Notification” vengono emesse per gli indirizzi che falliscono. La notifica non elenca chi ha ricevuto correttamente il messaggio; la sua funzione è informare il mittente di errori e ritardi.

Esempio di dialogo SMTP semplificato

MAIL FROM:&lt;mittente@azienda.tld&gt;
RCPT TO:&lt;to@dominio.tld&gt;        550 5.1.1 User unknown
RCPT TO:&lt;cc1@dominio.tld&gt;       250 2.1.5 OK
RCPT TO:&lt;cc2@altrodominio.tld&gt;  250 2.1.5 OK
DATA                           354 End data with &lt;CR&gt;&lt;LF&gt;.&lt;CR&gt;&lt;LF&gt;
.                               250 2.0.0 Queued as 12345

Nell’esempio, il destinatario principale fallisce (550), mentre i due CC vengono accettati (250). La DSN verrà emessa per to@dominio.tld e non includerà i CC, perché non sono “incidenti”.

Cosa mostra davvero un bounce

Una notifica di mancata consegna include solo gli indirizzi interessati da errori o ritardi. Se un indirizzo non compare:

o la consegna per quell’indirizzo è già stata accettata dal server di destinazione,
o la consegna è ancora in coda e non c’è (ancora) un esito definitivo, come accade con errori temporanei (4.x.x).

Gli stati più comuni sono:

2.x.x – Successo (non viene inviato alcun bounce).
4.x.x – Errore temporaneo (es. “Mailbox full” temporanea o rate limit). Il server tenterà di nuovo per un intervallo che può arrivare a 24–48 ore; se tutti i tentativi falliscono, riceverai un bounce ritardato.
5.x.x – Errore permanente (es. utente inesistente, dominio non risolvibile, policy antispam). La notifica è immediata per quel destinatario.

È per questo che il tuo rapporto di mancata consegna riporta solo l’indirizzo del collega in To: la notifica è “mirata”. L’assenza dei CC è un segnale positivo.

Impatto su To, CC e BCC

La distinzione fra To, CC e BCC è semantica (per i lettori), non tecnica (per il trasporto). A livello SMTP, tutti gli indirizzi sono elencati come destinatari dell’envelope e vengono trattati uno a uno.

To: destinatario principale visibile nell’header. Nessun privilegio particolare sul trasporto.
CC: copie visibili a tutti. Recapito identico a To; se un CC fallisce, la notifica riguarderà solo lui.
BCC: copie “nascoste”. I BCC non compaiono nell’header del messaggio e non sono visibili agli altri destinatari. Le eventuali notifiche di mancata consegna per indirizzi BCC arrivano al mittente senza svelare l’elenco completo ai destinatari.

Conferma pratica dell’utente

Dopo test realistici (invii con destinatario principale volutamente errato e più indirizzi in CC), l’utente ha verificato che i contatti in copia hanno effettivamente ricevuto il messaggio. Questo riscontro conferma il comportamento standard: un errore non “trascina” con sé gli altri destinatari.

Strumenti per avere prove puntuali

Se vuoi verificare con precisione l’esito per ciascun indirizzo, puoi utilizzare una o più delle seguenti opzioni.

Conferme di recapito e di lettura in Outlook

Quando utilizzi Outlook, puoi chiedere al client di includere richieste di conferma:

Apri un nuovo messaggio e vai su Opzioni.
Seleziona Richiedi conferma di recapito per sapere se il server destinatario ha accettato il messaggio.
Se necessario, seleziona anche Richiedi conferma di lettura per sapere se il destinatario ha aperto l’email. Ricorda che la conferma di lettura può essere rifiutata dal client destinatario.

Tracciamento lato server

Log del server SMTP. In ambienti on‑premises o su gateway SMTP dedicati, l’analisi dei log (send/receive) mostra il dettaglio per ogni RCPT TO con esito, timestamp e codici SMTP restituiti.
Message Trace in ambienti aziendali. Con Exchange Online / Microsoft 365, il Message trace (nel centro di amministrazione) permette di ricostruire il percorso di ciascun destinatario, distinguendo accettazioni, ritardi e rifiuti con i relativi codici.
Report DMARC aggregati. Se gestisci un dominio con record DMARC, i report aggregati (RUA) offrono visibilità sulle sorgenti di invio e gli esiti di autenticazione; non sono “proof di consegna”, ma aiutano a individuare problemi sistemici di deliverability.

Tabella di riferimento rapido per i codici di errore

Di seguito una mappa pratica fra i codici più comuni e le azioni consigliate. Ricorda: quando la notifica cita un singolo indirizzo, solo quell’indirizzo è coinvolto.

Codice	Significato tipico	Impatto su altri destinatari	Azione consigliata
550 5.1.1	Utente inesistente	Nessun impatto: gli altri recapiti proseguono	Correggi l’indirizzo o contatta l’amministratore del dominio
550 5.7.1	Policy antispam/denied	Solo l’indirizzo bloccato fallisce	Verifica SPF/DKIM/DMARC, reputazione IP, contenuto del messaggio
552 5.2.2	Casella piena	Nessun impatto su altri destinatari	Invia un avviso alternativo; l’utente deve liberare spazio
451 4.7.1	Errore temporaneo / rate limit	Gli altri recapiti non sono influenzati	Il server ritenterà automaticamente; nessuna azione immediata
421 4.4.2	Problema temporaneo del server remoto	Indipendente dagli altri destinatari	Attendi i ritenti; se persiste oltre 24–48 ore, coinvolgi il supporto
553 5.1.2	Dominio del destinatario non valido	Gli altri domini non sono coinvolti	Correggi il dominio o contatta il destinatario per un indirizzo valido

Casi particolari da conoscere

Gruppi di distribuzione e alias

Se il destinatario in To è un gruppo, il server espande il gruppo in elenco di membri e tenta la consegna per ciascuno. Un membro può fallire senza che ciò impedisca la consegna agli altri membri o ai CC esterni. La notifica può riportare il gruppo, i membri specifici o entrambi, a seconda della configurazione.

Inoltri e regole lato server

Un indirizzo può essere valido ma avere una regola di inoltro verso una casella inesistente o bloccata. In questi casi il tuo server potrebbe segnare “consegnato” al primo hop, ma un successivo server genererà un bounce separato (double bounce o NDR di inoltro). L’assenza dei CC nel bounce originale resta un segnale che il loro recapito primario è avvenuto.

Differenza fra consegna e visibilità in Posta in arrivo

Accettazione a livello SMTP non equivale a giacere in Posta in arrivo. I filtri antispam o le regole utente possono spostare il messaggio in cartelle diverse (Posta indesiderata, Posta in arrivo in evidenza/altro, cartelle personalizzate). Un destinatario CC che “non trova” l’email potrebbe averla ricevuta correttamente ma filtrata. In questi casi, non ricevi bounce perché il server ha accettato la consegna.

Ritardi nella notifica

Per errori temporanei (serie 4.x), il tuo server conserva il messaggio in coda e ritenta a intervalli crescenti. Solo alla scadenza del tempo massimo di coda verrà emesso un NDR definitivo. Gli indirizzi non interessati da quell’errore continuano il loro percorso sin da subito.

Procedura rapida di diagnostica

Leggi attentamente il bounce. Identifica esattamente quale indirizzo è in errore e quale codice SMTP è riportato.
Contatta un CC per conferma. Chiedi a uno dei destinatari in copia se ha ricevuto. Molto probabilmente sì; chiedigli di cercare anche in Posta indesiderata.
Controlla la Posta inviata. Verifica l’ora di invio, eventuali allegati pesanti e dimensione complessiva del messaggio.
Se sei in azienda, esegui un message trace. Verifica l’esito per ciascun destinatario. Annota eventuali delay o throttling.
Correggi l’errore specifico. Casella inesistente? Aggiorna i contatti. Blocco antispam? Rivedi autenticazioni (SPF/DKIM/DMARC) e contenuto.
Rinvia solo dove serve. Evita reinvii indiscriminati a tutti: invia nuovamente solo agli indirizzi che hanno fallito, per non generare traffico inutile o duplicati.

Buone pratiche per prevenire i bounce

Monitora le cause di bounce. Un singolo rimbalzo può dipendere da indirizzo errato, casella piena, filtri antispam, dominio inesistente, allegati troppo pesanti, record DNS mancanti. Rimuovere o correggere gli indirizzi problematici riduce il rischio di reputazione negativa per il dominio mittente.
Gestisci invii a gruppi numerosi. Per newsletter o comunicazioni massificate usa piattaforme o modalità bulk (o una lista di distribuzione) che gestiscono code, retry e feedback loop per destinatari problematici senza influire sugli altri.
Verifica la Posta inviata e attendi la finestra ragionevole. In assenza di bounce entro 24–48 ore si può ragionevolmente ritenere che il messaggio sia stato consegnato, pur senza garanzia di lettura. Per la lettura usa le conferme, tenendo conto che possono essere rifiutate.
Tieni allineati SPF, DKIM e DMARC. Un’autenticazione coerente riduce i rifiuti per policy e migliora la reputazione del tuo dominio.
Evita contenuti a rischio spam. Linguaggio aggressivo, allegati eseguibili, URL sospette o immagini pesanti possono causare rifiuti o filtraggio.
Dimensione del messaggio sotto controllo. Molti server hanno limiti (spesso 25 MB). Per allegati pesanti preferisci la condivisione da cloud aziendale.

Esempio guidato di interpretazione di una DSN

Immagina di ricevere una notifica che riporta:

Final-Recipient: rfc822; mario.rossi@azienda.it
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Cosa significa, concretamente?

Solo mario.rossi@azienda.it non ha ricevuto il messaggio.
Se avevi in CC laura.bianchi@azienda.it e paolo.verdi@partner.com, la loro consegna non è coinvolta da questo errore e, se accettata dal server, non comparirà nella notifica.
Puoi rinviare esclusivamente a Mario dopo aver verificato l’indirizzo corretto (es. m.rossi@azienda.it), senza disturbare gli altri.

Domande frequenti

Se fallisce il destinatario in To, i CC ricevono lo stesso?

Sì. SMTP tratta ogni destinatario in modo indipendente. La mancata consegna di un indirizzo non blocca gli altri. La DSN elenca solo gli indirizzi problematici.

Perché i CC non compaiono nella notifica?

Perché la notifica ha lo scopo di riportare gli errori, non gli esiti positivi. Un indirizzo che non compare è, in linea di massima, un indirizzo accettato o non ancora concluso (in caso di ritardi temporanei).

E se un CC dice di non aver ricevuto ma non c’è bounce?

È probabile che il messaggio sia stato filtrato (Posta indesiderata), instradato in una cartella, bloccato da una regola locale o da un sistema antispam post-accept. Verifica lato destinatario e, in ambito aziendale, esegui un message trace.

Inviare richieste di lettura garantisce che il messaggio sia stato letto?

No. Le richieste di lettura possono essere rifiutate dal destinatario o dal client. Sono utili come ulteriore indizio, non come prova assoluta.

Un errore temporaneo su un destinatario può rallentare tutti?

No, i retry si applicano al singolo indirizzo in errore. Gli altri recapiti non sono vincolati da quel ritardo.

Se uso BCC, come vengono gestite le DSN?

Eventuali notifiche di mancata consegna per un BCC arrivano al mittente senza esporre l’elenco dei BCC ad altri. La privacy del BCC resta preservata.

Checklist operativa per i team IT

Conferma lato utente: screenshot del bounce + ID messaggio.
Trace per destinatari: verifica esito per ogni recipient nel periodo di tempo rilevante.
Codice SMTP: classifica come 2.x (ok), 4.x (retry), 5.x (errore). Prendi nota dell’host remoto coinvolto.
Autenticazioni: controlla SPF, DKIM e DMARC per il dominio mittente e i record DNS aggiornati.
Contenuto: valuta allegati, URL e formattazione (HTML pesante, immagini inline).
Remediation mirata: correggi gli indirizzi non validi, adegua la policy antispam, inserisci in allowlist ove consentito.

Riepilogo applicativo

SMTP tratta ciascun destinatario separatamente. Un invio con To + CC genera tentativi di consegna indipendenti per ogni indirizzo.
Il bounce elenca solo i destinatari falliti. L’assenza di un indirizzo nella DSN è generalmente segno di accettazione o di esito ancora pendente.
Test reali confermano il comportamento. I destinatari in CC ricevono anche quando il To fallisce.
Strumenti di controllo opzionali. Conferme di recapito/lettura in Outlook, analisi dei log o dei message trace in ambienti aziendali, report DMARC per trend di deliverability.

Conclusione

Quando il server segnala la mancata consegna per un singolo destinatario, gli indirizzi in CC proseguono normalmente verso la recapitazione. Solo gli indirizzi esplicitamente elencati nel bounce non hanno ricevuto il messaggio; tutti gli altri, salvo ulteriori errori, lo riceveranno. Per la massima tranquillità, affianca alla lettura dei bounce gli strumenti di verifica disponibili (conferme, log, trace) e adotta buone pratiche di igiene degli indirizzi e di autenticazione del dominio. Così trasformi un avviso preoccupante in un’occasione di diagnosi puntuale, senza interruzioni inutili della tua comunicazione.

Appendice: guida rapida per utenti Outlook

Prima di inviare un messaggio importante a più destinatari, apri Opzioni e abilita Conferma di recapito. Valuta anche la Conferma di lettura sapendo che può essere rifiutata.
Se ricevi un bounce che cita solo il To, contatta un CC e chiedi conferma ricezione. Cerca l’email anche in Posta indesiderata o in Altra posta in arrivo.
Evita reinvii a tutti: invia solo a chi è in errore dopo aver corretto la causa (indirizzo, dimensioni, contenuto).

Appendice: modelli di comunicazione per notificare l’errore

Oggetto: Copia messaggio a [Oggetto originale] – conferma recapito CC

Ciao [Nome],
il destinatario principale ha restituito un errore di recapito, ma la copia per te risulta inviata con successo.
Se non la vedi, controlla per favore Posta indesiderata o cerca l’oggetto originale: “[Oggetto]”.
Grazie,
[La tua firma]

In sintesi: SMTP isola gli esiti per destinatario. Un rimbalzo su un indirizzo non invalida gli altri; la DSN riporta solo i falliti. Usa conferme e tracciamenti per avere prove, correggi le cause e reinvia solo dove serve.