Come testare e configurare la Deliverability email in Salesforce

Un commerciale scrive un'email da un record Lead in Salesforce, preme invia e non succede niente: nessun errore visibile, ma il destinatario non riceve mai il messaggio. Nella maggior parte dei casi la causa non è il contenuto dell'email né il dominio mittente, ma una singola impostazione di Setup chiamata Deliverability, spesso configurata da un amministratore anni prima e mai più rivista. Questa guida spiega dove si trova, come leggerla e come usarla senza bloccare per errore l'outreach B2B che passa dal CRM.

Perché questa impostazione riguarda chi fa outreach B2B dal CRM

Molti team commerciali collegano Salesforce a un tool di sequenze o inviano direttamente dai record di Lead e Contact, pensando che il CRM sia solo un contenitore di dati. In realtà ogni organizzazione Salesforce ha un pannello che decide centralmente se quelle email possono uscire, con quale livello di accesso e verso chi. Se questo pannello è configurato in modo restrittivo, un intero flusso di outreach a un pugno di decisori selezionati può fermarsi senza che nessuno se ne accorga per giorni.

Il problema si nota tipicamente in due momenti: quando un'organizzazione sandbox viene clonata dalla produzione (le sandbox nascono con Deliverability impostata su System Email Only) e quando un amministratore, per prudenza dopo un incidente di spam, restringe l'accesso e dimentica di riaprirlo. In entrambi i casi il sintomo è identico: email composte correttamente, contatto corretto, ma zero recapito e zero errore in interfaccia.

Per un'agenzia o un team che lavora su liste piccole e qualificate, con pochi invii al giorno verso persone fisiche precise, questo tipo di blocco silenzioso è particolarmente costoso: si perde la finestra di contatto con un decisore proprio nel momento in cui la sequenza era pronta a partire.

Dove si trova e come attivare Deliverability

Il percorso in Setup è Email, poi Email Administration, poi Deliverability (in alcune versioni dell'interfaccia si trova cercando semplicemente «Deliverability» nella casella di ricerca rapida di Setup). La pagina mostra un menu a tendina chiamato Access Level con quattro opzioni: All Email, No Mass Mail, System Email Only e No Access.

All Email consente l'invio di qualunque email dall'organizzazione, incluse quelle composte manualmente dai singoli utenti e quelle generate da automazioni o integrazioni esterne. No Mass Mail blocca solo gli invii massivi nativi di Salesforce ma lascia passare le email singole dai record: è l'opzione più comune per chi fa outreach one-to-one dal CRM, perché evita che qualcuno lanci per errore una campagna di massa dallo stesso ambiente usato per la prospezione mirata.

System Email Only lascia passare solo le notifiche di sistema (reset password, notifiche di workflow) e blocca tutto il resto: se un team scopre che le email dai Lead non partono più, questa è la prima voce da controllare. No Access blocca ogni invio, compresi quelli di sistema, ed è pensata per ambienti sandbox o di test dove non deve uscire nulla verso indirizzi reali.

Come leggere il log e il report degli invii

Nella stessa area di Setup si trova la casella Enable Email Logging (a volte etichettata come log delle email inviate). Attivandola, Salesforce genera un file CSV con l'elenco degli invii delle ultime 24-48 ore e lo consegna all'indirizzo dell'amministratore che ha richiesto il log: contiene mittente, destinatario, oggetto, stato di consegna e codice di errore quando presente.

Un secondo strumento utile è la Compliance BCC Email: impostando un indirizzo qui, ogni email inviata dall'organizzazione — comprese quelle dai record Lead e Contact — arriva in copia nascosta a quella casella. È il modo più affidabile per verificare cosa è stato davvero spedito, perché non dipende dal fatto che il destinatario risponda o apra il messaggio.

Per chi lavora con volumi bassi e mirati, la combinazione di log CSV e Compliance BCC è sufficiente a ricostruire la storia di ogni singolo invio senza bisogno di strumenti esterni: è un report grezzo, non un cruscotto, ma è preciso e affidabile.

Testare un invio e diagnosticare un mancato recapito

Il test più semplice è inviare un'email da un record Contact verso un indirizzo di posta personale controllato dal team, verificando sia l'arrivo sia la cartella (posta in arrivo o spam). Se l'email non arriva affatto, la causa quasi sempre è l'Access Level; se arriva ma finisce in spam, il problema si sposta sull'autenticazione del dominio mittente, che Salesforce non gestisce automaticamente.

Un secondo controllo riguarda il Bounce Management, un'altra sezione di Email Administration che, se attivata, marca automaticamente come non validi gli indirizzi che generano un hard bounce. Se questa funzione è disattivata, un indirizzo morto può continuare a ricevere tentativi di invio a ogni sequenza, danneggiando la reputazione del dominio senza che nessuno se ne accorga.

Infine, se l'organizzazione invia tramite un Email Relay configurato per instradare la posta attraverso un server SMTP esterno, un mancato recapito può dipendere da quel relay e non da Salesforce stesso: in questo caso va controllato il log del provider SMTP collegato, non solo quello del CRM.

Quando disattivare Deliverability e quali errori evitare

Impostare No Access è corretto in una sandbox usata per test di sviluppo, dove il rischio è inviare per sbaglio email a contatti reali durante una prova. È un errore, invece, lasciare System Email Only su un'organizzazione di produzione dopo un test o un incidente: blocca silenziosamente ogni sequenza di outreach finché qualcuno non nota il problema, spesso settimane dopo.

Un altro errore frequente è confondere Deliverability con l'autenticazione del dominio: attivare All Email non basta a far arrivare le email nella casella principale del destinatario se il dominio mittente non ha record SPF e DKIM corretti. Salesforce gestisce il permesso di uscita, non la reputazione del mittente sui server di Gmail o Microsoft 365.

Infine, chi gestisce più organizzazioni (produzione e una o più sandbox) dovrebbe documentare chi ha accesso a modificare questa impostazione: è una delle configurazioni più critiche e meno visibili dell'intero ambiente, e un cambio non comunicato può fermare la pipeline commerciale per giorni.

• Verificare l'Access Level ogni volta che si clona una sandbox dalla produzione
• Attivare Enable Email Logging e Compliance BCC prima di lanciare una nuova sequenza
• Attivare Bounce Management per evitare invii ripetuti a indirizzi morti
• Non confondere l'attivazione di Deliverability con l'autenticazione SPF/DKIM del dominio
• Documentare chi può modificare questa impostazione e quando è stata cambiata l'ultima volta

Il ruolo di Salesforce nel flusso di outreach B2B mirato

Per un'agenzia o un team interno che lavora su liste piccole e qualificate, Salesforce funziona bene come archivio delle attività e delle risposte, meno bene come motore di invio per una vera campagna di prospezione. L'invio massivo nativo del CRM non è pensato per la cura di reputazione di dominio, il warm-up progressivo o la rotazione tra caselle che servono a mantenere un buon tasso di recapito nel tempo.

Un flusso più solido separa i due ruoli: Salesforce resta il sistema di verità su lead, aziende e cronologia dei contatti, mentre l'invio vero e proprio delle email di prospezione passa da un dominio dedicato, autenticato con SPF e DKIM, e da un volume calibrato sul singolo destinatario. I risultati (aperture, risposte, bounce) vengono poi sincronizzati indietro nel CRM come attività, così il commerciale continua a lavorare da un'unica vista.

Questa separazione riduce anche il rischio legale e organizzativo: se la Deliverability dell'organizzazione principale viene ristretta per un incidente, l'outreach mirato in corso su dominio separato non si ferma insieme al resto del traffico email interno dell'azienda.

Domande frequenti