Begrens instruksjonene til SpamTitan Gateway-signering
TitanHQ publiserer en spesifikk konfigurering DKIM i SpamTitan Gateway-prosedyren. Denne artikkelen følger den produktgrensen. Det forutsetter ikke at SpamTitan Cloud, Skellig, en inngående distribusjon eller hver administrerte tjenesteutgave avslører de samme kontrollene. Bekreft den installerte versjonen, lisensierte funksjoner og faktisk utgående rute før du godkjenner en signeringsendring. Et domene som er oppført for å motta e-post er ikke i seg selv et bevis på at utgående meldinger går gjennom gatewayen eller mottar en kundedomenesignatur.
De Gateway prosedyre inneholder både DKIM -signeringstrinn og en separat diskusjon for domene-keys-policyposter. Den blandingen er en viktig implementeringsgrense. Den moderne signaturnøkkel-arbeidsflyten kan forklares fra kilden, men det gamle policy-trinnet krever bekreftelse av nåværende produkt. Ikke konverter gammel DomainKeys-terminologi til en DMARC krav eller påstand om at publisering av en o=-policy etablerer moderne domenebeskyttelse.
Identifiser domenereléet og nøkkeleierskap
Den dokumenterte navigasjonen er System Setup, Mail Relay, DKIM . Siden viser domenereléer. Rediger det tiltenkte domenet og åpne DOMENE NØKKEL-fanen. Prosedyren ber om en velger navn som skiller denne nøkkelen fra andre domenenøkler. Velg en etikett gjennom organisasjonens godkjente navneprosess og sjekk eksisterende bruk før du publiserer den. En forutsigbar etikett er ikke en hemmelighet, men gjenbruk av en okkupert velger kan overskrive en avhengighet som en annen avsender fortsatt trenger.
Kilden beskriver generering av et nytt nøkkelpar og tilbyr også et eksisterende-privat nøkkelfelt. Denne veiledningen ber ikke om, samler inn eller anbefaler å kopiere en privat nøkkel til en billett eller et delt dokument. Nøkkelgenerering eller -import er en separat autorisert administrativ handling. Veiledningen viser 1024-bit og 2048-bit alternativer og anbefaler det lengre valget. Bekreft støttet konfigurasjon og gjeldende kryptografiske krav for det distribuerte produktet; ikke nedgrader bare fordi en DNS editor viser en lang offentlig verdi på ubeleilig vis.
Publiser den genererte offentlige nøkkelen uten å kopiere eksemplet
Etter Generer dirigerer kilden administratoren til fanen OPTIONS og DNS TXT materialet. Publiser den faktiske offentlige nøkkelen med navnet dannet fra den valgte velgeren, _domainkey og signeringsdomenet. Den store offentlige nøkkelen som er trykt i dokumentasjonen er en illustrasjon, ikke en gjenbrukbar post. Registrer den valgte eieren og en kontrollert referanse til den utstedte offentlige verdien i endringsforespørselen. Ikke noe privat materiale hører hjemme i offentlig DNS .
TitanHQ diskuterer fjerning av overflødig formatering fra den kopierte skjermen. Tolk dette som å håndtere redaktørens presentasjon, ikke vilkårlig redigering av nøkkelbyte. RFC 6376 , avsnitt 3.6.2.2 spesifiserer TXT ressursposter for nøkkellagring. Et DNS verktøy kan vise flere siterte strenger i en enkelt TXT post; som er forskjellig fra flere konkurrerende poster eller bokstavelige anførselstegn satt inn i verdien. La DNS administratoren bekrefte den faktiske logiske posten og fullstendig eiernavn i stedet for å godta et skjermbilde av en inndataboks som endelig bevis.
Hold eldre retningslinjer og testmodus atskilt fra DMARC
Leverandørprosedyren beskriver også en TXT post ved _domainkey etterfulgt av domenet, med o=- eller o=~ -verdier, under Policy Records. Den kaller eksplisitt denne DomainKeys-policyen. Dette er ikke DMARC -policyplasseringen og er ikke en erstatning for en offentlig DKIM velgernøkkel. Fordi prosedyren kombinerer disse historiske elementene, må du bekrefte om dette policytrinnet er aktuelt for den eksakte gjeldende Gateway-versjonen før du legger det til. Bevar det uløste spørsmålet i utgivelsesposten i stedet for å finne på et moderne krav.
Veiledningen beskriver separat et DKIM -testflagg, t=y, i nøkkelposten. Ikke forveksle det med en instruksjon om å sette en DMARC distribusjon i testmodus eller med bevis på at mottakerne godtar all e-post. DKIM , DMARC og lokal mottakerhåndtering har distinkt semantikk. RFC 9989 , avsnitt 4.4 forklarer justering kreves mellom en bestått autentiseringsidentitet og forfatterdomenet. En eldre policyerklæring om at e-post er signert, fastslår ikke at en bestemt signatur validerer eller justerer.
Bekreft før aktivering og planlegg rotasjon bevisst
TitanHQs OPTIONS-arbeidsflyt bruker Verify for å hente DNS TXT posten og sammenligne den med gatewayens konfigurerte informasjon. Når verifiseringen er vellykket, aktiverer Aktiver DKIM signering for domenet. Behandle disse som separate sjekkpunkter. En publisert nøkkel beviser ikke at signering er aktivert, mens et valgt signeringsalternativ ikke kan validere en manglende eller feilaktig offentlig post. Ta vare på verifikasjonsresultatet og dets tid uten å beskrive det som en mottakers aksepttest.
Dokumentasjonen anbefaler periodisk nøkkelrotasjon. En praktisk rotasjonsplan trenger mer enn et kalenderintervall: identifiser aktive velgere, genererte nøkler, meldinger i kø, DNS bufring, autoriserte operatører og tilbakestillingsbetingelser. Ikke slett den tidligere offentlige posten bare fordi en erstatningsnøkkel ble generert. Bestem hvilken overlapping den faktiske postbanen trenger, og behold bevisene som støtter denne avgjørelsen. Dette manuskriptet har ikke målt køens levetid eller testet det installerte produktets overgangsatferd, så disse implementeringsdetaljene forblir åpne.
Sjekk den endelige utgående meldingen i stedet for filtreringsetiketten
En separat autorisert akseptøvelse bør skille gateway-transitt, signering, validering og justering. Se gjennom signaturens d= og s=-felt, det synlige forfatterdomenet og pålitelige mottakerautentiseringsresultater. RFC 6376 , avsnitt 3.5 definerer signaturfeltene. Sjekk meldingsklasser som kan ta forskjellige veier, for eksempel vanlig postkassepost, applikasjonsvarsler og videresendt trafikk. Det faktum at en innkommende melding ble skannet av SpamTitan sier ikke noe avgjørende om hvordan en utgående søknadsmelding ble signert.
SPF er en egen anmeldelse. RFC 7208 , avsnitt 2.4 og 4.6.4 beskriv den POST FRA identitets- og DNS-avhengige evalueringsgrenser. Denne kilden gir ikke en universell utgående SPF inkludering for hver SpamTitan-distribusjon, så ingen er oppfunnet her. Skaff deg den faktiske autoriserte sendeinfrastrukturen og gjennomgå én fullstendig policy for den identiteten. Suksess for autentisering forblir forskjellig fra innboksplassering, innholdssikkerhet eller mottakers godkjenning av en betalingsforespørsel.
Fiktiv diagnose og blankt akseptark
Et fiktivt ingeniørfirma, Alder Instruments, publiserer en ny velgernøkkel, men lar signering være deaktivert mens de venter på et vedlikeholdsvindu. Den interne sjekklisten markerer DKIM som fullført fordi Verify lyktes. En senere gjennomgang finner at sjekklisten blander DNS avtalen med aktiv signering. Den foreslåtte korreksjonen er å skille godkjenningen for å aktivere, den observerte konfigurasjonstilstanden og fremtidig mottakerbevis. Det er ikke for å publisere dokumentasjonens eksempelnøkkel eller legge til en eldre policypost som en erstatning. Ingen faktisk system-, meldings- eller DNS oppslag ligger til grunn for dette scenariet.
- Gateway-produkt, versjon, utgående rute og domenerelé: ______
- Velger eierskap og eksisterende avhengigheter: ______
- Generert offentlig eier-/verdireferanse og godkjent DNS endring: ______
- Avgjørelse om varetekt med privat nøkkel, uten hemmelig materiale: ______
- Legacy DomainKeys-policyanvendelsesbeslutning: ______
- Bekreft resultatet og påfølgende Aktiver godkjenning/tilstand: ______
- Rotasjonsoverlapping, tilbakerulling og oppbevaring av forrige velger: ______
- Pålitelig mottatt meldingssignatur og justeringsbevis: ______
- Gjenværende unntak, anmelder og utgivelseseier: ______
Opprinnelig implementeringsbevis, gjeldende kildeanvendelse, gjennomgang av menneskelig gjenstand, aksept av produksjonsruter, visuell tilgjengelighet og eierutgivelse forblir åpne. Ingen nøkkel ble generert, innstilling endret, DNS post publisert eller melding sendt. Katalogens bredere implementeringskrav kan ikke merkes som komplett fra denne dokumentariske arbeidsflyten alene.