A DKIM vælger er omfattet af et signeringsdomæne. To tjenester kan sikkert bruge ordet "default" under forskellige d=-domæner, men default._domainkey.example.com er ét DNS ejernavn. Hvis to uafhængige tjenester har brug for forskellige nøgler med det samme navn, kan tilføjelse af den anden tjeneste bryde bekræftelsen for den første. Løs ejerskabskollisionen, før du ændrer DNS .
Sammenlign de komplette navne
Indsaml en nyligt modtaget underskrevet besked fra hver aktive tjeneste, og optag d= og s=. Sammenlign disse værdier med de afventende instruktioner til opsætning af udbyderen. For DNS-baseret nøglehentning bestemmer vælgeren og signeringsdomænet opslagsnavnet. En udbyder-etiket som "vælger 1" i en opsætningsskærm er ikke nok til at identificere den rigtige DNS ejer. RFC 6376 §3.5 og RFC 6376 §3.6.2.1.
Illustrativt eksempel: løn og marketing anmoder begge om s=default med d=example.com, men hver har en anden privat nøgle. Begge signaturer fører verifikatorer til default._domainkey.example.com . Udskiftning af lønningslistens offentlige nøgle med markedsføringens nøgle kan efterlade lønmeddelelser, der ikke kan verificeres, inklusive meddelelser, der allerede er i transit. Omvendt er standard under d=payroll.example.com og standard under d=marketing.example.com forskellige opslagsnavne. Justering implikationer kræver stadig en separat kontrol.
Vælg et understøttet separationsdesign
Foretrækker særskilte vælgere til uafhængige signeringstjenester, når udbyderne understøtter dem. Offentliggør den nye tjenestes genererede offentlige nøglepost under dens eget ejernavn, valider den, aktiver derefter underskriveren og test modtagne e-mails. Hvis en tjeneste retter sit vælgernavn, skal du spørge, om den understøtter et separat signeringsunderdomæne eller en anden dokumenteret konfiguration. Opfind ikke en CNAME målrette eller omdøbe en vælger udelukkende i DNS : underskriveren skal udsende den matchende s=-værdi.
Ændring af d= til et underdomæne kan påvirke DMARC. Et underdomæne kan justeres under afslappede regler, mens det ikke er strengt tilpasset med et overordnet forfatterdomæne. Bekræft det tilsigtede forhold, før du vælger løsningen for navngivning. RFC 9989 §4.4.1 og RFC 9989 §4.10.2.
Stol ikke på tvetydige nøglesvar
Under RFC 6376 §3.6.2.2, TXT nøgleposter skal være unikke for et vælgernavn; resultater med flere poster er udefinerede. Udgivelse af flere forskellige nøgler hos én ejer overtræder denne udgivelsesregel og er ikke et serviceadskillelsesdesign. RFC 6376 tillader en verifikator at vælge én returneret nøgle eller prøve flere efter eget skøn med uspecificeret rækkefølge. En konfiguration, der fungerer på én modtager, kan derfor være upålidelig andre steder. Separate vælgere giver en eksplicit mapping i stedet for at stole på nøglevalgsadfærd. RFC 6376 §6.1.2.
Flere citerede tegnstrenge inden for en TXT ressourcepost er et andet problem: de kan være dele af en enkelt post. Forveksle ikke udbyderens displayindpakning med flere forskellige nøgler. Sammenlign de faktiske DNS svar og udbyderens genererede værdi ved hjælp af et passende DNS værktøj.
Håndter en eksisterende kollision sikkert
Hvis en kollision allerede har fundet sted, skal du registrere nuværende DNS , konfigurationshistorik, berørte d/s-par og modtagerfejl. Gendan kun den tidligere kortlægning, hvis den er sikker og stadig nødvendig, og bring derefter den nye tjeneste online under en understøttet særskilt vælger. Undgå at dele private nøgler mellem ikke-relaterede tjenester blot for at få dem til at passe til én offentlig registrering; som udvider varetægtsfængslingen og hændelsens indvirkning.
Behold den gamle bekræftelsespost for den overlapning, som din legitime forsinket e-mail-sti har behov for, med forbehold for sikkerhedsovervejelser og udbyderens rotationsproces. En kompromitteret nøgle er en anden sag og kan kræve øjeblikkelig tilbagekaldelse på trods af leveringspåvirkning. Test begge tjenester uafhængigt efter ændringen, registrer deres ejere og reserver deres vælgernavne i inventaret. Accepttesten er to verificerbare, tilsigtede identiteter, ikke blot to grønne udbyderopsætningsskærme.
Løs en syntetisk anmodning om to tjenester
Antag, at lønningslisten i øjeblikket tegner med s=default og d=example.com, og marketing anmoder om det samme par med en anden nøgle. Opslagsejeren er identisk, så du må ikke overskrive den eller udgive den anden uafhængige nøgle ved siden af den. Hvis marketing understøtter s=marketing2026, skal du offentliggøre dens genererede nøgle på marketing2026._domainkey.example.com og konfigurere den samme vælger i sin underskriver. Test derefter løn/default og marketing/marketing2026 selvstændigt. Hvis det kun er en mulighed for signering af underdomæner, der understøttes, skal du gennemgå dens justering, før du ændrer d. Disse er planlægningstrin, ikke en testet udbyderprocedure.