Trasforma le email in fatturato con Brew.
Controlla autenticazione, risposte dei provider, qualità del pubblico e disiscrizioni per capire perché un’email viene rifiutata o finisce nello spam.
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.
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 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.
Un codice di stato esteso è formato da tre numeri separati da punti, definiti nella RFC 3463. 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. Leggi il testo completo della risposta oltre al codice, perché lo stesso codice può coprire motivi diversi.
Google Postmaster Tools 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, 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.
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.
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.
_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.
_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.
Le linee guida di Google 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.
L’elenco di Google per ogni mittente, a qualsiasi volume, include questi punti:
I mittenti di grandi volumi devono inoltre:
p=none.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 spiegano come funziona il conteggio.
Anche le indicazioni di Yahoo trattano autenticazione, segnalazioni di spam e disiscrizioni. Yahoo non pubblica la stessa soglia numerica per i mittenti di grandi volumi: consulta le sue FAQ invece di applicare il numero di Gmail a tutti i provider.
Microsoft ha annunciato nel 2025 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.
La disiscrizione con un clic prevista dalla RFC 8058 è 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:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickQuando 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 essenziali separati per finalità e configurazione di invio.
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, 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.
