DKIM (DomainKeys Identified Mail) — email domeniga xabarning tanlangan header va body qismlariga raqamli imzo qo‘yish imkonini beradigan autentifikatsiya mexanizmi. Qabul qiluvchi server public key’ni DNS’dan olib imzoni tekshiradi. Muvaffaqiyatli DKIM xabar imzolanganidan keyin himoyalangan qismlar o‘zgarmaganini va imzo domen private key’iga ega tizim tomonidan yaratilganini ko‘rsatadi.
Imzo yaratish
Sending mail system body va tanlangan headerlarni canonicalization qoidasi bo‘yicha normallashtiradi, hash hisoblaydi va private key bilan imzolaydi. Natija DKIM-Signature headeriga yoziladi. Unda domen, selector, algorithm, signed headerlar va signature mavjud.
Selector bir domen uchun bir nechta key ishlatishga imkon beradi. DNS nomi odatda selector._domainkey.example.uz shaklida bo‘ladi. TXT record public key va parametrlarni beradi.
Tekshirish
Receiving server signature’dagi domen va selectorni oladi, DNS’dan public key topadi, canonical body/header hashni qayta hisoblaydi va signature’ni tekshiradi. Natija pass, fail, neutral, temperror yoki permerror kabi statusga aylanishi mumkin.
| Natija | Odatdagi mazmun |
|---|---|
| pass | Imzo matematik va content jihatdan mos |
| fail | Imzo yoki hash mos emas |
| temperror | DNS yoki vaqtinchalik tekshiruv xatosi |
| permerror | Noto‘g‘ri record yoki doimiy format xatosi |
| none | DKIM imzosi yo‘q |
Policy engine bu natijani SPF, DMARC va reputation bilan birga baholaydi.
Canonicalization
Email relay ayrim whitespace yoki header foldingni o‘zgartirishi mumkin. Simple canonicalization qattiqroq, relaxed esa ayrim semantik bo‘lmagan format farqlarini normallashtiradi. Body canonicalization va header canonicalization alohida tanlanadi.
Haddan tashqari yumshoq normalization mazmun o‘zgarishini yashirmasligi kerak. DKIM standartida aynan qaysi transformatsiya ruxsat etilishi belgilangan.
Signed headerlar
Imzo ro‘yxati qaysi headerlar himoyalanganini ko‘rsatadi. From odatda majburiy imzolanadi. Subject, Date, Message-ID, MIME headerlari ham qo‘shilishi mumkin. Relay yangi Received header qo‘shishi mumkinligi sabab u oldindan imzolanmaydi.
Header bir necha marta takrorlanishi mumkin. Imzolovchi va verifier ularning tartibini standart qoidasi bo‘yicha ishlatadi. Noto‘g‘ri implementatsiya header injection xavfini keltirishi mumkin.
Body length
DKIM body length parametri faqat dastlabki baytlarni imzolashga imkon beradi. Mailing list footer qo‘shishi uchun yaratilgan bu imkoniyat hujumchiga imzolangan qismdan keyin mazmun qo‘shish imkonini ham beradi. To‘liq body’ni imzolash odatda kuchliroq.
Mailing list subject yoki body’ni o‘zgartirsa original imzo buzilishi mumkin. List o‘z DKIM imzosini qo‘yishi, ARC esa oraliq authentication natijasini saqlashi mumkin.
Key rotation
Yangi selector va key DNS’da e’lon qilinadi, keyin sending system yangi private key bilan imzolaydi. Eski xabarlar va DNS cache uchun eski public key overlap davrida saqlanadi. So‘ng eski selector olib tashlanadi.
Private key mail signer’da minimal access bilan saqlanadi. Bir xil keyni ko‘p mustaqil vendor bilan bo‘lishish blast radius’ni oshiradi; har platformaga alohida selector berilishi mumkin.
DMARC alignment
DKIM pass bo‘lishi o‘zi header From domeni bilan bir xil domen ishlatilganini anglatmaydi. DMARC alignment imzo domenini foydalanuvchiga ko‘rinadigan From domeni bilan relaxed yoki strict qoidada solishtiradi. Forwardingda SPF buzilsa aligned DKIM DMARC’ni o‘tkazishi mumkin.
Cheklovlar
DKIM xabar rost yoki xavfsiz ekanini isbotlamaydi. Buzilgan account yoki zararli domen o‘z phishing xabarini to‘g‘ri imzolashi mumkin. Signature key’ga ega tizimni ko‘rsatadi, individual inson identity’sini emas.
Bog‘liq tushunchalar
Email authentication, SPF, DMARC, ARC, DNS TXT record, Digital signature, Mail transfer agent