SPF, DKIM va DMARC: pochta domenini tekshirish

SPF, DKIM va DMARC o‘zaro bog‘liq, ammo turli vazifalarni bajaradi. SPF konvertning texnik domeni uchun xat yuborishga ruxsat etilgan tizimlarni sanaydi. DKIM tanlangan sarlavhalar va xat mazmuniga kriptografik imzo qo‘shadi. DMARC bu tekshiruvlar natijasini foydalanuvchi From maydonida ko‘radigan domen bilan bog‘laydi va autentifikatsiyadan o‘tmagan xabarlarni qayta ishlash siyosatini e’lon qiladi.

Bu mexanizmlarning hech biri yakka holda xat foydali yoki kerakli ekanini isbotlamaydi. Muvaffaqiyatli autentifikatsiya qabul qiluvchi tizim xabarning domen bilan ko‘rsatilgan aloqasini tekshira olganini bildiradi. Xatni “Kiruvchi xatlar”, “Spam” papkasiga joylash yoki rad etish qarorini qabul qiluvchi qabul qiladi; bunda obro‘, shikoyatlar, hajm, mazmun va mahalliy qoidalar ham hisobga olinadi.

SPF jo‘natish yo‘lini tekshiradi

SPF DNS’da TXT yozuvi sifatida e’lon qilinadi. U SMTP’dagi MAIL FROM buyrug‘ida ma’lum domen bilan xat yuborishi mumkin bo‘lgan IP manzillar yoki tashqi xizmatlarni tavsiflaydi. Bu manzil envelope-from yoki qaytarish yo‘li deb ham ataladi. U pochta dasturidagi ko‘rinadigan From manzilidan farq qilishi mumkin — SPF natijasini noto‘g‘ri talqin qilish holatlarining ko‘pi shundan kelib chiqadi.

Soddalashtirilgan misol:

example.uz.  IN  TXT  "v=spf1 ip4:192.0.2.10 -all"

Bu yozuv ko‘rsatilgan IPv4 manzilga ruxsat beradi, boshqa manbalar uchun esa SPF fail natijasini qaytaradi. Natija bilan nima qilishni qabul qiluvchi tizim belgilaydi. Bu nusxalash uchun qolip emas, faqat sintaksis misoli: haqiqiy yozuv domenning barcha qonuniy jo‘natuvchilarini — asosiy SMTP serveri, CRM, bildirishnoma xizmati, jo‘natmalar va boshqa tizimlarni hisobga olishi kerak.

Bitta domen nomi uchun bitta SPF siyosati bo‘lishi kerak. v=spf1 bilan boshlanadigan ikkita alohida TXT yozuv birlashmaydi va tekshiruv xatosiga sabab bo‘ladi. Manbalar ko‘p bo‘lsa, ular yagona siyosatga birlashtiriladi. Standart include, a, mx, exists va redirect kabi mexanizmlarni baholashda yuzaga keladigan DNS so‘rovlari sonini ham cheklaydi. Tashqi ulanishlarning haddan tashqari uzun zanjiri, har bir xizmat alohida to‘g‘ri ko‘rsatilgan bo‘lsa ham, permerror bilan tugashi mumkin.

SPF odatiy qayta yo‘naltirishga sezgir. Qayta yo‘naltiruvchi server boshlang‘ich envelope-from’ni saqlab qolishi, ammo xabarni dastlabki domen siyosatida yo‘q o‘z IP manzilidan yuborishi mumkin. Shu sababli SPF DKIM o‘rnini bosmaydi, qayta yo‘naltirish infratuzilmasiga esa ba’zan Sender Rewriting Scheme kerak bo‘ladi. Asosiysi — faqat From manziliga qarab taxmin qilish emas, yakuniy Authentication-Results sarlavhasini tekshirish.

DKIM xabar imzosini tasdiqlaydi

DKIM’da chiquvchi server tanlangan sarlavhalar va xat tanasining xeshini hisoblaydi, uni yopiq kalit bilan imzolaydi va DKIM-Signature sarlavhasini qo‘shadi. Qabul qiluvchi undagi d= domeni va s= selektorini topadi, so‘ng quyidagi ko‘rinishdagi nomdan ochiq kalitni so‘raydi:

selector1._domainkey.example.uz

Yopiq kalit jo‘natuvchi tizimda qoladi. DNS’da faqat ochiq qismi e’lon qilinadi. Tekshiruv mos kelsa, qabul qiluvchi imzolangan qismlar imzolangandan keyin yashirincha o‘zgartirilmaganini va jo‘natuvchi tegishli yopiq kalitga ega bo‘lganini biladi.

Selektorlar barcha jo‘natishni bir vaqtda to‘xtatmasdan kalitlarni almashtirishga imkon beradi. Yangi kalit yangi selektorda e’lon qilinadi, imzolash unga o‘tkaziladi, haqiqiy oqim tekshiriladi va faqat o‘tish davridan so‘ng eski yozuv o‘chiriladi. Bu bitta kalitdan muddatsiz foydalanish yoki DNS keshi hisobga olinmasdan ayni nomdagi qiymatni almashtirishdan xavfsizroq.

DKIM ham “spam emas” muhri emas. Qonuniy ommaviy jo‘natma, keraksiz xat yoki buzib kirilgan hisob imzosi birdek muvaffaqiyatli tekshirilishi mumkin. Bundan tashqari, qayta yo‘naltirish tizimlari va pochta shlyuzlari ba’zan mavzu, xat tanasi yoki ilovalarni o‘zgartiradi. Imzolangan qism o‘zgarsa, tekshiruv o‘tmasligi mumkin. Shu sababli DMARC’da ikki yo‘ldan — SPF yoki DKIM’dan — kamida bittasining mos ravishda muvaffaqiyatli o‘tishi yetarli.

DMARC tekshiruvni ko‘rinadigan From bilan bog‘laydi

Foydalanuvchi odatda From maydonidagi domenga ishonadi. DMARC bu domen SPF’dan muvaffaqiyatli o‘tgan domen yoki amaldagi DKIM imzosi domeni bilan mosligini tekshiradi. Bu alignment, ya’ni domenlar mosligi deb ataladi.

Relaxed rejimida tashkiliy jihatdan bog‘liq subdomenlarga ruxsat beriladi. Strict rejimida domenlar aniqroq mos kelishi kerak. Kamida bitta mexanizm — SPF yoki DKIM — muvaffaqiyatli o‘tib, domen bilan mos kelsa, DMARC o‘tgan hisoblanadi. Demak, SPF muvaffaqiyatsiz bo‘lsa ham mos DKIM imzosi saqlansa xabar DMARC’dan o‘tishi mumkin va aksincha.

Siyosat _dmarc.example.uz TXT yozuvida e’lon qilinadi:

_dmarc.example.uz.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.uz"

p=none faqat DMARC siyosati sababli karantin yoki rad etishni so‘ramaydi. Umumlashtirilgan hisobot manzili alohida rua parametri bilan belgilanadi. p=quarantine tekshiruvdan o‘tolmagan xatlarni shubhali deb ko‘rishni, p=reject esa ularni rad etishni so‘raydi. “So‘raydi” so‘zi muhim: yakuniy qarorni qabul qiluvchi pochta tizimi o‘z mahalliy siyosati doirasida qabul qiladi.

rua manzili umumlashtirilgan hisobotlar uchun ishlatiladi. Ular domen nomidan xat yuboradigan manbalar, SPF/DKIM natijalari va nomuvofiqlik sabablarini ko‘rsatadi. Hisobot manzili uchun quti yoki maxsus qayta ishlovchi tayyorlash kerak: XML fayllarni qo‘lda o‘qish noqulay, hajmi sezilarli bo‘lishi mumkin va hisobotlarning o‘zida pochta oqimiga oid texnik metama’lumotlar bor.

Nega uchala mexanizm ham kerak

DMARC’siz SPF foydalanuvchi ko‘rmasligi mumkin bo‘lgan konvertning texnik manzilini tekshiradi. DMARC’siz DKIM imzo domenini tasdiqlaydi, lekin u ko‘rinadigan From bilan mos bo‘lishi shart emas. DMARC bu aloqani o‘rnatadi, ammo SPF va DKIM natijalariga tayanadi va ularni o‘zi yaratmaydi.

Amaliy modelni quyidagicha tasavvur qilish qulay:

Bu yozuvlar chiquvchi pochta autentifikatsiyasiga tegishli. MX boshqa vazifani bajaradi — kiruvchi xatlar serverini ko‘rsatadi. Qabul qilish yo‘nalishini o‘zgartirayotgan bo‘lsangiz, Pochta uchun MX yozuvi: xatlarni kerakli serverga yo‘naltirish maqolasidan boshlang.

Xavfsiz joriy etish tartibi

Avval jo‘natuvchilar xaritasini tuzing. Unga xodimlargina emas, sayt, parol tiklash tizimi, hisoblar, CRM, qo‘llab-quvvatlash, monitoring va jo‘natma xizmati ham kiradi. Har bir manba qaysi envelope-from’dan foydalanishi, DKIM’ni qaysi domen bilan imzolashi va provayderning umumiy domeni o‘rniga o‘z domenini sozlash mumkinligini aniqlang.

Keyin quyidagi bosqichlarda ishlang:

1. Barcha tasdiqlangan manbalar uchun bitta SPF siyosatini tuzing va DNS so‘rovlari sonini tekshiring.
2. Har bir xizmatda DKIM’ni yoqing, yopiq kalitlarni DNS va ochiq repozitoriydan tashqarida saqlang.
3. Turli tashqi pochta tizimlaridagi bir nechta haqiqiy xatni Authentication-Results bo‘yicha tekshiring.
4. Kuzatuv siyosati va ishlaydigan umumlashtirilgan hisobot manzili bilan DMARC’ni e’lon qiling.
5. Unutilgan qonuniy manbalarni toping, domen mosligini tuzating va ruxsatsiz jo‘natishni to‘xtating.
6. Faqat yetarli kuzatuv davridan keyin quarantine yoki rejectga o‘tishni muhokama qiling.
7. Har bir o‘zgarishdan so‘ng faqat DNS’dagi TXT mavjudligini emas, haqiqiy xatlarni yana tekshiring.

Inventarizatsiya to‘liq bo‘lmasa, darhol qat’iy siyosatga o‘tish qonuniy bildirishnomalarni to‘sib qo‘yishi mumkin. Boshqa chekka holat — yillar davomida p=none qoldirib, domenni himoyalangan deb hisoblash. Kuzatuv siyosati ma’lumot beradi; manbalar tuzatilib, qat’iyroq rejim ongli ravishda yoqilgach, soxtalashtirishdan himoya kuchayadi.

Mailcore mutaxassisi haqiqiy jo‘natish sxemasiga mos MX, SPF, DKIM va DMARC’ni tayyorlab tekshiradi. Mijoz sayt, CRM va boshqa manbalarni bildiradi, Mailcore esa almashtirish va siyosatni qat’iylashtirishdan oldin ularni hisobga oladi. Bosqichma-bosqich ulanish mazmuni Mailcore domenni qanday ulaydi: arizadan birinchi xatgacha maqolasida bor.

Xat sarlavhalarida nimaga qarash kerak

Tashqi qutiga sinov xati yuboring va xatning asl nusxasi yoki texnik sarlavhalarini oching. Authentication-Results’ni topib, alohida tekshiring:

• SPF natijasi va u tegishli bo‘lgan domen;
• DKIM natijasi, d= domeni va ishlatilgan selektor;
• DMARC natijasi va From sarlavhasi domeni;
• haqiqiy chiquvchi server kutilgan server bilan mosligi;
• xatni o‘zgartirgan oraliq shlyuz yo‘qligi.

Uchala mexanizmdagi pass natijasi yetkazilish uchun muhim texnik asos yaratadi. Xat rad etilsa yoki qabul qiluvchi qo‘shimcha filtr qo‘llasa, tashxis uchun SMTP javob kodi, manba obro‘si, oqim xususiyati va mazmun kerak bo‘ladi. Ketma-ket tahlil Nega xatlar spamga tushadi va nimalarni tekshirish kerak maqolasida berilgan.

Konfiguratsiyadagi ko‘p uchraydigan xatolar

SPF’dagi eng ko‘zga tashlanadigan xato — bitta nom uchun bir nechta siyosat. Keyingi o‘rinlarda eskirgan IP manzillar, unutilgan include va DNS tekshiruvlari limitidan oshish turadi. DKIM’da selektorlar adashtiriladi, panellar o‘rtasida ko‘chirishda uzun TXT qiymati kesilib qoladi yoki kalit bir domenda e’lon qilinib, boshqasi bilan imzolanadi. DMARC’da ishlamaydigan hisobot manzili, muddatidan oldingi reject va tashqi xizmatlarda domen mosligining yo‘qligi odatiy muammolardir.

O‘z sxemangizni tushunmasdan boshqa yo‘riqnomadagi yozuvlarni ko‘chirish ham xavfli. SPF aynan sizning manbalaringizni tasvirlashi, DKIM kalitini aynan sizning jo‘natuvchi tizimingiz berishi, DMARC siyosati esa sizning oqimingiz kuzatilgach tanlanishi kerak. Vakolatli DNS’ni tekshiring, TTL’ni hisobga oling va har bir o‘zgarishni hujjatlashtiring — shunda nosozlik sababini tiklash mumkin bo‘ladi, u jumboqqa aylanmaydi.

Manbalar

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• Google: Email sender guidelines
• Microsoft Learn: Email authentication in Microsoft 365
• Cloudflare: Email security DNS records