Conferma che TransIP è autorevole
Questa è una guida alla pubblicazione DNS , non una guida all'onboarding del servizio di posta TransIP. Un dominio può essere registrato su TransIP mentre è autorevole server dei nomi sono altrove. Controlla la delega pubblica del dominio e identifica la zona autorevole prima della modifica. Non cambiare server dei nomi solo per rendere accessibile un modulo DNS . Ottieni i nomi, i tipi e i valori esatti dei record del mittente, insieme all'esportazione della zona esistente e all'ambito della modifica approvata.
Immettere nomi e valori correttamente
Seleziona il dominio nel pannello di controllo e apri le impostazioni DNS . La modifica personalizzata richiede che le impostazioni TransIP automatiche siano disattivate. La riattivazione di tali impostazioni può sovrascrivere record personalizzati e server dei nomi. Il campo Nome utilizza @ per l'apice della zona e i relativi nomi per i sottodomini. Un esterno CNAME il target necessita del nome completo e del punto finale. Queste regole di interfaccia sono documentate nel codice sorgente del pannello di controllo TransIP riportato di seguito.
Per un TXT DKIM chiave, l'origine DKIM indica agli utenti di omettere le virgolette circostanti e le barre rovesciate non necessarie. Utilizza la chiave pubblica del mittente, mai un campione generato. UN selettore su un sottodominio di invio necessita di quel sottodominio nel relativo nome del proprietario. Utilizza CNAME solo quando il mittente ha effettivamente emesso una delega CNAME . La pubblicazione di una chiave non fa sì che un servizio di invio inizi a firmare.
Foglio di lavoro originale per la mappatura dei record
Quello che segue è un esercizio di mappatura fittizio per la zona example.org , non una configurazione di produzione. Una mappa completa del proprietario DKIM review._domainkey.news.example.org da rivedere. _domainkey.news nel campo Nome. UN DMARC il proprietario _dmarc.news.example.org si associa a _dmarc.news. IL SPF il proprietario news.example.org si associa a news. Contrassegnare il nome completo previsto sul ticket di modifica in modo che un revisore possa rilevare un suffisso example.org.example.org accidentale.
Mantieni SPF e DMARC come policy TXT con i nomi dei proprietari corretti. Non inserire una riga completa del file di zona, inclusi classe e tipo, nel campo Valore. Molteplici Record TXT possono coesistere per scopi non correlati, ma due policy SPF con un nome valutato non sono valide. I valori DKIM lunghi richiedono una gestione attenta: le pagine TransIP recuperate non stabiliscono una procedura di suddivisione universale delle stringhe lunghe. Se il comitato rifiuta l'intero valore del provider, interrompere e ottenere la guida TransIP corrente anziché troncarla.
Verificare la pubblicazione prima di testare la posta
Interroga ciascun server autorevole per i nomi completi SPF , DMARC e dei selettori. Confronta i valori completi, incluse le stringhe TXT concatenate dove restituite. Per una chiave delegata, verifica la destinazione CNAME e la risposta TXT finale. Ripetere attraverso un risolutore ricorsivo e conservare le osservazioni TTL. Una visualizzazione corretta del pannello di controllo con una risposta pubblica assente può indicare un'autorizzazione errata o dati non salvati, non semplicemente una propagazione lenta.
Solo allora attiva un messaggio controllato tramite il servizio di invio. Il rollback lato DNS dovrebbe ripristinare i record modificati, non riattivare le impostazioni automatiche o ripristinare un'intera vecchia zona senza confrontare modifiche non correlate.
Dimostrare l'identità al destinatario
Utilizza una casella di posta esterna controllata e invia attraverso il flusso di lavoro di produzione, con contenuti innocui e senza dati del cliente. Salva il messaggio non elaborato, il timestamp e quello del sistema ricevente Authentication-Results. Ignora le asserzioni di autenticazione inserite da un mittente non attendibile. Registra il dominio Da visibile, Return-Path o identità della busta autenticata e ogni coppia DKIM d= e s=. Un nome visualizzato o un indirizzo di risposta non è l'identità DMARC .
Il passaggio SPF autorizza il server di connessione per l'identità della busta valutata. Il pass DKIM convalida una firma per il dominio di firma. DMARC necessita di un metodo di passaggio il cui dominio sia allineato con il visibile From: strict allineamento richiede lo stesso dominio; un allineamento rilassato consente la relazione organizzazione-dominio applicabile. Una firma di proprietà del provider può passare senza autenticare il mittente visibile. Un passaggio allineato Firma DKIM può soddisfare DMARC anche quando un'altra firma fallisce. Queste regole di protocollo provengono da RFC 7208 , RFC 6376 e RFC 9989, elencati di seguito.
Controlla DNS autorevole prima di diagnosticare le cache. Chiedi a un server autorevole il nome e il tipo esatti, quindi confronta un risolutore ricorsivo dopo la sua durata nella cache. Per DKIM , segui qualsiasi CNAME nella relativa risposta TXT a chiave pubblica. Non pubblicare mai una chiave privata. Mantieni una policy SPF per ciascun nome valutato e controlla il limite di dieci termini che causano la ricerca DNS tra le inclusioni nidificate. Non sostituire una policy SPF condivisa con l'esempio di un provider.
Recupero e accettazione
Sospendere il flusso di lavoro interessato se i test mostrano una nuova regressione. Confronta il record modificato con la versione salvata e annulla solo quella modifica dopo aver controllato gli altri mittenti. Ricontrolla DNS e invialo nuovamente dopo il ripristino; il ripristino di un valore non scarica immediatamente tutti i risolutori. Mantieni disponibili i vecchi record di verifica DKIM mentre i messaggi firmati in precedenza potrebbero essere ancora in transito, a meno che un incidente di sicurezza non richieda la revoca.
Accettare la modifica solo quando DNS , stato dell'applicazione e un messaggio effettivamente ricevuto concordano. Registra il proprietario del flusso, il timestamp della prova e il successivo trigger di revisione. Il solo posizionamento della casella di posta non costituisce prova dell'autenticazione e l'autenticazione riuscita non garantisce il posizionamento della casella di posta. Non rafforzare la politica DMARC di un dominio condiviso sulla base del test di un provider. Inventariare prima le altre fonti legittime.
Diagnosticare una voce dall'aspetto corretto nella zona sbagliata
Il caso scritto TI-01 presuppone che il dominio sia registrato su TransIP, ma la sua delega pubblica punta a un altro operatore DNS . Una voce del pannello TransIP salvata per la revisione. _domainkey.news non stabilisce la pubblicazione su review._domainkey.news.example.org . Il titolare del dominio deve confermare l'operatore autorevole e predisporre lì il record approvato; cambiare i nameserver o abilitare le impostazioni automatiche non è la scorciatoia correttiva. Le risposte pubbliche, d=/s= emessi e i risultati del ricevitore rimangono sconosciuti fino a quando non vengono raccolti separatamente. Questo scenario è previsto, non una vera e propria ricerca DNS o un'azione del pannello.
Preservare il confine dell'applicazione
La sezione 7.4 RFC 9989 richiede DKIM valido, non il solo SPF , per i domini che pubblicano p=reject, e avverte sull'interoperabilità della posta indiretta e delle mailing list. Un singolo test di messaggio diretto riuscito non è la prova che ogni percorso legittimo sia pronto per una politica più forte. Mantenere la protezione approvata esistente diagnosticando al tempo stesso il divario effettivo; qualsiasi cambiamento di politica necessita di una propria decisione.