Omfang: Identificer Jive-implementeringen før redigering af DNS
Jives opsætningsvejledning adskiller Cloud- og Hosted-installationer. Dens SPF instruktionerne skelner også mellem USA og EU Cloud-ruter. Behandl denne forgrening som en forudsætning: Et velkendt produktnavn er ikke nok til at vælge DNS data. Denne anmeldelse vedrører Jive-meddelelses-e-mail, ikke et andet produkt ved navn Jive eller en generel udgående posttjeneste. Jive opsætning
Administratoren bør først beskrive den forretningsbegivenhed, der producerer beskeden. En fællesskabsmeddelelse, en adgangskoderelateret besked og et programgenereret sammendrag kan have forskellige konfigurations- eller leveringsafhængigheder. Registrer den nøjagtige installation, tjenesteejer, afsendende domæne og forventede modtagere. Udled ikke implementeringsmodellen fra et e-mail-logo eller fra organisationens geografiske hovedkvarter. Få en autoritativ kontobeskrivelse, før du vælger en dokumenteret filial.
Dette er en foreslået konfigurations- og acceptmetode. Ingen Jive-konto er blevet tilgået, ingen DNS post er blevet ændret, og der er ikke sendt nogen besked til denne artikel. Den aktuelle anvendelighed for en bestemt installation forbliver ubekræftet. Dokumentationsgennemgang kan ikke levere det originale modtagne meddelelsesbevis, der kræves for implementeringsaccept.
Få det korrekte udbydergenererede materiale
Det dokumenterede DKIM workflow bruger supportgenereret offentligt materiale: TXT for Hosted og CNAME optegnelser for Cloud. Den efterspurgte vælger skal være præcis tre tegn. Angiv e-mail-domænet; Cloud-kunder kan ikke få adgang til den citerede serveradministrator-e-mail-indstilling og bør fortælle support. Jive udfører sin side af implementeringen og leverer derefter kundens DNS poster. Dens DMARC opsætningsvejledning placerer ansvaret hos kundens it-team. Jive arbejdsgang
Forbered en anmodning i stedet for at opfinde en nøgle eller vælger. Den foreslåede anmodning skal identificere den eksisterende installation og påtænkte afsenderidentitet, spørge, hvilken implementeringsgren der gælder, og anmode om fuldstændige offentlige DNS instruktioner. Inkluder aldrig en privat signeringsnøgle, kontoadgangskode eller sessionstoken i et ændringsregneark. Udbyderassistance med signering giver ikke en separat administrator tilladelse til at ændre organisationens domænedækkende politik.
Hold det medfølgende materiale knyttet til en specifik ændringsversion. Hvis et supportsvar senere ændrer posttypen, ejeren eller målet, skal du stoppe den afventende godkendelse og afstemme forskellen. Et tidligere skærmbillede kan stadig se plausibelt ud, mens det beskriver en anden region, implementering eller nøglegenerering. DNS administratoren har brug for komplette aktuelle værdier, ikke et udledt mønster, der er samlet ud fra ikke-relaterede eksempler.
Bevar den eksisterende SPF politik
SPF evaluerer den passende SMTP identitet, ikke blot den adresse, en person ser i meddelelsen. Skelne fra MAIL FRA identitet fra HELO identitet ved optagelse af observationer. Et bestået resultat for et udbyderkontrolleret kuvertdomæne etableres ikke i sig selv justering med det synlige forfatterdomæne. RFC 7208 , afsnit 2.3 og 2.4
Inden du foreslår en redigering, skal du indhente den komplette eksisterende politik og identificere dens ejer. Bevar godkendte afsendere, der ikke er relateret til denne Jive-implementering. Opret ikke en anden SPF -politik hos samme ejer for at undgå at forstå den første. Gennemgå de resulterende evalueringsstier, inklusive indlejrede afhængigheder: Protokollens grænse for opslagsperioder er ikke en optælling af synlige inkluderer strenge eller netværkspakker. Caching giver ikke tilladelse til at overskride denne grænse. RFC 7208 , afsnit 3.2 og 4.6.4
Jive-siden indeholder en ruteafhængig note om fjernelse af en SendGrid reference efter DKIM opsætning. Anvend ikke denne note som en universel fjernelsesinstruktion: fastlæg den faktiske kuvertsti og enhver anden afsenderafhængighed først. Jive SPF vejledning
Skriv den påtænkte ændring som en forskel fra den godkendte baseline. Registrer, hvad der tilføjes, hvad der bevares, og hvad der foreslås fjernet. Hvis ejerskabet af en eksisterende afhængighed er ukendt, skal du lade spørgsmålet være uløst i stedet for at slette det. En vellykket redigering i en DNS grænseflade er et bevis på en administrativ handling, ikke et bevis på, at hele mailpopulationen stadig godkendes.
Offentliggør den nøjagtige ejer og offentlige værdi
For hver foreslået post skal du registrere den fuldt kvalificerede ejer uafhængigt af DNS editorens skærm. Nogle redaktører accepterer relative etiketter, mens andre viser komplette navne. En master-fil-konvention beviser ikke, hvordan en bestemt grafisk grænseflade håndterer domæne-suffikset. Bekræft den resulterende ejer ved hjælp af DNS udbyderens egne regler, før du gemmer. RFC 1035 , afsnit 5.1
Gem registreringstypen fra den relevante udbydervejledning. Du må ikke transformere en CNAME delegation til en lokalt opfundet TXT nøgle eller erstatte en medfølgende offentlig nøgle med en fra et eksempel. For TXT data skal du skelne mellem tegnstrenge inde i en enkelt ressourcepost fra separate ressourceposter. Opdeling af displaytekst skal bevare de tilsigtede bytes; tilføjelse af en uafhængig post er en anden operation. RFC 1035 , afsnit 3.3.14
Behandl en eksisterende vælger som en afhængighed, der kræver undersøgelse. Identificer det aktuelle signeringsflow, før du overskriver noget ved det navn. En foreslået tilbagerulning skal forklare, hvilken DNS version der kan gendannes, og om udbyderen allerede har skiftet underskriver. Gendannelse af gammel DNS uden at koordinere signeringssiden kan skabe endnu en uoverensstemmelse i stedet for at reparere den første.
Bekræft meddelelsen, ikke kun posten
Godkendelsesgennemgangen bør indsamle en autoriseret meddelelse fra den faktiske applikationsworkflow og bevare betroede modtagerresultater. Registrer dets synlige Fra-domæne, kuvertidentitet, hvert DKIM signeringsdomæne og -vælger og modtagerens autentificeringsresultater. DKIM binder en signatur til et signeringsdomæne og udvalgte beskeddata; En DNS nøgles eksistens viser ikke, at applikationen brugte den. RFC 6376 , afsnit 3.5 og 3.6.2.2
Adskil godkendelsessucces fra justering. DMARC kan lykkes gennem en kvalificerende justeret SPF sti eller en kvalificerende justeret DKIM sti. Hverken den succes eller en udbyderbekræftelse garanterer indbakkeplacering eller beviser, at en forretningsanmodning i en besked er sikker. Evaluer de faktiske identifikatorer under de gældende justeringsregler i stedet for at fortolke to grønne dashboard-etiketter som tilstrækkeligt bevis. RFC 9989 , afsnit 2.4 og 4.4
Hvis en mellemmand ændrer leveringsstien, diagnosticer SPF og DKIM uafhængigt. En anden forbindelses-IP kan påvirke SPF , men det faktum alene forklarer ikke en brud DKIM signatur. Undersøg den relevante offentlige nøgle, signatur og signerede data, før du tilskriver fejl. Reager ikke ved generelt at omgå sikkerhedsinspektionen. En snævert godkendt routingkorrektion kræver sin egen dokumentation og ejerbeslutning.
Fiktiv diagnose: det forkerte implementeringsarbejdsark
Overvej en fiktiv organisation, Cedar Eksempel, hvis administrator udarbejder et TXT-nøgle-arbejdsark efter at have læst instruktioner beregnet til hostede installationer. Kontoejeren producerer derefter et Cloud-supportsvar, der indeholder CNAME poster. Ingen DNS ændring er endnu blevet godkendt. Uoverensstemmelsen er en fejl i implementeringsgrenen, ikke et bevis på, at begge registreringsformater er universelt forkerte.
Gennemgangsteamet trækker det ufuldstændige arbejdsark tilbage, registrerer kontoens bekræftede rute og beder DNS ejeren om at vurdere de fuldstændige angivne navne og mål. Det efterlader eksisterende vælgerposter urørt, indtil deres ejere er kendt. Først efter en separat autoriseret implementering ville teamet indsamle en modtaget besked og sammenligne dens identiteter med den godkendte plan. Dette scenarie er opfundet for at illustrere en beslutningsproces; den indeholder ingen observerede lejerresultater eller eksekverbare kundeværdier.
Tomt godkendelsesark og frigivelsesbeslutning
- Installations- og implementeringsmodel: ______. Region og bevisejer: ______.
- Underretningsarbejdsgang og tilsigtet synlig Fra domæne: ______.
- Aktuel dato for supportinstruktion og gældende produktomfang: ______.
- Bekræftelse af vælgerlængde og gennemgang af eksisterende vælgerafhængighed: ______.
- Fuldstændige leverede pladeejere, typer og offentlige værdier: ______.
- Eksisterende SPF baseline og godkendt ændringsforskel: ______.
- Konvolut-domæneforventning og opslagsstigennemgang: ______.
- DNS redaktørens navngivningsadfærd og deraf følgende beviser fra offentlige ejere: ______.
- Bekræftelse af implementering på udbydersiden: ______.
- Autoriseret beskedreference og betroet modtageridentitetstabel: ______.
- Justeringsresultat, resterende fejl og tilbagerulning ejer: ______.
- Uafhængig anmelder, udgivelsesejer og anmeldelsesdato: ______.
Efterlad et felt tomt, når bevis mangler. En blank er en nyttig kontrol, fordi den forhindrer dokumentarberedskab i at blive et krav om operationel afslutning. Originale beviser, menneskelig SMV-gennemgang, kildeanvendelighed, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver åbne for dette udkast. Gense vurderingen, når implementeringsruten, udbyderinstruktioner, signeringsmateriale eller domæneejerskab ændres.