Start med et domene du kan autorisere
CleverReachs oppsett DKIM guiden beskriver en arbeidsflyt for tilpasset domene i kontoinnstillingene. Det er et nyttig utgangspunkt for autentiseringskonfigurasjon, men avsenderdomenet må være et organisasjonen legitimt kan administrere. En markedsføringsoperatørs tilgang til kampanjegrensesnittet gir ikke automatisk kontroll over DNS sonen eller godkjenning til endring i hele organisasjonen DMARC politikk.
Identifiser kontoen, beregnet fra domene, kampanjekategori og DNS eier. Hvis teamet bruker en offentlig gratis e-postadresse, må du ikke forsøke å publisere poster for den leverandørens domene. Guiden diskuterer håndtering av freemail-avsenderadresser, men det er ikke en erstatning for en organisasjons eget kontrollerte avsenderdomene. Planlegg enhver synlig avsenderadresseendring med kommunikasjonseieren slik at mottakerne ikke blir overrasket.
Dette manuskriptet dekker det dokumenterte DKIM oppsettet. Den finner ikke opp en SPF inkludere verdi, hevde at hver CleverReach-konto har identiske innstillinger, eller hevder at en implementert leietaker har blitt sjekket. CleverReach Sett opp DKIM
Generer domene- og velgerkonfigurasjonen
Den dokumenterte navigasjonen starter ved profilikonet, deretter Min konto, Innstillinger og DKIM . Legg til det tiltenkte domenet gjennom Legg til domene. Guiden gir også en velger alternativ. Behandle domenet og velgeren sammen som en spesifikk konfigurasjon: en annen velger fører en verifikator til en annen DNS nøkkelplassering, selv når forfatteradressen forblir uendret.
Etter å ha lagt til domenet, bruk handlingsmenyen til å vise DNS innstillinger. Kopier den genererte TXT post fra domenets innstillinger i stedet for å låne et eksempel fra en annen konto eller anta et konvensjonelt velgernavn. Behold det viste eiernavnet, typen og fullstendig verdi i endringsforespørselen. Registrer hvem som genererte forespørselen og hvilken konto den tilhører, uten å inkludere påloggingsinformasjon.
Velgere hjelper med å skille DKIM nøkler; de er ikke et løfte om at den samme nøkkelen kan gjenbrukes på tvers av uavhengige leverandører eller kontoer. Før du erstatter et eksisterende eiernavn, avgjør om en annen aktiv konfigurasjon avhenger av det. En kollisjon trenger en revidert oppløsning, ikke en uundersøkt overskriving. Domeneoppsett og DNS innstillinger; RFC 6376 , avsnitt 3.5
Publiser TXT verdien i riktig sone
DNS administratoren bør tilordne det genererte eiernavnet til den autoritative sonen og redaktørens konvensjoner. Noen grensesnitt legger til sonenavnet automatisk; andre godtar fullt navn. Bekreft det resulterende publiserte navnet i stedet for å behandle synsfeltverdien som definitiv. Oppføringstypen i denne CleverReach-arbeidsflyten er TXT ; ikke konverter den til en CNAME ganske enkelt fordi en annen tjeneste bruker aliaser.
Bevar hele nøkkelverdien og inspiser den endelige DNS representasjonen. En TXT post kan inneholde flere tegnstrenger som en applikasjon kombinerer; disse strengene er ikke det samme som flere uavhengige poster ved eiernavnet. Kopiering av sitert presentasjonstekst inn i et felt som gir egne tilbud kan også kreve leverandørspesifikk håndtering. Ikke gjett på redaktøratferd fra et generisk eksempel. RFC 1035 , avsnitt 3.3.14; RFC 6376 , avsnitt 3.6.2.2.
Dokumentasjonen inkluderer eksempler for DNS leverandører, men akseptmålet forblir det nøyaktige tiltenkte navnet og verdien. En rotstenografi som @ må ikke beskrives som et universelt jokertegn for hvert underdomene. I RFC 1035 master-fil syntaks, angir en frittstående @ gjeldende opprinnelse, ikke alle underdomene; en bestemt DNS editor kan kreve annen inndata. RFC 1035 , avsnitt 5.1; Genererte TXT -instruksjoner
Kjør verifisering og tolk statusen snevert
Etter publisering av posten går du tilbake til domenets handlingsmeny og velger Bekreft. Veiledningen beskriver den aktive statusen som følger etter vellykket verifisering. Hold denne leverandørsjekken forskjellig fra selve DNS publikasjonen. En lagret DNS endring beviser ikke at tjenesten har sjekket den, og en mislykket sjekk rettferdiggjør ikke umiddelbart å erstatte nøkkelen eller opprette en annen domeneoppføring.
Når en sjekk ikke lykkes, sammenligner du først tiltenkt eiernavn, autoritativ sone, fullfør TXT verdi og domenevalg. Vurder deretter publiseringstidspunkt og hurtigbufrede data. Tilbyderen diskuterer utbredelsesforsinkelser, men et oppgitt venteintervall bør ikke bli en garanti for at en feil registrering til slutt vil fikse seg selv. Behold tidsstemplet og nøyaktig status slik at en senere sjekk kan sammenlignes meningsfullt.
Statusen gjelder konfigurasjonen undersøkt av CleverReach. Det er ikke en levert meldingsrapport og beviser ikke uavhengig hvilket domene en spesifikk kampanje signerte med. Denne forskjellen er spesielt viktig når en organisasjon har flere avsenderdomener eller eldre planlagte kampanjer. Verifiser og statusveiledning
Sjekk justeringen på den valgte kampanjeruten
Den foreslåtte sluttkontrollen er en autorisert representant kampanjemelding inspisert i mottakssystemet. Registrer det synlige fra domene, DKIM d= domene, velger og klarert valideringsresultat. Sammenlign den beståtte signeringsidentiteten med forfatterdomenet ved å bruke gjeldende DMARC justering modus. Ikke utlede justering bare fordi begge domenene inneholder organisasjonens merkenavn.
SPF og DKIM er separate autentiseringsmekanismer. DMARC kan bruke en passerende justert identitet, men en DKIM -oppsettartikkel etablerer ikke den fullstendige SPF konfigurasjonen for hver produktrute. Hvis SPF trenger gjennomgang, skaff deg den faktiske konvoluttidentiteten og gjeldende leverandørinstruksjoner i stedet for å legge til en gjettet inkludering på rotdomenet.
En passerende justert melding etablerer bevis for den prøven og ruten. Den lover ikke innboksplassering, engasjement, samtykkekvalitet eller sikkerhet for meldingens forretningsforespørsel. Hold leveringsobservasjoner og innholdsrisikobeslutninger i sine egne arbeidsstrømmer. RFC 9989 , avsnitt 4.4; RFC 7208 , avsnitt 2.4
Godkjenningsark for kampanjeadministratorer
Bruk dette foreslåtte regnearket til å koble konfigurasjonsforespørselen til det endelige beviset. Fullfør den separat for hvert domene eller vesentlig forskjellig rute.
- Domeneeierskap: navngi kontoen, tiltenkt avsenderdomene, kommunikasjonseier og DNS administrator.
- Generert konfigurasjon: behold det valgte domenet, velgeren og utstedt TXT eier/verdi fra Vis DNS innstillinger.
- Kollisjonsgjennomgang: identifiser enhver eksisterende nøkkel med samme navn og dens aktive avhengigheter før du endrer den.
- DNS publisering: registrer den godkjente endringen, forventet fullt kvalifisert eiernavn og bekreftelsesbevis.
- Leverandørverifisering: registrer tidspunktet Verify ble forespurt og den faktiske returnerte statusen.
- Kampanjeeksempel: Registrer den valgte varslingen eller kampanjeklassen og de observerte forfatter-/signeringsidentitetene.
- Utgivelsesbeslutning: navngi anmelderen, gjenværende hull og tilbakeføringseier i stedet for å merke alle kampanjer som klare fra én skjerm.
Ingen kontopålogging, DNS publisering eller kampanjeoverføring er utført her. Regnearket er et originalt akseptdesign, ikke en fullført implementeringspost.
Fiktiv diagnose: aktivt domene, uventet avsender
En fiktiv medlemsorganisasjon konfigurerer DKIM for news.example og får en aktiv status. Den neste kampanjen er fortsatt planlagt med en eldre Fra-adresse på events.example . Kontrolløren ser det aktive domenet i innstillingene og antar i utgangspunktet at kampanjen må tilpasses. De to observasjonene gjelder ulike identiteter, så konklusjonen er ikke underbygget.
Den foreslåtte undersøkelsen begynner med kampanjens konfigurerte avsender og den mottatte meldingens signeringsdomene. Teamet sjekker om det tiltenkte domenet ble valgt for den ruten, og vurderer deretter det relevante justeringsforholdet. Den sletter ikke den fungerende news.example -nøkkelen for å reparere en urelatert kampanje. Den endelige overleveringen skiller den bekreftede konfigurasjonen fra kampanjen som fortsatt trenger bevis. Dette scenariet er fiktivt og inneholder ingen utført DNS oppslag eller testsending.