Perché le tue email finiscono nello spam: la guida diagnostica completa

⚡TL;DR

• 5 cause principali: autenticazione (SPF/DKIM/DMARC), reputazione IP/dominio, contenuto sospetto, scarso engagement, configurazione tecnica
• Verifica prioritaria: testa il tuo IP sulle blacklist principali e controlla la tua autenticazione
• Dal 2024: Gmail e Yahoo richiedono SPF, DKIM e DMARC per i mittenti di massa
• Rifiuti di Outlook.com di novembre 2026 (AS9031519): senza un DMARC applicabile, aggiungere p=none è la soluzione temporanea segnalata. Sono segnalati rifiuti anche con SPF, DKIM e DMARC in pass: se la tua autenticazione è già corretta, non riscrivere i tuoi record e segui la procedura di segnalazione della sezione Outlook.com
• Da novembre 2026: Spamhaus introduce gradualmente il requisito di un HELO valido e di record PTR e A coerenti per ogni IP di invio, con il rischio di un listing
• Soglia critica: un tasso di reclami superiore allo 0,1% attiva la classificazione come spam
• Diagnosi rapida: analizza gli header delle tue email per identificare il problema esatto

Perché le tue email vengono classificate come spam

Ogni giorno miliardi di email vengono filtrate dai sistemi anti-spam. Un'email su sei non raggiunge mai la posta in arrivo del destinatario. Per le aziende è una questione critica: fatture non ricevute, conferme d'ordine perse, comunicazioni con i clienti ignorate.

La classificazione come spam non è casuale. I provider di posta elettronica (Gmail, Outlook, Yahoo) utilizzano centinaia di segnali per decidere il destino di ogni email. Comprendere questi segnali è la chiave per risolvere il problema: si riducono a cinque pilastri misurabili (autenticazione, reputazione, sicurezza del trasporto, BIMI ed engagement) che la nostra guida al punteggio di deliverability email analizza uno per uno.

Questa guida analizza le 5 cause principali della classificazione come spam e ti fornisce un piano d'azione concreto per ogni situazione. Che tu sia amministratore di sistema, responsabile marketing o sviluppatore, troverai le risposte alle tue domande.

---

Causa 1: Autenticazione email assente o errata

L'autenticazione email è diventata obbligatoria nel 2024. Gmail, Yahoo e Apple hanno annunciato che le email non autenticate sarebbero state sistematicamente rifiutate o classificate come spam.

I 3 protocolli di autenticazione

Protocollo	Funzione	Impatto se assente
SPF	Elenca i server autorizzati a inviare per il tuo dominio	Rifiuto o spam
DKIM	Firma crittograficamente ogni email	Spam o diffidenza
DMARC	Definisce la policy in caso di fallimento SPF/DKIM	Nessuna protezione contro lo spoofing; rifiuti di Outlook.com segnalati da novembre 2026 (non è l'unica situazione segnalata)

Verificare la tua configurazione

Usa un audit email dominio per verificare istantaneamente se il tuo dominio è configurato correttamente:

1. Inserisci il tuo nome di dominio
2. Consulta i risultati SPF, DKIM e DMARC
3. Segui le raccomandazioni di correzione

Errori SPF comuni

Errore	Conseguenza	Soluzione
Nessun record SPF	Email classificate come spam	Creare un record TXT con v=spf1
Troppi include (>10 lookup)	SPF non valido (PermError)	Ottimizzare o usare un servizio di flattening
IP mancante	Fallimento SPF per alcuni invii	Aggiungere l'IP o l'include del servizio
~all vs -all	Policy troppo permissiva	Usare -all in produzione

Errori DKIM comuni

Errore	Conseguenza	Soluzione
Nessuna firma	Email non autenticata	Configurare DKIM sul server mail
Chiave troppo corta (<1024 bit)	Firma considerata debole	Generare una chiave a 2048 bit
Selettore errato	Fallimento della verifica	Verificare il DNS e la configurazione del server
Corpo modificato	Firma non valida	Verificare i relay intermedi

DMARC: la policy che cambia tutto

DMARC è il direttore d'orchestra dell'autenticazione. Senza di esso, anche con SPF e DKIM validi, le tue email possono finire nello spam, o essere rifiutate durante la transazione SMTP. Un rifiuto non deposita nulla nella cartella della posta indesiderata: il mittente riceve un rapporto di mancato recapito e il messaggio non viene consegnato. Da inizio novembre 2026, alcuni operatori segnalano questo tipo di rifiuto su Outlook.com per domini senza record DMARC. Le segnalazioni di novembre riguardano anche domini i cui SPF, DKIM e DMARC sono dichiarati corretti: l'assenza di DMARC non spiega tutti i casi (dettagli nella sezione Outlook.com più avanti).

# Record DMARC p=none con report aggregati
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

# Record DMARC strict (consigliato in produzione)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"

Policy	Comportamento	Raccomandazione
p=none	Solo monitoraggio	Fase iniziale (2-4 settimane)
p=quarantine	Email sospette nello spam	Fase intermedia
p=reject	Email sospette rifiutate	Produzione sicura

---

Causa 2: Reputazione IP o dominio degradata

Anche con un'autenticazione perfetta, le tue email possono finire nello spam se la tua reputazione è scarsa. I provider di posta elettronica mantengono punteggi di reputazione basati sullo storico degli invii.

Comprendere la reputazione

La reputazione è composta da due elementi:

1. Reputazione IP: Punteggio dell'indirizzo IP che invia le email
2. Reputazione dominio: Punteggio del dominio di invio (From)

Fattore	Impatto sulla reputazione
Tasso di reclami spam	Molto elevato (soglia: 0,1%)
Bounce rate	Elevato (soglia: 5%)
Engagement (aperture, clic)	Moderato
Storico del dominio	Moderato
Blacklist	Critico

Verificare se il tuo IP è in blacklist

Un IP presente in una blacklist importante (Spamhaus, Barracuda) vedrà le sue email sistematicamente rifiutate da Gmail, Outlook e Yahoo.

Per verificare se il tuo IP è presente, testalo contro le principali DNSBL:

• Spamhaus ZEN: Utilizzata dalla maggior parte dei grandi provider
• Barracuda BRBL: Molto diffusa in ambito aziendale
• SpamCop: Basata sulle segnalazioni degli utenti

Blacklist da monitorare in priorità

Blacklist	Impatto	Utilizzata da
Spamhaus ZEN	Critico	Gmail, Yahoo, Outlook
Barracuda BRBL	Critico	Aziende, filtri Barracuda
SpamCop	Elevato	Numerosi provider
UCEProtect	Moderato	Filtri anti-spam

Migliorare la propria reputazione

Azione	Impatto	Tempi
Richiedere il delisting dalle blacklist	Immediato	24-72h
Ridurre il tasso di reclami	Elevato	2-4 settimane
Rimuovere gli hard bounce che riguardano l'indirizzo (utente sconosciuto, casella inesistente). Un rifiuto che riguarda il dominio, l'IP o l'autenticazione si corregge alla fonte, senza rimuovere il destinatario	Elevato	Immediato
Riscaldare progressivamente i nuovi IP	Preventivo	4-6 settimane

---

Causa 3: Contenuto problematico

I filtri anti-spam analizzano il contenuto di ogni email. Alcuni elementi attivano automaticamente la classificazione come spam.

Parole ed espressioni da evitare

I filtri anti-spam utilizzano liste di parole sospette. Ecco le categorie più rischiose:

Categoria	Esempi	Rischio
Urgenza eccessiva	"URGENTE", "Agisci subito", "Ultima occasione"	Elevato
Promesse finanziarie	"Gratis", "Guadagna soldi", "Senza costi"	Elevato
Pressione commerciale	"Offerta limitata", "Solo 24 ore", "Scorte esaurite"	Moderato
Espressioni sospette	"Clicca qui", "100% garantito", "Nessun impegno"	Moderato

Struttura dell'email

Problema	Perché viene filtrato	Soluzione
Email 100% immagine	Testo nascosto, tecnica da spammer	Rapporto 60% testo / 40% immagini
Link accorciati (bit.ly)	Nascondono la destinazione	Usare gli URL completi
Troppi link	Comportamento tipico dello spam	Massimo 3-5 link per email
Nessuna versione testo	Solo HTML = sospetto	Includere sempre text/plain
Moduli integrati	Tecnica di phishing	Link verso il sito web

Rapporto HTML/testo ottimale

Contenuto consigliato:
- Testo: 60-80%
- Immagini: 20-40%
- Link: 3-5 massimo
- Dimensione totale: < 100 KB

---

Causa 4: Scarso engagement dei destinatari

I provider di posta elettronica misurano come i destinatari interagiscono con le tue email. Un basso engagement segnala contenuto non desiderato.

Segnali di engagement negativo

Segnale	Impatto	Soglia critica
Reclami spam	Molto elevato	>0,1% attiva lo spam
Hard bounce	Elevato	>5% degrada la reputazione
Soft bounce ripetuti	Moderato	>10% su 30 giorni
Basso tasso di apertura	Moderato	<10% su liste attive
Disiscrizioni elevate	Moderato	>1% per campagna

Il circolo vizioso dello spam

Basso engagement → Classificazione spam → Ancora meno engagement → Reputazione degradata

Per spezzare questo circolo:

1. Pulisci le tue liste: Rimuovi gli indirizzi inattivi da più di 6 mesi
2. Segmenta: Invia contenuti pertinenti a ogni segmento
3. Rispetta il consenso: Double opt-in obbligatorio
4. Facilita la disiscrizione: Link visibile, processo in 1 clic

Buone pratiche di igiene delle liste

Azione	Frequenza	Impatto
Rimuovere gli hard bounce che riguardano l'indirizzo (utente sconosciuto, casella inesistente). Se il rifiuto riguarda il dominio, l'IP o l'autenticazione: correggere la causa e rinviare, senza toccare la lista	Immediato	Critico
Rimuovere i reclami spam	Immediato	Critico
Pulire gli inattivi (>6 mesi)	Mensile	Elevato
Re-engagement dei tiepidi	Trimestrale	Moderato
Validazione email all'iscrizione	Continuo	Preventivo

---

Causa 5: Configurazione tecnica carente

Problemi di configurazione tecnica possono sabotare tutti i tuoi sforzi.

Checklist di configurazione server

Elemento	Verifica	Comando
Reverse DNS (PTR)	L'IP deve risolvere verso un FQDN	dig -x <IP>
FQDN verso IP	Il FQDN deve risolvere verso l'IP	dig A <fqdn>
HELO/EHLO	Deve risolvere verso l'IP di invio e restare invariato	Log del server
Porta 25 aperta	Nessun blocco ISP	telnet mail.server.com 25
TLS attivo	STARTTLS obbligatorio	Test di connessione

Reverse DNS: perché è critico

Il reverse DNS (record PTR) viene verificato da tutti i provider principali. Senza un PTR valido, le tue email sono immediatamente sospette.

# Verificare il PTR del tuo IP
dig -x 192.0.2.1

# Risultato atteso
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.

# Il FQDN deve risolvere verso lo stesso IP
dig A mail.captaindns.com
# Risultato: 192.0.2.1

Configurazione HELO/EHLO

Il server mail si identifica con HELO o EHLO. Il nome annunciato deve:

1. Essere un FQDN valido (non un IP, non "localhost", non un nome predefinito del provider di hosting)
2. Risolvere verso l'IP che invia l'email (record A)
3. Restare invariato da una connessione all'altra da questo IP

Il PTR di questo IP punta a sua volta a un FQDN che risolve verso lo stesso IP: si parla di FCrDNS (forward-confirmed reverse DNS).

# Sbagliato
EHLO localhost
EHLO [192.0.2.1]
EHLO server1

# Corretto
EHLO mail.captaindns.com

Spamhaus, novembre 2026. A partire da novembre 2026, Spamhaus introduce gradualmente un requisito per ogni IP di invio: un HELO valido, un reverse DNS (PTR) e un record A coerente. Un IP che non lo rispetta rischia un listing. Spamhaus non pubblica né un giorno preciso né un calendario. In IPv6, l'indirizzo di invio deve appartenere a un blocco /64 o più ampio, dotato di un reverse DNS valido. Verifica fin da ora il PTR e il record A di ogni IP di invio con i comandi dig qui sopra, poi il nome annunciato nell'HELO nei log del tuo server. Per un controllo concreto, invia un messaggio a una casella esterna e leggi l'header Received aggiunto dal server destinatario: il nome che segue from è in genere quello che il tuo server annuncia in HELO/EHLO. A seconda del server destinatario, compare invece tra parentesi, dopo helo= o HELO. L'analizzatore di header email presentato più avanti lo mostra. Se i tuoi server di invio sono anche i tuoi MX, il tester SMTP/MX segnala un banner il cui nome non corrisponde a quello del MX.

---

Diagnosi per provider

Ogni provider ha le sue specificità. Ecco come diagnosticare i problemi per i principali.

Gmail

Strumenti di diagnosi:

• Google Postmaster Tools: reputazione dominio e IP
• Header Gmail: cerca X-Gm-Spam e X-Gm-Phishy

Requisiti Gmail 2024:

Criterio	Volume <5.000/giorno	Volume >5.000/giorno
SPF o DKIM	Obbligatorio	Obbligatorio
DMARC	Consigliato	Obbligatorio
Tasso reclami	<0,3%	<0,1%
TLS	Consigliato	Obbligatorio
Disiscrizione 1-clic	-	Obbligatoria

Codici di errore comuni:

Codice	Significato	Azione
421 4.7.0	Troppe connessioni	Ridurre la frequenza
550 5.7.1	Policy DMARC	Correggere SPF/DKIM
550 5.7.26	Fallimento autenticazione	Verificare SPF, DKIM

Outlook.com e Microsoft 365: distinguere le diagnosi

Microsoft riceve le email tramite due servizi distinti, che non reagiscono sempre allo stesso modo. Outlook.com è la posta per i privati (indirizzi outlook.com, hotmail.com, live.com, msn.com). Microsoft 365 ospita la posta aziendale, sul dominio di ogni cliente. Il nome del server che rifiuta, nel rapporto di mancato recapito (NDR), aiuta a capire quale dei due risponde: MailRoute descrive i server di Outlook.com come olc.protection.outlook.com, e il dominio Microsoft 365 testato da Spam Resource passava da un server in mail.protection.outlook.com.

Strumenti di diagnosi:

• SNDS (Smart Network Data Services): reputazione IP
• JMRP: feedback loop

Particolarità Outlook:

• Utilizza Spamhaus e blacklist proprietarie
• Filtro aggressivo per i nuovi domini (<30 giorni)
• Programma SNDS per monitorare la reputazione

Outlook.com (privati)

La regola pubblicata da Microsoft riguarda i mittenti ad alto volume. Un dominio che invia più di 5.000 messaggi al giorno verso Outlook.com deve superare SPF e DKIM, pubblicare un record DMARC (almeno p=none) e superare DMARC grazie a un SPF o a un DKIM allineato al dominio del From. L'annuncio del sito Postmaster di Outlook.com fissa l'avvio al 5 maggio 2025, prima con lo spostamento nella posta indesiderata e poi con i rifiuti; il rifiuto associato è 550 5.7.515.

Il rifiuto segnalato ha questa forma (MailRoute segnala anche una variante senza il codice tra parentesi):

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Nel rapporto di mancato recapito pubblicato su Microsoft Q&A il 6 novembre, questo rifiuto arriva all'interno di un altro codice. La riga "Error Details" riporta, con i dati personali rimossi dal moderatore:

Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records

Il rapporto mostra 550 5.7.23 come codice di stato, sotto il titolo "SPF validation error". Il testo di aiuto che lo accompagna parla solo di SPF: verificare il record, pubblicarne uno solo, includervi spf.protection.outlook.com. La diagnosi dettagliata si trova dopo la freccia: è il 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records", che Hornblower409 ricollega all'AS9031519. Questo modello non dimostra che il tuo SPF sia sbagliato. Nello stesso thread, Martin segnala questo involucro dichiarando SPF, DKIM e DMARC corretti da anni.

Se ricevi questo rifiuto, leggi e conserva prima il rapporto completo: codice esterno, testo interno, server che rifiuta ed eventuale AS9031519. Cerca poi il record DMARC su _dmarc.<dominio>. Per un sottodominio, controlla anche quello del dominio padre, la cui policy può applicarsi. Puoi verificare il record DMARC pubblicato senza riga di comando. Una ricerca DNS che non va a buon fine (timeout, errore del server) non dimostra l'assenza del record: riprova prima di concludere. Questo controllo mostra ciò che è pubblicato, non il risultato SPF o DKIM di un determinato messaggio.

Se al dominio non si applica alcun record DMARC:

1. Pubblica un record TXT su _dmarc.<dominio> con valore v=DMARC1; p=none. Molti provider DNS aggiungono il dominio da soli: in quel caso inserisci solo _dmarc come nome. Un dominio ha un solo record DMARC: non crearne un secondo con lo stesso nome e non sostituire una policy più severa che funziona già.
2. Verifica che almeno SPF o DKIM passi e sia allineato al dominio dell'indirizzo del mittente visualizzato (From). Un record DMARC senza autenticazione allineata fallisce comunque. Per controllare l'allineamento, invia un messaggio a un'altra casella e leggi il suo header Authentication-Results (vedi come leggere gli header di un'email).
3. Attendi che le cache DNS scadano: i server conservano per un certo tempo il vecchio record, oppure il fatto che non ne esisteva nessuno. Per un vecchio record, questo intervallo è il suo TTL, fissato nella tua zona DNS. Se non esisteva alcun record, il tempo per cui i server ricordano questa assenza dipende dal record SOA della tua zona (cache negativa, RFC 2308), non dal TTL del nuovo record. Poi rinvia i messaggi rifiutati. Un 550 è un errore permanente: il tuo server non ritenterà l'invio.

L'aggiunta di un p=none è segnalata come soluzione temporanea per alcuni domini senza DMARC (Hornblower409 e Cameron Scott sul thread di Microsoft Q&A), non come una riparazione del servizio Microsoft. p=none non chiede né quarantena né rifiuto ai sensi della policy DMARC. Questo non garantisce però l'accettazione da parte di Outlook.com, né l'arrivo nella posta in arrivo.

Se SPF, DKIM e DMARC sono già corretti e i tuoi messaggi superano l'autenticazione:

1. Non riscrivere una configurazione corretta solo per rispondere al testo del rapporto. Non pubblicare un secondo record SPF: due record SPF provocano un PermError (vedi la guida SPF PermError). Non aggiungere nemmeno include:spf.protection.outlook.com perché il rapporto lo suggerisce: il tuo SPF deve autorizzare i servizi che inviano davvero per il tuo dominio.
2. Conserva il rapporto completo e gli elementi tecnici, poi segnala il rifiuto a Microsoft Sender Support. È la procedura che consiglia Hornblower409 quando i messaggi rifiutati con AS9031519 superano l'autenticazione.
3. In azienda, Daniel-Vo chiedeva il 9 novembre di fornire al supporto Microsoft 365 Network Message ID recenti, i log dei messaggi interessati ed esempi in formato .eml. Questi elementi vanno al supporto, non in un forum pubblico.
4. Riprova più tardi, senza garanzia di risultato. I rifiuti sono segnalati come intermittenti, ma un 550 resta un errore permanente: il tuo server non ritenterà l'invio, tocca a te rinviare il messaggio.

Un pass ottenuto su un altro messaggio, o presso un altro destinatario, aiuta la diagnosi ma non dimostra il verdetto del server di Outlook.com che ha rifiutato il tuo. Poiché i rifiuti sono parziali, un rinvio accettato non dimostra neppure che la configurazione sia corretta, avverte MailRoute: controlla i record invece del risultato di un singolo invio.

Microsoft 365 (aziende)

Microsoft 365 applica i propri meccanismi di filtraggio. Aggiunge un verdetto proprietario compauth nell'intestazione Authentication-Results; un compauth=fail aumenta il rischio di finire nella posta indesiderata (vedi la guida compauth di Microsoft 365). Durante il test di Al Iverson (Spam Resource) del 7 novembre 2026, il messaggio rifiutato verso outlook.com è stato accettato verso il dominio Microsoft 365 testato. Questo test isolato non dimostra che i destinatari ospitati su Microsoft 365 siano al riparo, né che subiscano lo stesso incidente. I clienti Microsoft 365 possono invece essere colpiti come mittenti, quando scrivono verso Outlook.com: è a loro che si rivolge la richiesta di supporto di Daniel-Vo citata sopra. Leggi sempre il testo completo dell'NDR.

Codici di errore di Outlook.com e Microsoft 365

Codice	Significato	Azione
550 5.7.1	Rifiuto generico: leggere il testo completo dell'NDR	Richiedere un delisting solo se il testo indica un blocco dell'IP, seguendo la procedura che riporta
550 5.7.1 con "Message lacks SPF/DKIM/DMARC Auth Records"	Rifiuto di Outlook.com segnalato da novembre 2026 per domini senza DMARC, ma anche per domini la cui autenticazione passa	Verificare il record DMARC e l'allineamento SPF o DKIM senza concludere che siano difettosi in base al solo testo. Senza DMARC: pubblicare p=none, poi rinviare. Se tutto passa: segnalare a Microsoft Sender Support
550 5.7.23, quando accompagna la diagnosi AS9031519	Involucro orientato a SPF attorno al rifiuto 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records" (rapporti pubblicati su Microsoft Q&A, novembre 2026). Da solo, questo codice segnala un fallimento SPF e non dimostra questo incidente	Leggere la diagnosi dopo la freccia prima di toccare l'SPF, poi seguire la situazione corrispondente (DMARC assente o autenticazione già corretta)
550 5.7.515	Livello di autenticazione richiesto non raggiunto (mittenti ad alto volume verso Outlook.com)	SPF e DKIM validi, DMARC pubblicato, allineamento al From
550 5.7.606	IP con bassa reputazione	Consultare SNDS e seguire la procedura di delisting indicata nell'NDR. Il rifiuto riguarda l'IP: non rimuovere i destinatari rifiutati
421 4.7.0	Limite di frequenza	Ridurre gli invii

Yahoo / AOL

Strumenti di diagnosi:

• Yahoo Sender Hub: reputazione e linee guida
• Complaint Feedback Loop: reclami in tempo reale

Requisiti Yahoo 2024:

Criterio	Richiesto
SPF	Obbligatorio
DKIM	Obbligatorio
DMARC	Obbligatorio per >5.000 email/giorno
Disiscrizione 1-clic	Obbligatoria
Tasso reclami	<0,3%

---

Piano d'azione consigliato

Fase 1: Diagnosi immediata (30 minuti)

1. Testa il tuo IP sulle blacklist principali
2. Verifica l'autenticazione (SPF, DKIM, DMARC) del tuo dominio
3. Analizza un'email problematica tramite i suoi header con l'analizzatore di header email

Se i tuoi messaggi vengono rifiutati invece che classificati come spam, parti dal testo esatto dell'NDR prima di qualsiasi richiesta di delisting. Uno stesso codice 550 5.7.1 copre più cause. "Message lacks SPF/DKIM/DMARC Auth Records" non riguarda il tuo IP: verifica DMARC e l'allineamento, senza concludere che siano difettosi in base al solo testo. Sono segnalati rifiuti anche con un'autenticazione in pass; in questo caso, segui la procedura "autenticazione già corretta" della sezione Outlook.com. Un delisting è giustificato solo se il testo indica l'IP o una blocklist.

Fase 2: Correzioni prioritarie (1-2 giorni)

1. Richiedi il delisting se sei in blacklist (Spamhaus, Barracuda in priorità)
2. Correggi gli errori di autenticazione rilevati
3. Configura il reverse DNS se mancante

Fase 3: Miglioramento continuo (2-4 settimane)

1. Iscriviti ai feedback loop (Gmail, Outlook, Yahoo)
2. Monitora i tassi di reclamo (obiettivo <0,1%)
3. Pulisci le tue liste: rimuovi gli indirizzi inattivi da più di 6 mesi e gli hard bounce il cui rifiuto riguarda l'indirizzo (utente sconosciuto, casella inesistente). Se il rifiuto riguarda il tuo dominio, il tuo IP o la tua autenticazione, correggi la causa e rinvia, senza rimuovere il destinatario
4. Implementa un monitoraggio regolare delle blacklist

Fase 4: Prevenzione a lungo termine

1. Double opt-in per tutte le iscrizioni
2. Disiscrizione facile (1-clic, header list-unsubscribe)
3. Monitoraggio automatizzato delle blacklist e della reputazione
4. Audit trimestrale della configurazione email

---

FAQ

Perché le mie email finiscono nello spam anche se ho configurato SPF e DKIM?

SPF e DKIM da soli non bastano. Dal 2024, Gmail e Yahoo richiedono anche DMARC ai mittenti di massa. Su Outlook.com, da inizio novembre 2026 sono segnalati rifiuti per domini senza DMARC, anche a basso volume, ma pure per domini la cui autenticazione passa; il 9 novembre, un moderatore di Microsoft Q&A li ricollegava a un degrado del servizio (vedi la domanda successiva). Verifica inoltre che il tuo IP non sia in una blacklist e che il tasso di reclami sia inferiore allo 0,1%. Un fallimento su uno qualsiasi di questi punti può attivare lo spam, anche con un'autenticazione parziale.

Perché Outlook.com rifiuta le mie email con AS9031519 nonostante SPF e DKIM validi?

Da inizio novembre 2026 sono segnalate due situazioni. Alcuni operatori (lista Mailop, MailRoute, Spam Resource) osservano questo rifiuto su domini senza record DMARC; alcuni partecipanti del thread di Microsoft Q&A "SPF Validation Error" lo segnalano anche, in modo intermittente, con SPF, DKIM e DMARC in pass. Il 9 novembre 2026, Daniel-Vo, presentato in quel thread come "Microsoft External Staff" e moderatore, descriveva un problema del servizio Exchange verso Outlook.com, Hotmail.com e Live.com, classificato come "service degradation", la cui causa era ancora da individuare. Non è né una voce di Service Health né una nuova regola pubblicata. Il rapporto di mancato recapito può mostrare 550 5.7.23 e il titolo "SPF validation error": leggi la diagnosi dopo la freccia prima di toccare l'SPF. Se non si applica alcun DMARC, pubblica un TXT v=DMARC1; p=none su _dmarc.<dominio>, verifica che SPF o DKIM passi e resti allineato al dominio del From, poi rinvia i messaggi rifiutati: un 550 è definitivo, il tuo server non ritenterà. p=none è una soluzione temporanea segnalata, senza garanzia di accettazione. Se l'autenticazione passa già, non riscrivere i tuoi record: conserva il rapporto completo e segnala il rifiuto a Microsoft Sender Support.

Come faccio a sapere se il mio IP è in una blacklist?

Usa un verificatore di blacklist che testa il tuo IP contro le liste principali (Spamhaus, Barracuda, SpamCop). Il test copre più di 25 blacklist contemporaneamente e fornisce i link per il delisting per ogni lista interessata. Testa il tuo IP immediatamente se le tue email vengono rifiutate o classificate come spam.

Quanto tempo ci vuole per uscire da una blacklist?

I tempi variano a seconda della blacklist: SpamCop si rimuove automaticamente in 24-48h senza nuove segnalazioni. Spamhaus elabora le richieste manuali in 24-48h. Barracuda risponde in 12-24h. UCEProtect ha un ritardo di 7 giorni. In ogni caso, il problema all'origine della segnalazione deve essere corretto prima di richiedere il delisting.

Le mie email finiscono nello spam solo su Gmail, perché?

Gmail è particolarmente rigoroso da febbraio 2024. Verifica i seguenti punti: (1) DMARC è configurato con almeno p=none? (2) Il tasso di reclami è sotto lo 0,1%? (3) La disiscrizione in 1-clic è implementata per le email di massa? Usa Google Postmaster Tools per vedere la reputazione del tuo dominio su Gmail.

Come posso migliorare rapidamente il mio tasso di deliverability?

Azioni immediate: (1) Verifica e correggi la tua autenticazione SPF/DKIM/DMARC. (2) Testa il tuo IP sulle blacklist e richiedi il delisting se necessario. (3) Rimuovi dalla tua lista gli hard bounce il cui rifiuto riguarda l'indirizzo (utente sconosciuto, casella inesistente), oltre agli inattivi da più di 6 mesi. Se il rifiuto riguarda il tuo dominio, il tuo IP o la tua autenticazione, correggi la causa e rinvia prima di toccare la lista. (4) Riduci gli invii verso gli indirizzi che non aprono mai. Queste azioni possono migliorare la deliverability in 1-2 settimane.

Qual è il tasso di reclami accettabile?

La soglia critica è 0,1% (1 reclamo ogni 1.000 email). Oltre questo limite, Gmail e Yahoo iniziano a classificare le tue email come spam. Google consiglia di restare sotto lo 0,05% per una deliverability ottimale. Monitora questo tasso tramite i feedback loop e Google Postmaster Tools.

Il mio server mail è configurato bene ma le mie email finiscono comunque nello spam?

Se la configurazione tecnica è corretta, il problema è probabilmente legato a: (1) La reputazione del tuo IP o dominio (verifica le blacklist). (2) Il contenuto delle tue email (parole trigger, rapporto immagine/testo). (3) L'engagement dei destinatari (basso tasso di apertura, reclami). Analizza i tuoi header per identificare il fattore scatenante.

Come riscaldare un nuovo IP per l'invio di email?

Il riscaldamento di un IP consiste nell'aumentare progressivamente il volume di invio in 4-6 settimane. Inizia con 50-100 email/giorno verso i destinatari più coinvolti, poi raddoppia il volume ogni settimana. Monitora i bounce e i reclami. Non passare mai da 0 a migliaia di email/giorno, altrimenti attiverai i filtri anti-spam.

Cosa cambia il requisito HELO/PTR di Spamhaus di novembre 2026?

A partire da novembre 2026, Spamhaus introduce gradualmente un requisito per ogni IP di invio: un reverse DNS (PTR) che punta a un FQDN, questo FQDN che risolve verso lo stesso IP (record A) e un nome HELO/EHLO che risolve verso l'IP di invio e resta invariato da una connessione all'altra. Secondo Spamhaus, un reverse DNS assente o non coerente è uno dei motivi più comuni per valutare il listing di un IP. Spamhaus non ha pubblicato né un giorno preciso né un calendario: si tratta di un'introduzione graduale, non di un blocco a data fissa. In IPv6, l'indirizzo di invio deve trovarsi in un blocco /64 o più ampio, con un reverse DNS valido.

---

Glossario

• DNSBL (DNS-based Blackhole List): Blocklist di IP consultabile tramite query DNS. Chiamata anche RBL (Realtime Blackhole List).
• SPF (Sender Policy Framework): Record DNS che elenca i server autorizzati a inviare email per un dominio.
• DKIM (DomainKeys Identified Mail): Firma crittografica aggiunta alle email per provare la loro autenticità.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): Policy che definisce il trattamento delle email che falliscono SPF/DKIM.
• Hard bounce: Errore di consegna permanente (codice 5xx). L'indirizzo può non esistere, ma il rifiuto può anche riguardare il tuo dominio o la tua autenticazione. Il server di invio non ritenta: dopo la correzione, rinvia il messaggio. Prima di rimuovere un indirizzo dalle tue liste, verifica che il rifiuto riguardi davvero quell'indirizzo.
• Soft bounce: Email temporaneamente rifiutata (casella piena, server non disponibile).
• Feedback loop: Programma che permette ai mittenti di ricevere le segnalazioni spam dei destinatari.
• Reverse DNS (PTR): Record DNS che associa un indirizzo IP a un nome di dominio.
• FQDN (Fully Qualified Domain Name): Nome di dominio completo (es: mail.captaindns.com).
• Reputazione IP: Punteggio attribuito a un indirizzo IP basato sul suo storico di invio.

---

Guide blacklist correlate

• Come rimuovere il tuo IP da una blacklist: la guida completa al delisting: Procedure dettagliate per Spamhaus, Barracuda, SpamCop e altro
• Spamhaus vs Barracuda vs SpamCop: Confronto: Le 3 principali blacklist spiegate

---

Fonti

• Google Email Sender Guidelines (2024) (requisiti ufficiali Gmail)
• Yahoo Sender Best Practices (linee guida Yahoo/AOL)
• Microsoft 365 Anti-Spam Protection (documentazione Outlook)
• Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (regola ufficiale per i mittenti ad alto volume verso Outlook.com)
• Outlook.com Postmaster (annuncio dei requisiti per i mittenti ad alto volume, avvio al 5 maggio 2025, consultato l'8 novembre 2026)
• Spam Resource - Microsoft newly rejecting mail lacking DMARC? (7 novembre 2026) (osservazioni e test di Al Iverson)
• Mailop - Microsoft requiring DMARC now or just us? (testimonianze di operatori, novembre 2026)
• MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (6 novembre 2026) (riscontro operativo di un fornitore di relay)
• Microsoft Q&A - SPF Validation Error (thread aperto il 6 novembre 2026) (scambio di supporto, non documentazione normativa: dichiarazione del 9 novembre 2026 di Daniel-Vo, Microsoft External Staff e moderatore, risposta del moderatore volontario Hornblower409 e testimonianze di utenti; consultato il 10 novembre 2026)
• The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (9 novembre 2026) (articolo di stampa)
• RFC 7489 - DMARC (specifica tecnica)
• Spamhaus - Understanding DNSBLs (funzionamento delle blacklist)
• Spamhaus Sender Guidelines (requisiti HELO, PTR e A per gli IP di invio)