دس سیکنڈ میں کسی کمپنی کی DMARC پالیسی کو کیسے پڑھیں (اور یہ آپ کو کیا نہیں بتاتی)

ایک DNS تلاش آپ کو بتاتا ہے کہ کسی کمپنی نے دنیا کے میل سرورز سے کیا کہا ہے کہ اس کے نام میں بھیجے گئے جعلی میل کے ساتھ کیا کریں۔ ریکارڈ عوام کے لیے ہے، اور کمانڈ ایک لائن ہے: dig +short TXT _dmarc.example.com۔ جو واپس آتا ہے وہ سیٹنگز کی ایک مختصر سٹرنگ ہے، اور اس کے اندر ایک ہدایت ہے — p=none، p=quarantine یا p=reject — جو ڈومین مالک کی ترجیح بیان کرتی ہے جب وہ پیغام اس ڈومین کو استعمال کرتے ہوئے تصدیق میں ناکام ہو۔

موجودہ تفصیل، RFC 9989، مئی 2026 میں IETF Standards Track دستاویز کے طور پر شائع ہوا، پرانے RFC 7489 کی جگہ لے گیا۔ یہ تینوں اقدار کو تقریباً مختصر طریقے سے بیان کرتا ہے:

• p=none — "ڈومین مالک کوئی ترجیح کا اظہار نہیں کرتا۔"
• p=quarantine — "ڈومین مالک اس طرح کے میل کو مشکوک سمجھتا ہے۔ یہ ممکن ہے میل درست ہو، اگرچہ ناکامی ایک اہم تشویش پیدا کرتی ہے۔"
• p=reject — "ڈومین مالک تمام ایسی ناکامیوں کو ایک واضح اشارہ سمجھتا ہے کہ ڈومین نام کا استعمال درست نہیں ہے۔"

ان الفاظ کو دوبارہ پڑھیں، کیونکہ یہ DMARC کی سب سے زیادہ وضاحتوں سے کمزور ہیں۔ ایک پالیسی ایک ترجیح ہے، بھیجنے والے کی طرف سے شائع کی گئی ہے تاکہ موصولین غور کریں۔ یہ ایک ہدایت نہیں ہے جو موصول کنندہ کو انجام دینی ہے۔ RFC 9989 ایک جملے میں کہتا ہے: "کسی بھی پیغام کو حتمی طور پر سنبھالنا ہمیشہ مقامی پالیسی کا معاملہ ہے اور یہ میل موصول کنندہ کے اختیار میں ہے۔" یہی حصہ دونوں حصے کے نتیجے میں شامل کرتا ہے — موصولین "ایک پیغام کو مسترد یا قرنطینہ کر سکتے ہیں یہاں تک کہ اگر یہ DMARC تصدیق چیک سے گزرے"، اور وہ "صرف DMARC ناکامی کی وجہ سے پیغامات کو مسترد نہیں کریں گے"، بالکل یہی وجہ ہے کہ جائز میل جو DMARC وضاحت نہیں کر سکتے ہیں، اور میلنگ لسٹیں، تباہ نہ ہوں۔

تو p=none اصل میں کیا اقرار کرتا ہے؟ عام طور پر اس پر الزام لگایا جاتا ہے اس سے کم۔ تفصیل کی شرائط میں یہ نگرانی موڈ ہے: ڈومین مالک مجموعی رپورٹس جمع کر رہا ہے اور "DMARC تصدیق میں ناکام پیغامات کے لیے کوئی سنبھالنے کی ترجیح نہیں بتاتا"، جب کہ موصول کنندہ جو DMARC مقرر کرتے ہیں "اب بھی" ڈومین کے استعمال کی تصدیق کر سکتے ہیں۔ یہ موصول کنندہ کے آخر میں کچھ بھی بند نہیں کرتا۔ آپ کے فراہم کنندہ کی اسپیم فلٹرنگ، شہرت کی سکورنگ، URL چیکس اور منسلکات کا تجزیہ علیحدہ میکانزم ہے جو بھیجنے والے نے کیا شائع کیا اس سے قطع نظر چلتا ہے۔ p=none ڈومین میں آنے والا جعلی پیغام ریکارڈ کے ذریعے آپ کے ان باکس میں فروغ نہیں دیا جاتا؛ یہ صرف موصول کنندہ کو بغیر بیان شدہ ترجیح کے دیا جاتا ہے، اور موصول کنندہ فیصلہ کرتا ہے۔

غلط فہمی کا دوسرا حصہ دوسری طرف چلتا ہے۔ DMARC فشنگ ای میل کے خطرناک حصے کو نہیں پڑھتا۔ اس کی اپنی تفصیل درج کرتی ہے کہ کیا جان بوجھ کر اسکوپ سے باہر ہے، اور "مواد کا تجزیہ" ان الفاظ میں اس فہرست میں ہے۔ یہ بھی کہتا ہے کہ DMARC "بصری طور پر ملتے جلتے ڈومین ناموں یا RFC5322.From انسان سے قابلِ فہم ڈسپلے نام کی بدعملی سے نمٹا نہیں ہے" — دونوں ترکیبیں جو زیادہ تر برانڈ نقالی میل لے کر آتی ہیں۔ اور پاس کی قیمت پر: "اپنے آپ میں DMARC پاس یہ گیرنٹی نہیں دیتا کہ وصول کنندہ کے ان باکس میں ڈیلیوری محفوظ یا مطلوبہ ہوگی۔" صحیح طریقے سے تصدیق شدہ پیغام کسی بھی ایک بار ڈومین سے DMARC صاف طریقے سے گزرتا ہے۔ DMARC جواب دیتا ہے کہ From: ہیڈر میں ڈومین کا استعمال کرنے کے لیے کو اختیار دیا گیا۔ اور کچھ نہیں۔

یہ وہ جگہ ہے جہاں 2024 بلک بھیجنے والے کے قوانین باقاعدگی سے غلط رپورٹ کیے جاتے ہیں، اس مضمون کے پہلے ورژن سمیت۔ Google کی بھیجنے والے کی ہدایتیں Gmail اکاؤنٹس کو ایک دن میں 5,000 یا اس سے زیادہ پیغامات بھیجنے والوں کو "اپنے بھیجنے والے ڈومین کے لیے DMARC ای میل کی تصدیق سیٹ اپ کریں" کی ضرورت ہے، اور پھر کہتا ہے، ایک ہی سانس میں: "آپ کی DMARC نافاذی پالیسی کو none سیٹ کیا جا سکتا ہے۔" Yahoo کا اپنا Sender Hub، جس کو الگ سے پڑھا جانا چاہیے نہ کہ Google کی نقل کرنے کے لیے فرض کریں، ضرورت کو "کم از کم p=none کے ساتھ ایک درست DMARC پالیسی شائع کریں - DMARC لازمی طور پر پاس ہونا چاہیے" کے طور پر بیان کرتا ہے، اور کوئی عددی حجم کی سیما شائع نہیں کرتا۔ دونوں سیٹ ضروریات فروری 2024 سے موثر ہوئے۔ کوئی بھی کسی کو p=none سے ہٹاتا نہیں ہے۔ دونوں اصل میں تصدیق کو نافاذ کرتے ہیں جو لائن اپ ہو: Google کی ضرورت ہے کہ "بھیجنے والے کے From: ہیڈر میں ڈومین کو SPF ڈومین یا DKIM ڈومین کے ساتھ متحرک ہونا چاہیے،" اور Yahoo کہتا ہے کہ نرم متحرک قابلِ قبول ہے۔ سخت ہونا نہیں، متحرک ہونا گیٹ ہے۔

جو ڈومین نگرانی میں بیٹھے ہیں اس کی حقیقی وجہ چھوڑ دیتا ہے، اور یہ بزدلانہ کے بجائے عملی ہے۔ quarantine یا reject میں جانے کا مطلب ہے پہلے ہر خدمت تلاش کریں جو آپ کے نام میں میل بھیجتی ہے — تنخواہ، ٹکٹنگ، مارکیٹنگ، ایک سپورٹ ڈیسک کسی نے دستاویز نہیں کی — اور ہر ایک کو تصدیق کریں تاکہ یہ متحرک ہو۔ معیار خود ان خطروں کو تسلیم کرتا ہے جو یہ سست بناتے ہیں: تیسری پکش بھیجنے والے DMARC کی طرف سے نہ تو متعارف کرایا جاتا ہے اور نہ ہی خارج کیے جاتے ہیں، آگے بھیجنا اور میلنگ لسٹیں بھیجنے والے کی خرابی کے ذریعے متحرک توڑ سکتے ہیں، اور تفصیل موصولین کو بالکل ان ناکامی کے طریقوں کے لیے RFC 7960 پر اشارہ کرتا ہے۔ ایک تنظیم جو p=none شائع کرتی ہے اور اپنی رپورٹس پڑھتی ہے وہ تفصیل میں وضاحت کے ترتیب میں کام کر رہی ہے۔ ایک جو p=none شائع کرتی ہے اور رپورٹس کو نظر انداز کرتی ہے وہ نہیں ہے۔ باہر سے، ریکارڈ اکیلے آپ کو یہ نہیں بتا سکتے کہ آپ دونوں میں سے کون سے کو دیکھ رہے ہیں۔

تلاش کے لیے آپ کو ٹرمینل کی ضرورت نہیں۔ مفت تلاش کی چیزیں — dmarcian کا ڈومین چیکر، MXToolbox کا DMARC چیک — ریکارڈ حاصل کریں اور آپ کے لیے پالیسی پرنٹ کریں۔ یہ اپنے بینک، اپنے تنخواہ کے فراہم کنندہ، جس ایئرلائن پر آپ اڑتے ہیں کے لیے کریں۔ صرف جواب کو پڑھیں اس کے لیے کہ یہ کیا ہے: ڈومین کے مالک کی طرف سے ایک نیت کا بیان، ایک مقامی فیصلہ میں بہت سی چیزوں میں سے ایک آپ کے میل فراہم کنندہ اپنے آپ کے ذریعے، جعل کی ایک خاص قسم کے بارے میں۔ یہ دس سیکنڈ میں پڑھنے کے قابلِ ایک حقیقی طور پر مفید چیز ہے۔ یہ کوئی فیصلہ نہیں ہے کہ اگلا پیغام جو اس برانڈ کے ہونے کا دعویٰ کرتا ہے محفوظ ہے یا نہیں۔

درستگی، 20 اکتوبر 2026۔ اس مضمون کے ایک پہلے ورژن نے p=none کو ان باکس میں جعل کو فراہم کرنے کے طور پر بیان کیا اور p=reject کو جعلی پیغام کو بلاک کرنے والی واحد سیٹنگ کے طور پر بیان کیا، کہا کہ 2024 Google اور Yahoo بلک بھیجنے والے کے قوانین بھیجنے والوں کو p=none سے دور کیے گئے، اور تقریباً ایک تہائی ڈومین نافاذی پر ایک اعداد و شمار کو حوالہ دیا۔ پالیسی کی تفصیل RFC 9989 کے خلاف درست کی گئی ہے؛ Google اور Yahoo دونوں اصل میں p=none قبول کرتے ہیں، اپنی خود کی دستاویز سے اوپر حوالہ دیا گیا ہے؛ اور نافاذی کی شکل ہٹا دی گئی ہے کیونکہ بنیادی رپورٹ اپنا نمونہ یا ڈینومینیٹر شائع نہیں کرتی ہے۔ مضمون اب یہ بھی بیان کرتا ہے کہ DMARC کیا امتحان نہیں کرتا۔