Invii un messaggio e il server risponde 250 OK. Due settimane dopo scopri che non è mai arrivato: era nella cartella spam oppure un filtro del gateway lo aveva eliminato prima che il destinatario accedesse. La causa non è necessariamente l'oggetto o la sfortuna. Potrebbe essere la reputazione del dominio email, deteriorata già da settimane.
Da quando Google e Yahoo hanno reso più severi alcuni requisiti nel febbraio 2024, i mittenti che rientrano nelle categorie definite dai provider devono rispettare le regole applicabili. Superare determinate soglie può ridurre la visibilità dei messaggi, senza comportare un silenziamento universale. Questa guida illustra perché la reputazione può peggiorare, quali codici aiutano a diagnosticare il problema e come pianificare il recupero. Se prima ti serve una base DNS, consulta la guida per configurare l'email sul tuo dominio.
Che cos'è davvero la reputazione del dominio email
La reputazione del dominio email è l'insieme dei segnali di fiducia che provider come Google, Microsoft e Yahoo associano nel tempo al dominio di invio. Reclami per spam, risultati di autenticazione, qualità delle liste e comportamento dei destinatari possono influire sulla valutazione. Non esiste un unico punteggio valido ovunque. Dopo un peggioramento, il recupero richiede in genere un periodo di invii corretti, ma tempi e risultati dipendono dal provider.
Il punto importante è che la reputazione non torna positiva automaticamente. Un dominio con una lunga cronologia favorevole può assorbire qualche errore, mentre reclami ripetuti o problemi di autenticazione possono richiedere più tempo per essere corretti. Non esiste però una condanna permanente prestabilita.
I provider possono aggregare alcuni segnali a livello del dominio organizzativo. I sottodomini non costituiscono una barriera garantita: se marketing.example.com viene segnalato, anche la posta da ceo@example.com potrebbe risentirne. Il grado di correlazione varia e va verificato con i dati del singolo provider.
La soglia massima raggiunta e la classificazione persistente
Quando Google classifica un dominio come mittente di grandi volumi, in base a circa 5,000 email al giorno verso account Gmail personali, la classificazione viene considerata persistente. Ridurre il volume non la annulla necessariamente. Continuano quindi ad applicarsi i requisiti previsti per questo gruppo, tra cui l'intestazione per la disiscrizione con un clic e la pubblicazione di DMARC. Questo non significa che ogni provider usi la stessa soglia, né che DMARC debba sempre essere impostato su p=quarantine o p=reject.
Se il volume giornaliero verso Gmail resta sotto ~100 email al giorno, Postmaster Tools potrebbe mostrare "No Data". I test con indirizzi campione e l'analisi dei rimbalzi possono offrire indicazioni, ma un campione limitato non rappresenta tutti i destinatari.
Le 4 cause principali del peggioramento della reputazione
Quando la reputazione del dominio crolla, conviene indagare quattro aree ricorrenti: tasso di reclami, allineamento dell'autenticazione, limite di ricerche SPF e rimbalzi permanenti. Non sono le sole cause possibili e anche contenuto, consenso e criteri del destinatario possono contare. Identificare il livello interessato evita interventi inutili.
1. La soglia di reclami dello 0.3%
I reclami per spam sono un segnale importante per Google e Yahoo. Un tasso dello 0.3%, cioè 3 reclami ogni 1,000 email, rappresenta una soglia di rischio indicata nelle loro linee guida e può portare a filtraggio o rifiuti. Non è un blocco istantaneo e identico per tutti. Google raccomanda di restare sotto lo 0.1% e di evitare di avvicinarsi allo 0.3%.
Yahoo può pubblicare metodologie specifiche per calcolare il tasso sui messaggi recapitati nella posta in arrivo. Definizioni e denominatori possono cambiare, quindi verifica la documentazione attuale anziché presupporre un calcolo universale.
Scenario: Invi 1,000 email. 900 vengono filtrate automaticamente come spam. 100 arrivano nella posta in arrivo. 1 persona presenta un reclamo.
Calcolo: 1 reclamo ÷ 100 messaggi nella posta in arrivo = tasso di reclami dell'1.0%.
Risultato: Nell'esempio il tasso è 3× superiore al limite e può aggravare il filtraggio.
Un calo del tasso di apertura può essere un segnale, ma le aperture sono dati incompleti e condizionati dalla privacy. Google Postmaster Tools può mostrare stati come "Low" o "Bad" quando dispone di dati sufficienti; interfaccia e copertura possono cambiare.
2. Disallineamento dell'autenticazione e segnali di spoofing
SPF e DKIM possono risultare validi senza essere allineati al dominio visibile nel campo From. In tal caso DMARC non supera il controllo, a meno che l'altro metodo allineato non passi. Un fallimento DMARC può sembrare un tentativo di spoofing e influire negativamente sulla reputazione, ma va letto insieme agli altri segnali.
Per esempio, usando un ESP come Mailchimp o SendGrid, il mittente della busta per SPF può essere mail.sendgrid.net, mentre l'intestazione From usa yourcompany.com. SPF passa perché l'IP è autorizzato, ma l'allineamento DMARC tramite SPF non riesce perché i domini non corrispondono. DMARC potrebbe comunque passare tramite una firma DKIM allineata.
Microsoft può restituire 550 5.7.515 in relazione ai requisiti di autenticazione o alle politiche per mittenti ad alto volume. Il codice completo non prova da solo un problema di contenuto o Return-Path. Configura nel tuo ESP le opzioni di autenticazione del dominio personalizzato, talvolta chiamate "Whitelabeling", e verifica sia l'allineamento SPF sia quello DKIM.
3. Il limite SPF di 10 ricerche (RFC 7208)
SPF non è un elenco infinito. La RFC 7208 §4.6.4 impone un limite di 10 ricerche DNS per i meccanismi che causano lookup durante una valutazione SPF. Includere Google, Outlook, Zendesk, Mailchimp e un CRM può avvicinare al limite. Le direttive include: annidate possono consumare ulteriori ricerche.
Con 11 ricerche causate dai meccanismi interessati, la valutazione può restituire PermError. Il record SPF non fornisce quindi un risultato valido per quel controllo. Le risposte possono differire tra destinatari e percorsi DNS, ma non è corretto attribuirle genericamente a parser permissivi o severi senza esaminare i log.
4. Sensibilità di Microsoft ai rimbalzi per destinatario inesistente
Microsoft presta attenzione ai rimbalzi permanenti e ai comportamenti che ricordano il namespace mining. Un tasso superiore al 2-3% è un esempio operativo di rischio, non una soglia ufficiale che provoca sempre un blocco immediato. Tra le risposte possibili figurano 550 5.7.1 o una limitazione 421 RP-001, ma il significato va confermato nel messaggio completo.
Un tasso di reclami dello 0% non esclude problemi dovuti a indirizzi permanentemente non validi, autenticazione o policy. Distingui i rimbalzi "User Unknown" dalle risposte permanenti di policy o autenticazione e verifica il consenso e la validità prima di contattare destinatari Microsoft.
Informazioni specifiche per provider
Per intervenire sulla reputazione devi capire quale provider filtra o rifiuta i messaggi. Ciascuno può ponderare segnali diversi e offrire strumenti diagnostici propri. Verifica sempre disponibilità, requisiti e documentazione correnti.
| Provider | Area di attenzione | Strumento diagnostico | Nota importante |
|---|---|---|---|
| Google (Gmail / Workspace) | Tasso di reclami + interazione | Google Postmaster Tools | Con volumi bassi (<100 al giorno verso Gmail) può apparire "No Data"; i test campione offrono solo una vista limitata |
| Microsoft (Outlook / 365) | Conformità tecnica + reputazione IP | SNDS (Smart Network Data Services) | Gli IP nuovi possono richiedere un aumento graduale; ritmo e limitazioni dipendono dai segnali osservati |
| Yahoo / AOL | Contenuto + tasso di reclami | Yahoo Sender Hub + CFL | Quando disponibile e configurato, il Complaint Feedback Loop può fornire report ARF sui reclami idonei |
Flusso diagnostico: isolare il guasto
Non affidarti alle supposizioni. Esegui controlli tecnici autorizzati nell'ambiente appropriato e poi leggi le intestazioni di un messaggio ricevuto. Insieme possono aiutare a distinguere problemi di infrastruttura, autenticazione e comportamento di invio, senza garantire una diagnosi completa da un solo campione.
Controllo dell'infrastruttura da terminale
Verifica lo stack di autenticazione prima di aumentare il volume. I tre controlli seguenti coprono punti frequenti, ma sono esempi da adattare e non vanno eseguiti senza autorizzazione sul dominio interessato.
# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short
# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short
# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.
# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4
Se il controllo FCrDNS non riesce e IP e nome host non corrispondono, alcuni destinatari possono trattarlo come un segnale negativo. Non comporta un rifiuto universale da parte di Gmail o Yahoo, ma conviene correggerlo e verificare la propagazione prima di aumentare gli invii.
Analisi delle intestazioni
Invia un messaggio di prova autorizzato a un account Gmail controllato. Aprilo, fai clic sui tre punti e scegli "Mostra originale". Cerca l'intestazione Authentication-Results. L'esito vale per quel percorso e quel destinatario, non per tutta la consegna futura.
Segnale negativo, allineamento fallito:
spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com
SPF passa e DKIM passa, ma DMARC fallisce perché nessuno dei domini è allineato con yourcompany.com. Questo campione mostra il disallineamento descritto sopra e può contribuire a segnali negativi.
Segnale positivo, allineato:
spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass
Protocollo di recupero
Se Google Postmaster Tools mostra "Bad", un periodo di 2-4 settimane di invii corretti è una stima operativa, non un tempo garantito. Il recupero dipende da volume, destinatari e causa. Procedi per fasi in modo da misurare gli effetti.
Fase 1: revisione della lista
Continuare a inviare a destinatari non validi ostacola il recupero. Non eliminare automaticamente chi non ha aperto o fatto clic per 90 giorni: le aperture sono inaffidabili e possono esistere consenso, necessità del servizio o obblighi di conservazione. Sopprimi gli indirizzi confermati come permanentemente non validi e correggi la gestione se ripeti invii dopo due risposte "User Unknown" dello stesso indirizzo.
Fase 2: correzione tecnica
Dopo aver autorizzato e inventariato tutti i mittenti reali, valuta un passaggio graduale da p=none a p=quarantine. La policy DMARC riduce alcuni abusi, ma non impedisce ogni spoofing e non garantisce un miglioramento della reputazione. Se usi chiavi DKIM da 1024-bit, verifica il supporto attuale e pianifica la rotazione a 2048-bit o a un algoritmo accettato, aggiornando il DNS in sicurezza. La guida ai record DNS richiesti descrive il formato previsto per i domini TrekMail; verifica sempre la configurazione attuale.
Fase 3: aumento lineare e controllato
Riprendi con i segmenti che hanno avuto un rapporto effettivo con il mittente negli ultimi 30 giorni, senza creare interazioni artificiali. Una sequenza illustrativa è:
- Giorno 1: 50 email
- Giorno 2: 100 email
- Giorno 3: 200 email
- Giorno 4: 400 email
Controlla i dati disponibili ogni giorno. Se i segnali peggiorano, una pausa di 48 ore e la ripresa dal volume precedente sono opzioni illustrative, non una regola universale. Adatta il ritmo alle policy del provider e ai risultati reali.
Igiene dell'infrastruttura: problemi poco visibili
Due aspetti dell'infrastruttura possono incidere senza produrre segnali di errore evidenti. Anche con record di autenticazione corretti, configurazione TLS e qualità del pool IP meritano una verifica. Non sono però le uniche possibili cause.
Uso di TLS
I principali provider si aspettano trasporto SMTP protetto quando disponibile, ma policy, contesto e versioni supportate variano. Configura TLS 1.2 o superiore quando richiesto e compatibile, senza presumere che ogni connessione in chiaro venga automaticamente respinta. TrekMail descrive l'abilitazione predefinita di TLS; verifica il comportamento e il piano attuali.
Altri mittenti negli IP condivisi
Con hosting condiviso economico o piani gratuiti di un ESP, l'IP può essere usato da molti altri mittenti. L'abuso da parte di un vicino può portare il pool su Spamhaus SBL e influire sui tuoi messaggi anche con un dominio privo di problemi noti.
Oltre 100k al mese, un IP dedicato non è automaticamente la scelta migliore: servono volume stabile, capacità operativa e monitoraggio. A volumi inferiori, valuta la gestione del pool del provider oppure un SMTP esterno. L'opzione BYO SMTP di TrekMail può collegare Amazon SES, SendGrid o Mailgun secondo piano e disponibilità. Usare un provider scelto non significa controllare direttamente l'IP né garantirne la reputazione.
Il ruolo di TrekMail
La reputazione del dominio email è un vincolo tecnico e operativo. Richiede DNS accurato, gestione responsabile dei destinatari e infrastruttura in uscita adeguatamente controllata.
Se gestisci più domini, la complessità cresce. La guida all'hosting email multidominio illustra come separarli riducendo il rischio di correlazione, senza promettere isolamento assoluto. Per approfondire l'autenticazione, la base di sicurezza dell'email tratta policy DMARC e rotazione delle chiavi DKIM.
TrekMail descrive servizi per la posta in entrata, tra cui archiviazione a tariffa fissa, caselle IMAP, routing catch-all e migrazione lato server, senza prezzo per singolo utente. Per l'uscita puoi collegare un provider SMTP esterno secondo piano e limiti. La procedura guidata SPF/DKIM/DMARC è indicata durante l'onboarding, ma configurazione, disponibilità e verifica finale vanno confermate prima di inviare.
I piani sono descritti a partire da $3.50 al mese. È indicata una prova gratuita di 14 giorni con carta di credito, oppure un piano Nano senza carta, presentato come sempre gratuito, con 10 domini e 5 GB inclusi. Consulta trekmail.net/pricing per verificare prezzi, idoneità, funzioni e limiti attuali.
Riepilogo
Tra le cause da verificare figurano un tasso di reclami superiore allo 0.3%, errori di allineamento DMARC dovuti alla configurazione dell'ESP, superamento del limite SPF di 10 ricerche e rimbalzi permanenti verso Microsoft. Non sono le sole quattro cause possibili e ciascuna richiede dati e diagnosi specifici.
Se la reputazione è già compromessa, rivedi la lista, correggi il livello tecnico e aumenta gradualmente gli invii. Un periodo di due o quattro settimane è solo indicativo: non esiste una scorciatoia né una durata fissa.
Controlla oggi il DNS con strumenti autorizzati. Se trovi un errore, correggilo e convalida il risultato prima della prossima campagna.
