Innan du godkänner DKIM delegering, be om den exakta DNS ändringen och den signeringsidentitet den kommer att möjliggöra. "Lägg till våra DNS -poster" är en för bred instruktion för en säkerhetsgranskning. A väljare CNAME, en NS-delegation och tillgång till hela DNS kontot ger olika former av kontroll.
Dra gränsen innan du godkänner den
Ett CNAME på ett väljarens ägarenamn styr upplösningen genom sitt mål. En leverantör som kontrollerar det målet kan ändra verifieringsdata som nås via aliaset. Det ger inte i sig tillstånd att redigera godtyckliga namn i din zon. En NS-delegation upprättar en zongräns och ger de delegerade auktoritativa servrarna ansvar för namn under den, med förbehåll för DNS hierarkin. Administrativ åtkomst för hela konton kan fortfarande vara mycket bredare. RFC 1034 §3.6.2 och RFC 1034 §4.2 beskriv dessa DNS mekanismer.
Skriv in ägarens namn och det berörda underträdet i godkännandet. En begäran om service1._domainkey.example.com skiljer sig från kontroll över hela _domainkey.example.com underträd. Ersätt inte en smal leverantörsstödd post med en bred delegering bara för att det verkar enklare att automatisera.
Skilj DNS omfång från signeringspåverkan
DKIM verifiering erhåller en nyckel med hjälp av signaturens väljare och signeringsdomän. Kontroll över en användbar väljares verifieringsdata, tillsammans med den matchande privata signeringsnyckeln, kan aktivera giltiga signaturer för den signeringsdomänen. Den uppenbara smalheten av ett DNS namn betyder därför inte att e-postförtroendekonsekvensen är försumbar.
Ett syntetiskt exempel illustrerar distinktionen. En leverantör får ett CNAME kl invoices._domainkey.example.com och driver den matchande signeraren för d=example.com. Dess DNS åtkomst är begränsad till aliasmålet, men den undertecknaren kan producera signaturer som tar ansvar från example.com. En väljare med namnet fakturor begränsar inte själv signaturer till fakturor, särskilda mottagare eller en godkänd kampanj. Applikations- och kontokontroller måste införa dessa gränser.
Om du använder en dedikerad sändande underdomän, bedöm tillämplig DMARC inriktning regler också. Subdomänseparation isolerar inte automatiskt avslappnad justering. RFC 9989 §4.4 beskriver hur autentiserade identifierare jämförs med Författardomänen; policyn och bestämning av organisationsdomänen.
Samla bevis som svarar på godkännandefrågan
Begär leverantörens aktuella instruktioner, genererade namn, kontoidentifierare, signeringsdomän som stöds och rotationsmodell. Verifiera vem som kan ändra dessa värden i leverantörskontot och om rollseparation är tillgänglig. Fråga om kontostängning och inaktuell DNS-hantering, utan att anta kontraktsgarantier som inte har tillhandahållits.
Bygg ett kompakt register: DNS ägare, posttyp, destination eller namnservrar, tjänsteägare, avsedd d= identitet, privilegierade leverantörsanvändare, förnyelsedatum och pensioneringsprocedur. För en föreslagen NS-delegering, inspektera hela det berörda underträdet för befintliga väljare innan du godkänner det. För en begäran om kontoåtkomst, utmana varför instruktioner per post eller en smalare stödd roll är otillräckliga.
Testa onboarding och planavslutning
Efter en godkänd ändring, jämför auktoritativa och rekursiva DNS observationer och skicka igenom den avsedda tjänsten. Inspektera en betrodd mottagares DKIM resultat och justering. Testet ska visa den beviljade identiteten, inte bara visa att någon signatur godkänns.
Vid uppsägning, stoppa applikationsåtkomst, ta bort föråldrade sändningsuppgifter och samordna väljarens pensionering med leveransköer och leverantörens process. Om leverantören misstänks för kompromiss, åberopa incidentrespons istället för att bevara en rutinöverlappning automatiskt. En tjänst som är markerad som inaktiv i inköpsregister kan fortfarande representera ett direkt tekniskt beroende.
Dokumentera det kvarvarande förtroendet explicit: vad leverantören kan skriva under, vem kan administrera det och hur snabbt organisationen kan ta bort beroendet. Den posten gör senare förnyelser en granskning av faktisk auktoritet snarare än en upprepning av den ursprungliga DNS biljetten.
Jämför tre hypotetiska godkännandeförfrågningar
Använd omfattningen och konsekvensen tillsammans:
- En väljare CNAME : granska dess exakta ägare och mål, avsedda d identitets- och leverantörskontokontroller. Den ger inte åtkomst till godtycklig zonredigering, men dess nyckelmappning kan möjliggöra signering för den identiteten.
- NS-delegering under _domainkey.example.com : inventera väljarna under den delegerade zonen och vem som kontrollerar dess auktoritativa servrar. Befintliga eller framtida väljare där kan påverkas, med förbehåll för ytterligare zonavskärningar.
- Fullständig åtkomst till DNS konto: kräver ett uttryckligt behov och inspektera kontots faktiska behörigheter. Det kan nå orelaterade post- och webbposter; detta motsvarar inte att publicera ett väljaralias.
Dessa är granskningsscenarier, inte auktoriseringar eller ändringar som gjorts i en verklig zon. Om den exakta omfattningen eller ägandet är okänt, lös detta gap innan godkännande.
Relaterad läsning
DKIM TXT och CNAME -publicering: följ leverantörens nyckelhanteringsmodell · Återkalla en DKIM nyckel och särskilj återkallelse från en saknad DNS post.