Utilizza il flusso di lavoro di posta elettronica personalizzato supportato da Atlassian Cloud quando Jira o Confluence devono inviare notifiche dal dominio della tua organizzazione. Questa guida copre quel modello di organizzazione-amministrazione. Non è una ricetta di registrazione universale per Statuspage, Trello, Data Center self-hosted o un server SMTP esterno; tali prodotti e percorsi richiedono le proprie istruzioni di prima parte.
Conferma il modello di notifica
Identificare l'organizzazione, l'applicazione, l'indirizzo del mittente personalizzato previsto e l'amministratore responsabile. Distingue la ricezione della posta da domini di proprietà di Atlassian dalla concessione dell'autorizzazione ad Atlassian per l'invio con la tua identità personalizzata. Non è necessario modificare i tuoi domini SPF semplicemente per ricevere una notifica inviata dal dominio di qualcun altro.
La guida Jira Cloud di Atlassian indica agli amministratori dell'organizzazione di aggiungere indirizzi e-mail personalizzati tramite Atlassian Administration. Il flusso di lavoro di configurazione dell'organizzazione separa l'aggiunta del dominio di posta elettronica, la pubblicazione dei record DNS generati, l'aggiunta di indirizzi e la loro disponibilità all'applicazione pertinente. La verifica del dominio utilizzata per la gestione degli account non sostituisce il completamento di questo flusso di lavoro di autenticazione e-mail.
Pubblicare il set di record generato completo
Aggiungi il dominio e-mail tramite l'attuale configurazione e-mail personalizzata e copia i proprietari DNS , i tipi di record e le destinazioni visualizzati in una richiesta di modifica. Atlassian ne documenta due DKIM CNAME record e un CNAME di rimbalzo in questo modello di autenticazione. I due record DKIM supportano la rotazione delle chiavi. Il dominio di rimbalzo Alias CNAME supporta l'identità della busta gestita dal provider e il comportamento SPF .
Pubblica esattamente i record generati dalla schermata di configurazione dell'organizzazione. Non sostituire il CNAME di rimbalzo con un TXT SPF generico copiato da un prodotto Atlassian non correlato e non inventare selettore target dall'URL dell'applicazione. Non aggiungere un CNAME alla radice di un dominio che deve mantenere il suo normale MX e altri record. I nomi dei proprietari generati identificano i nomi alias previsti.
Controlla se la console DNS prevede un nome proprietario completo o un'etichetta relativa. Un suffisso di dominio duplicato, mancante selettore di riserva o un target errato possono lasciare la verifica incompleta. Interroga il servizio DNS autorevole e confronta ciascuna risposta con la schermata di configurazione prima di premere nuovamente la verifica.
Completa la consegna della domanda
Dopo che i record corrispondono, attendi il completamento del provisioning del dominio di Atlassian e conferma che lo stato del dominio è Attivo. La corrispondenza DNS non equivale al provisioning completato; Atlassian documenta che l'operazione può richiedere fino a 72 ore. Solo allora completa l'indirizzo e la consegna della domanda. Aggiungi gli indirizzi email richiesti e rendili disponibili all'app desiderata in base al flusso amministrativo corrente. Seleziona l'indirizzo approvato per la configurazione di notifica pertinente. Mantieni la fase di verifica della proprietà, la disponibilità dell'indirizzo e la selezione dell'app come elementi della lista di controllo separati: il DNS potrebbe essere corretto mentre un'applicazione utilizza ancora il mittente predefinito precedente.
Attiva una notifica controllata dall'esatto flusso di lavoro Jira o Confluence. Cattura le sue intestazioni esterne non elaborate. Registra l'indirizzo del mittente effettivo, il dominio SPF smtp.mailfrom, i valori DKIM d= e s= e il destinatario attendibile DMARC risultato. Un corretto controllo DNS è una prova necessaria della configurazione, non una prova dell'identità di ogni messaggio dell'applicazione.
Valuta l'allineamento senza indovinare il formato del rimbalzo
Atlassian gestisce il lato di destinazione degli alias forniti; i valori generati sono prove specifiche dell'account. Non codificare in modo rigido un modello di nome host di rimbalzo in un runbook operativo. Confronta il dominio effettivamente visto nel messaggio ricevuto con il dominio Da sotto pubblicato allineamento modalità.
Esempio sintetico: Da notifications@example.com ha un passaggio Firma DKIM con d=example.com e un'identità SPF di passaggio non correlata. Il percorso DKIM con corrispondenza esatta può soddisfare DMARC . Se la firma personalizzata prevista è assente, una firma valida per un dominio di proprietà di Atlassian non si allinea automaticamente con example.com . Conserva tutte le firme e il percorso completo prima di decidere che la colpa è del DNS .
La tua organizzazione rimane responsabile della politica DMARC che protegge il suo dominio Da visibile. Inventaria gli altri mittenti legittimi e coordina la segnalazione e l'applicazione delle norme. Non creare duplicati Registri DMARC o sostituire una policy esistente come passaggio incidentale nell'aggiunta di un'applicazione.
Preservare la delega attraverso modifiche e pensionamenti
Ripetere il test dopo aver spostato l'hosting DNS , modificato gli indirizzi di notifica personalizzati, trasferito app, ruotato le chiavi o ricevuto istruzioni dal provider per modificare i record. Mantieni intatte entrambe le deleghe DKIM durante il funzionamento ordinario. Assegna al proprietario del dominio e al proprietario dell'app responsabilità esplicite per la verifica e la risposta agli incidenti.
Quando ritiri l'invio di domini personalizzati, modifica o disabilita innanzitutto la configurazione dell'app dipendente, verifica che nessuna notifica rimanente si basi su di essa, quindi rimuovi le autorizzazioni obsolete tramite una modifica DNS approvata. Conservare i vecchi valori e un piano di rollback per la transizione. Questa guida riporta risultati documentari di prima parte e test illustrativi, non l'esecuzione dell'account Atlassian in tempo reale.
Registrare le tre porte di trasferimento
Utilizza un campo di prova separato per ogni porta: i record generati corrispondono DNS autorevole; lo stato del dominio è Attivo dopo il provisioning; l'app desiderata può selezionare l'indirizzo approvato. Quindi conservare il risultato della notifica esterna. Se DNS corrisponde ma lo stato non è Attivo, esamina il provisioning anziché indovinare un nuovo record. Se attivo ma rimane il vecchio indirizzo del mittente, controlla la disponibilità dell'indirizzo e la selezione dell'app. Si tratta di rami diagnostici proposti, non di un test dell'account eseguito.