Le soglie sono pubbliche da febbraio 2024: le linee guida per i mittenti di Gmail fissano un hard requirement a 0,3% di reclami spam, e la maggior parte delle piattaforme considera che un tasso di hard bounce superiore al 2% per campagna attivi un throttling. Il codice SMTP 501 fa parte dei bounce permanenti che pesano in questo calcolo, e inganna per omissione. La sua vera natura si nasconde nel sotto-codice Enhanced Status che segue: 5.1.3, 5.1.7, 5.5.4 o altre varianti a seconda del server destinatario. Ogni sotto-codice ha una causa distinta e una correzione che non assomiglia alla precedente. Riprendere l’invio senza aver letto questo sotto-codice equivale a inviare un secondo hard bounce nella tua coda, il che peggiora direttamente la tua sender reputation.
Cosa significa davvero il codice 501
Un codice SMTP che inizia con 5 è un rifiuto permanente. Il server remoto dice: non tenterà di recapitare questo messaggio, né ora né in seguito. A differenza degli errori 4xx (temporanei), un 501 non si risolve aspettando o rispedendo il messaggio identico.
La sintassi completa di un messaggio di errore 501 appare così nel tuo NDR (Non-Delivery Report):
501 5.1.3 Invalid address format
La prima cifra (5) indica il rifiuto permanente. La seconda cifra indica la categoria dell’errore Enhanced Status: 1 = problema di indirizzo, 5 = problema di protocollo o di sintassi del comando. La terza cifra affina la diagnosi esatta. È questa combinazione a tre cifre, dopo il codice 501, che deve guidare la tua correzione.
In pratica, molti team leggono “501” e si fermano lì. Il sotto-codice scompare nella logica di reporting degli ESP (Email Service Provider). Risultato: trattano un problema del mittente come un problema del destinatario, o viceversa.
Sotto-codice 5.1.3: formato dell’indirizzo destinatario non valido
Il sotto-codice 5.1.3 segnala un errore di formato nell’indirizzo del destinatario: il server SMTP si ferma sull’anomalia sintattica prima ancora di verificare se la casella esiste.
Le cause più frequenti:
- Doppia chiocciola:
prenom@domaine@example.com - Dominio mancante:
prenom.nom@ - Caratteri non consentiti nella parte locale (spazi non codificati, parentesi, parentesi quadre fuori dalle virgolette)
- Estensione del dominio assente:
prenom@domaine - Punto all’inizio o alla fine della parte locale:
.prenom@domaine.com
Questi indirizzi arrivano in lista da moduli senza validazione lato server, da importazioni CSV mal ripulite o da inserimenti manuali nel CRM. La correzione non avviene lato SMTP: avviene a monte, prima dell’invio.
Prima di ogni campagna, fai girare la lista su un validatore di formato RFC 5321. Gli indirizzi 5.1.3 sono recuperabili: o si ritrova l’indirizzo corretto contattando il lead tramite un altro canale, o si elimina definitivamente il contatto dalla lista. Conservarlo con questo stato garantisce un hard bounce al prossimo invio.
Sotto-codice 5.1.7: indirizzo mittente non corretto o rifiutato
Qui il problema cambia fronte. Il sotto-codice 5.1.7 riguarda l’indirizzo del mittente, non del destinatario. Il server remoto ha rifiutato il comando MAIL FROM perché l’indirizzo di invio non è valido secondo i suoi criteri.
Questo sotto-codice appare in due casi: o il tuo indirizzo di invio ha un errore di formato (dominio inesistente, sintassi non valida), oppure il server destinatario applica una politica rigorosa che blocca i mittenti il cui indirizzo From o Return-Path non supera i controlli di autenticazione.
Un 5.1.7 può quindi tradire un problema SPF mal configurato sul tuo dominio di invio. Se il tuo record SPF non include l’indirizzo IP o il dominio del tuo ESP, alcuni server riceventi rifiutano il comando MAIL FROM con questo sotto-codice invece di un classico 550.
Inizia dal NDR completo: individua l’indirizzo segnalato. Se è il tuo Return-Path (indirizzo tecnico di rimbalzo), verifica che il tuo record SPF includa il dominio della tua piattaforma di invio. Se è il tuo indirizzo From visibile, controlla che il dominio di invio corrisponda al tuo dominio SPF autorizzato.
Verifica anche il tuo allineamento DMARC: un mittente il cui dominio From differisce dal dominio SPF (o DKIM) può generare rifiuti 5.1.7 sui server che applicano una politica DMARC rigorosa lato ricezione.
Sotto-codice 5.5.4: comando SMTP non valido
Il sotto-codice 5.5.4 è diverso: qui il problema è il comando SMTP, non l’indirizzo. Il server remoto ha ricevuto un comando malformato o dei parametri che non riconosce.
In pratica, questo sotto-codice appare raramente sugli invii standard tramite un ESP affidabile (Brevo, Mailgun, Postmark, Amazon SES). È più comune quando invii tramite un server SMTP interno, un relay SMTP configurato manualmente o un’integrazione API che costruisce la sessione SMTP direttamente.
Le cause tipiche di un 5.5.4:
- Header SMTP mal formattati (codifica errata nell’
EHLOo nelMAIL FROM) - Parametri non supportati passati nel comando (es. estensioni SMTP non negoziate tramite
EHLO) - Incoerenza tra il nome host dichiarato in
EHLOe l’indirizzo IP del server di invio - Connettore o middleware che inserisce caratteri di controllo nella sessione
La correzione passa attraverso i log SMTP grezzi, non dal solo NDR. Attiva la modalità debug sul tuo server o relay per catturare la transazione completa e identificare il comando esatto che provoca il rifiuto.
Altre varianti 501: leggere il messaggio di testo
Non tutti i server implementano i codici Enhanced Status in modo uniforme. Alcuni restituiscono un 501 senza sotto-codice o con un sotto-codice proprietario (5.0.0, 5.7.1, ecc.). In questo caso, la diagnosi si basa interamente sul messaggio di testo che accompagna il codice.
Alcuni esempi di messaggi 501 senza sotto-codice standardizzato che puoi incontrare:
501 Syntax: MAIL FROM: <address>, problema di formato nel comando MAIL FROM, lato mittente501 Bad recipient address syntax, variante del 5.1.3, problema lato destinatario501 Domain must be present in address, dominio assente nell’indirizzo, variante 5.1.3501 Too many invalid addresses, il server ha raggiunto la sua soglia di tolleranza per una sessione con più destinatari non validi
Vale la pena soffermarsi su quest’ultimo caso. Se la tua lista contiene un alto tasso di indirizzi non validi sullo stesso dominio destinatario, alcuni server bloccano l’intera sessione dopo N errori consecutivi. Ottieni quindi un 501 su indirizzi che avrebbero potuto passare. Il tasso di hard bounce apparente supera allora il tasso di indirizzi realmente non validi.
Leggere il NDR per identificare il giusto sotto-codice
Il tuo ESP ti fornisce generalmente un riepilogo dell’errore, spesso troncato. Per la diagnosi, hai bisogno del NDR completo.
Su Gmail / Google Workspace: il NDR arriva nella casella del mittente. Apri il messaggio, clicca sui tre puntini in alto a destra, seleziona Mostra originale. Il codice SMTP completo appare nell’intestazione Diagnostic-Code.
Su Outlook / Exchange: stesso principio. Il NDR contiene una sezione Diagnostic information for administrators con il codice completo restituito dal server remoto.
Sul tuo ESP (Brevo, Mailchimp, Postmark): vai nell’attività del messaggio o nel report di bounce. La maggior parte degli ESP espone il codice Enhanced Status e il messaggio di testo grezzo nella scheda di attività di ogni invio. Se il tuo ESP non lo mostra, esporta i log di attività e filtra sul codice 501.
Una volta identificato il sotto-codice, applica la correzione corrispondente. Correggi l’indirizzo per i 5.1.3, correggi il mittente o l’SPF per i 5.1.7, correggi la sessione SMTP per i 5.5.4.
Evitare i 501 prima dell’invio: verifica degli indirizzi
La correzione dopo il bounce è costosa: un hard bounce registrato, un contatto da eliminare, una reputazione IP leggermente compromessa. Meglio intervenire prima dell’invio.
Per gli errori 5.1.3 (formato di indirizzo non valido), la verifica sintattica prima dell’importazione blocca i casi più ovvi: doppie chiocciole, domini assenti, caratteri non consentiti. Non costa nulla e si applica all’importazione del file o all’invio del modulo.
Per andare oltre, una verifica SMTP live (ping del server destinatario senza inviare messaggi) permette di rilevare i domini che non esistono o che non accettano più mail, categoria che genera anch’essa bounce 5.1.x. Servizi come Captain Verify combinano la verifica sintattica, la risoluzione DNS e il ping SMTP in un unico passaggio, con un risultato per indirizzo che distingue i catchall, i non validi e i validi.
Per gli errori 5.1.7, la prevenzione passa per un audit della tua configurazione di autenticazione (SPF, DKIM, allineamento DMARC) prima di toccare la lista. Un dominio di invio mal configurato genera 5.1.7 indipendentemente dalla qualità degli indirizzi destinatari.
Fare list hygiene regolarmente — eliminare i bounce, gli inattivi di lunga data e i catchall non verificati — riduce la probabilità di accumulare 501 in sessione.
Quello che le guide non dicono: l’effetto di accumulo sulla reputazione
Un 501 isolato non distrugge una reputazione. Il problema si presenta quando si accumulano su più campagne consecutive dalla stessa IP o dallo stesso dominio di invio. Gmail Postmaster Tools e Microsoft SNDS tracciano il tasso di rifiuti permanenti per dominio mittente. Un tasso di hard bounce superiore al 2% su una campagna è sufficiente per attivare un throttling o un blocco temporaneo da parte di alcuni server.
Un dettaglio che molte guide sugli errori SMTP saltano: i server destinatari comunicano tra loro tramite i sistemi di reputazione condivisa (Spamhaus, Senderscore, Microsoft SNDS). Un mittente che accumula bounce permanenti su Gmail può vedere il suo IP warmup compromesso su Outlook qualche settimana dopo, anche se non ha mai avuto problemi diretti con quel server.
La buona pratica, come documentato nelle linee guida per i mittenti Gmail aggiornate nel 2024, raccomanda di mantenere il tasso di spam sotto lo 0,1% e fissa la soglia dura di rifiuto allo 0,3%. La tolleranza sui rifiuti permanenti ripetuti è dello stesso ordine di grandezza.
Un 501 si legge. Trenta secondi in più rispetto all’ignorare il bounce. La differenza è tra correggere e rispedire nello stesso errore.
