आप अप्रयुक्त डोमेनों पर ईमेल स्पूफिंग कैसे रोकते हैं?

अप्रयुक्त डोमेनों को ईमेल रिकॉर्ड की ज़रूरत क्यों है?

क्योंकि कोई भी आपके डोमेन को किसी ईमेल की From पंक्ति में डाल सकता है, और बिना रिकॉर्ड वाला डोमेन प्राप्तकर्ताओं को जाँचने के लिए कुछ नहीं देता। इसी कारण आपके ब्रांड की टाइपो जैसा रक्षात्मक डोमेन आकर्षक होता है। फ़िशर ऐसे मेल भेजते हैं जो वैरिएंट से, या आपके सपोर्ट पते जैसे दिखने वाले नाम से आते लगें, और जो प्राप्त करने वाला सिस्टम कोई नीति नहीं पाता, उसके पास उसे अस्वीकार करने का आधार नहीं होता।

दो रिकॉर्ड उस अंतर का अधिकांश हिस्सा बंद करते हैं। SPF उन सर्वरों की सूची देता है जो किसी डोमेन की ओर से भेज सकते हैं, और बिना सर्वर वाला SPF रिकॉर्ड, जिसका परिणाम सख़्त विफलता हो, हर भेजने वाले को अस्वीकार करता है। DMARC प्राप्तकर्ताओं को बताता है कि SPF और DKIM जाँच में विफल मेल के साथ क्या करें, और p=reject उनसे उसे अस्वीकार करने को कहता है। तीसरा रिकॉर्ड, null MX, भेजने वालों को बताता है कि डोमेन का कोई मेल सर्वर नहीं है, इसलिए उसे भेजा गया संदेश तुरंत विफल हो जाता है, न कि दिनों तक दोबारा प्रयास होता रहता है।

Wardmint की रक्षात्मक एक्सटेंशन सूची कौन-से डोमेन क्रिप्टो प्रोजेक्ट को पंजीकृत करने चाहिए में है। एक बार ये आपके हो जाएँ, तो ये तीन रिकॉर्ड जोड़ने की पहली चीज़ हैं।

null MX रिकॉर्ड (RFC 7505) क्या करता है?

null MX प्राथमिकता 0 और लक्ष्य के रूप में root बिंदु वाला एक ही MX रिकॉर्ड है, और इसका अर्थ है कि डोमेन कोई ईमेल स्वीकार नहीं करता। इसे RFC 7505 परिभाषित करता है। विनिमय (exchange) एक शून्य-लंबाई का लेबल है, जो ज़ोन फ़ाइलों में एक बिंदु के रूप में लिखा जाता है, और चूँकि बिंदु एक वैध होस्ट नाम नहीं है, इस रिकॉर्ड को असली मेल सर्वर समझा नहीं जा सकता।

दो नियम लागू होते हैं। जो डोमेन null MX प्रकाशित करता है, उसे कोई और MX रिकॉर्ड प्रकाशित नहीं करना चाहिए। और रिकॉर्ड केवल इसी रूप में null MX है: प्राथमिकता 0, लक्ष्य बिंदु। जो भेजने वाले इसे देखते हैं वे तुरंत स्थायी त्रुटि के साथ विफल हो जाते हैं, जो मेल लूप रोकता है और ईमानदार भेजने वालों की दोबारा प्रयास कतारों को बचाता है, जिन्होंने आपके डोमेन में टाइपो किया।

इसके बिना, जो भेजने वाला कोई MX नहीं पाता, वह डोमेन के A रिकॉर्ड पर लौटता है और वहीं डिलीवर करने की कोशिश करता है, जो धीमा और कम स्पष्ट है। null MX यह अनुमान हटा देता है।

SPF v=spf1 -all का क्या अर्थ है?

यह एक TXT रिकॉर्ड है जो कोई भेजने वाला अधिकृत नहीं करता, और माइनस चिह्न हर जाँच को विफल करता है। RFC 7208 इसे परिभाषित करता है: v=spf1 संस्करण टैग है, और -all एक ही निर्देश है जिसमें all तंत्र हमेशा मेल खाता है और माइनस योग्यता (qualifier) विफलता लौटाती है। साथ में वे कहते हैं कि इस नाम के लिए कोई होस्ट मेल नहीं भेज सकता।

RFC 7208 उन नामों के लिए यह तरीका सुझाता है जो न पतों में इस्तेमाल होते हैं और न ही मेल भेजने की उम्मीद है। इसे हर रक्षात्मक डोमेन के शीर्ष (apex) पर प्रकाशित करें। SPF envelope sender या HELO नाम में डोमेन के लिए जाँचा जाता है, इसलिए स्पूफ़र एक ऐसे सबडोमेन की भी कोशिश कर सकता है जिसे आपने कभी कॉन्फ़िगर नहीं किया। वाइल्डकार्ड TXT रिकॉर्ड, जो डोमेन के अंतर्गत उन नामों पर लागू होता है जिनका अपना कोई रिकॉर्ड नहीं है, उन्हें कवर कर सकता है।

example.com.          3600  IN  MX   0 .
example.com.          3600  IN  TXT  "v=spf1 -all"
_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=reject; adkim=s; aspf=s"

DMARC p=reject क्या जोड़ता है?

DMARC नीति और रिपोर्टिंग जोड़ता है: यह प्राप्तकर्ताओं को विफल मेल अस्वीकार करने को कहता है और आपको दिखाता है कि कौन प्रयास करता है। RFC 7489 नीति को डोमेन के _dmarc नाम पर एक TXT रिकॉर्ड के रूप में रखता है। v टैग पहले आना चाहिए और DMARC1 पढ़ता है, और p नीति को none, quarantine या reject पर सेट करता है। sp टैग सबडोमेन के लिए नीति सेट करता है, और अगर वह नहीं है तो p उन पर लागू होता है। adkim और aspf टैग सख़्त या ढीला संरेखण (alignment) सेट करते हैं, और rua संकलित रिपोर्टों के लिए पते देता है।

RFC p=reject की ताकत के बारे में सावधान है: मालिक प्राप्तकर्ताओं से अस्वीकार करने को कहता है, और प्राप्तकर्ताओं से अपेक्षा है कि वे भरसक प्रयास करें, पर उन्हें सख़्ती से बाध्य नहीं किया गया है। बड़े मेलबॉक्स प्रदाता व्यवहार में इसका पालन करते हैं, इसीलिए यह रिकॉर्ड प्रकाशित करने लायक है।

प्रयास देखने के लिए, एक रिपोर्टिंग पता जोड़ें, उदाहरण के लिए rua=mailto:[email protected], ऐसे मेलबॉक्स पर जिसे आप पढ़ते हैं। कई रक्षात्मक डोमेन वाले प्रोजेक्ट के लिए, उन सभी के लिए एक रिपोर्टिंग मेलबॉक्स काफ़ी है। जो डोमेन सचमुच मेल भेजता है, जैसे आपका मुख्य डोमेन, उसे उसके वास्तविक भेजने वालों से मेल खाती नीति पर रखें, और reject पर ले जाने से पहले संकलित रिपोर्टें पढ़ें।

एक रक्षात्मक सेट की सुरक्षा पर कितना खर्च होता है?

तीन रिकॉर्ड Wardmint पर कोई अतिरिक्त खर्च नहीं हैं; लागत डोमेन की है। Wardmint एक "no email" DNS टेम्पलेट (null MX, SPF -all, DMARC p=reject) ताकि डिफ़ेंसिव डोमेन से आपके मेल की नकल न हो सके, हर वेरिएंट को आपकी मुख्य साइट पर भेजने के लिए मुफ़्त URL फ़ॉरवर्डिंग, और आपके बैलेंस से स्वचालित नवीनीकरण ताकि कोई वेरिएंट छूटे नहीं प्रदान करता है।

Wardmint के 12 नवंबर 2026 के सर्वेक्षण के अनुसार, उसके phisher सेट के नौ एक्सटेंशन (.xyz, .pro, .info, .shop, .online, .icu, .click, .live और .support) कुल मिलाकर $212.41 प्रति वर्ष लगते हैं, या तीन वर्ष के लिए $637.23, और हर एक पर बिना-ईमेल टेम्पलेट लग सकता है। .com, .net, .org, .io, .xyz, .app का मुख्य सेट $128.94 प्रति वर्ष में आता है। ये सेट सुझाव हैं, बंडल नहीं: नाम बल्क खोज से कार्ट में डाले जाते हैं, एक बार में 50 तक।

टेम्पलेट को हर उस सुरक्षात्मक डोमेन पर लागू करें जो वेब ट्रैफ़िक को रीडायरेक्ट नहीं करता, और उसे उन डोमेन के लिए URL फ़ॉरवर्डिंग के साथ जोड़ें जो करते हैं। नाम चुनने का तरीका अपने ब्रांड की सुरक्षात्मक डोमेन सूची कैसे बनाएँ में है।