Brug Atlassian Clouds understøttede brugerdefinerede e-mail-workflow, når Jira eller Confluence skal sende meddelelser fra din organisations domæne. Denne vejledning dækker denne organisations-administrationsmodel. Det er ikke en universel postopskrift for Statuspage, Trello, selv-hostet datacenter eller en ekstern SMTP server; disse produkter og ruter kræver deres egne førstepartsinstruktioner.
Bekræft meddelelsesmodellen
Identificer organisationen, applikationen, tilsigtet brugerdefineret fra-adresse og administrator, der er ansvarlig for det. Skeln modtagelse af mail fra Atlassian-ejede domæner fra at give Atlassian tilladelse til at sende med din brugerdefinerede identitet. Du behøver ikke at redigere dit domæne SPF blot for at modtage en meddelelse sendt fra en andens domæne.
Atlassians Jira Cloud-guide instruerer organisationsadministratorer til at tilføje tilpassede e-mailadresser gennem Atlassian Administration. Dets organisationsopsætningsworkflow adskiller tilføjelse af e-mail-domænet, publicering af de genererede DNS poster, tilføjelse af adresser og tilgængeliggørelse for den relevante applikation. Domænebekræftelse, der bruges til at administrere konti, er ikke en erstatning for at fuldføre denne e-mail-godkendelsesworkflow.
Udgiv det komplette genererede rekordsæt
Tilføj e-mail-domænet gennem den aktuelle brugerdefinerede e-mail-opsætning og kopier de viste DNS ejere, registreringstyper og mål til en ændringsanmodning. Atlassian dokumenterer to DKIM CNAME records og et afvisnings CNAME i denne godkendelsesmodel. De to DKIM -poster understøtter nøglerotation. Bounce-domænet CNAME alias understøtter den udbyderstyrede kuvertidentitet og SPF adfærd.
Udgiv præcis de poster, som organisationens opsætningsskærm genererer. Udskift ikke bounce CNAME med en generisk SPF TXT kopieret fra et ikke-relateret Atlassian-produkt, og opfind ikke vælger mål fra applikationens URL. Tilføj ikke et CNAME i roden af et domæne, der skal bevare dets normale MX registreringer og andre poster. De genererede ejernavne identificerer de tilsigtede aliasnavne.
Tjek, om DNS konsollen forventer et fuldt ejernavn eller en relativ etiket. Der mangler et duplikeret domæne-suffiks reservevælger eller forkert mål kan efterlade verifikationen ufuldstændig. Spørg den autoritative DNS tjeneste, og sammenlign hvert svar med opsætningsskærmen, før du trykker på bekræftelse igen.
Fuldfør ansøgningsoverdragelsen
Når posterne matcher, skal du vente på, at Atlassians domæneklargøring er færdig, og bekræfte, at domænestatus er Aktiv. Matchende DNS er ikke det samme som fuldført klargøring; Atlassian dokumenterer, at dette kan tage op til 72 timer. Først derefter udfyldes adressen og ansøgningsoverdragelsen. Tilføj de nødvendige e-mailadresser og gør dem tilgængelige for den tilsigtede app i henhold til det aktuelle administrationsflow. Vælg den godkendte adresse for den relevante meddelelseskonfiguration. Behold ejerskabsbekræftelsestrinnet, adressetilgængelighed og appvalg som separate tjeklistepunkter: DNS kan være korrekt, mens en applikation stadig bruger sin tidligere standardafsender.
Udløs en kontrolleret meddelelse fra den nøjagtige Jira- eller Confluence-arbejdsgang. Fang dens rå eksterne overskrifter. Registrer den faktiske From-adresse, SPF smtp.mailfrom domæne, DKIM d= og s= værdier og betroet modtager DMARC resultat. En vellykket DNS kontrol er nødvendig opsætningsbevis, ikke bevis for hver applikationsmeddelelses identitet.
Evaluer justering uden at gætte afvisningsformatet
Atlassian administrerer målsiden af de leverede aliaser; de genererede værdier er kontospecifikke beviser. Undlad at hårdkode et bounce-værtsnavnmønster i en operationel runbook. Sammenlign domænet, der faktisk ses i den modtagne besked med Fra-domænet under det offentliggjorte justering tilstande.
Syntetisk eksempel: Fra notifications@example.com har en bestået DKIM signatur med d=example.com og en ikke-relateret bestået SPF identitet. Den nøjagtige DKIM sti kan opfylde DMARC . Hvis den tilsigtede brugerdefinerede signatur mangler, er en gyldig signatur for et Atlassian-ejet domæne ikke automatisk på linje med example.com . Bevar alle signaturer og den fulde rute, før du beslutter dig for, at DNS er skyld i.
Din organisation forbliver ansvarlig for DMARC -politikken, der beskytter dets synlige Fra-domæne. Inventar andre legitime afsendere og koordiner rapportering og håndhævelse. Opret ikke dublet DMARC optegnelser eller erstatte en eksisterende politik som et tilfældigt trin i tilføjelsen af en applikation.
Bevar delegation gennem ændringer og pensionering
Gentest efter flytning af DNS hosting, ændring af brugerdefinerede underretningsadresser, overførsel af apps, roterende nøgler eller modtagelse af udbyderinstruktioner til at ændre registreringer. Hold begge DKIM delegationer intakte under ordinær drift. Tildel domæneejeren og appejeren eksplicit ansvar for bekræftelse og hændelsesrespons.
Når du trækker afsendelse af tilpasset domæne tilbage, skal du først ændre eller deaktivere den afhængige app-konfiguration, kontrollere, at ingen resterende meddelelser er afhængige af den, og derefter fjerne forældede godkendelser gennem en godkendt DNS ændring. Bevar de gamle værdier og en tilbagerulningsplan for overgangen. Denne vejledning rapporterer førsteparts dokumentariske resultater og illustrative tests, ikke live Atlassian-kontoudførelse.
Optag de tre afleveringsporte
Brug et separat bevisfelt for hver gate: genererede poster matcher autoritativ DNS ; domænestatus er Aktiv efter klargøring; den tilsigtede app kan vælge den godkendte adresse. Behold derefter det eksterne meddelelsesresultat. Hvis DNS matcher, men status ikke er aktiv, skal du undersøge klargøring i stedet for at gætte en ny rekord. Hvis Aktiv, men den gamle Fra-adresse forbliver, skal du kontrollere adressetilgængelighed og appvalg. Disse er foreslåede diagnostiske grene, ikke en udført kontotest.