L’email deliverability è uno di quei temi che spesso vengono semplificati. Molte aziende la riducono a una domanda apparentemente lineare: “Le email arrivano oppure no?”. In realtà la questione è più complessa, perché tra un messaggio inviato dal server e un messaggio realmente visualizzato nella inbox del destinatario esiste una lunga catena di controlli tecnici, segnali reputazionali e valutazioni comportamentali.
Un’email può essere consegnata ma finire nello spam. Può essere accettata dal provider ma limitata nella visibilità. Può anche essere rifiutata prima ancora di raggiungere la casella del destinatario.
Per questo motivo, quando si parla di deliverability, il focus non va posto solo sul recapito tecnico, ma sulla capacità complessiva di far arrivare un messaggio legittimo nella posta in arrivo nel momento giusto, con continuità e senza deteriorare la reputazione del dominio.
Il tema riguarda sia chi invia newsletter e campagne commerciali, sia chi gestisce email transazionali, notifiche di sistema, conferme d’ordine, reset password o comunicazioni operative. Una scarsa deliverability non produce soltanto un calo delle aperture: può compromettere automazioni, relazioni commerciali, assistenza clienti e fiducia nel brand.
Per capire come migliorarla serve un approccio tecnico, ordinato e misurabile. Entrano in gioco l’autenticazione del dominio, i record DNS, la reputazione di IP e dominio, la qualità della lista contatti, la coerenza tra contenuto e aspettative del destinatario, la frequenza di invio, la gestione dei bounce e il monitoraggio continuo dei segnali che i provider usano per giudicare il mittente.
A tutto questo si aggiunge un punto spesso sottovalutato: SPF, DKIM e DMARC non sono una formalità burocratica.
Sono il fondamento su cui si costruisce identità, fiducia e protezione dallo spoofing. Senza questa base, ogni strategia di email marketing o posta aziendale parte con un limite tecnico serio.
Ecco perché affrontare il tema con profondità aiuta a prevenire problemi, migliorare il posizionamento dei messaggi in inbox e ridurre i rischi legati a phishing, impersonificazione del dominio e perdita di reputazione.
Cos’è l’email deliverability e perché non coincide con la semplice consegna
Quando si analizza la qualità di un sistema email, il primo errore da evitare è confondere delivery e deliverability.
La delivery indica che il messaggio è stato accettato dal server ricevente.
La deliverability valuta invece dove quel messaggio è finito, con quale probabilità verrà visto e quanto il mittente viene considerato affidabile nel tempo.
Questa distinzione è fondamentale perché molte dashboard mostrano tassi di consegna apparentemente elevati, mentre una quota rilevante dei messaggi viene filtrata nello spam o in cartelle secondarie.
Dal punto di vista operativo, la deliverability è il risultato di una combinazione di elementi tecnici e comportamentali. I provider di posta non esaminano solo il contenuto dell’email, ma osservano chi invia, da quale infrastruttura, con quale storia reputazionale, con quali autenticazioni, verso quali destinatari e con quali reazioni nel tempo.
Una campagna può essere perfettamente formattata e avere comunque prestazioni deboli se il dominio è giovane, se l’IP ha una cattiva reputazione o se le autenticazioni sono configurate male.
Un altro aspetto chiave è l’intento del messaggio. Le email transazionali, ad esempio, hanno spesso pattern diversi rispetto alle email promozionali.
Cambiano frequenza, contenuto, aspettativa del destinatario e tolleranza ai ritardi. Per questo motivo la deliverability non si gestisce con una singola regola valida per tutti, ma con un insieme di buone pratiche adattate al contesto.
Delivery, deliverability e inbox placement
La differenza tra questi termini merita una definizione chiara:
- Delivery: il messaggio viene accettato dal server ricevente.
- Deliverability: il messaggio riesce a raggiungere la casella giusta con una probabilità elevata di essere visto.
- Inbox placement: il messaggio finisce nella posta in arrivo e non nello spam o in altre sezioni filtrate.
Molti problemi nascono proprio qui. Se ci si ferma al solo dato di consegna, si rischia di credere che l’infrastruttura funzioni bene mentre il vero collo di bottiglia è la visibilità del messaggio.
Perché la deliverability impatta business, supporto e sicurezza
Una deliverability debole produce effetti molto concreti:
- riduce il ritorno delle campagne email;
- abbassa aperture, clic e conversioni;
- compromette email critiche come conferme ordine e reset password;
- aumenta il rischio di falsi positivi nei filtri antispam;
- espone il dominio a spoofing e perdita di fiducia.
Chi gestisce un ecosistema digitale maturo dovrebbe considerarla una disciplina trasversale tra marketing, infrastruttura, sicurezza e customer experience.
Da cosa dipende l’email deliverability
La deliverability non dipende da un singolo interruttore. È il risultato di segnali che i provider aggregano per decidere quanto fidarsi di un mittente.
Alcuni segnali sono visibili e misurabili, altri sono valutati tramite modelli proprietari. Per questa ragione conviene ragionare in termini di aree di controllo: identità del mittente, reputazione tecnica, qualità del database, comportamento di invio, contenuto del messaggio e risposte dei destinatari.
Uno dei punti più rilevanti è la reputazione. I provider valutano storicità del dominio, coerenza dei volumi, tassi di reclamo, autenticazione, bounce e altri indicatori.
Questo significa che una configurazione corretta non basta se i destinatari ignorano i messaggi, li segnalano come spam o se la lista contiene indirizzi obsoleti. Al contrario, anche una buona lista può essere penalizzata se il dominio invia senza DKIM, con SPF incompleto o con allineamento DMARC assente.
La deliverability migliora quando si lavora su più livelli contemporaneamente. Chi cerca scorciatoie tende a intervenire solo su subject line o layout, ma la parte decisiva sta spesso nei record DNS, nel controllo dei flussi di invio e nella manutenzione del database contatti.
Reputazione del dominio e reputazione IP
La reputazione del dominio riguarda l’affidabilità percepita del mittente nel tempo. La reputazione IP si concentra invece sull’indirizzo o sul pool di invio. Entrambe contano, ma oggi il dominio ha un peso crescente.
Fattori che incidono sulla reputazione:
- volume di invio stabile o improvvisamente anomalo;
- percentuale di spam complaint;
- hard bounce e indirizzi inesistenti;
- presenza su blocklist;
- cronologia di autenticazione corretta;
- engagement dei destinatari.
Se il dominio cambia provider, piattaforma o modalità di invio, è utile eseguire una fase di warm-up graduale, soprattutto in presenza di volumi medio-alti.
Qualità della lista e comportamento dei destinatari
Una lista sporca o acquisita male è tra le cause più frequenti dei problemi di deliverability. I provider osservano se i destinatari aprono, cliccano, ignorano, cancellano o segnalano.
Un database costruito con consenso debole, contatti vecchi o indirizzi inattivi tende a peggiorare questi segnali.
Le pratiche più utili sono:
- rimozione periodica degli hard bounce;
- segmentazione degli utenti inattivi;
- conferma dell’iscrizione con double opt-in quando appropriato;
- gestione corretta delle disiscrizioni;
- invio coerente con le aspettative dichiarate al momento della raccolta del contatto.
Contenuto, frequenza e coerenza del messaggio
Il contenuto non è l’unico fattore, ma resta importante. Email poco chiare, aggressive o scollegate dal consenso iniziale possono aumentare reclami e disinteresse.
Anche la frequenza conta: un aumento improvviso di volume o una cadenza incoerente può essere interpretata come segnale di rischio.
Ogni messaggio dovrebbe avere:
- mittente riconoscibile;
- oggetto coerente con il contenuto;
- call to action non fuorvianti;
- link funzionanti e domini coerenti;
- footer chiaro con modalità di contatto e disiscrizione.
SPF, DKIM e DMARC: la base tecnica dell’identità del mittente
Quando un provider riceve un’email, la prima domanda non è “questo contenuto è interessante?”, ma “posso fidarmi dell’identità dichiarata dal mittente?”.
SPF, DKIM e DMARC servono proprio a questo: dimostrare che il dominio che compare nell’email è autorizzato a inviare e che il messaggio non è stato alterato in transito.
Senza questa base, la deliverability si indebolisce e aumenta il rischio che il dominio venga usato per spoofing, phishing o altre forme di abuso.
L’errore più comune è attivare questi record in modo superficiale. Molti domini hanno uno SPF incompleto, un DKIM non firmato da tutti i sistemi che inviano oppure un record DMARC pubblicato ma senza una politica realmente utile.
La presenza del record, da sola, non garantisce che la configurazione sia efficace. Conta l’allineamento, conta la copertura reale di tutte le sorgenti di invio e conta il monitoraggio dei report.
Chi vuole migliorare la deliverability in modo stabile dovrebbe considerare l’autenticazione come un processo continuo, non come una configurazione una tantum.
SPF: chi è autorizzato a inviare per il dominio
SPF è un record DNS che indica quali server possono inviare email per conto del dominio. Quando il server ricevente controlla il messaggio, confronta la sorgente di invio con quanto dichiarato nel record SPF.
Il controllo riguarda in particolare il dominio usato nel Mail From o envelope sender, cioè l’identità tecnica utilizzata durante la sessione SMTP.
SPF è utile, ma ha alcuni limiti pratici:
- può rompersi nei forwarding;
- ha limiti sul numero di lookup DNS;
- spesso non copre tutti i servizi terzi effettivamente usati;
- da solo non basta a proteggere il dominio.
Per questo va mantenuto ordinato, sintetico e aggiornato ogni volta che si aggiunge una piattaforma di invio.
Dal punto di vista operativo, è importante conoscere anche i qualificatori più comuni del record SPF:
-allindica un fail esplicito per i server non autorizzati;~allsegnala un softfail, spesso usato in fasi iniziali o di transizione;?allesprime una posizione neutrale, poco utile in ottica di enforcement;+allautorizza qualunque server ed è generalmente da evitare.
Un errore frequente è costruire record SPF troppo complessi. SPF consente fino a 10 lookup DNS durante la valutazione: superare questo limite può generare errori permanenti e peggiorare la deliverability.
Quando il dominio usa più servizi di invio, conviene quindi razionalizzare il record, rimuovere riferimenti obsoleti e verificare con regolarità che tutti i sistemi effettivamente in uso siano coperti.
In scenari più articolati può essere utile anche valutare tecniche di SPF flattening, da usare con criterio per ridurre la complessità del record senza perdere controllo sulle sorgenti autorizzate.
DKIM: integrità del messaggio e firma crittografica
DKIM aggiunge una firma digitale all’email. Il server ricevente usa la chiave pubblica pubblicata nel DNS per verificare che il messaggio non sia stato modificato e che la firma corrisponda al dominio dichiarato.
DKIM ha un valore strategico forte perché:
- rafforza la fiducia tecnica del mittente;
- aiuta a superare i controlli di autenticazione anche in scenari dove SPF non è sufficiente;
- contribuisce all’allineamento richiesto da DMARC.
È buona pratica verificare che tutti i flussi di invio, incluse piattaforme esterne, firmino correttamente i messaggi con il dominio desiderato.
Dal punto di vista operativo, DKIM si basa anche sul concetto di selector, cioè un identificatore che permette di pubblicare nel DNS la chiave pubblica corretta associata a una determinata firma.
Questo approccio rende più semplice la gestione di chiavi diverse per servizi diversi o per fasi successive di rotazione.
Per ambienti moderni è in genere preferibile usare chiavi DKIM da 2048 bit, salvo limiti specifici della piattaforma utilizzata. Inoltre, la rotazione periodica delle chiavi è una buona pratica di sicurezza e governance, soprattutto quando il dominio invia da più strumenti o quando il team cambia provider, piattaforme o processi interni.
Un altro aspetto utile da considerare è la canonicalization DKIM: impostazioni più tolleranti, in alcuni casi, aiutano a mantenere valida la firma anche quando il messaggio subisce modifiche minime durante inoltri o rielaborazioni intermedie.
DMARC: politica, allineamento e visibilità sui problemi
DMARC collega SPF e DKIM a una regola di dominio. Dice ai provider come trattare i messaggi che non superano i controlli e permette di ricevere report utili per individuare abusi o errori di configurazione.
I vantaggi principali di DMARC sono:
- richiede allineamento tra autenticazione e dominio presente nel campo From;
- riduce il rischio di impersonificazione del dominio;
- fornisce report per analizzare chi invia davvero a nome del dominio;
- migliora la fiducia dei provider quando è configurato correttamente.
Una sequenza prudente prevede di partire da p=none, analizzare i report, correggere le sorgenti non allineate e solo dopo passare a politiche più restrittive come quarantine o reject.
Per rendere DMARC davvero utile è importante comprendere alcuni tag operativi del record:
ruaper i report aggregati;rufper i report forensi, quando supportati;pctper applicare la policy solo a una percentuale dei messaggi;adkimeaspfper definire il livello di allineamento, rilassato o stretto.
Questi parametri aiutano a gestire una fase di adozione graduale, utile soprattutto quando il dominio invia da più piattaforme e non c’è ancora una mappa completa di tutte le sorgenti autorizzate.
In una fase più avanzata può entrare in gioco anche BIMI (Brand Indicators for Message Identification), uno standard che permette di associare un logo verificato ai messaggi autenticati in alcuni provider compatibili.
BIMI non è obbligatorio per una buona deliverability, ma può migliorare riconoscibilità del brand e fiducia percepita, soprattutto quando il dominio ha già una configurazione DMARC matura.
A seconda del provider e del tipo di certificazione disponibile, BIMI può basarsi su VMC o su CMC: per questo conviene verificare sempre i requisiti del mailbox provider di riferimento prima di pianificarne l’adozione.
Come funziona il percorso di un’email: dal server mittente alla inbox
Per capire davvero la deliverability è utile osservare il tragitto tecnico di un messaggio. Un’email parte dal client o dalla piattaforma che la genera, viene gestita dal server o dal servizio SMTP del mittente, raggiunge il server del provider destinatario e, prima di essere accettata o filtrata, passa attraverso una serie di controlli.
In questa fase entrano in gioco reputazione del dominio, reputazione dell’IP, reverse DNS, coerenza dell’host di invio, autenticazione SPF, firma DKIM, allineamento DMARC, contenuto del messaggio, presenza di link sospetti, cronologia del mittente e segnali comportamentali associati a invii precedenti.
Questa visione aiuta a chiarire un punto essenziale: la deliverability non dipende da un singolo record DNS né dal solo testo dell’email.
Dipende dalla coerenza dell’intera catena tecnica. Se uno solo di questi elementi manda segnali contraddittori, il provider può ridurre la fiducia nel messaggio, rallentarlo, classificarlo come spam o rifiutarlo.
I controlli tecnici iniziali che spesso fanno la differenza
Tra i primi controlli effettuati da molti server destinatari rientrano anche aspetti infrastrutturali spesso sottovalutati, come il reverse DNS o record PTR dell’IP di invio.
Quando hostname, IP, identità SMTP e dominio del mittente risultano coerenti, il sistema appare più affidabile. Quando invece l’infrastruttura è configurata male o presenta incongruenze, la deliverability può peggiorare anche in presenza di un buon contenuto.
Per questo motivo, oltre a SPF, DKIM e DMARC, conviene verificare sempre:
- PTR o reverse DNS dell’IP di invio;
- coerenza tra hostname e IP;
- presenza di sistemi di invio non documentati;
- separazione chiara tra traffico transazionale e promozionale.
Come verificare l’email deliverability e individuare i problemi
Migliorare la deliverability senza misurazione è difficile. Serve una vista chiara sui segnali tecnici e sui risultati reali delle email inviate.
Per questa ragione è utile combinare strumenti di autenticazione, dashboard del provider, analisi dei bounce, monitoraggio delle complaint e controllo delle blocklist.
Un audit serio parte sempre dai dati: che percentuale dei messaggi autentica correttamente, quali domini firmano, quali campagne generano rimbalzi anomali, quali mailbox provider mostrano un peggioramento.
Anche i messaggi di errore SMTP meritano attenzione. Spesso contengono indizi decisivi: dominio con reputazione bassa, autenticazione assente, policy del provider non rispettata, picco di volume sospetto o problemi temporanei dell’infrastruttura. Trascurarli significa perdere una fonte primaria di diagnosi.
Un buon monitoraggio include sia indicatori tecnici sia metriche di comportamento. L’errore è guardare solo open rate e click rate: sono dati utili, ma da soli non raccontano lo stato della deliverability.
Metriche da controllare con continuità
Le metriche più utili sono:
- tasso di recapito;
- inbox placement quando disponibile;
- hard bounce e soft bounce;
- spam complaint rate;
- disiscrizioni;
- tasso di autenticazione SPF, DKIM e DMARC;
- errori SMTP ricorrenti;
- engagement per segmento e per provider.
Se i bounce crescono, le complaint aumentano o l’autenticazione cala, il problema va affrontato prima che si trasformi in un danno reputazionale più ampio.
Strumenti utili per il controllo tecnico
Tra gli strumenti più pratici ci sono:
- Google Postmaster Tools per osservare reputazione e autenticazione sul traffico Gmail;
- strumenti di verifica DNS e autenticazione come MXToolbox;
- report DMARC aggregati;
- log del proprio SMTP o dell’ESP;
- controlli periodici delle blocklist pertinenti;
- Microsoft SNDS per ottenere visibilità sul traffico e sulla reputazione nell’ecosistema Microsoft;
- feedback loop, dove disponibili, per intercettare segnalazioni di spam;
- seed list testing per controllare in modo comparativo il comportamento dei principali provider.
L’obiettivo non è accumulare tool, ma costruire una routine di monitoraggio che permetta di capire rapidamente se il problema nasce dall’autenticazione, dal contenuto, dalla reputazione o dalla qualità della lista.
Per comprendere meglio la parte infrastrutturale della posta elettronica, può essere utile approfondire anche il funzionamento di POP3, IMAP e SMTP, perché la deliverability si inserisce in una filiera tecnica più ampia.
Come migliorare l’email deliverability in modo stabile
Una deliverability solida non nasce da un singolo intervento, ma da una disciplina operativa.
La logica corretta è questa: prima si mette ordine nell’identità del mittente, poi si stabilizza l’infrastruttura, poi si ripuliscono i dati, infine si ottimizzano frequenza, contenuti e monitoraggio. Invertire questo ordine porta spesso a inseguire sintomi secondari senza risolvere la causa.
Chi invia volumi elevati dovrebbe separare i flussi: marketing, transazionali e comunicazioni di servizio non dovrebbero necessariamente condividere gli stessi percorsi reputazionali.
Una reputazione compromessa sul traffico promozionale può riflettersi anche su email critiche per l’operatività, come reset password o notifiche di accesso.
Anche la sicurezza ha un ruolo diretto. Un dominio vulnerabile a spoofing o phishing viene percepito come più rischioso sia dai provider sia dagli utenti. Da questo punto di vista, la deliverability migliora quando si riduce la superficie di abuso.
Checklist tecnica di priorità
Per impostare un lavoro ordinato conviene seguire questa sequenza:
- verificare SPF, DKIM e DMARC su tutte le sorgenti di invio;
- controllare l’allineamento tra dominio del From e autenticazioni;
- eliminare invii da sistemi non autorizzati o dimenticati;
- configurare correttamente reverse DNS, PTR, hostname e identità SMTP quando applicabile;
- separare flussi transazionali e promozionali;
- valutare se usare IP condiviso o IP dedicato in base a volumi, competenze e necessità di controllo;
- fare warm-up graduale di dominio o IP in caso di nuove attivazioni;
- pulire il database contatti;
- ridurre frequenze e segmentare gli utenti inattivi;
- monitorare report DMARC e dashboard reputazionali;
- reagire subito a reclami, bounce anomali e blocchi.
IP condiviso o IP dedicato: quando conta davvero
La scelta tra IP condiviso e IP dedicato incide soprattutto quando i volumi di invio iniziano a diventare significativi.
Un IP condiviso consente di beneficiare della reputazione collettiva del provider, a patto che l’infrastruttura sia ben gestita. È spesso adatto a chi invia volumi contenuti o non ha risorse interne per amministrare in modo rigoroso la reputazione dell’invio.
Un IP dedicato, invece, offre più controllo ma richiede maggiore disciplina operativa. Tutta la reputazione dipende dal comportamento del singolo mittente: qualità della lista, frequenza, volumi, reclami, bounce e stabilità degli invii. In questi casi il warm-up dell’IP diventa decisivo, perché un IP nuovo non ha storico e deve costruire fiducia progressivamente presso i mailbox provider.
La scelta migliore non è sempre quella più autonoma. Dipende dal volume reale, dal tipo di traffico inviato e dalla capacità del team di mantenere processi puliti e costanti nel tempo.
Sicurezza, spoofing e fiducia del dominio
Autenticare il dominio significa anche proteggerlo. Per questo è utile collegare il lavoro sulla deliverability a una cultura di sicurezza più ampia. Su questo fronte possono essere inseriti in modo naturale due approfondimenti utili: uno sull’email spoofing, che aiuta a capire perché SPF, DKIM e DMARC sono così importanti, e uno sul phishing, utile per inquadrare il problema dal punto di vista dell’utente finale e della fiducia verso il mittente.
Per i team che curano la postura di sicurezza in senso più ampio, può essere pertinente anche il tema di privacy e sicurezza operativa, perché una gestione matura dell’identità digitale non riguarda solo l’email, ma l’intero ecosistema di accessi e protezione.
Errori frequenti che peggiorano l’email deliverability
Molti problemi di deliverability non dipendono da un errore macroscopico, ma da una somma di piccole incoerenze.
È il caso dei domini che inviano da più strumenti senza avere una mappa aggiornata delle sorgenti, delle aziende che cambiano provider senza rifare i record DNS o dei team marketing che aumentano i volumi senza un adeguato warm-up.
Spesso nessuno di questi errori, preso da solo, sembra grave. Insieme però producono un profilo di rischio che i provider intercettano rapidamente.
Un altro errore diffuso è trattare SPF, DKIM e DMARC come un’attività una tantum. In realtà ogni nuovo CRM, help desk, piattaforma newsletter, tool per fatturazione o servizio cloud che invia email può introdurre una nuova sorgente da autorizzare, firmare e monitorare.
Se questo passaggio manca, parte del traffico resta fuori controllo e può fallire i controlli di allineamento.
I problemi più comuni da correggere subito
Ecco gli errori che meritano priorità alta:
- record SPF troppo lunghi, duplicati o incompleti;
- DKIM attivo solo su una parte delle email;
- DMARC pubblicato ma ignorato, senza lettura dei report;
- liste acquistate o poco aggiornate;
- mancanza di one-click unsubscribe dove richiesto o opportuno;
- picchi di invio improvvisi da domini nuovi;
- contenuti promozionali inviati a utenti freddi o inattivi;
- uso dello stesso dominio per flussi molto diversi senza separazione reputazionale.
Il falso mito del “basta cambiare server SMTP”
Spostare l’invio su un nuovo SMTP può aiutare solo in casi specifici. Se però restano irrisolti problemi di consenso, autenticazione, allineamento o reputazione del dominio, il beneficio dura poco.
Il provider cambia, ma i segnali che i mailbox provider leggono restano deboli.
La deliverability migliora davvero quando l’intero sistema di invio diventa più credibile, prevedibile e ben governato.
Fonti affidabili e riferimenti utili
Per un tema come l’email deliverability conviene fare riferimento a documentazione ufficiale, standard tecnici e risorse autorevoli dei principali provider.
Tra le fonti più utili rientrano le linee guida per i sender di Google, i materiali tecnici su autenticazione e protezione del dominio, le pagine di supporto dedicate a SPF, DKIM, DMARC e BIMI, oltre agli strumenti di monitoraggio della reputazione e dei report di autenticazione.
Accanto alle fonti ufficiali, possono essere utili anche articoli tecnici di settore e strumenti pratici per la verifica dei record DNS, purché vengano usati come supporto e non come unico riferimento.
Su un argomento che tocca deliverability, sicurezza e reputazione, la qualità delle fonti fa la differenza anche nella fase di implementazione.
FAQ su SPF, DKIM e DMARC
1. Cos’è l’email deliverability in parole semplici?
L’email deliverability è la capacità di un messaggio di arrivare davvero nella casella di posta in arrivo del destinatario, e non solo di essere accettato dal server ricevente. Per questo è diversa dalla semplice consegna tecnica del messaggio.
2. Qual è la differenza tra delivery e deliverability?
La delivery indica che l’email è stata recapitata al server del provider destinatario. La deliverability misura invece la probabilità che il messaggio finisca in inbox, eviti la cartella spam e mantenga nel tempo una buona affidabilità.
3. SPF, DKIM e DMARC sono obbligatori?
Dal punto di vista tecnico e reputazionale sono ormai fondamentali. Anche quando non sono formalmente richiesti in ogni singolo scenario, rappresentano la base per autenticare il dominio, ridurre il rischio di spoofing e migliorare la fiducia dei provider.
4. Perché le email finiscono nello spam anche se il server funziona?
Perché il problema non dipende solo dal server SMTP. I provider valutano reputazione del dominio, autenticazione, qualità della lista, contenuto, frequenza di invio, tasso di reclamo e comportamento storico dei destinatari.
5. Qual è il primo controllo da fare se la deliverability peggiora?
Il primo passo è verificare SPF, DKIM e DMARC, controllare eventuali bounce o reclami anomali, osservare la reputazione del dominio nei principali strumenti di monitoraggio e capire se ci sono stati cambiamenti recenti nei volumi o nelle sorgenti di invio.
Lascia un commento