Identificer domænet og Critical Impact-kontoen
Critical Impact dokumenterer afsendergodkendelse som en kontoarbejdsgang, der producerer domænespecifikke DNS instruktioner, sammenligner offentliggjorte værdier med disse instruktioner og starter derefter godkendelse. Denne vejledning dækker det dokumenterede værktøj til afsendergodkendelse. Det fastslår ikke, at et bestemt abonnement afslører værktøjet, at et domæne allerede er autoriseret, eller at en meddelelse har bestået en modtagers kontrol. Disse kræver konto- og beskedbeviser. Den dokumenterede navigation er Konto, derefter Afsendergodkendelse; hvis værktøjet mangler, leder udbyderen kunden til deres account manager. Tilgængelighed er derfor en forudsætning, ikke en kontrol, som denne artikel kan påtage sig. Critical Impact opsætningsvejledning
Begynd med det faktiske domæne eller underdomæne, der er beregnet til afsendelse. Identificer dens virksomhedsejer, den konto, der bruger den, den autoritative DNS operatør og alle andre systemer, der allerede sender under samme identitet. Et webstedsdomæne og en kampagnes synlige Fra-domæne kan variere. Registrering af den tilsigtede identitet før indhentning af DNS instruktioner hjælper med at undgå at konfigurere et ubrugt overordnet domæne, mens kampagnens underdomæne forbliver urørt. Dette er et foreslået forberedelsestrin, ikke en påstand om en automatiseret lagerfunktion.
Få de unikke instruktioner uden at behandle dem som genbrugelige standarder
Den dokumenterede sekvens er Tilføj domæne, indtast domænet eller underdomænet, og Gem. Vælg det pågældende domæne i gitteret, og vælg Godkend domæne for at få dets instruktioner. Critical Impact beskriver en unik DKIM TXT post for hvert domæne og en ip4-mekanisme til at tilføje til det eksisterende SPF politik. Udskift ikke disse kontogenererede værdier med en rekord kopieret fra en anden kunde, et andet domæne eller et gammelt skærmbillede. Udskift ikke en gættet inkludere-mekanisme med den dokumenterede ip4-instruktion. Afsendergodkendelsesforklaring
Hold de genererede ejernavne, posttyper og komplette værdier sammen med den konto og domæne, der har produceret dem. En korrekturlæser bør være i stand til at skelne en anmodet ny post fra en ændring af en eksisterende post. DNS editorer adskiller sig i deres behandling af relative navne og domæne-suffikser, så det tilsigtede fuldt kvalificerede navn bør forblive eksplicit i ændringsanmodningen. Ingen vælger, adresse eller offentlig nøgle i denne artikel er en implementeringsværdi.
Værktøjets handling med e-mail-instruktioner sender instruktioner til den loggede brugers e-mailadresse. Det er en kommunikationshandling, ikke blot en forhåndsvisning på skærmen. Beslut, om modtageren og postkassen er passende, før du bruger den. Denne vejledning har ikke sendt disse instruktioner eller kontaktet en kontoadministrator. Udbyderens arbejdsgang er beskrevet, så en autoriseret operatør kan planlægge den. Critical Impact opsætningsvejledning
Bevar eksisterende afsendere, når du forbereder DNS ændringer
Critical Impact siger ikke at slette en eksisterende SPF rekord at tilføje sin tilladelse. Opdater i stedet den eksisterende politik med den udstedte mekanisme. SPF tillader kun én valgt SPF -politik ved et givet ejernavn; at offentliggøre en anden konkurrerende politik er ikke en sikker måde at bevare den første på. Bevar godkendelsen for stadig godkendte afsendere, kontroller syntaks og bestilling, og vurder den fuldstændige evaluerede afhængighedssti, hvor DNS-opslagsmekanismer er til stede. En ip4-term er ikke en inkludering og udfører ikke selv et DNS opslag, men andre vilkår i den resulterende politik kan stadig forårsage, at evalueringsgrænser overskrides. Critical Impact Authentication forklaring RFC 7208
For DKIM skal du bruge den unikke TXT ejer og nøgle, der er leveret til dette domæne. Registrer, om DNS panelet viser præsentationscitater eller opdeler en lang TXT værdi i tegnstrenge, og valider derefter den resulterende post i stedet for at fortolke et skærmbillede som bevis på ledningsniveau. En vælgers offentliggjorte offentlige nøgle muliggør verifikation af matchende signaturer; udgivelse af en nøgle beviser ikke, at afsendertjenesten er begyndt at signere beskeder med den. Selve signaturens domæne og vælger skal senere kontrolleres i forhold til den påtænkte konfiguration. RFC 6376
Separat sammenligning, aktivering og modtagne meddelelsesbeviser
Godkendelses-popup'en adskiller eksisterende DNS værdier fra anbefalede DNS værdier. Critical Impacts opsætningsvejledning instruerer operatøren til at sammenligne dem og fortsætte med Begynd godkendelse, når værdierne er grønne. En rød mismatch skal undersøges: forkert ejer, kopieret værdi, manglende registrering, forældet resolver-svar eller en ufuldendt ændring er forskellige problemer. Forklaringen beskriver også tidstillæg og en advarselssti, når værdierne endnu ikke stemmer overens. Denne foreslåede godkendelsesprocedure bruger ikke denne advarselssti til at give afkald på sammenligningskravet. Critical Impact opsætningsvejledning
Efter initiering beskriver dokumentationen en notifikations-e-mail og en godkendt tilstand i domænetettet. Dens timing estimater er planlægningsinformation, ikke bevis for, at en specifik post vil blive korrekt inden for en deadline. Registrer den observerede tilstand og tid i stedet for at konvertere forløbet tid til succes. Hvis DNS indstillingerne ændres senere, dirigerer udbyderen brugerne til at godkende domæne igen og genbekræfte værdierne. Bevar denne genvalideringsafhængighed i den operationelle runbook. Afsendergodkendelsesforklaring
En kontos Autentificerede etiket er ét kontrolpunkt. En senere godkendt meddelelsesvurdering bør separat identificere det synlige Fra-domæne, SPF identitet og -resultat, DKIM signeringsdomæne og -resultat, og DMARC justering. DMARC kan passere gennem et justeret bestået SPF resultat eller et justeret bestået DKIM resultat; det kræver ikke universelt at begge dele består. Godkendelse garanterer heller ikke indbakkeplacering eller validerer forretningshensigten med en meddelelse. RFC 9989
Behandl det viste DMARC -eksempel som en politisk beslutning
Udbyderforklaringen beskriver en aktuel DMARC værdi og et eksempel på anbefalet DMARC værdi i pop op-vinduet. Et eksempel er ikke tilladelse til at erstatte en organisations politik. Gennemgå alle legitime afsendelsesruter, rapportering af destinationer og konsekvenser, før du godkender enhver politikændring. Omfanget af dette manuskript er konfigurationsplanlægning og bevisindsamling, ikke en anbefaling om at pålægge en bestemt håndhævelsespolitik på et ikke-undersøgt domæne. Hold DMARC beslutninger adskilt fra kopiering af den udstedte DKIM nøgle eller sammenlægning af en afsenderautorisation. Afsendergodkendelsesforklaring
Tomt accept arbejdsark
- Konto, påtænkt afsendende domæne, virksomhedsejer og tilgængelighed af værktøj: ____.
- Genererede instruktioner fanget på, godkendt DNS operatør og nøjagtige ejernavne: ____.
- Eksisterende SPF bevaret, udstedt ip4 gennemgået, komplet politik kontrolleret: ____.
- Unik DKIM TXT værdi og domænebinding gennemgået: ____.
- Eksisterende versus anbefalede værdier, mismatch forklaring og godkendelse: ____.
- Begynd godkendelse autoriseret, observeret gittertilstand og meddelelse: ____.
- Ejer af DMARC -politikbeslutning og separat godkendelse, hvis nogen: ____.
- Godkendt bevis for modtaget meddelelse, justeringsresultat og uafklarede ruter: ____.
- Genvalideringsudløser efter senere DNS ændringer og udgivelsesejer: ____.
Fiktiv diagnose: den grønne sammenligning var ikke den endelige test
En fiktiv velgørenhedsorganisation forbereder godkendelse til notices.example . Dens operatør kopierer i første omgang en DKIM nøgle, der tidligere er udstedt til appeals.example . Korrekturlæseren stopper ændringen, fordi instruktionerne er domænespecifikke, henter det korrekte domænes foreslåede ændringspost og bevarer de eksisterende SPF afsendere, mens den udstedte autorisation tilføjes. Intet i denne illustration er en ægte DNS forespørgsel eller lejerhandling.
I den fiktive anmeldelse bliver sammenligningen senere grøn, og kontoen viser til sidst Authenticated. Teamet lader stadig beskedaccept stå åben: et kampagneudkast bruger et andet Fra-underdomæne, og ingen modtaget besked har etableret sin signeringsidentitet. De retter opgørelsen og søger en autoriseret rutespecifik kontrol i stedet for at erklære hver organisations-e-mail for autentificeret. Det nyttige resultat er en klar adskillelse mellem matchende DNS instruktioner, udbyderaktivering og beviser for den besked, der faktisk sendes.
Frigivelse forbliver betinget
Katalogets påkrævede originale beviser, aktuelle kontoanvendelse, live DNS , modtagne meddelelsesadfærd, menneskelig gennemgang, visuelle tilgængelighed og ejerudgivelse forbliver ubekræftede. Denne dokumentarguide giver en foreslået arbejdsgang og en eksplicit fiktiv diagnose. Det er ikke en afsluttet implementering, en leveringsgaranti eller autorisation til at ændre DNS , sende instruktioner, ændre politik eller udgive artiklen.