Definire innanzitutto l'identità di sensibilizzazione
Una campagna stampa può apparire corretta nell'editor ma uscire con un'identità di mittente inaspettata. Prima di modificare DNS , registrare l'organizzazione, l'indirizzo del mittente previsto, la persona responsabile della divulgazione e se il percorso è una campagna o una presentazione individuale. Includi bozze e integrazioni esistenti in questo inventario. La scelta del mittente è parte del test di accettazione, non un dettaglio da dedurre dall'aspetto della redazione.
Prezly fornisce un indirizzo prezlymail.com pronto all'uso e supporta indirizzi di domini aziendali verificati. Suo guida all'indirizzo del mittente descrive l'aggiunta dell'indirizzo, la selezione del dominio, la pubblicazione di tre o quattro emessi CNAME record ed eseguendo il controllo dello stato. Utilizza i valori visualizzati per il dominio selezionato. Gli esempi in un articolo pubblico identificano la progettazione del servizio; non sono record da copiare nella zona di un'altra organizzazione.
Mantieni la configurazione del sito web e della posta elettronica separate
Un nome host di una redazione funzionante non è una prova che l'e-mail della campagna venga autenticata. Prezly separa esplicitamente la configurazione del dominio personalizzato del sito Web dalla disponibilità del dominio del mittente nel suo file guida per sviluppatori. Assegna alla modifica DNS uno scopo specifico: autorizzare il dominio di sensibilizzazione approvato, anziché riparare ogni nome host con marchio in un'unica operazione.
Acquisisci i valori della zona corrente presso ciascun proprietario del record proposto. Registra se l'editor DNS prevede un'etichetta relativa o un nome completo. Chiedi all'amministratore di confrontare il nome del proprietario pubblico risultante con le istruzioni prima di procedere. Suffissi ripetuti, un record inserito nella zona sbagliata o un CNAME esistente presso un proprietario incompatibile possono produrre una voce dall'aspetto plausibile che non supera il controllo previsto. Conserva i normali record di posta aziendale e i valori TXT non correlati.
Per un'organizzazione con più di un marchio pubblico, prepara una riga di modifica per dominio. Non dare per scontato che la convalida del dominio dell'agenzia autorizzi tutte le identità dei clienti. Il proprietario dell'account deve approvare quali persone possono utilizzare ciascuna identità e quale casella di posta riceve le risposte. Tale decisione operativa dovrebbe essere registrata prima di selezionare una nuova impostazione predefinita.
Pubblicare la delega rilasciata senza ampliarla
Documenti Prezly a percorso di ritorno sottodominio e delega dell'autenticazione basata su CNAME. Dice anche un esistente Registro DMARC non è necessario ricrearlo e i record Cloudflare devono utilizzare la modalità solo DNS per questa configurazione. Rivedere l'esistente DMARC policy prima di aggiungere qualsiasi cosa al suo proprietario. Non sostituire una politica approvata più forte con una politica di monitoraggio di esempio semplicemente per far corrispondere una procedura guidata. IL istruzioni sull'indirizzo del mittente richiedono anche che il dominio del mittente abbia Record MX; verificare che le risposte raggiungano la casella di posta prevista anziché reindirizzare casualmente la posta in entrata.
Tratta ogni CNAME come una delega continua. Conserva insieme l'obiettivo del fornitore, lo scopo commerciale, il proprietario e le istruzioni per il ripristino. Una futura pulizia DNS dovrà distinguere un alias di sito web inutilizzato da una dipendenza di autenticazione della posta. Se un proprietario proposto è in conflitto con un altro servizio, interrompi la modifica del record e cerca istruzioni per l'account esatto. Indovinarne uno nuovo selettore o il target non è un metodo sicuro per la risoluzione dei conflitti.
SPF valuta l'identità SMTP utilizzata per il messaggio, anziché il nome visualizzato descrittivo. Laddove sia effettivamente necessaria una policy SPF , mantieni una policy presso quel proprietario e rivedi il suo costo completo di ricerca DNS. Vedere RFC 7208. Non aggiungere un'autorizzazione ampia al dominio principale solo perché un messaggio di prova menziona una piattaforma di consegna esterna.
Verifica la disponibilità dell'interfaccia e delle integrazioni
Salva il controllo dello stato del dominio con timestamp e revisione dell'istruzione utilizzata. Uno stato dell'applicazione verde dovrebbe essere seguito da un invio controllato. Conferma una parte della configurazione, mentre il messaggio ricevuto fornisce evidenza di ciò che il servizio ha effettivamente utilizzato.
Per le integrazioni, controlla l'ID mittente, l'indirizzo, lo stato di approvazione e la validità del dominio previsti. Prezly avverte che il suo campo serializzato is_verified al momento è sempre vero e non costituisce prova di approvazione o di disponibilità DNS . Suo Guida API consiglia inoltre ID mittente espliciti anziché dare per scontato che una modifica predefinita riscriva le bozze esistenti. Chiedi al proprietario dell'integrazione di confermare l'identità selezionata senza esporre le credenziali API negli screenshot o nei file di revisione.
Se viene modificata un'impostazione predefinita, testare separatamente una campagna appena creata e la relativa bozza esistente. Un oggetto salvato può mantenere la propria identità. Mantieni precisa qualsiasi procedura di ripristino: ripristina la selezione del mittente approvato o metti in pausa la comunicazione interessata, anziché eliminare tutti i record di autenticazione durante la diagnosi dell'impostazione di un'applicazione.
Leggere il messaggio ricevuto dal destinatario
Invia una campagna innocua e una presentazione innocua a caselle di posta esterne controllate. Includere una casella di posta interna come test separato quando la distribuzione interna è importante. Cattura ID messaggio, ora UTC, Da, Return-Path , DKIM firma del dominio e del selettore e risultati dell'autenticazione attendibile del destinatario finale. Oscura i dettagli del destinatario e i contenuti della campagna che non sono necessari per la revisione.
Un pass DKIM dimostra la convalida del dominio firma. DMARC richiede inoltre un'identità SPF o DKIM di passaggio allineata relativa al dominio Da visibile. RFC 6376 definisce i campi della firma e RFC 9989 definisce DMARC allineamento. Registrare la modalità di allineamento in vigore; un sottodominio correlato non è automaticamente sufficiente in caso di stretto allineamento.
Non utilizzare il risultato del posizionamento della posta in arrivo come intero verdetto di autenticazione. Un messaggio può essere autenticato e ricevere comunque filtri sfavorevoli a causa della reputazione, delle regole del destinatario, del contenuto o del comportamento di invio. Al contrario, un messaggio incluso nella lista consentita potrebbe essere visualizzato in una casella di posta senza dimostrare che il percorso di autenticazione pubblica sia corretto.
Foglio di lavoro per l'accettazione di Prezly
Completa righe separate per campagne, presentazioni e qualsiasi percorso basato sull'integrazione:
- Organizzazione, dominio, titolare dell'attività e percorso: ____.
- Da previsto, casella di posta di risposta e ID mittente esplicito, ove applicabile: ____.
- Bozza esistente o test appena creato: ____; selezione predefinita selezionata: ____.
- Proprietari CNAME emessi e riferimenti di destinazione: ____; conflitti risolti: ____.
- Riferimento alla modifica esistente conservata o approvata della policy DMARC : ____.
- Risposte DNS pubbliche, stato della domanda e tempi di verifica: ____.
- Destinatario controllato, ID messaggio e ora di invio UTC: ____.
- Return-Path , DKIM d= e s=, risultati SPF / DKIM / DMARC attendibili: ____.
- Meccanismo allineato osservato e risultato del filtro interno: ____.
- Rilascio del proprietario, azione di recupero e successivo attivazione della verifica: ____.
Un campo identità o destinatario vuoto lascia il percorso non verificato. Andare oltre il progetto pilota solo quando il proprietario delle comunicazioni e l'amministratore della posta concordano sul fatto che l'identità testata è quella destinata alla vera sensibilizzazione.
Diagnosi fittizia di un test interno fallito
Solo un esempio fittizio: Alder Press vede il suo test interno nella spazzatura e propone di sostituire la politica SPF del dominio. La copia esterna ha allineato DKIM e un passaggio DMARC . Il destinatario interno identifica il messaggio come posta originata esternamente utilizzando un indirizzo mittente interno. Quello di Prezly indicazioni sulla consegna discute questo modello di test interno. Il team esamina la politica del destinatario prima di modificare DNS pubblico.
Un'eccezione del destinatario ristretta e rivista potrebbe essere appropriata per un percorso aziendale documentato, ma non deve essere presentata come una riparazione dell'autenticazione o una garanzia di consegna esterna. Il team controlla anche la soppressione e il mancato recapito delle prove quando un indirizzo non riceve nulla. Questa diagnosi è illustrativa; non è stato osservato alcun account Alder, zona DNS o messaggio.
Mantenere visibile il confine di accettazione
Ricontrolla dopo modifiche al mittente, migrazioni DNS , integrazioni che modificano la selezione dell'identità o uno stato di verifica perso. Conserva insieme l'inventario dei record e le intestazioni redatte in modo che un altro amministratore possa riprodurre la conclusione. La documentazione pubblica supporta questa procedura, ma l'ispezione dal vivo degli inquilini, i valori emessi dall'account, i test DNS , le prove dei messaggi ricevuti, la revisione visiva resa, l'approvazione e la pubblicazione delle PMI umane rimangono in sospeso.
Rendere esplicito il passaggio di integrazione
Per una campagna basata sull'integrazione, conserva l'ID mittente numerico con il record di rilascio. L'approvazione e la validità del dominio sono campi separati; né la creazione di un oggetto riuscita né is_verified=true sono un sostituto. Un operatore di integrazione dovrebbe registrare tali stati senza esportare le credenziali, quindi ispezionare l'effettiva identità selezionata in una campagna controllata. Si tratta di un controllo di accettazione proposto, non di una chiamata API eseguita per questo articolo.
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.