Omfang: Afrihost delt hosting og cPanel
Afrihost publiserer separate instruksjoner for å skaffe autentiseringsposter i cPanel og legge dem til gjennom ClientZones Shared Hosting DNS Editor. Denne veiledningen følger den dokumenterte ruten. Det tyder ikke på at Afrihost Pure Mail, en ekstern postboksleverandør eller hver vertspakke bruker identiske poster eller signeringskontroller. Etabler det faktiske e-postproduktet og den autoritative DNS tjenesten før du forbereder en endring. De kontospesifikke verdiene og gjeldende grensesnittbruk forblir ubekreftede.
Leverandørens SPF generasjonsinstruksjoner bruker cPanels e-postleveringsområde: velg Administrer ved siden av domenet, finn SPF og kopier verdien. Dens DKIM instruksjonene bruker det samme området og handlingen Install The Suggested Record. Dette er foreslåtte operatørtrinn, ikke handlinger utført for dette manuskriptet. Afrihost SPF generasjon Afrihost DKIM generasjon
Separat generering, publisering og signering
En foreslått post er bevis på hva et bestemt konfigurasjonsgrensesnitt anbefaler. Det er ikke bevis på at den offentlige autoritative sonen inneholder den verdien eller at en melding ble signert og vellykket verifisert. Bevar domenekonteksten ved siden av den foreslåtte posten. En administrator som kopierer en verdi fra feil vertskonto kan produsere en plausibel, men irrelevant endringsforespørsel.
For DKIM skiller du det offentlige bekreftelsesmaterialet fra alt privat signeringsmateriale. DNS posten inneholder informasjon om offentlig nøkkel. Private nøkler må ikke samles i mottaksarket eller limes inn i en billett. Protokollen kobler en meldings signatur til et signeringsdomene og velger; disse identifikatorene bestemmer hvor en verifikatoren ser etter nøkkelen. Et visuelt lignende domene eller en generisk kontoetikett kan ikke erstatte dem. RFC 6376 , DKIM-Signature og nøkkellagring
Afrihosts DKIM opprettingsartikkel sier at posten kan kopieres til domenets DNS klynge etter at den foreslåtte posten er installert. Behandle dette som en grunn til å fastslå hvem som faktisk betjener autoritativ DNS . En lokal vertsvisning og en eksternt drevet offentlig sone kan kreve forskjellig publikasjonseierskap. Ikke konkluder med at den offentlige posten endret seg bare fordi et lokalt grensesnitt viste en suksessmelding. Afrihost DKIM generasjon
Forbered SPF endringen uten å forkaste andre avsendere
Den dokumenterte ClientZone-banen er Hosting, domenet under Shared Hosting, Hosting Settings, DNS Editor, og deretter Create New Record. For SPF spesifiserer artikkelen TXT , et tomt prioritetsfelt, det kopierte SPF innholdet og TTL 7200. Denne grensesnittoppskriften rettferdiggjør ikke å opprette en andre SPF policy når en allerede eksisterer. Gå gjennom den eksisterende policyen og slå sammen bare de godkjente autorisasjonsendringene. Afrihost SPF -publikasjon
SPF evaluerer SMTP identiteten, inkludert POST FRA, i stedet for bare å stole på det menneskelesbare Fra-feltet. Inventarapplikasjoner som sender etter den relevante identiteten før de endrer retningslinjene. Vertsbaserte postboksinnsendinger, nettstedvarsler og et eksternt markedsføringsverktøy kan ha forskjellige konvolutter og infrastruktur. Ikke anta at en cPanel-standard inkluderer hver tjeneste organisasjonen har tatt i bruk. RFC 7208 , HELO og MAIL FRA identiteter
Behold én gjeldende SPF policy ved eiernavnet. Gjennomgå nestede inkluderer og andre DNS-søkende termer mot protokollens evaluerte tidsgrense. En kort politikk på toppnivå kan fortsatt ha en overdreven avhengighetsbane. Registrer gjennomgangsmetoden og bevistiden, men ikke merk en ikke-utført plan som en vellykket live-evaluering. Et bufret svar fraviker ikke evalueringsreglene. RFC 7208 , flere poster og DNS oppslagsgrenser
Løs uklarheten om DKIM -eiernavn før publisering
Afrihosts DKIM publikasjonsside beskriver ClientZone-ruten og limer inn en DKIM TXT verdi. Teksten inkluderer imidlertid en SPF-merket instruksjonsoverskrift og et generisk domenenavnfelt i stedet for en fullstendig kontospesifikk velgereier. Disse detaljene er ikke et trygt grunnlag for å finne opp en apex DKIM post. Skaff og gjennomgå det fullstendige genererte navnet og verdien for det faktiske domenet, og løs redaktørens navnekonvensjon før du godkjenner publisering. Afrihost DKIM publikasjon
Under DKIM danner velgeren og signeringsdomenet nøkkeloppslagsnavnet under _domainkey . Selve velgeren må komme fra kontoens støttede konfigurasjon og samsvare med meldingene som signeres. Ikke oppgi en gjettet velger bare fordi en annen tjeneste bruker den. Den samme regelen gjelder for en kopiert offentlig nøkkel: dens syntaks alene fastslår ikke at den tiltenkte signeren har den tilsvarende private nøkkelen. RFC 6376 , nøkkeloppbevaring
Bekreft om redaktøren forventer en relativ etikett eller et fullstendig eiernavn. DNS -hovedfilkonvensjoner inkluderer en gjeldende opprinnelse, men grafiske redaktører er produktgrensesnitt og trenger sin egen tolkning. Akseptkriteriet er det resulterende fullt kvalifiserte eiernavnet, ikke om operatøren har skrevet en kjent stenografi. RFC 1035 , master-filformat
Tolk autentiseringsresultater snevert
Noen introduksjonsord fra leverandøren beskriver DKIM som å forhindre spam eller forbedre levering. Ikke gjør den beskrivelsen til en garanti. DKIM gir en kryptografisk signatur og en tilskrivbar signeringsidentitet; det er ikke kryptering av meldingsteksten og fastslår ikke at alle forretningsinstruksjoner i meldingen er trygge. En gyldig signatur er også forskjellig fra DMARC justering. RFC 6376 , introduksjon
For den faktiske senderruten bør en akseptvurdering knytte en bestått SPF eller DKIM identitet til det synlige forfatterdomenet. DMARC kan passere gjennom begge kvalifiserende justert mekanismer. En DNS post som eksisterer isolert etablerer ikke denne relasjonen for en melding. Autentisering garanterer heller ikke levering, omgår mottakerfiltrering eller beviser at en konto ikke har blitt misbrukt. RFC 9989 , identifikatorjustering og omfang
Fiktiv diagnose: feil publikasjonseier
Se for deg en fiktiv forening kalt Cedar Trail Club. Dens frivillige skaffer en foreslått DKIM post fra det riktige cPanel-domenet, og kopierer deretter bare verdien inn i en DNS endringsforespørsel. En annen operatør antar at posten tilhører roten fordi forespørselen ikke inneholder noen velgereier. Dette er et oppfunnet planleggingsscenario, ikke en påstand om en Afrihost-kunde eller en test utført her.
Kontrolløren avviser den ufullstendige forespørselen uten å gjette en velger. Applikasjonseieren må oppgi den fullstendige genererte offentlige journalen og identifisere den tiltenkte signeringsruten. DNS operatøren må bekrefte den autoritative sonen og det resulterende eiernavnet. Utgivelseseieren krever da faktisk meldingsbevis, innhentet gjennom en autorisert prosess, før han aksepterer signering og justering. Den korrigerende leksjonen er å bevare forholdet mellom generert kontekst, offentlig nøkkelplassering og meldingsidentitet i stedet for å behandle en innlimt verdi som en fullstendig konfigurasjon.
Tomt arbeidsark for godkjenning
Dette arbeidsarket er et forslag. Ingen celle er forhåndsfylt med et oppfunnet kontoresultat.
- Hosting av produkt, pakke og domenekontekst: ______
- Autorisert cPanel-operatør og godkjenningsreferanse: ______
- Autoritativ DNS leverandør og soneeier: ______
- Eksisterende SPF policy og legitim avsenderbeholdning: ______
- Foreslått SPF verdi og gjennomgått sammenslått policy: ______
- Fullt generert DKIM eiernavn og offentlig verdi: ______
- Tolkning av redaktørnavn og konfliktsjekk: ______
- Offentlig journalobservasjon, tidsstempel og omfang: ______
- Faktisk meldingsvelger, signeringsdomene og konvoluttidentitet: ______
- Bevis for autentisering og justering: ______
- Tilbakeføring, ansvarlig eier og frigjøringsbeslutning: ______
Publisering og operasjonelle holder
Kontoanvendelse, gjeldende produktkontroller, DNS publisering, signeringsaktivering og bekreftelse av mottatte meldinger forblir åpne. Ingen konto ble åpnet, ingen foreslått post installert, ingen DNS post opprettet og ingen testmelding sendt. Gjennomgang av menneskelig gjenstand, kildeanvendbarhet, originale katalogbevis, produksjonsruter, visuell tilgjengelighet og eierutgivelse er også åpne. Utkastet erstatter ikke katalogens nødvendige implementeringsbevis med denne fiktive diagnosen eller med leverandørens instruksjonssuksessformulering.