Begränsa instruktionerna till SpamTitan Gateway-signering
TitanHQ publicerar en specifik konfiguration DKIM i SpamTitan Gateway-proceduren. Den här artikeln följer den produktgränsen. Det förutsätter inte att SpamTitan Cloud, Skellig, en inkommande-enbart distribution eller varje hanterad tjänsteutgåva exponerar samma kontroller. Bekräfta den installerade versionen, licensierade funktionerna och den faktiska utgående rutten innan du godkänner en signeringsändring. En domän som är listad för att ta emot e-post är inte i sig ett bevis på att utgående meddelanden passerar gatewayen eller tar emot en kunddomänsignatur.
De Gateway-procedur innehåller både DKIM -signeringssteg och en separat diskussion om äldre DomainKeys-policyposter. Den blandningen är en viktig implementeringsgräns. Det moderna arbetsflödet med signaturnyckel kan förklaras från källan, men det äldre policysteget kräver bekräftelse av nuvarande produkt. Konvertera inte gammal DomainKeys-terminologi i tysthet till en DMARC krav eller påstående att publicering av en o=-policy etablerar modernt domänskydd.
Identifiera domänreläet och nyckelägande
Den dokumenterade navigeringen är System Setup, Mail Relay, DKIM . Sidan listar domänreläer. Redigera den avsedda domänen och öppna fliken DOMÄNNYCKEL. Förfarandet kräver en väljare namn som skiljer denna nyckel från andra domännycklar. Välj en etikett genom organisationens godkända namngivningsprocess och kontrollera befintlig användning innan du publicerar den. En förutsägbar etikett är ingen hemlighet, men återanvändning av en upptagen väljare kan skriva över ett beroende som en annan avsändare fortfarande behöver.
Källan beskriver generering av ett nytt nyckelpar och erbjuder även ett befintligt-privat nyckelfält. Den här guiden begär inte, samlar in eller rekommenderar att du kopierar en privat nyckel till en biljett eller ett delat dokument. Nyckelgenerering eller -import är en separat auktoriserad administrativ åtgärd. Guiden listar 1024-bitars och 2048-bitar alternativ och rekommenderar det längre valet. Bekräfta den konfiguration som stöds och aktuella kryptografiska krav för den distribuerade produkten; nedgradera inte bara för att en DNS redigerare visar ett långt offentligt värde på ett obekvämt sätt.
Publicera den genererade publika nyckeln utan att kopiera exemplet
Efter Generera dirigerar källan administratören till fliken ALTERNATIV och DNS TXT materialet. Publicera den faktiska publika nyckeln vid namnet som bildas av den valda väljaren, _domainkey och signeringsdomänen. Den stora publika nyckeln som är tryckt i dokumentationen är en illustration, inte en återanvändbar post. Anteckna den valda ägaren och en kontrollerad referens till det utfärdade offentliga värdet i ändringsbegäran. Inget privat material hör hemma i offentlig DNS .
TitanHQ diskuterar att ta bort främmande formatering från den kopierade skärmen. Tolka detta som att hantera redaktörens presentation, inte godtycklig redigering av nyckelbytes. RFC 6376 , avsnitt 3.6.2.2 anger TXT resursposter för nyckellagring. Ett DNS verktyg kan visa flera citerade strängar inom en enda TXT post; som skiljer sig från flera konkurrerande poster eller citattecken som infogas i värdet. Låt DNS administratören verifiera den faktiska logiska posten och fullständiga ägarens namn istället för att acceptera en skärmdump av en inmatningsruta som slutgiltigt bevis.
Håll äldre policy och testläge åtskilda från DMARC
Providerproceduren beskriver också en TXT post vid _domainkey följt av domänen, med o=- eller o=~ -värden, under Policy Records. Den kallar uttryckligen denna DomainKeys-policy. Detta är inte DMARC -policyplatsen och är inte en ersättning för en offentlig DKIM väljarnyckel. Eftersom proceduren kombinerar dessa historiska element, bekräfta om det policysteget är tillämpligt på den exakta aktuella Gateway-versionen innan du lägger till den. Bevara den olösta frågan i releaseposten snarare än att uppfinna ett modernt krav.
Guiden beskriver separat en DKIM -testflagga, t=y, i nyckelposten. Blanda inte ihop det med en instruktion att placera en DMARC distribution i testläge eller med bevis på att mottagarna kommer att acceptera all post. DKIM , DMARC och lokal mottagarhantering har distinkt semantik. RFC 9989 , avsnitt 4.4 förklarar inriktning krävs mellan en passerande autentiseringsidentitet och författarens domän. Ett äldre policyuttalande om att e-post är signerat fastställer inte att en viss signatur validerar eller anpassar sig.
Verifiera innan du aktiverar och planera rotation medvetet
TitanHQs OPTIONS-arbetsflöde använder Verify för att hämta DNS TXT posten och jämföra den med gatewayens konfigurerade information. När verifieringen har lyckats aktiverar Enable DKIM -signering för domänen. Behandla dessa som separata kontrollpunkter. En publicerad nyckel bevisar inte att signering är aktiverad, medan ett valt signeringsalternativ inte kan validera en saknad eller felaktig offentlig post. Bevara verifieringsresultatet och dess tid utan att beskriva det som ett mottagaracceptanstest.
Dokumentationen rekommenderar periodisk nyckelrotation. En praktisk rotationsplan behöver mer än ett kalenderintervall: identifiera aktiva väljare, genererade nycklar, köade meddelanden, DNS cache, auktoriserade operatörer och återställningsvillkor. Ta inte bort den tidigare offentliga posten bara för att en ersättningsnyckel genererades. Bestäm vilken överlappning den faktiska postsökvägen behöver och behåll bevisen som stöder det beslutet. Det här manuskriptet har inte mätt kölivslängder eller testat den installerade produktens övergångsbeteende, så dessa implementeringsdetaljer förblir öppna.
Kontrollera det slutliga utgående meddelandet i stället för filtreringsetiketten
En separat auktoriserad acceptövning bör särskilja gatewaytransitering, signering, validering och anpassning. Granska signaturens d= och s=-fält, den synliga författaredomänen och betrodda mottagarautentiseringsresultat. RFC 6376 , avsnitt 3.5 definierar signaturfälten. Kontrollera meddelandeklasser som kan ta olika vägar, såsom vanlig postlådepost, applikationsaviseringar och vidarebefordrad trafik. Det faktum att ett inkommande meddelande skannades av SpamTitan säger inget avgörande om hur ett utgående applikationsmeddelande undertecknades.
SPF är en separat recension. RFC 7208 , avsnitt 2.4 och 4.6.4 beskriv dess MAIL FRÅN identitet och DNS-beroende utvärderingsgränser. Den här källan tillhandahåller inte en universell utgående SPF inkludering för varje SpamTitan-distribution, så ingen är uppfunnen här. Skaffa den faktiska auktoriserade sändningsinfrastrukturen och granska en fullständig policy för den identiteten. Autentiseringens framgång skiljer sig från placering i inkorgen, innehållssäkerhet eller mottagarens godkännande av en betalningsbegäran.
Fiktiv diagnos och blank acceptans arbetsblad
En fiktiv ingenjörsfirma, Alder Instruments, publicerar en ny väljarnyckel men lämnar signering inaktiverad i väntan på ett underhållsfönster. Dess interna checklista markerar DKIM som klar eftersom verifieringen lyckades. En senare granskning visar att checklistan blandar DNS avtal med aktiv signering. Den föreslagna korrigeringen är att separera godkännandet för att aktivera, det observerade konfigurationstillståndet och framtida mottagarbevis. Det är inte för att publicera dokumentationens exempelnyckel eller lägga till en äldre policypost som ersättning. Inget egentligt system, meddelande eller DNS uppslag ligger bakom detta scenario.
- Gateway-produkt, version, utgående rutt och domänrelä: ______
- Väljarägande och befintliga beroenden: ______
- Genererad offentlig ägare/värdereferens och godkänd DNS ändring: ______
- Beslut om vårdnad med privat nyckel, utan hemligt material: ______
- Legacy DomainKeys policytillämplighetsbeslut: ______
- Verifiera resultatet och efterföljande Aktivera godkännande/tillstånd: ______
- Rotationsöverlappning, återställning och kvarhållning av föregående väljare: ______
- Pålitlig signatur för mottagna meddelande och anpassningsbevis: ______
- Återstående undantag, granskare och releaseägare: ______
Originalimplementeringsbevis, aktuell källans tillämplighet, granskning av mänskligt ämne, godkännande av produktionsvägar, visuell tillgänglighet och ägarefrigivning förblir öppna. Ingen nyckel genererades, inställningen ändrades, DNS posten publicerades eller meddelandet skickades. Katalogens bredare implementeringskrav kan inte markeras som komplett endast från detta dokumentära arbetsflöde.