Gli errori SMTP 421 450 451 appartengono normalmente alla classe 4xx, cioè condizioni temporanee. Il server mittente dovrebbe mantenere il messaggio in coda e riprovare secondo la propria politica, invece di considerarlo immediatamente perso.
Questa guida approfondisce errori SMTP 421 450 451 con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Il codice principale non basta: il testo e il sottocodice esteso spiegano se la causa è greylisting, servizio non disponibile, casella temporaneamente occupata, rate limit, reputazione o errore locale.
Se il problema persiste oltre la durata della coda, il mittente genera un rimbalzo definitivo. Bisogna quindi controllare orari e numero dei tentativi.
Come riconoscere il problema
- Track Delivery mostra deferred.
- Il rimbalzo parla di try again later.
- La consegna arriva dopo alcuni minuti.
- Solo un provider destinatario rinvia i messaggi.
- Molti invii simultanei ricevono 421.
Cause più frequenti
1. Greylisting
Il destinatario rinvia il primo tentativo e accetta quelli successivi. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Servizio temporaneamente indisponibile
Il server remoto chiude o limita la sessione. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Rate limiting
L’IP invia troppi messaggi in un intervallo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Casella o risorsa occupata
Il destinatario non può accettare temporaneamente. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Reputazione incerta
Il provider applica defer temporaneo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Problema DNS o routing momentaneo
La consegna non può essere completata in quel tentativo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Leggi il rimbalzo completo. Copia codice esteso, testo e host remoto. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla Track Delivery. Verifica deferred, tentativi e risposta. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta destinatari. Stabilisci se il problema è del singolo dominio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla coda e volume. Individua picchi o account compromessi. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica autenticazione. SPF, DKIM e DMARC devono essere validi. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla reputazione e contenuto. Esamina pattern di invio e liste. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Attendi il retry previsto. Non reinviare manualmente molte copie. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Lascia lavorare la coda. Per un 4xx isolato il server riprova automaticamente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riduci la velocità. Scagliona newsletter e messaggi transazionali. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi autenticazione. Allinea SPF e DKIM. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Blocca invii anomali. Cambia credenziali e correggi moduli compromessi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Contatta il provider destinatario. Quando il defer è persistente e specifico. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Verifica quota e casella. Se il testo indica risorse del destinatario o locale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Monitora l’esito finale. Conferma delivered o rimbalzo definitivo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- La coda si svuota.
- Track Delivery mostra delivered.
- Nessun nuovo picco.
- Autenticazione valida.
- Il destinatario conferma la ricezione.
Prevenzione
- Invii graduali.
- Liste pulite.
- SPF DKIM DMARC.
- Monitoraggio coda.
- Password sicure.
Errori da evitare
- Non reinviare molte copie.
- Non confondere 4xx e 5xx.
- Non rimuovere DMARC.
- Non ignorare una coda crescente.
- Non pubblicare indirizzi completi nei forum.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- mittente e destinatario
- orario
- codice e testo
- Message-ID
- risultato Track Delivery
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su errori SMTP 421 450 451
Un errore 4xx perde subito il messaggio?
Normalmente no, il server mittente lo mantiene in coda e riprova.
Che cos’è il greylisting?
Un rinvio temporaneo del primo tentativo per verificare che il mittente riprovi correttamente.
Devo inviare di nuovo il messaggio?
È meglio attendere la coda, evitando duplicati.
Quanto durano i retry?
Dipende dalla configurazione del server mittente.
Quando diventa definitivo?
Quando i tentativi superano il tempo massimo e viene generato un rimbalzo 5xx o di scadenza.