Start med den kontakt-e-mail, der definerer det afsendende domæne
ControlShifts embedsmand Vejledning til konfiguration af afsendergodkendelse, opdateret 20. maj 2025, knytter sin platforms afsendende identitet til organisationens kontakt-e-mail. Guiden siger, at denne adresse bruges til platformsmail til supportere, der skrider til handling, og administratorer, der abonnerer på notifikationer. Bekræft, at den konfigurerede adresse tilhører den tilsigtede organisatorisk domæne før du opretter godkendelsesposter. En tastefejl eller et forældet branddomæne på dette første trin kan producere en teknisk konsistent konfiguration for den forkerte identitet.
Den dokumenterede sti er administratorens hjemmeside, Indstillinger, Kontakt, hvor adressen indtastes og gemmes. Behandl ændring af denne adresse som en kommunikationskonfigurationsændring, ikke blot en godkendelsesreparation. Identificer berørte meddelelseskategorier, svar forventninger og ansvarligt personale, før du gemmer. Denne artikel ændrer ikke en adresse, kontakter en supporter eller sender en platformsmeddelelse. Aktuel kontoanvendelse og den faktiske rute, der bruges af repræsentative beskeder, forbliver åbne.
Brug indstillinger for levering til at få kontospecifikke poster
Efter at have indstillet kontakt-e-mailen, leder guiden administratoren til Indstillinger, Leverbarhed. Det viste domænenavn er afledt af kontaktmailen. Hvis det er forkert, skal du først rette kontakt-e-mailen i stedet for at offentliggøre poster for et utilsigtet domæne. Indtast organisationens tekniske kontakt-e-mail i det angivne felt, og gem via en autoriseret konto-workflow. En teknisk kontaktadresse bør kun oplyses med passende tilladelse og holdes opdateret, efterhånden som personalets ansvar ændres.
Efter at have gemt, præsenterer siden tre CNAME optegnelser. Udgiv de nøjagtige udstedte ejere og mål gennem organisationens autoritative DNS udbyder. Guiden forklarer retningen for kortlægningen: navnet til venstre peger på målet til højre. Vend ikke disse felter, erstatte en rekord kopieret fra en anden organisation, eller erstat den udstedte konfiguration med et generisk SendGrid eksempel. ControlShifts kontogenererede værdier er implementeringsinput for denne arbejdsgang.
Før du redigerer, skal du sammenligne hvert komplette ejernavn med DNS editorens suffikshåndtering og eksisterende zonedata. En relativ etiket kan være tilstrækkelig i ét panel, mens et andet forventer et fuldt kvalificeret navn. Bevar de nuværende registreringer og noter de godkendte ændringer. De tre CNAME'er repræsenterer afhængigheder, der bør forblive tilskrives denne platformskonfiguration, så de kan gennemgås under fremtidige migreringer, domæneændringer eller offboarding.
Tjek DNS synlighed, før du fortolker Bekræft
Guiden siger, at Cloudflare brugere skal holde e-mail-leveringsposterne uden proxy. Dette er specifik vejledning for disse godkendelsesposter, ikke en grund til at deaktivere proxy- eller sikkerhedskontrol på tværs af et helt websted. Hvis DNS værten tilbyder proxyfunktioner, skal du gennemgå den relevante registreringsindstilling med den autoriserede DNS ejer og bekræfte, at det udstedte alias er afsløret efter behov. Ingen DNS indstilling ændres af denne artikel.
Når du har oprettet posterne, skal du vende tilbage til Leverbarhed og vælge Bekræft. Den dokumenterede succesmeddelelse angiver, at ControlShifts DNS kontrol bestået. Bevar denne observation adskilt fra den indsendte ændring og den faktiske offentlige registrering. Et udbydertjek beviser ikke, at alle fremtidige meddelelser er signeret korrekt, eller at det synlige forfatterdomæne er justeret. Hvis verifikationen mislykkes, skal du inspicere den nøjagtige ejer, målet, autoritative zone og relevante registreringsindstillinger, før du gentagne gange venter eller genopbygger konfigurationen.
Udbyderens korte udbredelsesestimat bør ikke behandles som en universel deadline. En forkert registreringsejer eller et fuldmagtsalias repareres ikke alene efter forløbet tid. Registrer, hvad der ændrede sig, hvornår det ændrede sig, og hvad udbyderen observerede. Efterlad usikkerhed eksplicit, hvis det autoritative svar og udbyderens seneste status endnu ikke er blevet afstemt.
Løs vælgerkollisioner uden at overskrive en anden afsender
ControlShift advarer specifikt om, at organisationer, der allerede bruger SendGrid , direkte eller gennem et andet værktøj, kan have s1. _domainkey og s2. _domainkey records. Guiden tilbyder en brugerdefineret DKIM vælger gennem avancerede indstillinger for at undgå sådanne kollisioner. Den beskriver markering af Brug tilpasset DKIM vælger, indtastning af en vælger på op til tre tegn og lagring, så de genererede CNAME'er afspejler valget. Bekræft den nuværende grænseflades accepterede værdi før implementering; dette er en produktspecifik grænse, ikke en universel DKIM selektorlængderegel.
Overskriv ikke en eksisterende vælger blot for at få den nye sides standardposter til at passe. Identificer den tjeneste, der ejer hver eksisterende post, og om den stadig signerer post. Hvis konfigurationen allerede er nået frem til udstedte poster, beskriver vejledningen, hvordan du fjerner den og starter igen for at vælge den brugerdefinerede indstilling. Det er en ændring af en eksisterende godkendelseskonfiguration og kræver en konsekvensgennemgang, især hvis produktionsmail allerede afhænger af det.
Kilden tilføjer en vigtig advarsel: efter at have fjernet og genskabt konfigurationen, vil den første CNAME sandsynligvis også ændre sig. Gennemgå hele det nyligt udstedte sæt, ikke kun de to navne, der synligt indeholder vælgeren. En accept-tjekliste, der opdaterer de DKIM-lignende poster, men bevarer et forældet første alias, kan efterlade en skjult uoverensstemmelse. Hold gamle og nye værdier adskilte i ændringsposten, og slet ikke urelaterede afhængigheder.
Behandl et nyt kontakt-e-mail-domæne som en konfigurationsmigrering
Guiden adskiller ændring af den lokale del af kontaktmailen fra ændring af dens domæne. En adresseændring på samme domæne kræver ikke ændringer af leveringsindstillinger i henhold til den dokumenterede arbejdsgang. Et andet domæne gør det: vejledningen beskriver fjernelse af den gamle leveringskonfiguration, opdatering af kontakt-e-mailen og fuldførelse af opsætningen igen. Denne sekvens bør planlægges som en migrering med en eksplicit ejer- og rollback-beslutning, ikke en tilfældig kosmetisk redigering.
Bekræft, at det nye domæne er kontrolleret af organisationen, og at dets DNS ejer kan offentliggøre de udstedte poster. Gennemgå tidspunktet for planlagte meddelelser og de nødvendige beviser, før du genoptager normal brug. Det faktum, at det tidligere domæne bestod Verify, overfører ikke dette resultat til det nye. Bevar den tidligere konfigurations acceptpost for kontekst, mens du tydeligt markerer den nye identitet som ubekræftet, indtil de relevante kontroller er gennemført.
Bekræft beskedens identitet uden at love levering
En særskilt autoriseret acceptøvelse bør inspicere harmløse repræsentative meddelelser og betroede modtagerresultater. Registrer det synlige forfatterdomæne, signaturdomæne og -vælger, kuvertidentitet og faktisk platformsrute. RFC 6376 , afsnit 3.5 definerer DKIM signatur felter, og RFC 9989 , afsnit 4.4 forklarer justering. Et vellykket DNS tjek er ikke en erstatning for dette forhold på meddelelsesniveau.
Den bevarede opsætningsvejledning giver tre CNAME'er i stedet for en universel SPF inkludere for at tilføje ved enhver organisatorisk rod. Lad være med at opfinde en inkludere eller tilføje en anden SPF politik, blot fordi en generisk tjekliste beder om SPF . Hvis en separat SPF ændring virkelig er påkrævet af den faktiske rute, skal du gennemgå den under RFC 7208 , afsnit 3.2 og 4.6.4 med den ansvarlige operatør. Autentificering kan adressere identitetskontrol; det garanterer ikke indbakkeplacering, supporterengagement eller sikkerheden ved enhver linket anmodning.
Fiktiv diagnose og blankt acceptark
En fiktiv samfundsorganisation, Riverbank Neighbours, har allerede SendGrid -vælgere til en anden platform. Dens administrator vælger en brugerdefineret vælger i ControlShift, men opdaterer kun de to vælgerrelaterede CNAME'er efter genskabelse af konfigurationen. Gennemgangen konstaterer, at den først udstedte journal også ændrede sig. Den foreslåede rettelse er at sammenligne det fulde nye sæt med den autoritative zone, bevare den anden platforms vælgere og opnå nyt verifikationsbevis. Dette scenarie er fiktivt og indeholder ingen egentlig DNS observation, supporterinformation eller udført handling.
- Aktuelt kontakt-e-mail-domæne og berørte meddelelseskategorier: ______
- Leverance Domænenavn og autoriseret teknisk kontakt: ______
- Fuldfør ejer-/målsæt med tre poster og udstedelsestidspunkt: ______
- Eksisterende vælgerejere og brugerdefineret vælgerbeslutning: ______
- Alle ændrede poster efter enhver rekreation, inklusive den første: ______
- Autoritativ DNS og relevant proxy-indstilling gennemgang: ______
- Bekræft resultat og pålidelige beviser for modtaget meddelelses identitet: ______
- Timing af domænemigration, tilbagerulning af ejer og frigivelsesbeslutning: ______
Originale implementeringsbeviser, gennemgang af menneskeligt emne, aktuel kildeanvendelse, produktionsrutetest, visuel tilgængelighed og ejerudgivelse forbliver åbne. Ingen kontaktadresse, godkendelseskonfiguration eller DNS post blev ændret, og ingen meddelelse blev sendt. Det bredere katalogimplementeringskrav forbliver underlagt faktiske autoriserede konto- og meddelelsesbeviser.