Separare la migrazione delle cassette postali dall'autenticazione
Proton Mail , precedentemente comunemente chiamato ProtonMail, supporta indirizzi di dominio personalizzati su piani a pagamento. Suo guida al dominio personalizzato separa la verifica del dominio, la creazione dell'indirizzo, le modifiche MX e l'autenticazione. Pianificarli come elementi di accettazione distinti. La ricezione di un messaggio nella nuova casella di posta non dimostra che la posta in uscita abbia la firma prevista e a DKIM il controllo non dimostra che ogni indirizzo commerciale esista dopo una migrazione.
Inizia con un inventario degli indirizzi: singoli utenti, alias, destinazioni aziendali condivise, mittenti automatizzati e indirizzi di risposta. Identifica qualsiasi servizio che invia utilizzando lo stesso dominio senza passare attraverso Proton. Assegnare una persona al cutover della casella di posta e un'altra alla revisione DNS ove possibile. Registra i record MX e di autenticazione esistenti, la finestra di modifica approvata e il decisore che può interrompere il cutover.
Proton consiglia espressamente di creare indirizzi corrispondenti prima di spostarsi Record MX. Ciò è importante perché i messaggi relativi agli indirizzi mancanti non continueranno a raggiungere il servizio precedente una volta modificato il routing in entrata. Usa il sequenza migratoria per l'account e verificare le destinazioni critiche con messaggi controllati prima di dichiarare completa la parte ricevente.
Registra il dominio esatto e i valori emessi
Apri il dominio desiderato nelle impostazioni del dominio di Proton e conserva le istruzioni di autenticazione visualizzate per esso. Distinguere il record di verifica della proprietà del dominio da SPF, DKIM e DMARC. Rispondono a domande diverse e dovrebbero avere campi di prova separati. Non sostituire mai i record pubblicati di un'altra organizzazione con i valori presenti nell'account.
L'amministratore DNS deve registrare il nome completo del proprietario, il tipo di record e il valore previsto per ciascuna voce. Confrontali con la gestione dei suffissi dell'editor DNS , quindi controlla le risposte pubblicate. Un'etichetta può essere visivamente corretta in un pannello di controllo ma apparire con il nome completo errato. Mantieniti estraneo Record TXT e registrare qualsiasi utilizzo esistente dei proprietari DKIM proposti prima di apportare modifiche.
Se il dominio è già utilizzato da un CRM, un sito web o un sistema di fatturazione, elenca ora i mittenti. Lo spostamento della posta del personale su Proton non autentica la consegna diretta di un'applicazione separata. Il percorso approvato dell'applicazione deve avere una propria autenticazione valida oppure deve essere implementato e testato un percorso di invio progettato esplicitamente. Tratta i mittenti incerti come lacune nell'inventario, non come motivi per indebolire immediatamente la politica del dominio.
Preservare una politica SPF coerente
Quello del protone documentazione anti-spoofing identifica include:_spf.protonmail.ch come la sua autorizzazione SPF e spiega come incorporarlo in una politica esistente. Utilizza il record consigliato dell'account e l'inventario completo dei mittenti del dominio per preparare il valore finale. Non pubblicare una seconda policy per lo stesso proprietario né eliminare l'autorizzazione per un altro percorso legittimo durante una migrazione.
Valutare la politica completa rispetto a Regole di ricerca DNS di SPF. Scegliere deliberatamente la qualificazione finale piuttosto che trattare un esempio copiato come una decisione politica a livello di organizzazione. Un risultato SPF è una prova di autenticazione; i sistemi riceventi prendono le proprie decisioni di gestione. Mantieni disponibile la policy precedente per una modifica di ripristino approvata e annota quando le versioni memorizzate nella cache potrebbero essere ancora in uso.
Conserva la configurazione completa della rotazione DKIM
Proton ne usa tre CNAME record per la rotazione DKIM automatica. Suo guida all'autenticazione del dominio indica ai clienti di mantenerli tutti e tre, di abbinare esattamente la procedura guidata e di attendere il rilevamento prima che venga avviata la firma del dominio personalizzato in uscita. Un apparentemente inattivo selettore può essere richiesto per una rotazione successiva. Non rimuoverlo perché un singolo messaggio di prova utilizza solo un selettore di firma.
Se la verifica fallisce, confronta ciascun proprietario e personaggio di destinazione per personaggio. Quello del protone Guida alla risoluzione dei problemi CNAME identifica come possibili problemi i valori errati, la gestione da parte del registrar di un periodo finale e un vecchio record TXT gestito manualmente. Investiga sul conflitto effettivo prima di eliminare qualsiasi cosa. Un record TXT su un diverso selettore può appartenere a un altro mittente legittimo e non è automaticamente obsoleto.
Laddove l'account si sta spostando dalla vecchia disposizione di chiave manuale di Proton, pianifica attentamente la transizione documentata. Proton avvisa di un'interruzione della firma quando il vecchio record TXT viene rimosso. Preparare in anticipo tutti i valori sostitutivi e un test controllato, coordinare la finestra di modifica e pubblicare tempestivamente la sostituzione richiesta. Non si tratta di un consiglio per eliminare tutti i record TXT DKIM nella zona.
Testare la posta del personale e l'invio della domanda separatamente
Invia nuovi messaggi da indirizzi rappresentativi di domini personalizzati attraverso i percorsi utilizzati dall'organizzazione. Registra il cliente o l'applicazione, l'indirizzo del mittente, l'ora e l'ID del messaggio. Su un ricevitore esterno controllato, acquisisci i risultati SPF , DKIM e DMARC attendibili, l' SMTP percorso di ritorno e i valori DKIM d= e s=. Il dominio e il selettore della firma identificano la ricerca della chiave pubblica descritta da RFC 6376.
Per un dispositivo o un'applicazione aziendale, Proton documenta una funzionalità di invio SMTP separata per piani a pagamento con indirizzi di dominio personalizzati. Suo Guida SMTP utilizza token SMTP specifici dell'indirizzo, non la normale password della casella di posta, e spiega che la posta inviata da SMTP non è crittografata end-to-end. Confermare l'idoneità della funzionalità e l'indirizzo autorizzato prima di configurare un'applicazione. La creazione di credenziali e l'accesso permanente richiedono la propria approvazione di sicurezza; nessun token dovrebbe apparire nella cartella di lavoro delle prove.
Registra un risultato separato per ciascuna domanda anche se viene superato un test webmail del personale. Un accesso riuscito a un server di invio non dimostra né il mittente visibile finale né il risultato dell'autenticazione del destinatario. Se una stampante o un CRM si guasta prima dell'invio, risolvi il problema di connessione prima di diagnosticare DKIM . Se viene inviato con successo, segui il messaggio risultante al destinatario controllato.
Imposta la politica DMARC dai percorsi osservati
Esamina la politica DMARC esistente del dominio e la destinazione dei rapporti con il suo proprietario. Conservare una politica stabilita a meno che non sia necessaria una modifica approvata separatamente. Un risultato SPF o DKIM che passa allineato può soddisfare DMARC , come definito in RFC 9989. Controlla l'effettivo allineamento modalità piuttosto che presupporre che ogni sottodominio correlato sia idoneo.
Prima di aumentare l'applicazione delle norme, tenere conto delle richieste dirette, degli accordi di inoltro e dell'uso delle mailing list su cui fa affidamento l'azienda. Un periodo di monitoraggio dovrebbe avere un proprietario e un risultato di revisione e non diventare un sostituto indefinito dell'indagine. Rapporti aggregati possono guidare la scoperta, ma non sostituiscono le intestazioni specifiche del percorso né dimostrano il posizionamento della casella di posta per ciascun destinatario.
Foglio di lavoro per l'accettazione Proton Mail
Crea una riga per ogni posta del personale o percorso di candidatura:
- Revisione inventario dominio, proprietario locatario e indirizzo: ____.
- Verifica del dominio, creazione dell'indirizzo e prova del cutover MX : ____.
- Mittenti esistenti mantenuti nella revisione SPF : ____.
- Set CNAME DKIM emesso e tutti e tre i controlli del proprietario pubblicato: ____.
- Conflitto di chiave manuale preesistente e piano di transizione approvato, se presente: ____.
- Itinerario, cliente o dispositivo e autorizzato Da indirizzo: ____.
- Riferimento per l'approvazione dell'accesso SMTP dell'applicazione, esclusi i segreti: ____.
- ID messaggio, ora UTC, Return-Path e DKIM d=/s=: ____.
- Risultati di autenticazione attendibili, controlli di allineamento e ricevute aziendali: ____.
- Titolare del recupero, eccezioni irrisolte e decisione di revisione: ____.
Diagnosi fittizia dopo una pulizia DNS
Solo esempio fittizio: Juniper Accounts rimuove due CNAME Proton perché il suo ultimo messaggio utilizza il terzo selettore. Successivamente, l'autenticazione diventa incoerente. L'amministratore di posta confronta la zona con il set completo emesso anziché aggiungere una nuova policy SPF del dominio root. I CNAME mancanti vengono ripristinati tramite il processo di modifica approvato, lo stato di Proton viene ricontrollato e nuovi messaggi stabiliscono se la firma è stata ripristinata.
Questo esempio illustra il motivo per cui le dipendenze di rotazione appartengono all'inventario. Non si tratta di un incidente Proton osservato e non è stato effettuato l'accesso a nessuna casella di posta Juniper o zona DNS .
Conservare le prove per la modifica successiva
Mantieni insieme i record emessi, i controlli DNS pubblici e le intestazioni ricevute oscurate. Verifica nuovamente dopo modifiche dell'host DNS, migrazioni di indirizzi, operazioni di transizione delle chiavi o nuovi percorsi di applicazione. L'ispezione dell'account live, la pubblicazione dei record, l'invio controllato, la revisione visiva resa, l'approvazione e la pubblicazione delle PMI umane non sono state completate da questo articolo. Tali cancelli restano pendenti anche una volta completata la procedura documentale.
Separare l'accesso all'invio dall'accesso alla posta in arrivo
Proton descrive l'invio SMTP come di solo invio; la ricezione tramite un client desktop di terze parti è un flusso di lavoro Bridge separato. Un test di invio della domanda riuscito non stabilisce la sincronizzazione della posta in arrivo. Mantenere un token approvato distinto per applicazione in modo che un dispositivo revocato non interrompa inutilmente altri client. Questa è una raccomandazione relativa alla progettazione dell'accesso; nessuna credenziale è stata creata o configurata.
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.