# Email deliverability: diagnostica il percorso verso l’inbox URL canonico: https://brew.new/it/blog/email-deliverability Autore: Brew Team Pubblicato: 2026-08-23 Aggiornato: 2026-09-29 Consegna e posizionamento in inbox sono due cose diverse. Un server ricevente può accettare un messaggio e metterlo nello spam. Una dashboard della campagna che mostra “consegnata” non dimostra che il lettore l’abbia visto. Quando compare un problema, raccogli le prove prima di cambiare i testi o passare a un altro provider. L’anello debole potrebbe essere l’autenticazione, la reputazione, il pubblico o il messaggio stesso. ## Parti dalla risposta del server ricevente Per i messaggi rifiutati o rinviati, esamina la risposta SMTP effettiva e il codice di stato esteso (enhanced status code). Errori temporanei e rifiuti permanenti richiedono una gestione diversa. Le [FAQ di Google per i mittenti](https://support.google.com/mail/answer/14229414) descrivono entrambi i casi, ma non dicono che ogni mancata conformità produca ormai errori permanenti. Se i messaggi vengono accettati ma finiscono nello spam, esamina i risultati dell’autenticazione negli header ricevuti, i dati sulla reputazione forniti dai provider, dove disponibili, e i cambiamenti recenti nel pubblico o nei volumi. Qualche inbox di test aiuta a diagnosticare un problema, ma non misura il posizionamento sull’intera lista. ### Leggi il codice di stato esteso Un codice di stato esteso è formato da tre numeri separati da punti, definiti nella [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html). Il primo numero è la classe. Un codice che inizia con 4 indica un errore temporaneo, e il server di invio dovrebbe riprovare più tardi. Un codice che inizia con 5 indica un errore permanente, quindi ripetere l’invio dello stesso messaggio senza modifiche non servirà. Il secondo numero restringe l’ambito. I codici nell’intervallo X.1.X riguardano l’indirizzamento, e 5.1.1 di solito significa che la casella di posta non esiste: escludi quell’indirizzo. I codici nell’intervallo X.7.X riguardano la sicurezza o le policy, ed è lì che tendono a comparire i problemi di autenticazione e di reputazione. Google elenca le risposte restituite da Gmail nel suo [riferimento sugli errori SMTP](https://support.google.com/a/answer/3726730). Leggi il testo completo della risposta oltre al codice, perché lo stesso codice può coprire motivi diversi. ### Dove trovare i dati sulla reputazione presso i provider [Google Postmaster Tools](https://postmaster.google.com/) mostra come Gmail vede il tuo dominio di invio, compreso il tasso di spam segnalato dagli utenti a cui fanno riferimento i requisiti di Google. Il dominio si verifica con un record DNS. Gmail mostra i dati solo quando un dominio invia ogni giorno abbastanza email ai suoi utenti, quindi un piccolo mittente potrebbe vedere dashboard vuote. Smart Network Data Services di Microsoft, noto come [SNDS](https://substrate.office.com/ip-domain-management-snds/snds), fornisce report sulle email inviate da specifici indirizzi IP alle caselle di posta personali di Outlook.com, compresi i tassi di segnalazione di spam e gli invii finiti in spam trap. Registri gli indirizzi IP che controlli, quindi è più utile con IP di invio dedicati. Sugli IP condivisi, chiedi al tuo provider di invio cosa monitora. Nessuno dei due strumenti ti dice dove è finita una singola campagna. Mostrano tendenze giornaliere, ed è proprio ciò che ti serve quando un problema si è accumulato nel corso di più invii. ## Verifica l’identità sui messaggi reali SPF autorizza l’infrastruttura di invio per un dominio della busta. DKIM firma un messaggio con l’identità di un dominio. DMARC verifica l’allineamento con il dominio From visibile e pubblica una policy e un meccanismo di report. Nessuno dei tre garantisce il posizionamento in inbox. Usa i record forniti dal tuo provider di invio e verifica il risultato su un messaggio realmente ricevuto. Non aggiungere record SPF in conflitto tra loro e non dare per scontato che un record DNS dimostri che ogni percorso di invio lo usa correttamente. La tua infrastruttura ha bisogno anche di un DNS inverso adeguato e di un trasporto sicuro. In Brew, segui la procedura di verifica del dominio e pubblica i record richiesti. Controlla l’indirizzo del mittente usato dalla campagna o dall’automazione effettiva, soprattutto quando un agente gestisce più brand. ### Porta DMARC dal monitoraggio all’applicazione della policy Una policy DMARC è un record TXT sull’host `_dmarc` del dominio presente nell’indirizzo From. Inizia con `p=none`: chiede ai server riceventi di non intraprendere azioni specifiche sulle email che non superano il controllo, ma i server continuano a inviare report aggregati all’indirizzo `rua`. ```text _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` I report elencano ogni fonte che invia email a nome del tuo dominio e indicano se ciascuna ha superato SPF o DKIM con allineamento. Aspettati di trovare strumenti che avevi dimenticato, come un sistema di fatturazione o un help desk. Correggi o rimuovi ogni fonte che non supera il controllo. Quando tutte le email legittime superano il controllo, passa a `p=quarantine`. Questa policy chiede ai server riceventi di trattare come sospette le email che non lo superano, il che di solito significa metterle nello spam. ```text _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` La policy più rigida, `p=reject`, chiede ai server riceventi di rifiutare le email che non superano il controllo. Passaci solo dopo che quarantine è rimasta attiva per un po’ senza che alcuna email legittima abbia fallito il controllo. Continua a leggere i report in ogni fase: un nuovo strumento che inizia a inviare a nome del tuo dominio comparirà prima lì. Un sottodominio di invio dedicato, come `mail.example.com`, è l’eccezione. Se nient’altro invia da lì e il tuo provider ne ha verificato SPF e DKIM, può partire direttamente da `p=reject`. Brew consiglia `p=reject` per un sottodominio dedicato configurato da Brew e `p=none` per un dominio principale da cui potrebbero inviare altri servizi. ## Leggi i requisiti direttamente alla fonte Le [linee guida di Google](https://support.google.com/mail/answer/81126) distinguono i requisiti per tutti i mittenti dalle regole più rigide per chi arriva a circa 5.000 messaggi al giorno verso account Gmail personali. Google chiede tassi di spam inferiori allo 0,1% e mette in guardia dal raggiungere lo 0,3%. I suoi requisiti per i grandi volumi includono SPF e DKIM, DMARC, allineamento e disiscrizione con un clic per i messaggi pertinenti inviati agli iscritti. ### Requisiti di Google per tutti i mittenti L’elenco di Google per ogni mittente, a qualsiasi volume, include questi punti: - Configura SPF o DKIM per il tuo dominio di invio. - Assegna ai domini o agli IP di invio record DNS diretti e inversi validi. - Invia tramite una connessione TLS. - Mantieni il tasso di spam riportato in Postmaster Tools sotto i limiti indicati sopra. - Formatta i messaggi secondo la RFC 5322. ### Requisiti aggiuntivi per i mittenti di grandi volumi I mittenti di grandi volumi devono inoltre: - Configurare sia SPF sia DKIM. - Pubblicare un record DMARC per il dominio di invio. Google accetta una policy `p=none`. - Allineare il dominio From con il dominio SPF o con il dominio DKIM. - Supportare la disiscrizione con un clic per i messaggi di marketing e per quelli inviati agli iscritti, e includere nel corpo del messaggio un link di disiscrizione ben visibile. Quando applica la soglia, Google somma le email provenienti dallo stesso dominio principale, e un dominio che l’ha superata una volta mantiene la qualifica di mittente di grandi volumi. Le sue [FAQ per i mittenti](https://support.google.com/mail/answer/14229414) spiegano come funziona il conteggio. Anche le [indicazioni di Yahoo](https://senders.yahooinc.com/best-practices/) trattano autenticazione, segnalazioni di spam e disiscrizioni. Yahoo non pubblica la stessa soglia numerica per i mittenti di grandi volumi: consulta le sue [FAQ](https://senders.yahooinc.com/faqs/) invece di applicare il numero di Gmail a tutti i provider. ### Microsoft Outlook.com Microsoft [ha annunciato nel 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) che i domini che inviano più di 5.000 email al giorno alle sue caselle di posta personali, cioè agli indirizzi outlook.com, hotmail.com e live.com, devono superare SPF e DKIM e pubblicare DMARC. La policy DMARC può essere `p=none`, e il dominio dell’indirizzo From deve essere allineato con SPF o DKIM. Indicazioni dei provider verificate il 28 settembre 2026. Controlla le pagine linkate quando diagnostichi un nuovo incidente. ## Testa il funzionamento della disiscrizione La disiscrizione con un clic prevista dalla [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) è un meccanismo basato su header e su una richiesta POST HTTPS. Anche un link visibile nel footer è utile, ed è richiesto dalle norme pertinenti, ma una pagina delle preferenze da sola non implementa il protocollo. Un messaggio che supporta la disiscrizione con un clic contiene due header: ```text List-Unsubscribe: , List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` Quando il lettore annulla l’iscrizione dall’inbox, il provider di posta invia una richiesta POST all’URL HTTPS con il corpo `List-Unsubscribe=One-Click`. L’indirizzo `mailto:` è un’alternativa per i programmi di posta che non supportano la disiscrizione con un clic. La RFC 8058 richiede inoltre una firma DKIM valida che copra entrambi gli header. Rendi l’URL specifico per ogni destinatario e difficile da indovinare. Gli scanner di sicurezza aprono spesso i link delle email in arrivo, quindi una semplice richiesta GET a quell’URL non dovrebbe annullare l’iscrizione di nessuno. Brew aggiunge gli header `List-Unsubscribe` e `List-Unsubscribe-Post` agli invii di marketing, con un URL HTTPS firmato e specifico per ogni destinatario che accetta la richiesta POST della disiscrizione con un clic. Verifica che una disiscrizione dal marketing blocchi gli invii di marketing successivi su ogni percorso di invio che usi. Conserva le esclusioni quando importi contatti o cambi piattaforma. Tieni i [messaggi transazionali](/it/blog/transactional-emails) essenziali separati per finalità e configurazione di invio. ## Controlla il pubblico prima di aumentare i volumi Verifica da dove arrivano gli indirizzi e cosa si aspettavano le persone al momento dell’iscrizione. Rimuovi gli indirizzi non validi tramite la procedura di esclusione del provider, indaga sui picchi di segnalazioni di spam ed evita di inviare di nuovo alle persone solo perché il tracciamento dice che non hanno aperto. Non esiste un’età della lista, un rapporto tra immagini e testo o una parola vietata che valga in assoluto e garantisca la consegna. Un aumento improvviso dei volumi verso una lista che conosci poco è un problema più serio dell’uso della parola “gratis”. Se [è un agente a inviare la campagna](/it/blog/agent-email-deliverability), valgono gli stessi controlli. Usa fatti verificati, un pubblico pertinente e un indirizzo di risposta monitorato. Correggi la causa individuata, invia un test controllato e rivedi le risposte dei provider prima di aumentare di nuovo i volumi.