Perché le email finiscono nello spam, e cosa aiuta davvero
I consigli soliti girano intorno all'oggetto. La consegna la decidono tre record DNS, la reputazione del tuo dominio e la qualità della tua lista.
Il copione è quasi sempre lo stesso. La conferma del modulo non arriva mai al cliente, la newsletter finisce nella scheda promozioni o nello spam per metà dei destinatari, e la prima ricerca di una soluzione porta a un elenco di parole da evitare nell'oggetto. Via il punto esclamativo, quindi, e "gratis" viene riscritto. Dopo non cambia nulla.
Succede perché quel consiglio agisce sulla leva più piccola. Un server di posta che riceve un messaggio si chiede prima chi sta scrivendo e solo dopo cosa c'è scritto. Alla prima domanda rispondono tre record DNS e quello che il tuo dominio ha spedito nelle ultime settimane. Nulla di tutto questo sta nell'oggetto.
Questo articolo mette le leve in ordine di effetto. Alla fine si sa quale record toccare per primo.
Il lavoro rende in questo ordine
Gran parte delle liste di controllo sul recapito butta venti voci nello stesso mucchio senza pesarne nessuna. Messa in ordine di effetto, la questione diventa più chiara:
- Autenticazione. SPF, DKIM e DMARC sono configurati e l'allineamento regge.
- Percorso di invio. Le email partono da un server che i tuoi stessi record DNS autorizzano a spedire per il dominio.
- Qualità della lista. In lista ci sono indirizzi con consenso documentato e i rimbalzi vengono rimossi.
- Reputazione del mittente. Volume e frequenza corrispondono a quello che quel dominio ha spedito finora.
- Contenuto. Oggetto, testo, rapporto tra immagini e testo, numero e destinazione dei link.
Il punto cinque è quello di cui si scrive di più. Comincia a contare solo quando i quattro sopra sono a posto. Chi inverte l'ordine lima frasi in un messaggio che il server ricevente non riesce comunque ad attribuire a nessuno.
Cosa controllano davvero i tre record
I tre vengono nominati sempre insieme e confusi con la stessa frequenza. Rispondono a tre domande diverse.
SPF dice quali server possono spedire
SPF è descritto nella RFC 7208. È un record TXT sul tuo dominio in cui è scritto quali server possono consegnare posta a nome di quel dominio. Il server che riceve confronta l'indirizzo IP di chi consegna con quell'elenco e ottiene una risposta: se il percorso è permesso oppure no.
Il secondo errore più frequente della pratica sta esattamente qui. La valutazione di un record SPF può innescare al massimo dieci interrogazioni DNS, e ogni servizio incluso ne costa almeno una. Aggiungendo uno dopo l'altro il fornitore della casella, un servizio di newsletter, uno strumento di fatturazione e un sistema di ticket, prima o poi si supera il limite. Il risultato è un permerror, e un record SPF con permerror non vale nulla. Nel pannello DNS continua ad avere un aspetto del tutto normale.
DKIM dimostra che nulla è stato modificato per strada
DKIM sta nella RFC 6376. In fase di invio viene inserita una firma crittografica nell'intestazione del messaggio, e la chiave pubblica corrispondente sta nel DNS del tuo dominio. Chi riceve verifica così due cose insieme: il messaggio proviene davvero da quel dominio e la parte firmata è arrivata invariata.
DMARC lega i due risultati a un'istruzione
DMARC è descritto nella RFC 7489 ed è il record che trasforma due esiti in una decisione. Lì si stabilisce cosa deve fare chi riceve quando il controllo fallisce. I valori sono tre: none significa non fare nulla, quarantine significa mettere nello spam, reject significa rifiutare. DMARC apre inoltre il canale dei rapporti che raccontano chi spedisce a tuo nome.
L'errore di gran lunga più comune sul campo: il record resta su p=none per sempre. Come punto di partenza è corretto, perché la prima cosa che serve è vedere cosa esce a tuo nome. Come stato permanente è una riga nel DNS senza effetto. Un record che fa sul serio alla fine si presenta così:
_dmarc.latuaazienda.it. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@latuaazienda.it"L'allineamento è il punto in cui cade la maggior parte delle configurazioni
Qui sta la cosa che quasi nessuna guida racconta. DMARC non verifica solo se SPF o DKIM hanno superato il controllo. Pretende anche che il dominio mittente visibile corrisponda al dominio verificato. Si chiama allineamento, in inglese alignment, ed è il termine che compare negli strumenti.
Nella pratica succede questo. La newsletter parte da un servizio di invio. Nel campo mittente compare il tuo indirizzo. Tecnicamente però consegna il servizio, che ha un record SPF pulito per il proprio dominio. SPF quindi passa. Anche la firma viene apposta con il dominio del servizio. Per DMARC la scena è questa: è stato verificato un dominio estraneo mentre quello visibile è il tuo. L'allineamento fallisce, con lui fallisce DMARC, e ogni strumento di controllo continua a mostrare uno SPF verde.
Da ogni fornitore serio la via d'uscita è la stessa: si registra il proprio dominio nell'account del servizio di invio e si pubblica nel proprio DNS la chiave DKIM che il servizio rilascia per quel dominio. Da quel momento la firma è emessa a nome del tuo dominio, l'allineamento regge e DMARC passa.
Cosa chiedono Google, Yahoo e Microsoft a chi spedisce in massa
Da febbraio 2024 Google e Yahoo applicano requisiti ai mittenti di massa, quindi a grandi linee a chi spedisce più di circa 5.000 messaggi al giorno verso account Gmail. Sono richiesti SPF, DKIM e DMARC, una disiscrizione in un clic funzionante nell'intestazione del messaggio secondo la RFC 8058 e un tasso di reclami per spam sotto lo 0,3 per cento. Microsoft ha annunciato e applicato requisiti comparabili per Outlook.com nel 2025.
Chi resta molto sotto quel volume formalmente non è un mittente di massa. Questo però non cambia nulla nella configurazione: i tre record costano un'ora una volta sola, la disiscrizione in un clic la mette lo strumento di invio, e il tasso di reclami dipende dallo stato della lista a qualsiasi volume. L'unica differenza sotto la soglia è che nessuno ti sta misurando.
Trova il tuo caso in questa tabella
| Sintomo | Causa probabile | Come verificare |
|---|---|---|
| Le conferme dei moduli non arrivano da nessuna parte | Invio dal percorso PHP predefinito del server web, senza SPF e senza firma | Guardare le intestazioni di un messaggio di prova e vedere quale server ha consegnato |
| Gmail accetta i messaggi, Outlook.com li mette da parte | DMARC assente oppure su p=none | Interrogare il record TXT sotto _dmarc e leggere il valore dopo p |
| La newsletter finisce nello spam, le fatture no | Due percorsi di invio, solo uno firmato con il tuo dominio | Confrontare la firma DKIM nell'intestazione dei due tipi di messaggio |
| SPF passa e DMARC fallisce comunque | Allineamento: il dominio mittente visibile non corrisponde a quello verificato | Leggere la riga Authentication-Results, lì spf=pass sta accanto a dmarc=fail |
| Gli strumenti segnalano permerror su SPF | Il record innesca più di dieci interrogazioni DNS | Contare tutti gli include e togliere i servizi non più in uso |
| Prima consegna buona, poi spam all'improvviso | Volume aumentato troppo in fretta o tasso di reclami in crescita | Rivedere i volumi delle ultime settimane e le disiscrizioni per invio |
Perché il primo invio grande viene quasi sempre frenato
I sistemi che ricevono tengono una specie di storico per ogni dominio che spedisce. Un dominio che per anni non ha mandato nulla e poi consegna 2.000 messaggi in un martedì mattina sembra un account compromesso. Viene frenato, e quanto siano puliti i record DNS non cambia niente.
La via d'uscita si chiama riscaldamento, warmup negli strumenti, e non ha nulla di spettacolare. Si parte piccoli e si alza il volume nell'arco di più settimane. Meglio cominciare dai destinatari che hanno aperto, cliccato o comprato di recente, perché è la loro reazione a costruire la reputazione. I contatti di cui non si hanno notizie da tempo vengono dopo.
Se il contatto più recente della lista ha tre anni, il riscaldamento da solo serve a poco. In quel caso il lavoro sulla lista viene prima dell'invio.
Una lista curata rende più di qualsiasi ottimizzazione del testo
Liste comprate, indirizzi vecchi di anni e rimbalzi mai gestiti costano più recapito di qualunque parola sospetta evitata nell'oggetto. Il motivo è semplice: ogni messaggio a un indirizzo morto e ogni reclamo è un segnale che conta direttamente contro la reputazione.
Le regole sono corte. Gli hard bounce, cioè gli indirizzi definitivamente non recapitabili, escono subito dalla lista. I soft bounce si possono ritentare più volte e poi si rimuovono. Un reclamo vale come disiscrizione immediata, senza chiedere conferma. Gli indirizzi che da anni non aprono nulla sono un rischio per tutti gli altri in lista.
All'inizio di tutto c'è il consenso. Come si presenta un doppio opt-in pulito, cosa va registrato e perché aiuta anche sul piano tecnico è il tema dell'articolo su doppio opt-in e GDPR. Questo è un inquadramento pratico e non una consulenza legale, per una valutazione vincolante del tuo caso serve qualcuno abilitato.
WordPress di serie spedisce dalla strada sbagliata
Merita un punto a sé, perché nei progetti piccoli è la singola causa più frequente. WordPress spedisce tramite wp_mail e, senza altra configurazione, si finisce sulla funzione PHP mail(), che passa il messaggio direttamente al server web. Quel server web di norma non compare in nessun record SPF del tuo dominio e non firma nulla. Il messaggio esce e fallisce entrambi i controlli nello stesso momento.
La via d'uscita abituale è portare l'invio su SMTP o sull'API del proprio fornitore, con il proprio dominio verificato. Riguarda tutto quello che il sito spedisce da solo: conferme dei moduli, email di reimpostazione password, conferme d'ordine e fatture. Per il cliente questi messaggi contano più di qualsiasi newsletter, e sono proprio quelli che spariscono nel modo più silenzioso.
Dove stai sprecando tempo
Resta la domanda su cosa sopravviva dei consigli soliti. Le parole sospette nell'oggetto sono il classico, e oggi sono in buona parte folklore. I filtri pesano il comportamento del mittente molto più delle singole parole. La parola "gratis" nell'oggetto non è un problema finché il mittente ha una buona reputazione, e non salva nulla finché non ce l'ha.
Questo non rende inutile il lavoro sull'oggetto. Semplicemente rende sul tasso di apertura e non sulla consegna. Tenere separati i due cantieri risparmia parecchie riscritture inutili.
p=none, hai i rapporti e nessun effetto. Se lì non c'è niente, non hai nemmeno i rapporti.Newsletter dal tuo WordPress, con un occhio alla consegna
Kurato spedisce tramite il tuo accesso al fornitore e porta con sé disiscrizione in un clic secondo la RFC 8058, gestione di rimbalzi e reclami e un semaforo di recapito per SPF, DKIM e DMARC. I dati di contatto restano nel tuo database.
Cosa copre la versione gratuita e dove comincia Pro sta sulla pagina dei prezzi. Per onestà: le sequenze di automazione con diramazioni in Kurato sono ancora in lavorazione.
Domande frequenti
Che differenza c'è tra SPF, DKIM e DMARC?
SPF (RFC 7208) dice quali server possono spedire per il tuo dominio. DKIM (RFC 6376) inserisce una firma crittografica con cui chi riceve verifica che il messaggio provenga dal tuo dominio e non sia stato modificato per strada. DMARC (RFC 7489) lega i due esiti a un'istruzione su cosa fare in caso di fallimento e attiva i rapporti. Solo tutti e tre insieme danno un quadro completo.
Il mio record DMARC è su p=none. Basta così?
Come punto di partenza sì, come stato permanente no. Con p=none non succede nulla quando un controllo fallisce, arrivano solo i rapporti. Il senso di quella fase è vedere per qualche settimana chi spedisce a tuo nome. Poi l'istruzione va portata su quarantine e più avanti su reject, altrimenti il record resta una riga senza effetto.
SPF passa ma DMARC fallisce lo stesso. Com'è possibile?
Quasi sempre è l'allineamento. DMARC pretende che il dominio mittente visibile corrisponda al dominio verificato da SPF o DKIM. Chi spedisce tramite un servizio di invio senza verificare e firmare lì il proprio dominio supera SPF per il dominio del servizio e fallisce DMARC. La soluzione è la chiave DKIM emessa per il proprio dominio.
Serve evitare parole sospette nell'oggetto?
Poco. I filtri di oggi pesano il comportamento del mittente molto più delle singole parole. Un mittente con buona reputazione passa senza problemi con la parola gratis nell'oggetto, uno senza reputazione fallisce anche con la formulazione più cauta. Il lavoro sull'oggetto rende sul tasso di apertura, sulla consegna incide poco.
Perché le conferme dei moduli di WordPress finiscono nello spam?
Perché senza altra configurazione WordPress spedisce con la funzione PHP mail() e il messaggio parte quindi dal server web. Quel server di norma non compare in nessun record SPF del tuo dominio e non firma nulla, quindi SPF e DKIM falliscono insieme. La via abituale è portare l'invio su SMTP o sull'API del proprio fornitore con il proprio dominio verificato.
