SPF, DKIM e DMARC per Salesforce Marketing Cloud.
Salesforce Marketing Cloud Engagement (ex ExactTarget) non autentica l'email come un ESP self-service. Non puoi incollare un record e fare clic su “verify”: devi invece acquistare un Sender Authentication Package (SAP) o il più leggero componente aggiuntivo Private Domain, Salesforce predispone per il tuo account un sottodominio di invio dedicato (e di solito un IP dedicato) e tu deleghi quel sottodominio ai nameserver di Salesforce oppure pubblichi esattamente i record SPF, DKIM e MX che ti fornisce il loro team di deliverability. Questa guida illustra la procedura SAP reale: il meccanismo SPF include:cust-spf.exacttarget.com, la chiave DKIM condivisa 200608 rispetto alla chiave dedicata delegata tramite CNAME che si allinea davvero al tuo dominio, la delega del sottodominio rispetto al DNS gestito in proprio, Reply Mail Management e il record DMARC che devi aggiungere tu.
Perché autenticare Salesforce Marketing Cloud?
Da febbraio 2024 Gmail e Yahoo richiedono a ogni mittente di grandi volumi di superare SPF, DKIM e una policy DMARC: se non li rispetti, gli invii di Marketing Cloud vengono rallentati o finiscono nello spam proprio presso i provider di posta dove si trova il tuo pubblico. Un'autenticazione SAP corretta elimina anche l'indicatore di dominio condiviso / “via”, applica il tuo brand ai link di tracciamento dei clic, delle immagini, di View-as-webpage e delle CloudPages, e permette a SFMC di inviare da un IP dedicato su cui costruire una reputazione pulita. Poiché SAP invia da un sottodominio del tuo dominio, sia SPF (busta/return-path sul tuo sottodominio) sia DKIM (una chiave dedicata sul tuo sottodominio) possono allinearsi al tuo dominio organizzativo per DMARC: una posizione più solida rispetto alla maggior parte degli ESP, ma solo se firmi con la chiave DKIM dedicata invece che con la chiave condivisa predefinita 200608 e pubblichi tutto correttamente.
Come funziona davvero SPF con Salesforce Marketing Cloud
L'autorizzazione SPF di SFMC è un include reale e attivo: include:cust-spf.exacttarget.com. Se lo risolvi oggi ottieni un unico record piatto di circa 50 intervalli ip4 che termina con ~all, senza include annidati, quindi costa esattamente una delle dieci ricerche DNS di SPF. Due aspetti distinguono SFMC da un normale provider del tipo “aggiungi questo include al tuo SPF”. Primo, l'include va sul sottodominio di invio SAP dedicato (es. cloud.yourdomain.com), non sul dominio radice/apex: SFMC non invia quasi mai direttamente dal tuo dominio principale, quindi metterlo sulla radice di solito aggiunge una ricerca che non serve a nulla. Secondo, nella configurazione consigliata da Salesforce deleghi l'intero sottodominio a Salesforce tramite record NS ed è Salesforce a gestire il record SPF per te, quindi potresti non toccare mai direttamente la stringa SPF. Solo se gestisci il DNS in proprio sei tu a pubblicare v=spf1 include:cust-spf.exacttarget.com ~all sul sottodominio. In entrambi i casi l'include sta nel record SPF del sottodominio, quindi non intacca mai il budget di ricerche del tuo dominio radice: ecco perché non va aggiunto per impostazione predefinita all'SPF del dominio radice.
Due modi per configurarlo
Delega il sottodominio di invio a Salesforce (consigliato)
- Aggiungi record NS che fanno puntare il sottodominio SAP (es. cloud.yourdomain.com) ai nameserver di Salesforce
- Salesforce gestisce per te SPF (cust-spf.exacttarget.com), la chiave DKIM dedicata, l'MX di risposta e i record di tracciamento
- Salesforce può ruotare automaticamente la chiave DKIM dedicata, senza coordinamento manuale delle chiavi
- Manutenzione minima; meno occasioni di sbagliare a digitare un record
- NON pubblicare anche SPF/DKIM per quel sottodominio nella zona padre
Gestisci i record SAP nel tuo DNS
- Mantieni il DNS internamente e pubblica esattamente i record forniti dal team di deliverability di Salesforce
- SPF: aggiungi v=spf1 include:cust-spf.exacttarget.com ~all sul sottodominio di invio
- DKIM: pubblica il CNAME (o TXT) specifico dell'account fornito da Salesforce; non convertire un CNAME in TXT
- MX: aggiungi il record di Reply Mail Management sul tuo sottodominio di risposta
- Il coordinamento della rotazione delle chiavi DKIM spetta a te: più controllo, più manutenzione
Passo dopo passo
- 1
Conferma di avere SAP o un Private Domain
L'autenticazione di SFMC non è self-service. Per autenticare la posta sul tuo dominio ti serve il Sender Authentication Package a pagamento (o il più leggero componente aggiuntivo Private Domain); Salesforce lo propone ai mittenti con oltre ~250.000 email al mese. Senza questo pacchetto invii da un dominio condiviso exacttarget.com per cui non puoi pubblicare record. L'attivazione passa dal tuo account team: la parte DNS/configurazione richiede spesso circa cinque giorni lavorativi dall'invio del modulo di richiesta, ma contratto e assegnazione dell'IP allungano i tempi, quindi parti da qui.
- 2
Scegli il sottodominio di invio dedicato
SAP predispone un dominio privato che è un sottodominio del tuo brand, di solito cloud.yourdomain.com, email.yourdomain.com o mkt.yourdomain.com. Ogni indirizzo From, URL di tracciamento di link/immagini, link View-as-webpage e CloudPage dell'account lo userà, quindi scegli un sottodominio che ti stia bene vedere a lungo nelle caselle di posta e nei browser.
- 3
Scegli tra delega e DNS gestito in proprio
Opzione preferita: delega il sottodominio di invio ai nameserver di Salesforce tramite record NS, così Salesforce gestisce i record SPF, DKIM, di tracciamento e di risposta da un file di zona che amministra e può ruotare le chiavi DKIM per te. Alternativa: mantieni il DNS internamente e pubblica esattamente i record forniti da Salesforce. La delega richiede meno manutenzione; la gestione in proprio ti lascia il controllo, ma il coordinamento della rotazione delle chiavi resta a tuo carico.
- 4
Procedura con delega: aggiungi i record NS per il sottodominio
Crea record NS per il sottodominio di invio che puntino ai nameserver Salesforce/ExactTarget indicati dal tuo team (es. cloud.yourdomain.com NS -> gli host del file di zona di Salesforce). Non pubblicare anche SPF o DKIM per quel sottodominio nella zona padre: la zona figlia delegata diventa autoritativa e i record della zona padre vengono ignorati.
- 5
Procedura in proprio: pubblica il record SPF sul sottodominio
Se non deleghi, aggiungi un record TXT sul sottodominio di invio: v=spf1 include:cust-spf.exacttarget.com ~all. È il valore documentato da Salesforce; restringi ~all a -all solo dopo aver verificato che nient'altro invii a nome di quel sottodominio. Mantieni un unico record TXT SPF, mai due.
- 6
Pubblica la chiave DKIM
SAP predispone una chiave DKIM dedicata che Salesforce di solito delega come CNAME sul tuo sottodominio di invio (un selettore specifico dell'account/stack come [stack]dkim1._domainkey.cloud.yourdomain.com che punta a [stack]dkim1._domainkey.sNN.exacttarget.com), così è Salesforce a conservare e ruotare la chiave privata e la firma si allinea al tuo dominio. Le configurazioni meno recenti ti forniscono invece una chiave pubblica TXT grezza da pubblicare. Il selettore condiviso 200608 è la chiave legacy su exacttarget.com e NON si allinea al tuo dominio. Pubblica esattamente ciò che fornisce Salesforce: non sei mai tu a generare la chiave (a differenza di Salesforce core con Setup > DKIM Keys).
- 7
Configura Reply Mail Management
Configura il dominio di risposta autenticato in modo che le risposte degli iscritti, i bounce delle risposte automatiche di assenza e le richieste manuali di disiscrizione tornino in SFMC. Questo pubblica un record MX su un sottodominio di risposta (e su un sottodominio di bounce parallelo) che punta all'infrastruttura di ricezione di Salesforce. Se lo salti, le risposte alle tue campagne non arrivano dove servono.
- 8
Aggiungi DMARC, poi verifica e attiva
SAP non crea DMARC: aggiungi tu il TXT _dmarc.yourdomain.com, partendo da v=DMARC1; p=none con una casella rua. Conferma che il dominio privato risulti Active/autenticato in SFMC Setup, invia un'email di prova (seed) e controlla che le intestazioni mostrino spf=pass e dkim=pass con il dominio d= e quello della busta allineati al tuo sottodominio (non exacttarget.com). Quando i report aggregati sono puliti, porta la policy a quarantine, poi a reject.
Record da aggiungere
Salesforce Marketing Cloud genera i valori esatti nella sua procedura guidata di configurazione: questi mostrano la struttura di ciò che aggiungerai presso il tuo provider DNS.
| Tipo | Host | Valore |
|---|---|---|
| TXT | cloud.yourdomain.com | v=spf1 include:cust-spf.exacttarget.com ~allSPF sul sottodominio di invio SAP (metodo con DNS gestito in proprio). Nel modello consigliato con delega è Salesforce a gestirlo per te; è riportato qui per gli account che mantengono il DNS internamente. Il nome del sottodominio di invio è assegnato per account: valore di esempio. Sta nell'SPF del sottodominio, quindi non tocca mai il budget di 10 ricerche del tuo dominio radice. |
| CNAME | s10dkim1._domainkey.cloud.yourdomain.com | s10dkim1._domainkey.s10.exacttarget.comChiave DKIM SAP dedicata, delegata tramite CNAME così che Salesforce possa ruotarla: è questa la chiave che si allinea al tuo dominio per DMARC. Il selettore (es. [stack]dkim1) e il numero di stack (sNN) sono specifici dell'account; pubblica esattamente ciò che fornisce Salesforce. Non convertire un CNAME in TXT e non accorciare il nome host. |
| TXT | <selector>._domainkey.cloud.yourdomain.com | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...Formato DKIM alternativo: alcune configurazioni SAP forniscono una chiave pubblica TXT grezza invece di un CNAME. Il selettore è specifico dell'account e fornito da Salesforce (quello predefinito condiviso, che non si allinea, è 200608 su exacttarget.com, non sul tuo dominio). Chiave di esempio: non copiarla così com'è. |
| MX | reply.yourdomain.com | reply.s10.exacttarget.comMX di Reply Mail Management, perché risposte degli iscritti, risposte automatiche di assenza e richieste di disiscrizione passino da SFMC. Viene predisposto anche un MX parallelo per il sottodominio di bounce (bounce.sNN.exacttarget.com). Sottodominio di risposta, stack (sNN) e host MX sono specifici dell'account: valori di esempio. |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARC lo aggiungi tu: SAP non lo crea mai. Inizia con p=none, poi passa a quarantine/reject quando i report sono puliti. |
Tieni esattamente un record TXT SPF (v=spf1) sul dominio radice e unisci al suo interno tutti i mittenti. Avere due record SPF è di per sé un errore.
Il limite di 10 ricerche DNS
SPF ha un tetto fisso di 10 ricerche DNS: se lo superi, restituisce un permerror e smette di essere valido ovunque. Ecco quanto consuma di questo budget la configurazione di Salesforce Marketing Cloud.
Salesforce Marketing Cloud occupa 1 delle tue 10 ricerche; i meccanismi ip4: e ip6: non consumano ricerche.
DKIM
In Salesforce Marketing Cloud convivono due storie DKIM diverse. Quella predefinita legacy è un'unica chiave condivisa con selettore 200608, creata nel 2006 e usata da tutti gli account SFMC senza dominio privato. È pubblicata su exacttarget.com, firma come d=exacttarget.com e quindi NON si allinea al tuo dominio From per DMARC; inoltre, essendo un selettore TXT fisso, è scomoda da ruotare. Quando attivi SAP / un dominio privato, Salesforce emette invece una chiave DKIM dedicata e di solito la delega tramite un CNAME sul tuo sottodominio di invio (un selettore specifico dell'account/stack come s10dkim1._domainkey.cloud.yourdomain.com che punta a s10dkim1._domainkey.s10.exacttarget.com), così è Salesforce a conservare e ruotare la chiave privata mentre la firma si allinea al tuo dominio organizzativo. Alcune configurazioni ti forniscono ancora una chiave pubblica TXT grezza da pubblicare. In ogni caso Salesforce fornisce sempre il record esatto: non sei mai tu a generare la chiave, a differenza di Salesforce core (Sales/Service Cloud), dove la crei in Setup > DKIM Keys. Poiché una chiave SAP dedicata firma con un sottodominio del tuo dominio, è la strada più affidabile per superare DMARC: verifica che il tuo pacchetto includa una chiave dedicata e allineata al dominio invece di affidarti alla chiave condivisa predefinita 200608.
DMARC
SAP non crea né gestisce DMARC: lo pubblichi tu. Aggiungi un record TXT su _dmarc.yourdomain.com: inizia con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com per raccogliere i report aggregati senza influire sul recapito. Poiché SAP invia da un sottodominio del tuo dominio, SPF può allinearsi tramite la busta/return-path su quel sottodominio e DKIM tramite la chiave SAP dedicata: DMARC può quindi essere superato con l'uno o con l'altro, e DKIM è il meccanismo di allineamento più solido. La sola chiave condivisa 200608 non si allinea (firma come exacttarget.com), quindi assicurati che il tuo account firmi con la chiave dedicata prima di applicare la policy. Attenzione alla policy dei sottodomini: se imposti p=reject, aggiungi sp= in modo consapevole e verifica prima che il sottodominio di invio SAP sia completamente autenticato. Procedi per gradi, p=none -> quarantine -> reject, solo dopo che i report confermano che tutta la tua posta legittima di SFMC (e degli altri mittenti) supera i controlli con allineamento.
Verifica che funzioni davvero
Interroga l'SPF del sottodominio di invio (dig +short TXT cloud.yourdomain.com) e conferma che restituisca include:cust-spf.exacttarget.com, poi controlla il selettore DKIM che ti ha dato Salesforce (es. dig +short CNAME s10dkim1._domainkey.cloud.yourdomain.com, oppure una ricerca TXT se ti è stata fornita una chiave grezza; non il selettore condiviso 200608). Invia una campagna di prova (seed) a una casella che controlli e ispeziona le intestazioni: Authentication-Results deve mostrare spf=pass e dkim=pass, e sia il dominio DKIM d= sia il dominio della busta SPF devono essere il tuo sottodominio (allineati), non exacttarget.com. In Marketing Cloud Setup, conferma che il dominio privato / SAP risulti Active e autenticato (non Pending). Poi analizza il sottodominio di invio e il record _dmarc con il controllo autenticazione email e il check-up del dominio di Qualisend per individuare errori di battitura, record dietro proxy o una policy DMARC mancante prima di aumentare i volumi.
Insidie comuni
- Configurazione DNS
Non è self-service. Non puoi limitarti a pubblicare i record e iniziare a inviare: SAP / Private Domain è un componente aggiuntivo a pagamento attivato dal team di Salesforce (circa cinque giorni lavorativi per il DNS dopo l'invio del modulo, più i tempi del contratto) ed è pensato per mittenti con oltre ~250.000 email al mese. Senza SAP invii da un dominio condiviso exacttarget.com che non puoi autenticare.
- Configurazione DNS
Prodotto giusto, record giusti. include:cust-spf.exacttarget.com e il selettore 200608 valgono SOLO per Marketing Cloud Engagement (ExactTarget). Salesforce core (Sales/Service Cloud) usa include:_spf.salesforce.com con chiavi che generi in Setup > DKIM Keys, e Account Engagement (Pardot) usa i propri CNAME di tracciamento: non unirli mai in un unico record SPF.
- Fa fallire l'autenticazione
Sottodominio, non radice. SAP invia da un sottodominio dedicato (es. cloud.yourdomain.com), ed è lì che stanno include, DKIM e MX. Non aggiungere cust-spf.exacttarget.com all'SPF del tuo dominio radice/apex, a meno che l'indirizzo From di SFMC non sia davvero sul dominio radice: per la maggior parte degli account aggiunge solo una ricerca che non serve a nulla.
- Configurazione DNS
200608 è la chiave condivisa, e non si allinea. Il selettore 200608 è l'unica chiave DKIM condivisa di Marketing Cloud (risalente al 2006), pubblicata su exacttarget.com; firma come exacttarget.com, quindi non ti dà alcun DKIM allineato al dominio per DMARC e, essendo un selettore TXT fisso, è difficile da ruotare. L'allineamento al dominio arriva dalla chiave SAP dedicata che Salesforce delega tramite CNAME: verifica che il tuo pacchetto la includa.
- Configurazione DNS
Delega e record manuali sono in conflitto. Se deleghi il sottodominio a Salesforce tramite NS, NON pubblicare anche SPF/DKIM per quel sottodominio nella zona padre: la zona figlia delegata è autoritativa e i record della zona padre vengono ignorati senza alcun avviso.
- Configurazione DNS
Pubblica i record esattamente come sono. Non convertire un CNAME di Salesforce in TXT, non accorciare i nomi host e non mettere i record dietro proxy (niente nuvola arancione di Cloudflare): ognuno di questi errori rompe DKIM, l'instradamento delle risposte o la risoluzione del return-path.
- Configurazione DNS
Budget SPF e qualificatore. cust-spf.exacttarget.com è un unico record piatto solo ip4 = una sola ricerca (nessun annidamento), ma è grande. Il valore documentato da Salesforce termina con ~all; restringi a -all solo quando hai la certezza che nient'altro invii a nome di quel sottodominio.
- Configurazione DNS
DMARC tocca a te. SAP non crea _dmarc: senza una policy DMARC pubblicata, le regole di Gmail e Yahoo per i mittenti di grandi volumi rallenteranno i tuoi invii di Marketing Cloud o li manderanno nello spam.
Crea il tuo record SPF
Salesforce Marketing Cloud non richiede un include: nel record SPF del dominio radice. Usa il generatore per comporre un unico record pulito per gli altri mittenti e tienilo su una sola riga.
Fonti di invio
Cerca ogni piattaforma con cui invii email e selezionala.
Cerca qui sopra la tua piattaforma email oppure .
Server propri del dominio
Autorizza il dominio stesso, se invia posta direttamente (non tramite una delle piattaforme sopra).
Altri mittenti e IP
Tutto ciò che non è nella lista: l'host SPF di un altro provider o indirizzi IP specifici.
Aggiungiamo noi il prefisso include:. Inserisci l'hostname indicato nella documentazione del provider.
Policy per tutti gli altri
Cosa devono fare i server riceventi con la posta proveniente da server non elencati sopra (il meccanismo all).
Ancora nessun mittente, quindi ogni messaggio finirebbe nella policy ~all. Aggiungi al passaggio 1 le piattaforme con cui invii.
- Pubblicalo come record TXT sul dominio radice: host @ (il dominio senza prefissi), come valore l'intera stringa qui sopra.
- Tieni un solo record SPF per dominio. Unisci tutte le fonti di invio in quest'unica riga. Un secondo record TXT che inizia con v=spf1 li rende entrambi non validi.
- Resta entro le 10 ricerche DNS. Contano come ricerche include:, a e mx, e un include può innescarne altre al suo interno; ip4: e ip6: sono gratuiti.
Autenticazione pubblicata? Il passo successivo è inviare a una lista pulita e verificata.
Verifica una listaSPF per Salesforce Marketing Cloud: domande frequenti
Letture correlate
Dopo la pubblicazione, controlla con il check-up del dominio che tutti i record vengano risolti correttamente, poi scopri con l'analizzatore di report DMARC chi invia a tuo nome. Sfoglia tutte le fonti di invio nel generatore. L'autenticazione, però, è solo metà della deliverability: un IP o un dominio di invio in blacklist ti manda comunque nello spam, per quanto pulito sia il tuo SPF, quindi conviene tenere d'occhio le blacklist con il monitoraggio blacklist.
Dominio autenticato: ora mantieni pulita la lista
Superare SPF, DKIM e DMARC ti porta nella posta in arrivo; una lista pulita ti ci fa restare. Verifica la tua: inizia gratis con 100 crediti, senza carta di credito.