ای میل کی تصدیق میں DKIM (DomainKeys Identified Mail) ایک بنیادی ستون کی حیثیت رکھتا ہے۔ جب کوئی ای میل سرور پیغام بھیجتا ہے، تو وہ ای میل کے ہیڈر میں ایک ڈیجیٹل دستخط شامل کرتا ہے۔ وصول کنندہ سرور بھیجنے والے ڈومین کے DNS ریکارڈز سے پبلک کی (Public Key) حاصل کر کے اس دستخط کی تصدیق کرتا ہے۔ اس عمل کو درست طریقے سے کام کرنے کے لیے، DNS میں موجود DKIM TXT ریکارڈ کا بالکل درست فارمیٹ میں ہونا لازمی ہے۔
"DKIM ریکارڈ چیکر" ایک ایسا مقامی ٹول ہے جو آپ کے پیسٹ کردہ DKIM TXT ریکارڈ کا تفصیلی تجزیہ کرتا ہے۔ یہ ریکارڈ کے مختلف اجزاء جیسے کہ ورژن، کلید کی قسم، پبلک کی، اور سروسز کو الگ الگ کر کے دکھاتا ہے اور فارمیٹنگ کی ممکنہ غلطیوں کی نشاندہی کرتا ہے۔
مقامی براؤزر پروسیسنگ اور رازداری
اس ٹول کی سب سے اہم خصوصیت یہ ہے کہ آپ کا DKIM ریکارڈ آپ کے براؤزر میں رہتا ہے۔ BroBroGo اسے اپلوڈ یا محفوظ نہیں کرتا۔ یہ ایک مقامی ریکارڈ-ٹیکسٹ چیک ہے۔ چونکہ یہ ٹول انٹرنیٹ پر کوئی ڈیٹا منتقل نہیں کرتا، اس لیے آپ بغیر کسی ہچکچاہٹ کے اپنے ریکارڈ کا تجزیہ کر سکتے ہیں۔
یہ ٹول براہ راست DNS سے کوئی سوال نہیں کرتا اور نہ ہی دستخط شدہ ای میل کی تصدیق کرتا ہے، لہذا نتیجہ کو ترسیل کے ثبوت کے بجائے ایک کنفیگریشن جائزہ کے طور پر استعمال کریں۔
ان پٹ کی خصوصیات اور فارمیٹنگ کے اصول
ٹول میں تجزیہ شروع کرنے کے لیے آپ کو DKIM TXT قدر فراہم کرنی ہوتی ہے۔ ان پٹ فیلڈ میں ایسی ٹیگ فہرست پیسٹ کریں جیسے v=DKIM1; k=rsa; p=…۔
ان پٹ کے حوالے سے درج ذیل تکنیکی اصول لاگو ہوتے ہیں:
- حجم کی حد: ان پٹ کی حد زیادہ سے زیادہ 20,000 کریکٹرز تک محدود ہے۔
- کوٹڈ ٹیکسٹ اور بریکٹس: زون فائل (Zone File) سے کاپی کیے گئے ریکارڈز جن میں ڈبل کوٹس (Quotes) یا بریکٹس (Parentheses) شامل ہوں، انہیں یہ ٹول خودکار طور پر قبول کرتا ہے اور ان حصوں کو آپس میں جوڑ دیتا ہے۔
- خالی ان پٹ: اگر ان پٹ فیلڈ مکمل طور پر خالی ہو تو ٹول "پہلے DKIM ریکارڈ پیسٹ کریں۔" کا ایرر پیغام دکھاتا ہے۔
ڈی این ایس ٹیکسٹ ریکارڈ کی حدیں اور چنکس (Chunks)
ڈی این ایس (DNS) پروٹوکول کے تحت ایک TXT ریکارڈ کے اندر موجود کریکٹر سٹرنگز کے لیے کچھ تکنیکی حدود متعین ہیں:
- 255 بائٹ کی حد: ایک DNS TXT ریکارڈ کئی کریکٹر سٹرنگز پر مشتمل ہو سکتا ہے، ہر سٹرنگ 255 بائٹس تک محدود ہوتی ہے۔ اگر کوئی ایک حصہ اس حد سے تجاوز کر جائے تو ٹول "TXT حصہ
‹detail›ایک DNS کریکٹر سٹرنگ کے لیے 255 بائٹ کی حد سے تجاوز کر گیا۔" کا انتباہ جاری کرتا ہے۔ - حصوں کو جوڑنا: جب طویل پبلک کیز کو متعدد کوٹڈ حصوں میں تقسیم کیا جاتا ہے، تو یہ ٹول انہیں یکجا کرتا ہے اور رپورٹ کرتا ہے: "ریکارڈ چیک کرنے سے پہلے
‹detail›اقتباس شدہ TXT حصے جوڑے گئے۔"۔ - خراب فارمیٹ: اگر کوٹیشن مارکس درست طریقے سے بند نہ ہوں یا ان کے باہر فالتو متن موجود ہو تو "اقتباس شدہ TXT پیشکش خراب ہے۔ تمام حصے اقتباس میں رکھیں اور اقتباس کے باہر کا متن ہٹا دیں۔" کا ایرر ظاہر ہوتا ہے۔
ڈی کے آئی ایم ٹیگز اور کلیدی اجزاء کے اصول
ایک معیاری DKIM ریکارڈ مختلف ٹیگز (Tags) پر مشتمل ہوتا ہے، جن کے لیے ٹول سخت قوانین کے تحت جانچ پڑتال کرتا ہے:
| ٹیگ | تفصیل اور مطلوبہ قوانین |
|---|---|
v |
ورژن ٹیگ۔ جب v=DKIM1 ٹیگ موجود ہو تو یہ سب سے پہلا ٹیگ ہونا چاہیے۔ یہ بالکل DKIM1 ہونا چاہیے، کوئی اور قدر قابل قبول نہیں ہے۔ |
k |
کلید کی قسم (Key Type)۔ یہ ٹول صرف rsa اور ed25519 کو سپورٹ کرتا ہے۔ |
p |
پبلک کی (Public Key)۔ یہ ایک لازمی ٹیگ ہے۔ اگر یہ خالی ہو تو یہ منسوخ شدہ کلید کو ظاہر کرتا ہے۔ |
s |
سروس کی قسم۔ اس کی قیمت میں لازمی طور پر email یا * شامل ہونا چاہیے۔ |
h |
ہیش الگورتھم۔ موجودہ دور میں اس ٹیگ کو لازمی طور پر sha256 کی اجازت دینی چاہیے۔ |
اگر ریکارڈ میں کوئی ایسا ٹیگ موجود ہو جو معیاری تعریف میں شامل نہ ہو تو اسے "نامعلوم ‹tag› ٹیگ برقرار رکھا گیا ہے لیکن اس کی تشریح نہیں کی گئی۔" کے طور پر رپورٹ کیا جاتا ہے۔
کلیدوں کی اقسام، سائز اور ہیش الگورتھم کے اصول
سیکیورٹی کو برقرار رکھنے کے لیے پبلک کیز کے سائز اور ہیش الگورتھم کا درست ہونا لازمی ہے۔ یہ ٹول ان پیرامیٹرز کو درج ذیل قوانین کے تحت پرکھتا ہے:
- RSA کلید کا سائز: 1024 بٹس سے کم کی RSA کلیدوں کو غیر معتبر مانا جاتا ہے اور ٹول "RSA کلید
‹detail›بٹس کی ہے۔ DKIM کے لیے کم از کم 1024 بٹس ضروری ہیں۔" کا ایرر دیتا ہے۔ اگر کلید کا سائز 1024 بٹس یا اس سے زیادہ ہو لیکن 2048 بٹس سے کم ہو، تو وارننگ ملتی ہے: "RSA کلید‹detail›بٹس کی ہے۔ 2048 بٹس یا زیادہ کی سفارش کی جاتی ہے۔"۔ - Ed25519 کلید: یہ جدید کلید بالکل 32 بائٹس پر مشتمل ہونی چاہیے۔ اگر ڈی کوڈنگ کے بعد سائز مختلف ہو تو "Ed25519 کلید 32 کی بجائے
‹detail›بائٹس میں ڈی کوڈ ہوتی ہے۔" کا ایرر سامنے آتا ہے۔ - منسوخ شدہ کلید: اگر
pٹیگ کی قیمت خالی رکھی جائے تو ٹول اسے "p کی قیمت خالی ہے، جو منسوخ شدہ DKIM کلید شائع کرتی ہے۔" کے طور پر شناخت کرتا ہے۔ - متروک ہیش: پرانا ہیش الگورتھم
sha1اب ای میل دستخطوں کے لیے غیر محفوظ ہو چکا ہے۔ اگر ریکارڈ میں اس کا استعمال پایا جائے تو ٹول واضح کرتا ہے کہ "sha1 DKIM دستخطوں کے لیے پرانا ہو چکا ہے اور استعمال نہیں کیا جانا چاہیے۔"۔
عام کنفیگریشن غلطیاں اور انتباہات
تجزیہ کے دوران ٹول ریکارڈ میں موجود نحوی (Syntactical) غلطیوں کو بھی پکڑتا ہے:
- ڈپلیکیٹ ٹیگز: اگر کوئی ٹیگ ایک سے زیادہ بار استعمال ہوا ہو تو ایرر ملتا ہے: "
‹tag›ٹیگ ایک سے زیادہ بار ظاہر ہوتا ہے۔"۔ - مساوات کا نشان غائب ہونا: ہر ٹیگ اور اس کی قدر کے درمیان
=ہونا ضروری ہے، ورنہ "فیلڈ “‹tag›” میں مساوات کا نشان غائب ہے۔" کا پیغام ظاہر ہوتا ہے۔ - خراب ٹیگ نام: اگر ٹیگ کا نام ہی غلط لکھا گیا ہو تو "ٹیگ کا نام “
‹tag›” خراب ہے۔" کا ایرر ملتا ہے۔ - غائب پبلک کی: اگر ریکارڈ میں
pٹیگ ہی موجود نہ ہو تو "ضروری p پبلک کی ٹیگ غائب ہے۔" کا نوٹس جاری کیا جاتا ہے۔
جب تجزیہ مکمل ہو جاتا ہے تو ٹول خلاصہ پیش کرتا ہے جیسے: "چیک کیے گئے ‹fields› فیلڈز: ‹errors› ایررز اور ‹warnings› وارننگز۔"۔ اگر ریکارڈ بالکل درست ہو تو "پیسٹ کی گئی قدر میں کوئی ریکارڈ کی خرابی یا کلید کی وارننگ نہیں ملی۔" کا پیغام ظاہر ہوتا ہے۔
اکثر پوچھے جانے والے سوالات (FAQ)
طویل DKIM ریکارڈز کو کوٹ کی گئی سٹرنگز میں کیوں تقسیم کیا جاتا ہے؟
ایک DNS TXT ریکارڈ کئی کریکٹر سٹرنگز پر مشتمل ہو سکتا ہے، ہر سٹرنگ 255 بائٹس تک محدود ہوتی ہے۔ DNS سٹرنگز کو ترتیب سے جوڑتا ہے، اس لیے تمام حصے ایک ہی TXT ریکارڈ میں رہنے چاہئیں۔
یہ چیکر کون سے DKIM کی قسم کی چابیاں پہچانتا ہے؟
یہ RSA اور Ed25519 پبلک کیز کو پہچانتا ہے، ان کے Base64 فارم کو چیک کرتا ہے، اور 1024 بٹس سے کم کیز کو غیر معتبر اور 2048 بٹس سے کم کیز کو سفارش کردہ سے کمزور رپورٹ کرتا ہے۔
کیا صاف نتیجہ یہ ثابت کرتا ہے کہ DKIM کام کر رہا ہے؟
نہیں۔ یہ صفحہ صرف آپ کے پیسٹ کیے گئے ریکارڈ ٹیکسٹ کو چیک کرتا ہے۔ یہ DNS کو استفسار نہیں کرتا، کسی میسج کے دستخط کو توثیق نہیں کرتا، سیلیکٹر نام کی تصدیق نہیں کرتا یا یہ ثابت نہیں کرتا کہ میل وصول کرنے والے ریکارڈ کو بازیافت کر سکتے ہیں۔