Confermare la modalità di invio predittivo
Questa guida copre il flusso di lavoro del server della campagna di risposta predittiva descritto nel relativo centro assistenza pubblico. Non presuppone che ogni prodotto Predictive, accordo SMTP aziendale o percorso di posta elettronica Salesforce si comporti allo stesso modo. Registra l'account, il tipo di campagna, il dominio Da visibile previsto e il sistema che invia effettivamente il messaggio. Non sostituire la configurazione di autenticazione di Salesforce con un percorso di campagna di terze parti senza la prova che si tratta del percorso in uso.
La pagina di consegna del provider distingue l'invio del dominio del provider predefinito dall'uso del dominio del cliente. Indica ai clienti di contattare l'assistenza dopo la pubblicazione SPF in modo che i server di invio possano essere allineati. La pubblicazione DNS è quindi solo una parte del cambiamento documentato; rimane necessario un passaggio lato server confermato dal supporto. Configurazione della consegna della risposta predittiva
Prima di pianificare le modifiche, acquisisci un test innocuo della campagna e le risposte DNS autorevoli esistenti. Identificare le persone che controllano DNS , il dominio di invio aziendale, il indirizzo di rimbalzoe il conto predittivo. Richiedi istruzioni specifiche per l'account corrente laddove il materiale pubblico lasci una domanda aperta. Questo manoscritto non rappresenta una risposta di supporto o una prova che un particolare account sia stato aggiornato.
Integra SPF senza sostituire mittenti non correlati
La guida SPF del provider identifica include:spf.predictiveresponse.net come meccanismo di autorizzazione. Le sue istruzioni distinguono l'aggiunta dell'autorizzazione a una policy esistente dalla creazione di una policy dove non esiste e includono una fase di verifica del supporto. Utilizzalo come punto di partenza per l'account e il dominio esatti, non come prova che la busta corrente utilizza già l'identità prevista. Impostazione SPF della risposta predittiva
Conserva una policy SPF presso il nome del proprietario pertinente. Non crearne un secondo Registro SPF oppure incollare un secondo meccanismo di terminale in una policy esistente. Inserire le autorizzazioni necessarie nell'ordine di valutazione previsto e trattenere altri mittenti legittimi. La scelta del fallimento o softfail della policy esistente è una decisione di sicurezza separata; l'esempio di un fornitore non è l'approvazione per indebolirlo. Rivedi i limiti di ricerca dopo le modifiche. SPF RFC 7208 sezioni 3.2 e 4.6.4
Un validatore che mostra SPF sintatticamente valido non dimostra che una campagna valuta quel dominio, che la fase di supporto è completa o che DMARC allinea. Registra il proprietario interrogato, la politica di restituzione, l'ora di ritiro e il risultato del test. Quindi confrontali con il dominio effettivo della busta di un messaggio ricevuto. La catena completa delle prove deve collegare autorizzazione, percorso di invio e identità visibile.
Preserva la dipendenza dall'elaborazione del rimbalzo
Predittivo percorso di ritorno le istruzioni utilizzano un test della campagna per identificare la destinazione di rimbalzo del fornitore specifico dell'account. Il cliente prepara quindi un indirizzo di ritorno sul proprio sistema di posta, gli assegna un alias alla destinazione identificata e chiede supporto per aggiornare l'applicazione di invio. La pagina collega questa disposizione all'elaborazione del rimbalzo in Salesforce . Non indovinare mai il nome breve specifico dell'account né utilizzare la destinazione di un altro cliente. Impostazione predittiva del percorso di ritorno
Considera questo come una modifica operativa del routing, non solo una modifica estetica del mittente. Documentare chi possiede l'alias, quale supporto di destinazione è confermato e cosa succede se l'alias non può essere consegnato. Coordinarsi con il proprietario della campagna in modo che i nuovi tentativi e la gestione dell'eliminazione siano compresi. Mantieni disponibile la vecchia soluzione di lavoro per un rollback approvato fino a quando non saranno state dimostrate sia l'autenticazione che l'elaborazione del rimbalzo.
Utilizza solo un test di rimbalzo controllato e autorizzato o una diagnostica supportata dal fornitore per valutare tale flusso di lavoro. Non inviare campagne reali a destinatari inventati né interrompere i dati di soppressione semplicemente per ottenere prove. Il record di accettazione dovrebbe mostrare l'aggiornamento dello stato previsto o il risultato diagnostico senza esporre pubblicamente gli indirizzi dei destinatari. Una consegna corretta del destinatario e un percorso di feedback di rimbalzo funzionante sono test separati.
Non equiparare DKIM del fornitore al DKIM del cliente allineato
La pagina di consegna rivista dice DKIM viene gestito sui server del provider. Non stabilisce un'attuale procedura di generazione del selettore del dominio del cliente né dimostra quale dominio d= utilizza una campagna specifica. Questa guida quindi non inventa DKIM CNAME target, un cambio di dominio personalizzato self-service o un'affermazione non supportata secondo cui DKIM del dominio del cliente non è disponibile. Tali domande rimangono per prove specifiche per l'account. Dichiarazione DKIM predittiva
Un messaggio ricevuto può contenere una firma del dominio del provider valida senza che tale firma sia allineata al dominio Da visibile del cliente. Verifica DKIM e DMARC allineamento rispondere a domande diverse. Registra il dominio di ogni firma e selettore, i risultati del destinatario e se eventuali firme passate sono allineate. Anche un percorso SPF che passa allineato può soddisfare DMARC , ma solo se il dominio della busta valutata e la relazione From soddisfano la modalità applicabile. DKIM RFC 6376 DMARC RFC 9989
Non modificare la politica DMARC a livello di dominio semplicemente perché un fornitore afferma di gestire DKIM . Chiedi quale identità esatta è autenticata e testala. Se non viene stabilito alcun percorso allineato supportato, mantieni in sospeso l'implementazione del dominio personalizzato e decidi con il proprietario dell'azienda se è appropriato un percorso provider-dominio autorizzato o un'altra configurazione supportata.
Foglio di lavoro per l'accettazione della campagna predittiva
Completa un record per ciascun account distinto e percorso di invio.
- Contesto della campagna: account, tipo di campagna, proprietario dell'attività, servizio del mittente effettivo e dominio del mittente previsto.
- Modifica SPF : politica attuale, autorizzazione proposta, dominio busta che la richiede, risposte DNS autorevoli, revisione della ricerca e modifica del proprietario.
- Checkpoint del supporto: riferimento del ticket, modifica esatta lato server richiesta, account e dominio confermati dal supporto, tempo di completamento e domande irrisolte.
- Percorso di restituzione: indirizzo del percorso di restituzione del cliente, destinazione specifica dell'account, proprietario dell'alias, diagnostica controllata e prove di elaborazione previste Salesforce .
- Identità ricevuta: timestamp del test, destinatario attendibile, visibile da, Return-Path , tutti i domini e i selettori DKIM , risultato SPF , risultati DKIM e percorso di passaggio allineato.
- Decisione sul rilascio: restanti funzionalità non supportate, piano di rollback, approvazione aziendale, revisione da parte della PMI umana e revisione della presentazione editoriale. Questi sono campi di accettazione vuoti, non risultati in tempo reale.
Diagnosi fittizia di una modifica DNS completata ma di una configurazione non completata
Questo scenario è immaginario. Un amministratore marketing pubblica l'autorizzazione SPF documentata e un validatore DNS segnala una policy valida. La campagna successiva mostra ancora il dominio busta del provider e non supera DMARC per il dominio Da del cliente. Un fornitore valido Firma DKIM viene visualizzato, ma neanche il relativo dominio di firma è allineato.
Il team controlla il record delle modifiche e scopre che nessuno ha completato il checkpoint di supporto. Il passaggio successivo proposto è confermare la disposizione della busta cliente supportata, convalidare l'alias di mancato recapito per quell'account e chiedere al supporto di completare la configurazione autorizzata. Solo una nuova campagna ricevuta e una diagnostica di rimbalzo controllata possono stabilire il risultato. Il controllo della sintassi originale non ha dimostrato l'allineamento o la gestione del rimbalzo Salesforce .
Cancelli di prova e pubblicazione
La documentazione pubblica di configurazione di prima parte è stata recuperata ed esaminata. Nessun account predittivo, ticket di supporto, DNS del cliente, casella di posta di mancato recapito, record Salesforce o messaggio del cliente ricevuto è stato controllato o modificato. L'applicabilità del conto corrente, l'attivazione lato server, i risultati allineati e l'elaborazione del rimbalzo rimangono parametri attivi. L'approvazione della PMI umana e la revisione della presentazione renderizzata sono in sospeso. Il titolo di configurazione completo più ampio rimane mantenuto fino alla risoluzione delle domande sul DKIM e sul percorso esatto; la bozza è inedita.
Distinguere un alias da una ricetta del percorso di ritorno DNS
La configurazione del mancato recapito documentata utilizza l'indirizzo e-mail del cliente che inoltra all'indirizzo di elaborazione specifico dell'account. Non fornisce una ricetta CNAME DNS universale. Mantieni il proprietario dell'alias e la modifica dell'applicazione confermata dal supporto nello stesso ticket e lascia irrisolta la funzionalità DKIM del dominio personalizzato finché il provider non fornisce prove applicabili.
Separare l'accettazione dei messaggi dall'implementazione delle policy
Un risultato SPF allineato che passa può soddisfare la valutazione di un messaggio, ma non giustifica da solo lo spostamento di un intero dominio per rifiutarlo. RFC 9989 La sezione 7.4 richiede DKIM valido per la pubblicazione dei domini p=reject e mette in guardia sull'interoperabilità della posta indiretta. Inventaria tutti i mittenti legittimi e i percorsi indiretti prima che il proprietario della policy approvi l'applicazione. Per questo articolo non è stata eseguita alcuna modifica DNS , operazione tenant o test dei messaggi ricevuti.