" Salesforce invia la nostra email" non è un riassunto di configurazione sufficiente. I messaggi CRM, l'invio classico di Account Engagement, Marketing Cloud Engagement e le esperienze di campagna più recenti hanno flussi di lavoro DNS e di amministrazione diversi. Inizia con il prodotto e la funzionalità che producono messaggi, quindi seleziona la procedura di autenticazione supportata.
Crea un inventario prodotto-messaggio
Per ogni email aziendale, registra il prodotto, l'edizione o l'esperienza, l'organizzazione o unità aziendale, funzione di avvio, visibile dal dominio e da qualsiasi inoltro di posta elettronica configurato. Ottenere un campione esterno redatto e l'evento dell'applicazione che lo ha prodotto. Una notifica del flusso di lavoro CRM e un percorso di marketing possono condividere un marchio ma utilizzare sistemi di invio non correlati.
Rendi l'inventario sufficientemente specifico da assegnare un amministratore. “Marketing Cloud” senza il suo prodotto e la sua esperienza è troppo ampio. Controlla se un utente di Account Engagement sta utilizzando l'interfaccia di invio consolidata o la più recente esperienza di campagna Marketing Cloud. L'attuale documentazione di Salesforce distingue esplicitamente questi casi.
Selezionare il ramo di configurazione corretto
Per l'invio Salesforce CRM, il comando Crea a DKIM La procedura chiave utilizza l'installazione, le chiavi DKIM , una chiave primaria selettore e un selettore alternativo. Genera la chiave per l'esatto dominio di invio, pubblica entrambi quelli generati CNAME record e attivarli dopo che DNS è pronto. Le linee guida attuali richiedono chiavi separate per i sottodomini di proprietà anziché fare affidamento sulla corrispondenza con caratteri jolly. Non riutilizzare i valori generati da un'altra organizzazione.
Per l'invio classico di Account Engagement, la guida DKIM utilizza Gestione domini, Domini di invio e-mail e Voci DNS previste. Copia la DomainKey generata da quel dominio nel file specificato registrazione TXT. Questo non è il flusso di lavoro CRM a due CNAME. Risolvi gli errori di verifica nello stato di gestione del dominio del prodotto, quindi esamina il messaggio effettivamente recapitato.
Per Marketing Cloud Engagement, determinare se l'account utilizza a Pacchetto di autenticazione del mittente o Dominio Privato e chi ne ospita i DNS . La documentazione del dominio privato distingue l'autenticazione dal branding di link e immagini e afferma che un dominio privato non include un IP dedicato. Segui la configurazione del dominio dell'account configurato anziché considerare sufficiente una chiave DKIM CRM non correlata.
Per le edizioni Marketing Cloud Next Growth/Advanced e la nuova esperienza di campagna Account Engagement, la guida attuale di Salesforce descrive l'attivazione Dominio autenticatos sulla messaggistica unificata. SPF è gestito tramite il CNAME di rimbalzo e i CNAME in uscita richiesti supportano DKIM . Esamina la configurazione generata per quell'esperienza; non aggiungere un SPF generico Salesforce come sostituto. È consigliato Registro DMARC necessita ancora della revisione del proprietario del dominio. Questo ramo non copre l'app Marketing in Salesforce Starter, Salesforce Pro Suite o Salesforce Foundations: la citata guida Next afferma che questi invii utilizzano un dominio salesforce.com con l'autenticazione gestita automaticamente e nessuna configurazione DNS del cliente. Conferma l'esperienza reale prima di scegliere uno dei due rami.
Mantieni coerenti le domande sul protocollo condiviso
Indipendentemente dal prodotto, registra il dominio della busta utilizzato per SPF , i valori DKIM d= e s= e il dominio Da visibile. Distinguere la schermata di verifica del dominio riuscita di un prodotto dal risultato dell'autenticazione presso il destinatario finale. Se un inoltro aziendale modifica il messaggio o le sue identità, includi tale inoltro nel test.
Mantieni un'unica policy SPF applicabile ovunque gestisci direttamente SPF . Non incollare diversi prodotti specifici Registri SPF presso lo stesso proprietario. Coordinata DMARC nel dominio Da in tutti i prodotti legittimi prima di aumentare l'applicazione. Il test positivo di un prodotto non può stabilire la disponibilità per ogni mittente che utilizza il marchio.
Utilizzare un foglio di lavoro di selezione originale
Questo è un foglio di lavoro proposto, non un inventario della distribuzione del cliente.
- Evento aziendale: notifica del flusso di lavoro CRM; Ramo di configurazione: Chiavi DKIM CRM e impostazioni effettive dei relè; Prove necessarie prima dell'approvazione: chiave attiva, sia CNAME che intestazioni esterne.
- Evento aziendale: campagna di coinvolgimento degli account consolidati; Ramo di configurazione: Gestione Domini DKIM TXT ; Prove necessarie prima dell'approvazione: voce DNS prevista, stato verificato e campione.
- Evento aziendale: percorso Marketing Cloud Engagement; Ramo di configurazione: Account SAP o Dominio Privato; Prove necessarie prima dell'approvazione: configurazione del dominio specifico del prodotto e esempio di percorso.
- Evento aziendale: nuova esperienza di campagna; Ramo di configurazione: Domini autenticati di messaggistica unificata; Prove necessarie prima dell'approvazione: record di dominio attivato e campione specifico dell'esperienza.
Se il prodotto non può essere identificato, interrompi la modifica DNS , non l'indagine. Chiedi al proprietario dell'applicazione la schermata di origine, la definizione di invio o l'identificatore dell'evento. Non dedurre mai il ramo solo da un'etichetta di marketing.
Riprova quando l'esperienza cambia
Ripetere la selezione e la revisione dell'intestazione dopo la migrazione del prodotto, una nuova business unit, la modifica del dominio autenticato, la modifica dell'inoltro, la rotazione del selettore o l'avviso di migrazione DNS del provider. Mantieni datati i valori generati e le istruzioni di origine. Questa guida riflette la revisione della documentazione e la pianificazione dell'accettazione sintetica; i messaggi reali e le impostazioni del tenant rimangono la prova dell'esecuzione dell'organizzazione.
Richiedere una decisione della filiale prima del ticket DNS
Allega al ticket proposto il nome del prodotto e dell'esperienza, l'unità aziendale o l'organizzazione, la funzionalità selezionata, l'esportazione generata nel registro pubblico e l'amministratore responsabile. Non includere le credenziali. Registra perché gli altri rami non si applicano. Una migrazione a un'altra esperienza riapre questa decisione anche quando il dominio Da rimane lo stesso.