Testare la deliverability delle email: la guida completa prima dell'invio
Di CaptainDNS
Pubblicato il 27 marzo 2026
- Un'email su cinque non raggiunge mai la casella di posta, principalmente a causa di un'autenticazione SPF, DKIM o DMARC assente o mal configurata
- Punteggio di deliverability: SPF (+25), DKIM (+25), DMARC (+20), MX/PTR (+15), header (+15) = 100 punti possibili
- Dal 2024: Gmail e Yahoo richiedono SPF + DKIM obbligatori, e DMARC per i mittenti di massa (> 5 000 email/giorno)
- Correzione prioritaria: un test di 30 secondi identifica i problemi esatti, questa guida spiega come correggerli uno per uno
Hai appena lanciato una campagna email. Tutto è pronto: il contenuto è curato, il design è impeccabile, la lista di destinatari è pulita. Tre giorni dopo, arrivano le statistiche: il 22 % delle tue email non ha mai raggiunto la casella di posta. Nessun bounce. Nessun errore visibile. I tuoi messaggi sono semplicemente scomparsi in una cartella spam o sono stati silenziosamente rifiutati dal server di ricezione.
Questo scenario non è un caso estremo. Secondo i dati di Validity (Sender Score), un'email su cinque inviata nel mondo non raggiunge mai la casella di posta del suo destinatario. Per le aziende, il costo è diretto: fatture ignorate, conferme d'ordine perse, prospect di marketing sprecati, e una reputazione di dominio che si degrada silenziosamente.
La buona notizia: la maggior parte di questi problemi è rilevabile prima dell'invio. Un test di deliverability analizza la tua configurazione DNS (SPF, DKIM, DMARC), verifica la reputazione del tuo IP, controlla i tuoi header email e produce un punteggio globale su 100. In 30 secondi, sai esattamente cosa funziona e cosa blocca le tue email.
Questa guida copre il processo completo: perché testare, come funziona un test di deliverability, come interpretare ogni sezione del punteggio, e soprattutto come correggere i problemi identificati per passare da 40/100 a 100/100. Che tu sia amministratore di sistema, sviluppatore o responsabile marketing, ogni sezione contiene azioni concrete.
Testa la tua deliverability adesso
Perché testare la deliverability prima di ogni invio
Il problema invisibile
La deliverability delle email è un problema silenzioso. A differenza di un sito web fuori servizio (visibile immediatamente), un'email che finisce nello spam non genera alcun allarme. Il mittente pensa che il messaggio sia stato consegnato. Il destinatario non sa che un'email lo aspetta nella cartella spam. Nessuno si lamenta perché nessuno lo sa.
I provider di posta (Gmail, Outlook, Yahoo, Apple Mail) prendono decisioni di filtraggio in pochi millisecondi, basandosi su centinaia di segnali. E questi segnali evolvono costantemente. Un dominio che superava tutti i controlli sei mesi fa può fallire oggi perché un fornitore ha aggiunto un include SPF aggiuntivo, o perché la rotazione della chiave DKIM non è stata effettuata.
I 5 controlli di un test di deliverability
Un test completo verifica cinque categorie distinte, ognuna contribuendo al punteggio globale:
| Categoria | Punti | Cosa viene verificato |
|---|---|---|
| SPF | 25/100 | Record DNS TXT valido, IP del mittente autorizzato, numero di lookup |
| DKIM | 25/100 | Firma crittografica valida, chiave pubblica DNS accessibile, allineamento del dominio |
| DMARC | 20/100 | Policy pubblicata, allineamento SPF/DKIM, indirizzo di report configurato |
| MX / PTR | 15/100 | Record MX presenti, reverse DNS configurato, IP non in blacklist |
| Header | 15/100 | From/Reply-To coerenti, Message-ID valido, nessun campo sospetto |
Un punteggio inferiore a 70/100 significa che le tue email hanno una probabilità significativa di essere classificate come spam. Sotto i 50/100, la maggior parte dei provider rifiuterà o filtrerà i tuoi messaggi.
Le esigenze di Gmail e Yahoo 2024
Da febbraio 2024, Gmail e Yahoo hanno reso obbligatori controlli che prima erano opzionali. Queste esigenze si applicano a tutti i mittenti, con regole aggiuntive per gli invii di massa:
Per tutti i mittenti:
- SPF o DKIM valido (almeno uno dei due)
- Record DNS di tipo PTR (reverse DNS) configurato per l'IP di invio
- Tasso di spam dichiarato in Google Postmaster Tools inferiore allo 0,3 %
Per i mittenti di massa (> 5 000 email/giorno verso Gmail):
- SPF e DKIM validi (entrambi obbligatori)
- DMARC pubblicato con almeno
p=none - Allineamento del dominio From con SPF o DKIM
- Header
List-Unsubscribecon disiscrizione in un clic (RFC 8058) - Formattazione conforme alla RFC 5322
Non rispettare queste esigenze provoca un rifiuto progressivo. Gmail non blocca il 100 % delle email da un giorno all'altro: inizia differendo il 4 % dei messaggi (codice 4xx), poi aumenta la percentuale fino al rifiuto permanente (codice 5xx) se il problema non viene corretto.
Come funziona un test di deliverability
Un test di deliverability riproduce il processo esatto che un server di ricezione esegue quando riceve la tua email. Ecco le quattro fasi, in ordine.
Fase 1: risoluzione DNS e verifica SPF
Il test inizia interrogando il DNS del tuo dominio per recuperare il record SPF.
# Recuperare il record SPF di captaindns.com
dig TXT captaindns.com +short | grep "v=spf1"
Il record SPF è un record DNS di tipo TXT che inizia con v=spf1. Elenca i server autorizzati a inviare email per il tuo dominio. Ecco un esempio reale:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
Il server di ricezione confronta l'IP del server che ha inviato l'email con le IP autorizzate dal tuo SPF. Il processo è ricorsivo: ogni include: innesca una nuova query DNS per recuperare le IP del sottodominio referenziato.
Punto critico: la RFC 7208 limita a 10 il numero di query DNS (lookup) durante la valutazione SPF. I meccanismi include, a, mx, redirect e exists contano ciascuno come un lookup. I meccanismi ip4 e ip6 non contano (sono valori diretti). All'undicesimo lookup, il server restituisce permerror e il tuo SPF è considerato invalido.
# Verificare quanti lookup genera il tuo SPF
# Ogni include genera almeno 1 lookup
dig TXT _spf.google.com +short
# Risultato: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ..."
# Ogni sotto-include conta anche!
Fase 2: verifica della firma DKIM
DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica a ogni email. Il server di invio firma il messaggio con una chiave privata. Il server di ricezione verifica questa firma recuperando la chiave pubblica corrispondente nel DNS.
La firma DKIM è presente nell'header DKIM-Signature dell'email:
DKIM-Signature: v=1; a=rsa-sha256; d=captaindns.com; s=google;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
I campi chiave:
d=: il dominio che rivendica la firma (deve corrispondere al dominio From per DMARC)s=: il selettore, che identifica quale chiave pubblica usarea=: l'algoritmo di firma (rsa-sha256oed25519-sha256)bh=: l'hash del corpo del messaggiob=: la firma stessa
Il test recupera la chiave pubblica via DNS:
# Recuperare la chiave pubblica DKIM
# Formato: selettore._domainkey.dominio
dig TXT google._domainkey.captaindns.com +short
La risposta contiene un record TXT con la chiave pubblica:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
Il server di ricezione utilizza questa chiave pubblica per verificare la firma. Se il corpo del messaggio o gli header firmati sono stati modificati dopo la firma, la verifica fallisce.
RSA vs Ed25519: la maggior parte dei server utilizza RSA-SHA256 con chiavi da 2048 bit. Ed25519 è più veloce e genera firme più corte, ma il supporto lato ricezione non è ancora universale. Google Workspace e Microsoft 365 supportano solo RSA per la firma DKIM in uscita a marzo 2026.
Fase 3: valutazione DMARC e allineamento
DMARC (Domain-based Message Authentication, Reporting, and Conformance) verifica che SPF e DKIM non siano solo validi, ma anche allineati con il dominio visibile nel campo From dell'email.
# Recuperare la policy DMARC
dig TXT _dmarc.captaindns.com +short
Risultato tipico:
"v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"
Analizziamo ogni tag:
| Tag | Valore | Significato |
|---|---|---|
v=DMARC1 | obbligatorio | Identifica il record come DMARC |
p= | none, quarantine, reject | Policy applicata alle email che falliscono |
rua= | indirizzo email | Destinazione dei report aggregati (statistiche giornaliere) |
ruf= | indirizzo email | Destinazione dei report forensi (campioni di fallimenti) |
adkim= | r (relaxed) o s (strict) | Modalità di allineamento DKIM |
aspf= | r (relaxed) o s (strict) | Modalità di allineamento SPF |
pct= | 0-100 | Percentuale di email sottoposte alla policy |
Allineamento relaxed vs strict: in modalità relaxed (adkim=r), il dominio della firma DKIM (d=) deve condividere lo stesso dominio organizzativo del From. Esempio: una firma d=mail.captaindns.com è allineata con un From contact@captaindns.com. In modalità strict (adkim=s), i domini devono corrispondere esattamente.
La valutazione DMARC segue questa logica:
- SPF passa e è allineato con il From: DMARC passa.
- DKIM passa e è allineato con il From: DMARC passa.
- Se nessuno dei due è allineato: DMARC fallisce, e la policy (
p=) si applica.
Un punto spesso frainteso: DMARC passa se almeno uno dei due meccanismi (SPF o DKIM) passa con allineamento. Non è necessario che entrambi riescano.
Fase 4: controlli complementari (MX, PTR, header, blacklist)
Il test verifica poi elementi tecnici aggiuntivi:
Record MX: il dominio deve avere record MX validi che puntano a server di posta attivi. Un dominio senza MX segnala un dominio che non è configurato per ricevere posta, il che è sospetto per un mittente.
dig MX captaindns.com +short
# 10 mx1.captaindns.com.
# 20 mx2.captaindns.com.
Reverse DNS (PTR): l'IP del server di invio deve avere un record PTR che risolve verso un hostname, e quell'hostname deve risolvere a sua volta verso la stessa IP. È la verifica FCrDNS (Forward-confirmed reverse DNS).
# Verificare il reverse DNS di un IP
dig -x 203.0.113.10 +short
# mail.captaindns.com.
# Verificare che il forward corrisponde
dig A mail.captaindns.com +short
# 203.0.113.10
Blacklist: l'IP di invio viene verificata contro le principali blacklist (Spamhaus ZEN, Barracuda, SORBS, SpamCop). La presenza in una sola blacklist importante può bastare a far rifiutare le tue email dalla maggior parte dei provider.
Header email: il test verifica la coerenza degli header From, Reply-To, Message-ID, Date e la presenza dei campi obbligatori secondo la RFC 5322.
Interpretare i risultati sezione per sezione
Una volta eseguito il test, il report mostra un punteggio globale e un dettaglio per categoria. Ecco come leggere ogni sezione e identificare le azioni prioritarie.
Sezione SPF (25 punti)
| Risultato | Punti | Significato | Azione |
|---|---|---|---|
pass | 25/25 | L'IP di invio è autorizzata dal tuo SPF | Nessuna azione |
softfail | 10/25 | L'IP non è esplicitamente autorizzata (~all) | Passare a -all dopo verifica |
fail | 0/25 | L'IP è esplicitamente rifiutata dal tuo SPF | Aggiungere l'IP o l'include mancante |
permerror | 0/25 | Il record SPF è invalido | Correggere la sintassi o ridurre i lookup |
none | 0/25 | Nessun record SPF trovato | Creare un record SPF |
Errore frequente: un risultato softfail dà l'impressione che "passa comunque". In realtà, i server moderni trattano il softfail quasi come un fail, soprattutto in combinazione con un DMARC in modalità quarantine o reject. Il softfail dovrebbe essere solo una fase transitoria durante il deploy iniziale dell'SPF.
Sezione DKIM (25 punti)
| Risultato | Punti | Significato | Azione |
|---|---|---|---|
pass | 25/25 | Firma valida e chiave pubblica trovata | Nessuna azione |
fail | 0/25 | Firma invalida (corpo modificato, chiave errata) | Diagnosticare la causa esatta |
none | 0/25 | Nessuna firma DKIM nell'email | Configurare DKIM sul server di invio |
permerror | 0/25 | Chiave pubblica malformata o inaccessibile | Verificare il record DNS del selettore |
Il risultato dkim=fail è il più complesso da diagnosticare perché le cause sono molteplici: hash del body alterato da un relay intermedio, chiave pubblica assente dal DNS, firma scaduta (tag x= superato), o algoritmo di canonicalizzazione errato. Consulta la guida di diagnosi DKIM fail per un albero decisionale completo.
Sezione DMARC (20 punti)
| Risultato | Punti | Significato | Azione |
|---|---|---|---|
pass | 20/20 | SPF o DKIM allineato e valido | Nessuna azione |
fail (p=none) | 5/20 | Fallimento ma senza conseguenza (modalità sorveglianza) | Progredire verso quarantine poi reject |
fail (p=quarantine) | 0/20 | Email messe nello spam | Correggere l'allineamento SPF/DKIM |
fail (p=reject) | 0/20 | Email rifiutate | Correggere l'allineamento SPF/DKIM |
none | 0/20 | Nessun record DMARC | Creare un record DMARC |
La trappola di p=none: questa policy è indispensabile durante la fase di deploy, perché permette di raccogliere report senza impattare la consegna. Ma restare in p=none indefinitamente equivale a non avere DMARC in termini di protezione. I provider di posta accordano un credito di fiducia ai domini che pubblicano p=quarantine o p=reject.
Sezione MX / PTR (15 punti)
| Verifica | Punti | Criterio |
|---|---|---|
| MX validi | 5/15 | Almeno un record MX che risolve verso un IP attivo |
| PTR configurato | 5/15 | Reverse DNS dell'IP di invio che risolve verso un hostname |
| FCrDNS | 3/15 | Forward-confirmed reverse DNS (andata e ritorno IP/hostname) |
| Nessuna blacklist | 2/15 | IP assente dalle blacklist principali |
Il reverse DNS (PTR) è spesso trascurato perché dipende dal proprietario del range IP, non dal proprietario del dominio. Se utilizzi un VPS o un server dedicato, il PTR si configura tramite il pannello del tuo hosting provider. Se utilizzi un servizio di invio (SendGrid, Mailgun, Brevo), il PTR è normalmente gestito dal fornitore sui suoi IP dedicati.
Sezione header (15 punti)
| Verifica | Punti | Criterio |
|---|---|---|
| From valido | 4/15 | Indirizzo email sintatticamente corretto con dominio che risolve |
| Message-ID | 3/15 | Presente e in formato RFC 5322 |
| Date | 3/15 | Presente e in un intervallo ragionevole (non nel futuro, non > 7 giorni) |
| Reply-To coerente | 3/15 | Stesso dominio del From o dominio di fiducia |
| Nessun X-Mailer sospetto | 2/15 | Nessun software di spam noto negli header |
Un header Message-ID assente o malformato è un segnale forte di spam per i filtri. Ogni email deve avere un Message-ID unico nel formato <identificativo@dominio>. I server di posta correttamente configurati lo generano automaticamente, ma certi script PHP o librerie di invio personalizzate lo omettono.
Da 40/100 a 100/100: le correzioni passo dopo passo
Hai eseguito il test e il punteggio non è buono. Ecco l'ordine esatto delle correzioni, classificate per impatto sul punteggio.
Priorità 1: creare o correggere SPF (+25 punti)
Se il tuo SPF è assente o invalido, è la correzione che porta più punti immediatamente.
Caso 1: Nessun record SPF
Crea un record DNS TXT sul tuo dominio root:
captaindns.com. IN TXT "v=spf1 include:_spf.google.com -all"
Adatta i meccanismi ai tuoi servizi di invio:
| Servizio | Include da aggiungere |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
| Brevo (ex-Sendinblue) | include:sendinblue.com |
| Amazon SES | include:amazonses.com |
| OVHcloud | include:mx.ovh.com |
Caso 2: SPF PermError (troppi lookup)
Il limite di 10 lookup è la causa più frequente del PermError. Ogni include: conta come almeno 1 lookup, e gli include annidati si sommano. Google Workspace da solo consuma 4 lookup.
Per diagnosticare il problema:
# Contare i lookup del tuo SPF
dig TXT captaindns.com +short | grep "v=spf1"
# Poi seguire ogni include ricorsivamente
dig TXT _spf.google.com +short
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# = 3 lookup aggiuntivi solo per questo include
Soluzioni di riduzione:
- Sostituire gli
include:conip4:eip6:diretti quando gli IP sono stabili (SPF flattening) - Utilizzare le macro SPF (
%{i}eexists:) per i casi avanzati - Eliminare gli include di servizi che non utilizzi più
Per una guida dettagliata sul PermError, consulta la guida SPF PermError.
Caso 3: Due record SPF sullo stesso dominio
La RFC 7208 vieta rigorosamente la presenza di più record TXT che iniziano con v=spf1 sullo stesso dominio. Se ne hai due, il server restituisce immediatamente permerror.
# Verificare se ci sono duplicati
dig TXT captaindns.com +short | grep "v=spf1"
# Se appaiono due righe: unire in un unico record
Unisci i due record in uno solo che contenga tutti i meccanismi.
Priorità 2: configurare DKIM (+25 punti)
DKIM richiede due elementi: una chiave privata installata sul server di invio (che firma i messaggi) e una chiave pubblica pubblicata nel DNS (che permette la verifica).
Configurazione con Google Workspace:
- Google Admin Console > Apps > Google Workspace > Gmail > Authenticate email
- Seleziona il tuo dominio e clicca "Generate new record"
- Scegli una lunghezza di chiave di 2048 bit
- Copia il record DNS CNAME o TXT fornito
- Pubblicalo nella tua zona DNS con il formato
google._domainkey.captaindns.com - Torna nella console e clicca "Start authentication"
Configurazione con Microsoft 365:
Microsoft 365 utilizza due record CNAME per dominio:
selector1._domainkey.captaindns.com CNAME selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com
selector2._domainkey.captaindns.com CNAME selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com
Verifica post-configurazione:
# Verificare che la chiave pubblica sia accessibile
dig TXT google._domainkey.captaindns.com +short
# Dovrebbe restituire un record contenente "v=DKIM1; k=rsa; p=MII..."
Se il comando non restituisce nulla, il problema è DNS: o il record non si è ancora propagato (attendere 24-48h), o c'è un errore di denominazione nel selettore.
Lunghezza della chiave: utilizza 2048 bit come minimo. Le chiavi da 1024 bit sono considerate deboli dal 2020. Alcuni provider rifiutano già le firme basate su chiavi RSA inferiori a 1024 bit.
Priorità 3: pubblicare e rafforzare DMARC (+20 punti)
L'implementazione di DMARC segue un ciclo in tre fasi.
Fase 1: Sorveglianza (da 2 a 4 settimane)
_dmarc.captaindns.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@captaindns.com; pct=100"
Durante questa fase, nessuna email viene bloccata. I report aggregati (rua=) arrivano quotidianamente in formato XML e contengono le statistiche di autenticazione di tutti i server che hanno inviato email per il tuo dominio.
Analizza i report per identificare:
- Le fonti legittime che falliscono (server di fatturazione, CRM, strumento di marketing)
- Le fonti illegittime (tentativi di spoofing)
- Il tasso di allineamento SPF e DKIM
Fase 2: Quarantena (da 4 a 8 settimane)
_dmarc.captaindns.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@captaindns.com; pct=25"
Il pct=25 applica la policy di quarantena solo al 25 % delle email che falliscono. È una rete di sicurezza: se una fonte legittima non è stata ancora corretta, il 75 % delle sue email passa ancora. Aumenta progressivamente: 25 %, 50 %, 75 %, 100 %.
Fase 3: Rifiuto
_dmarc.captaindns.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rua@captaindns.com; ruf=mailto:dmarc-ruf@captaindns.com; adkim=r; aspf=r; pct=100"
A questo punto, ogni email che fallisce l'allineamento DMARC viene rifiutata dal server di ricezione. È la configurazione più sicura e quella che porta più credito di fiducia presso i provider.
Priorità 4: configurare il reverse DNS (+15 punti MX/PTR)
Record MX: se il tuo dominio non ha record MX, aggiungine uno che punti al tuo server di ricezione:
captaindns.com. IN MX 10 mx1.captaindns.com.
captaindns.com. IN MX 20 mx2.captaindns.com.
Reverse DNS: connettiti al pannello di amministrazione del tuo hosting provider e configura il PTR del tuo IP di invio affinché punti al FQDN del tuo server di posta:
# Dopo la configurazione, verifica:
dig -x 203.0.113.10 +short
# Atteso: mail.captaindns.com.
Blacklist: se il tuo IP appare su una blacklist, la procedura di rimozione dipende dalla lista:
| Blacklist | Procedura | Tempi |
|---|---|---|
| Spamhaus | Modulo di rimozione su spamhaus.org | 24-48h dopo la correzione |
| Barracuda | Modulo su barracudacentral.org | 12-24h |
| SORBS | Rimozione automatica dopo 48h senza spam | 48h |
| SpamCop | Scadenza automatica in 24h | 24h |
Priorità 5: pulire gli header (+15 punti)
I problemi di header sono spesso causati da script di invio personalizzati o librerie mal configurate.
Checklist degli header:
- Il campo
Fromutilizza un indirizzo con il tuo dominio, non un dominio generico - Il
Message-IDè presente e nel formato<unique-id@captaindns.com> - Il campo
Dateè presente e corretto (fuso orario incluso) - Il
Reply-To, se presente, utilizza un dominio coerente con il From - Nessun header
X-Mailerche referenzia uno strumento di spam noto - Il
Content-Typespecifica il charset (UTF-8 raccomandato)
Se utilizzi PHP mail(), passa a una libreria come PHPMailer o SwiftMailer che genera header conformi. Se utilizzi un framework (Laravel, Django, Rails), gli header sono generalmente corretti per default.
Gli errori più frequenti
SPF PermError: il limite di 10 lookup
È l'errore più diffuso. Un dominio che utilizza Google Workspace (4 lookup), SendGrid (2 lookup), Mailchimp (2 lookup) e un server interno (1 lookup con un a:) raggiunge già 9 lookup. L'aggiunta di un solo servizio in più provoca il PermError.
La diagnosi è semplice:
dig TXT captaindns.com +short | grep "v=spf1"
# Conta ogni include, a, mx, redirect, exists
# Segui gli include annidati ricorsivamente
La correzione dipende dalla tua situazione:
- Elimina i servizi inutilizzati: verifica se ogni include corrisponde a un servizio attivo
- Utilizza lo SPF flattening: sostituisci gli include con gli IP finali (attenzione alla manutenzione)
- Dedica un sottodominio: invia il marketing da
news.captaindns.comcon il suo proprio SPF
Se nonostante queste correzioni le tue email finiscono ancora nello spam, il problema va oltre l'SPF. Consulta la guida diagnostica completa dello spam per analizzare le altre cause (reputazione, contenuto, engagement).
DKIM fail: body hash did not verify
Questo errore significa che il contenuto dell'email è stato modificato dopo la firma. Le cause più comuni:
- Relay intermedio: un server tra l'invio e la ricezione ha aggiunto un footer, riscritto URL o iniettato un pixel di tracciamento
- Antivirus o DLP: un software di sicurezza ha modificato il corpo del messaggio
- Mailing list: i server di liste (Listserv, Sympa) aggiungono spesso un footer di disiscrizione che rompe la firma
La correzione consiste nell'identificare quale componente della tua catena di invio modifica il messaggio dopo la firma DKIM, e poi riconfigurare l'ordine delle operazioni affinché la modifica avvenga prima della firma.
Per le mailing list, il protocollo ARC (Authenticated Received Chain) permette di preservare i risultati di autenticazione attraverso i relay. Gmail e Microsoft supportano ARC dal 2019.
DMARC fail: difetto di allineamento
L'errore più sottile. SPF passa, DKIM passa, ma DMARC fallisce ugualmente. La causa: nessuno dei due è allineato con il dominio del campo From.
Scenario tipico: invii da contact@captaindns.com, ma il tuo fornitore di invio firma con d=sendgrid.net (DKIM non allineato) e la busta SMTP utilizza bounces@sendgrid.net (SPF non allineato). Risultato: le due autenticazioni passano tecnicamente, ma nessuna è allineata con captaindns.com.
Correzione:
- Configura il tuo fornitore per firmare con
d=captaindns.com(DKIM allineato) - Configura il return-path (busta SMTP) per utilizzare un sottodominio del tuo dominio (SPF allineato)
La maggior parte dei fornitori di invio (SendGrid, Mailgun, Brevo, Postmark) offre un'opzione "Domain Authentication" o "Sender Authentication" che configura automaticamente l'allineamento DKIM e SPF.
IP su una blacklist
Il tuo punteggio MX/PTR cala a causa di un IP in blacklist. Le cause principali:
- IP condiviso: se sei su un IP condiviso con altri clienti del tuo hosting provider, lo spam di un altro cliente può colpirti
- Compromissione: uno script sul tuo server invia spam a tua insaputa (modulo di contatto sfruttato, account email compromesso)
- Storico dell'IP: l'IP che hai appena ricevuto era precedentemente utilizzato da uno spammer
La verifica è immediata:
# Verificare Spamhaus
dig +short 10.113.0.203.zen.spamhaus.org
# Se appare una risposta 127.0.0.x, l'IP è listato
Nota che l'IP è invertito nella query DNS (203.0.113.10 diventa 10.113.0.203).
Quando testare: le 5 situazioni critiche
Un test di deliverability non è un controllo occasionale. Ecco le cinque situazioni in cui un test è indispensabile.
1. Prima del lancio di una campagna email
Ogni campagna di marketing dovrebbe essere preceduta da un test. Un problema di autenticazione su un invio di 50 000 email significa 50 000 email potenzialmente perse. Il test richiede 30 secondi e può salvare un'intera campagna.
Invia un'email di test all'indirizzo fornito dal mail tester, consulta il report e correggi i problemi prima dell'invio massivo.
2. Dopo un cambio di fornitore di invio
La migrazione da un servizio di invio a un altro è il momento più rischioso per la deliverability. Bisogna aggiornare l'SPF (sostituire il vecchio include con il nuovo), riconfigurare DKIM (nuovo selettore, nuova chiave), e verificare l'allineamento DMARC.
Checklist per la migrazione:
- Aggiornare l'SPF: rimuovere il vecchio include, aggiungere il nuovo
- Configurare DKIM presso il nuovo fornitore e pubblicare la chiave nel DNS
- Verificare l'allineamento DMARC con il nuovo fornitore
- Testare la deliverability prima di trasferire il traffico
- Conservare il vecchio include SPF per 48h (email in transito)
3. Dopo una modifica DNS
Qualsiasi modifica della tua zona DNS può impattare la deliverability: cambio di TTL, aggiornamento di un record TXT, migrazione di registrar, attivazione di DNSSEC. Gli errori di copia-incolla nei record DNS sono frequenti e il risultato è un SPF o DKIM rotto senza alcun messaggio di errore visibile.
4. Quando i tassi di apertura calano
Un calo improvviso dei tassi di apertura (più del 10 % di variazione in una settimana) può indicare un problema di deliverability. Prima di cercare la causa nel contenuto o nell'oggetto delle email, testa la tua autenticazione. Un SPF che supera improvvisamente i 10 lookup (perché un fornitore ha aggiunto un include annidato) può provocare un calo brusco.
5. Con un ritmo mensile, in prevenzione
Le configurazioni DNS cambiano, i fornitori aggiornano i loro record, le chiavi DKIM devono essere rinnovate. Un test mensile rileva le regressioni prima che impattino i tuoi invii. Programma un promemoria mensile e verifica che il tuo punteggio resti a 100/100.
Piano d'azione raccomandato
-
Esegui un test di deliverability sul mail tester di CaptainDNS. Invia un'email di test e recupera il tuo punteggio dettagliato sezione per sezione.
-
Correggi i problemi per ordine di impatto: SPF prima (25 punti), poi DKIM (25 punti), poi DMARC (20 punti). Ogni correzione aumenta immediatamente il tuo punteggio e il tuo tasso di deliverability.
-
Verifica le tue correzioni rilanciando il test dopo ogni modifica DNS. Attendi la propagazione DNS (da 5 a 60 minuti a seconda del TTL) prima di ritestare.
-
Implementa il monitoring DMARC: i report aggregati (
rua=) ti avvisano automaticamente quando appare un problema di autenticazione. Analizzali almeno una volta alla settimana durante la fase di crescita, poi mensilmente. -
Pianifica un test mensile per rilevare le regressioni. Le configurazioni DNS evolvono silenziosamente (fornitore che modifica i suoi include, chiave DKIM che scade, IP che cambia blacklist). Un test mensile costa 30 secondi e può evitare settimane di deliverability degradata.
FAQ
Cos'è un mail tester e come funziona?
Un mail tester è uno strumento che analizza la deliverability delle tue email verificando la tua configurazione DNS (SPF, DKIM, DMARC), la reputazione del tuo IP di invio, i tuoi header email e l'eventuale presenza del tuo IP in blacklist. Invii un'email di test a un indirizzo fornito dallo strumento, e questo produce un report dettagliato con un punteggio su 100 e le correzioni da applicare.
Quale punteggio di deliverability bisogna raggiungere?
Punta a un punteggio di 100/100. Un punteggio superiore a 80/100 è accettabile per la maggior parte degli invii transazionali. Sotto i 70/100, le tue email hanno una probabilità significativa di essere classificate come spam. Sotto i 50/100, la maggior parte dei provider (Gmail, Outlook, Yahoo) rifiuterà o filtrerà i tuoi messaggi.
SPF, DKIM e DMARC sono tutti obbligatori?
Da febbraio 2024, Gmail e Yahoo richiedono almeno SPF o DKIM per tutti i mittenti. Per i mittenti di massa (più di 5 000 email al giorno verso Gmail), tutti e tre sono obbligatori: SPF e DKIM validi, più un record DMARC pubblicato. In pratica, configurare tutti e tre è raccomandato per tutti i domini, qualunque sia il volume.
Cos'è il limite di 10 DNS lookup di SPF?
La RFC 7208 limita a 10 il numero di query DNS ricorsive durante la valutazione di un record SPF. I meccanismi include, a, mx, redirect e exists contano ciascuno come un lookup. Gli include annidati si sommano: un include che contiene a sua volta 3 include consuma 4 lookup in totale. Oltre i 10, il server restituisce un PermError e il tuo SPF è considerato invalido.
Perché il mio DMARC fallisce se SPF e DKIM passano?
DMARC verifica non solo che SPF e DKIM passino, ma anche che siano allineati con il dominio del campo From dell'email. Se il tuo fornitore di invio firma con il proprio dominio DKIM e utilizza il proprio indirizzo nella busta SMTP, né SPF né DKIM sono allineati con il tuo dominio From. Configura il tuo fornitore per utilizzare il tuo dominio (Domain Authentication) per risolvere questo problema.
Quanto tempo ci vuole perché le correzioni DNS facciano effetto?
Il tempo dipende dal TTL (Time To Live) dei tuoi record DNS. Un TTL di 300 secondi (5 minuti) significa che i server di ricezione vedranno la tua modifica in meno di 5 minuti. Un TTL di 86400 (24 ore) può richiedere fino a 24 ore. Prima di modificare un record critico, riduci prima il TTL a 300, attendi la propagazione di quel nuovo TTL, poi effettua la modifica.
Come sapere se il mio IP è in una blacklist?
Interroga le principali blacklist tramite una query DNS inversa. Ad esempio, per verificare l'IP 203.0.113.10 su Spamhaus: dig +short 10.113.0.203.zen.spamhaus.org. Se viene restituita una risposta di tipo 127.0.0.x, l'IP è listato. Uno strumento di verifica blacklist automatizza questa verifica su diverse decine di liste simultaneamente.
Bisogna testare prima di ogni invio di campagna?
Sì, per le campagne di marketing di massa. Un test richiede meno di un minuto e può evitare di sprecare un intero invio. Per le email transazionali (conferme, fatture), un test mensile è sufficiente, salvo dopo un cambio di configurazione DNS o di fornitore di invio. L'obiettivo è rilevare le regressioni prima che impattino la deliverability.
Qual è la differenza tra allineamento relaxed e strict in DMARC?
In modalità relaxed (adkim=r, aspf=r), il dominio della firma DKIM o della busta SPF deve condividere lo stesso dominio organizzativo del From. Esempio: una firma d=mail.captaindns.com è allineata con un From @captaindns.com. In modalità strict (adkim=s, aspf=s), i domini devono corrispondere esattamente. La modalità relaxed è raccomandata per la maggior parte dei deploy perché tollera l'uso di sottodomini.
Cosa fare se il mio punteggio non sale nonostante le correzioni?
Verifica che la propagazione DNS sia terminata (attendi almeno il TTL dei tuoi record). Testa ogni componente individualmente: SPF da solo (dig TXT captaindns.com), DKIM da solo (dig TXT selettore._domainkey.captaindns.com), DMARC da solo (dig TXT _dmarc.captaindns.com). Se i record DNS sono corretti ma il punteggio non cambia, il problema può venire dalla reputazione dell'IP (blacklist) o dal contenuto dell'email di test.
Glossario
- SPF (Sender Policy Framework): protocollo di autenticazione email definito dalla RFC 7208 che elenca i server autorizzati a inviare email per un dominio tramite un record DNS TXT che inizia con
v=spf1. - DKIM (DomainKeys Identified Mail): protocollo di autenticazione email definito dalla RFC 6376 che aggiunge una firma crittografica a ogni email, verificabile tramite una chiave pubblica pubblicata nel DNS.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): protocollo definito dalla RFC 7489 che verifica l'allineamento SPF e DKIM con il dominio From e definisce la policy di trattamento dei fallimenti (none, quarantine, reject).
- Allineamento: in contesto DMARC, corrispondenza tra il dominio utilizzato da SPF o DKIM e il dominio visibile nel campo From dell'email. Può essere relaxed (stesso dominio organizzativo) o strict (corrispondenza esatta).
- PermError: errore permanente restituito quando un record SPF è strutturalmente invalido (troppi lookup, sintassi errata, duplicati). Il record non può essere valutato.
- PTR (Pointer Record): record DNS che associa un indirizzo IP a un hostname (reverse DNS). Utilizzato dai server di ricezione per verificare l'identità del server di invio.
- FCrDNS (Forward-confirmed reverse DNS): verifica in due passaggi. Il reverse DNS dell'IP restituisce un hostname, e la risoluzione di quell'hostname deve restituire l'IP di origine.
- Blacklist (DNSBL): lista di blocco basata sul DNS che registra gli indirizzi IP noti per inviare spam. Le principali sono Spamhaus, Barracuda, SORBS e SpamCop.
- Selettore DKIM: identificatore (stringa di caratteri) che permette di localizzare la chiave pubblica DKIM nel DNS. Il record è pubblicato su
selettore._domainkey.captaindns.com. - RFC 7208: specifica ufficiale del protocollo SPF che definisce la sintassi dei record, il limite di 10 lookup, i void lookup e i risultati possibili.
- ARC (Authenticated Received Chain): protocollo che preserva i risultati di autenticazione email attraverso i relay intermedi (mailing list, inoltri). Supportato da Gmail e Microsoft.
- RFC 8058: specifica del meccanismo di disiscrizione in un clic (One-Click Unsubscribe) tramite l'header List-Unsubscribe-Post, richiesto da Gmail per i mittenti di massa dal 2024.
Testa la tua deliverability adesso: utilizza il mail tester di CaptainDNS per ottenere il tuo punteggio su 100 e la lista esatta delle correzioni da applicare. Un test richiede 30 secondi e può trasformare i tuoi tassi di consegna.
