Un’e-mail va in bounce con errore 550 5.4.1 presso un cliente Microsoft 365, mentre l’autenticazione SPF/DKIM/DMARC risulta PASS: perché viene rifiutata? La risposta sta in una frase. Il codice 550 5.4.1 significa che l’indirizzo del destinatario non esiste nella directory del server che riceve il messaggio, oppure che l’accesso gli è esplicitamente negato. È un rifiuto di directory, diverso dai rifiuti legati alla sender reputation. Il contesto del rifiuto indirizza verso una delle 4 cause: un indirizzo isolato e un intero dominio non si trattano allo stesso modo.
Su Exchange Online, questa risposta è in genere la conseguenza del Directory-Based Edge Blocking, un meccanismo che filtra gli indirizzi non validi prima ancora che il contenuto del messaggio venga esaminato. Qui molte campagne si fermano: il tuo CMO chiede perché l’open rate cala, il tuo strumento di emailing mostra una configurazione tecnica impeccabile e l’NDR (Non-Delivery Report) resta incomprensibile se non sai leggerne il testo esatto.
Cosa significa il codice 550 5.4.1
550 è un codice di stato permanente (classe 5yz della RFC 5321, pubblicata nell’ottobre 2008): il server non ritenterà l’invio, a differenza degli errori 4xx temporanei, che la stessa RFC fa ritentare per almeno 4 o 5 giorni. Il sottocodice 5.4.1 (Enhanced Status Code ai sensi della RFC 3463 del gennaio 2003) indica un problema di routing o di accesso lato destinatario, non un problema di contenuto o di blacklist. È la differenza principale rispetto al 550 5.7.1, in cui il rifiuto deriva da una policy di filtraggio o da una reputazione del mittente degradata. Qui lo scambio EHLO e poi MAIL FROM si è svolto senza intoppi e il comando RCPT TO è stato accettato sintatticamente. L’indirizzo è stato rifiutato solo al momento della sua risoluzione nella directory. Per una panoramica delle famiglie di codici 4xx e 5xx, la tassonomia completa degli errori SMTP offre il quadro generale.
Casella eliminata o mai creata: il caso più frequente
L’NDR mostra «550 5.4.1 Recipient address rejected: Access denied». L’indirizzo non è mai esistito nella directory di Exchange Online, oppure ne è stato rimosso dopo l’uscita di una persona dall’azienda o la chiusura di un account. Nessun nuovo tentativo cambierà l’esito: il destinatario del messaggio, lato ricezione, non esiste.
Il primo riflesso resta verificare l’ortografia esatta dell’indirizzo: basta un dominio copiato male per produrre questo rifiuto. Se l’indirizzo è corretto e il rifiuto persiste per più giorni, l’indirizzo è morto. Appartiene a un ex contatto o a una posizione eliminata, spesso ereditato da un import CRM mai aggiornato.
Dominio accettato configurato male come Internal Relay o Authoritative
Un sintomo permette di riconoscere questa causa: il rifiuto colpisce tutti i destinatari di uno stesso dominio e non un solo indirizzo isolato. In Exchange Online, un dominio accettato può essere di tipo Authoritative (la directory M365 fa fede, ogni indirizzo assente viene rifiutato da DBEB) oppure Internal Relay (una parte delle caselle vive altrove e il flusso prosegue verso un altro sistema tramite un connettore).
Il problema si presenta tipicamente in ambiente ibrido: il tenant Microsoft 365 è configurato come Authoritative mentre alcune caselle esistono ancora su un server Exchange locale non del tutto sincronizzato. Exchange Online rifiuta allora indirizzi perfettamente validi, perché ne ignora l’esistenza nella directory. Secondo Microsoft Learn, durante la sincronizzazione degli utenti la procedura DBEB mantiene il dominio accettato come Internal Relay. Il passaggio ad Authoritative arriva solo quando tutti i destinatari sono presenti in Microsoft 365.
La correzione classica per l’amministratore, quando il dominio dovrebbe già essere a posto ma indirizzi validi vanno comunque in bounce: portare il dominio accettato da Authoritative a Internal Relay nell’interfaccia di amministrazione di Exchange (Flusso della posta > Domini accettati), salvare, poi tornare ad Authoritative. In PowerShell, lo stesso cambio passa dal cmdlet Set-AcceptedDomain e dal suo parametro -DomainType. Il passaggio obbliga Exchange Online a riprovvisionare lo stato della directory e cancella una cache di directory obsoleta.
Directory-Based Edge Blocking: il rifiuto al perimetro prima di ogni filtro
«Se l’indirizzo non compare nella directory, il servizio blocca il messaggio prima ancora che inizi il filtraggio.» (documentazione Exchange Online, Microsoft Learn)
DBEB (Directory-Based Edge Blocking) rifiuta gli indirizzi sconosciuti al perimetro di rete del servizio, prima che il messaggio entri nella pipeline di filtraggio anti-spam di Microsoft 365. Non è un blocco del relay né un rifiuto di connessione a monte, caso trattato nell’articolo sull’errore SMTP 554 5.0.0: lì la connessione stessa viene rifiutata. Qui la connessione va a buon fine e fallisce solo la risoluzione dell’indirizzo, subito dopo. In ambiente ibrido, DBEB funziona solo se il record MX del dominio punta a Microsoft 365, precisa la stessa pagina. Microsoft stima in 5-10 minuti il tempo di attivazione di DBEB.
L’NDR completo riporta spesso un codice aggiuntivo: «550 5.4.1 Recipient address rejected: Access denied. AS(201806281)». Questo codice indica un rifiuto DBEB. Conferma che il blocco proviene dalla directory di Exchange Online, ma non dice perché l’indirizzo vi manchi. Quando compare subito dopo la creazione di una casella in ambiente ibrido, la causa più probabile resta un ritardo di sincronizzazione tra la directory locale (Microsoft Entra Connect, l’ex Azure AD Connect rinominato nel 2023) ed Exchange Online: la casella esiste in locale, la modifica aspetta la replica. L’amministratore forza allora un ciclo delta con il comando Start-ADSyncSyncCycle -PolicyType Delta sul server Entra Connect, prima di cercare altrove.
Alias o lista di distribuzione inattiva
Quarto caso: l’indirizzo rifiutato è un alias o una lista di distribuzione disattivata. Un gruppo di distribuzione eliminato e un alias rimosso da una casella condivisa producono esattamente lo stesso sintomo a schermo. Il caso più ostico resta il gruppo di distribuzione dinamico on-premises in un ambiente ibrido: non può sincronizzarsi verso Exchange Online, per quanto ci si aspetti il contrario.
La soluzione documentata per questo caso consiste nel creare in Exchange Online un contatto di posta che riprenda l’indirizzo esterno del gruppo dinamico locale. Per un semplice alias eliminato, bisogna ricreare l’alias sulla casella di destinazione oppure avvisare il mittente che l’indirizzo è cambiato.
Cosa rivela il 550 5.4.1 sullo stato della lista
«Le mie campagne finiscono in rifiuto eppure il mio strumento di emailing mostra una configurazione tecnica perfetta»: questa frase torna spesso tra i responsabili growth o lifecycle che scoprono il 550 5.4.1 per la prima volta. La tentazione è scavare su SPF, DKIM, IP warmup, sender reputation, come per qualsiasi rifiuto di deliverability classico. Su questo codice, quel lavoro non serve a nulla: le 4 cause sopra stanno tutte lato destinatario, nella sua directory.
Il riflesso SPF, DKIM, warmup nasce da una buona abitudine. Ma nessun ESP verifica per impostazione predefinita se l’indirizzo esiste ancora davvero presso il destinatario, controlla solo che il formato sia valido. È il punto cieco che una verifica della lista copre, senza aggiungere un altro livello da monitorare ogni giorno.
Un indirizzo eliminato, un alias morto, un intero dominio configurato male per mancata sincronizzazione: in tutti e 4 i casi il punto in comune è una lista che contiene voci morte, e quelle voci si accumulano in fretta. CaptainVerify ha verificato 126 milioni di indirizzi nel 2025, di cui solo il 57 % validi. Una lista perde inoltre ogni anno circa il 23 % dei suoi indirizzi validi, secondo l’analisi su quanto vale veramente un indirizzo email.
Una verifica della lista a monte cambia la situazione. Agisce prima dell’invio ed elimina l’intera categoria di errore, senza toccare il DNS né la configurazione di Exchange. Un indirizzo che non esiste più nella directory del destinatario si individua al momento della verifica, prima del bounce su una campagna già partita. Prima del prossimo invio, basta far passare da una verifica un campione della lista per capire quanti indirizzi finirebbero in 550 5.4.1, senza aver scaldato l’IP per niente. È una questione di list hygiene, risolta a monte di qualsiasi intervento sull’infrastruttura di invio.
Domande frequenti
Il 550 5.4.1 è identico al 550 5.7.1? No. Il 5.4.1 segnala un problema di routing o di accesso all’indirizzo nella directory, il 5.7.1 segnala una policy di filtraggio o una reputazione del mittente degradata. Le correzioni sono completamente diverse: lato directory per l’uno, lato reputazione per l’altro.
Quanto aspettare dopo una risincronizzazione della directory ibrida? Microsoft Entra Connect sincronizza per impostazione predefinita ogni 30 minuti, secondo Microsoft Learn, poi Exchange Online deve ancora recepire la modifica. Calcola qualche ora prima di concludere che la causa sia un’altra: riprovare prima riproduce lo stesso rifiuto.
Un rifiuto 550 5.4.1 fa salire il mio hard bounce rate complessivo? Sì, ogni occorrenza conta come hard bounce nelle statistiche del tuo strumento di emailing e in quelle dei provider di posta dei destinatari. Un accumulo di questi rifiuti su una stessa lista degrada la sender reputation anche se nessun altro errore di deliverability è in causa. Per un quadro più ampio sull’aumento di questi rifiuti, l’articolo sui rifiuti SMTP e il loro aumento illustra il meccanismo di degrado.
