Omfang og udbyderspecifik konfiguration
Atlassian Statuspage adskiller et tilpasset statussidewebdomæne fra en tilpasset meddelelse Fra-adresse. En fungerende hjemmeside CNAME godkender ikke mail. E-mail-workflowet har også flere leveringsudbydere, så fuldfør alle viste udbyderregistreringer i stedet for at stoppe ved den første succesfulde DKIM opsætning.
Gå til Din side, Tilpas side og e-mail og derefter Tilpas e-mail. Indstil Send fra e-mail, konfigurer eventuelt Svar på e-mail, og gem e-mailtilpasninger. Følg det nye link, eller åbn Din side, DNS konfiguration. Indfang værdierne i sektionen Meddelelse Fra e-mail. Ejerskabs TXT bruger formatet status-page-domain-verification=<ORGANIZATION_CODE>; selve organisationskoden skal komme fra kontoen.
Den aktuelle DNS vejledning kræver SPF autorisation inklusive stspg-customer.com . Inkorporer include:stspg-customer.com i den gældende eksisterende politik, ikke et sekund SPF rekord. Dets Mailgun eksempel er illustrativt og giver ikke tilladelse til at tilføje ikke-relaterede tjenester. Udgiv DKIM posten for udbyder #1, Mailgun , og de tre CNAME poster for udbyder #2, SendGrid , ved hjælp af kontoens aktuelle værdier. Vejledningen har en separat migreringssti fra ældre DKIM nøgler til CNAME'er; ugyldiggør ikke en arbejdsregistrering, medmindre du bevidst udfører den godkendte migrering.
En vigtig grænse er eksisterende Mailgun brug: Statusside siger, at den ikke kan tilføje det samme domæne en anden gang, når en anden tjeneste allerede bruger Mailgun . Den anbefalede løsning er et dedikeret Fra-underdomæne, såsom notifications.example.com . Dette illustrative underdomæne har stadig brug for sin egen viste opsætning og passende DMARC evaluering.
Brug Genvalider alle poster efter offentliggørelse. Atlassian siger, at autentificeret og underskrevet afsendelse begynder inden for 24 timer efter validering, og at optegnelser kontrolleres hver time og skal forblive til stede. Med kun én udbyder konfigureret, kan en systemdækkende failover få beskeder til at bruge noreply@statuspage.io . Begge udbyderkonfigurationer er derfor et kontinuitetsmål, ikke redundant rod.
Den beslutning, der betyder noget
Test udbyderens beredskab og branded-sender kontinuitet; én konfigureret leveringspartner er ikke den fulde opsætning.
Bekræft de offentliggjorte poster og den rigtige afsendelsessti
Registrer ændring af ejer, afsendende produkt, domæne, godkendt vedligeholdelsesvindue og tidligere DNS svar før redigering. Få de aktuelle registreringsværdier fra den navngivne konto eller dokumenterede udbyderarbejdsgang. Adskil værdier leveret af udbyderen fra valg, din organisation kontrollerer, såsom DMARC -politik og rapporteringsmodtagere. Eksisterende postkasse MX , ikke-relateret verifikation TXT registreringer og aktive DKIM selektorer er ikke oprydningskandidater, blot fordi en ny tjeneste tilføjes.
Spørg de autoritative navneservere for hver eksakt ejer og posttype efter offentliggørelse. Registrer forespørgselstiden, svarserveren og komplet svar. Sammenlign TXT strenge som én logisk værdi, hvor DNS svaret opdeler dem i tegnstrenge. Tjek CNAME -mål samt startaliaset. Sammenlign derefter et rekursivt resolver-svar for at identificere caching-forskelle. En vellykket udbydervalidering er et nyttigt bevis på konfiguration, men det fastslår ikke, hvad en faktisk modtager har modtaget.
Send kun en autoriseret test til en kontrolleret modtager ved hjælp af den påtænkte produktrute. Behold den rå besked og det betroede modtagesystem Authentication-Results. Optag det synlige Fra domæne, SMTP MAIL FRA eller observeret Return-Path domæne, hver DKIM d= og s= værdi, SPF og DKIM resultater og modtagerens DMARC resultat. Et bestået SPF eller DKIM tjek understøtter kun DMARC , når dets autentificerede domæne stemmer overens med det synlige Fra-domæne under den gældende politik. Reply-To og et mærket visningsnavn er ikke justering identiteter. RFC 7208 , RFC 6376 og RFC 9989 give protokolgrundlaget for disse sondringer.
Acceptregneark, genoprettelses- og bevisgrænser
Dette er et originalt godkendelsesark, ikke en rapport om live test. Marker hver gate afventende, indtil der findes beviser: kontoomfang bekræftet; tidligere optaget DNS ; nøjagtig ny ejer/type/værdi offentliggjort; udbyder verifikation fuldført; planlagt rute udøvet; modtagne identiteter registreret; justeret godkendelse bekræftet; andre afsendere upåvirket. Tildel en person og bevisfil til hver port. En rød låge blokerer udrulning, selv når udbyderens dashboard er grønt.
Hvis en test mislykkes, skal du først skelne mellem manglende publikationer, forældede cachelagrede data, inaktiv udbyderkonfiguration, forkert udgående rute og ikke-justeret godkendelse. Ret den mindste påviste defekt og test igen. Undlad at svække DMARC eller slette andre afsenderes poster blot for at få en testbestået. Hvis en ændring skader eksisterende e-mail, skal du bruge den godkendte gendannelsesplan og den registrerede konfiguration før ændring, og koordinere enhver afsenderændring på udbydersiden samt DNS . Behold gamle nøgler, mens meddelelser i kø eller et godkendt overlap stadig kræver dem.
Ingen kundelejer, autoritativ før/efter ændring eller reel modtaget besked var tilgængelig for dette manuskript. De bevarede kilder understøtter den dokumentariske arbejdsgang; de opfylder ikke den bestilte live-evidence gate. Uafhængig checker-gennemgang og menneskelig SMV-godkendelse afventer stadig. Beskriv ikke denne vejledning som feltvalideret eller udgiv den som at have passeret disse porte.
Brug en kontinuitetsbog fra udbyder for udbyder
Skriftlig sag SP-01 antager brugerdefineret Fra status@notifications.example.com , Mailgun konfigurationen er fuldført, og SendGrid postsættet mangler. En forudsat Mailgun-leveret prøve har betroet DKIM pass d=notifications.example.com, s=demo1; SPF er ukendt. Denne prøve leverer nøjagtig DKIM tilpasning, men etablerer ikke brandet kontinuitet gennem SendGrid . Hændelseskommunikationsejeren skal løse den manglende udbyderopsætning eller eksplicit acceptere den dokumenterede standardafsender-tilbagefaldsrisiko, før der kræves kontinuitet. Fremkald ikke afbrydelse eller underret rigtige abonnenter om at teste denne undervisningssag. Fuldfør kontovalidering og brug en autoriseret kontrolleret test, hvor understøttet; en uobserveret failover forbliver uobserveret. Ingen hændelse eller failover blev udført.
Bevar håndhævelsesgrænsen
RFC 9989 Afsnit 7.4 kræver gyldig DKIM , ikke SPF alene, til domæneudgivelse p=reject, og advarer om interoperabilitet mellem indirekte mail og mailinglister. En enkelt vellykket test med direkte beskeder er ikke et bevis på, at enhver legitim rute er klar til en stærkere politik. Behold eksisterende godkendt beskyttelse, mens du diagnosticerer det faktiske hul; enhver politikændring kræver sin egen beslutning.