संक्षिप्त उत्तर
MX, SPF, DKIM और DMARC रिकॉर्ड कैसे जाँचें?
MX के लिए dig MX yourdomain +short, SPF के लिए dig TXT yourdomain +short, DKIM के लिए dig CNAME selector._domainkey.yourdomain +short, और DMARC के लिए dig TXT _dmarc.yourdomain +short चलाएँ। Windows पर nslookup भी यही करता है। एक Postelva डोमेन पर पूरा Proton Mail सेटअप 8 रिकॉर्ड के लिए 6 लुकअप लेता है।
कौन सा लुकअप कौन सा रिकॉर्ड जाँचता है
| रिकॉर्ड | dig कमांड | सही उत्तर कैसा दिखता है |
|---|---|---|
| MX | dig MX example.com +short | 10 mail.protonmail.ch. और 20 mailsec.protonmail.ch. (Proton Mail) |
| SPF | dig TXT example.com +short | एक पंक्ति जो v=spf1 से शुरू होती है, जैसे "v=spf1 include:_spf.protonmail.ch ~all" |
| DKIM | dig CNAME fm1._domainkey.example.com +short | प्रदाता का लक्ष्य, जैसे fm1.example.com.dkim.fmhosted.com. (Fastmail) |
| DMARC | dig TXT _dmarc.example.com +short | एक पंक्ति जो v=DMARC1 से शुरू होती है, जैसे "v=DMARC1; p=none; rua=mailto:[email protected]" |
| MTA-STS (वैकल्पिक) | dig TXT _mta-sts.example.com +short | "v=STSv1; id=..." |
अंतिम जाँच को; पुराने आँकड़ों की अपनी तारीख होती है
# dig (macOS, Linux, Windows with BIND tools)
dig MX example.com +short
dig TXT example.com +short
dig CNAME protonmail._domainkey.example.com +short
dig TXT _dmarc.example.com +short
# Ask the authoritative nameserver directly, skipping caches
dig NS example.com +short
dig MX example.com +short @ns1.your-nameserver.example
# nslookup (Windows, macOS, Linux)
nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com
# PowerShell
Resolve-DnsName -Type MX example.com
Resolve-DnsName -Type TXT _dmarc.example.comमैं MX रिकॉर्ड कैसे जाँचूँ?
अपने डोमेन के साथ dig MX को +short के साथ चलाएँ, और प्राथमिकताओं और होस्ट नामों की तुलना अपने प्रदाता के दिए मानों से करें। उत्तर में हर रिकॉर्ड के लिए एक पंक्ति छपती है: प्राथमिकता, एक स्पेस और होस्ट। Proton Mail के लिए आप 10 mail.protonmail.ch. और 20 mailsec.protonmail.ch. की अपेक्षा करते हैं; Fastmail के लिए 10 in1-smtp.messagingengine.com. और 20 in2-smtp.messagingengine.com.; Mailbox.org के लिए चार mxext होस्ट।
यहाँ दो समस्याएँ दिखती हैं। पिछले प्रदाता का कोई रिकॉर्ड सूची में बचा हो तो डिलीवरी अनिश्चित हो जाती है, इसलिए उसे हटाएँ। और खाली उत्तर का अर्थ है कोई MX नहीं: तब भेजने वाले डोमेन के एड्रेस रिकॉर्ड पर लौटते हैं, जैसा RFC 5321 बताता है। हर पंक्ति का अर्थ MX रिकॉर्ड क्या है में समझाया गया है।
मैं SPF रिकॉर्ड कैसे जाँचूँ?
डोमेन की जड़ पर TXT रिकॉर्ड माँगें और पक्का करें कि ठीक एक पंक्ति v=spf1 से शुरू होती है। जड़ पर दूसरे TXT रिकॉर्ड भी होते हैं, जैसे आपके ईमेल प्रदाता का स्वामित्व प्रमाण, इसलिए पूरी सूची पढ़ें। v=spf1 से शुरू होने वाली दो पंक्तियाँ गलती हैं: RFC 7208 के अनुसार किसी डोमेन पर एक से ज़्यादा SPF रिकॉर्ड होने पर स्थायी त्रुटि आती है।
फिर लुकअप गिनें। हर include, a, mx, ptr और exists, साथ ही redirect मॉडिफ़ायर, 10 की सीमा में गिने जाते हैं, और include के भीतर जो है वह भी गिना जाता है। सीमा से ऊपर का रिकॉर्ड हर भेजने वाले के लिए विफल होता है। रिकॉर्ड बनाने का विवरण SPF रिकॉर्ड कैसे बनाएँ में है।
अगर मुझे selector नहीं पता तो DKIM कैसे जाँचूँ?
अपने प्रदाता का selector इस्तेमाल करें: DNS से selectors की सूची नहीं मिलती, इसलिए उन्हें प्रदाता की DKIM स्क्रीन से लें। DNS _domainkey के नीचे के नामों की सूची की अनुमति नहीं देता। Proton Mail पर selectors protonmail, protonmail2 और protonmail3 हैं, Fastmail पर fm1, fm2 और fm3, और Mailbox.org पर MBO0001 से MBO0004।
लुकअप नाम selector._domainkey.yourdomain है। जो प्रदाता CNAME रिकॉर्ड इस्तेमाल करता है, जैसे ये तीन, वह अपने ही होस्ट का CNAME लौटाता है। जो प्रदाता कुंजी सीधे प्रकाशित करता है, वह TXT रिकॉर्ड लौटाता है जिसमें v=DKIM1 और p= के बाद सार्वजनिक कुंजी होती है। खाली p= का मतलब है कि कुंजी रद्द है। सबसे पक्का परीक्षण एक असली संदेश है, क्योंकि मौजूद रिकॉर्ड फिर भी अप्रयुक्त हो सकता है: किसी दूसरे प्रदाता को मेल भेजें और पूरे हेडर में dkim=pass देखें।
मैं DMARC रिकॉर्ड कैसे जाँचूँ?
_dmarc.yourdomain पर TXT रिकॉर्ड माँगें और पक्का करें कि एक पंक्ति v=DMARC1 से शुरू होती है और उसमें p= नीति है। यदि p नहीं है, तो रिसीवर नीति को none मानते हैं। यदि पंक्ति में rua नहीं है, तो कोई एग्रीगेट रिपोर्ट नहीं बनती, और DMARC रोलआउट के मॉनिटरिंग चरण से कुछ पता नहीं चलता। पुराने ढंग में लिखे रिकॉर्ड में अब भी pct टैग हो सकता है, जिसे RFC 9989 ने हटा दिया है।
सब-डोमेन जिसका अपना रिकॉर्ड नहीं है, DNS ट्री वॉक के ज़रिए माता-पिता की नीति के अंतर्गत आता है, जिसमें अधिकतम आठ क्वेरी लगती हैं। जिस नाम का रिकॉर्ड नहीं है, उसका लुकअप कुछ नहीं लौटाता, जो बिना DMARC जैसा ही है।
मेरा लुकअप अब भी पुराना मान क्यों दिखा रहा है?
कैश पुराना उत्तर तब तक रखता है जब तक उसका TTL खत्म न हो, और गायब रिकॉर्ड भी कैश हो सकता है। बदलाव फैलने में लगने वाला समय लगभग उस पुराने TTL जितना होता है जो आपके बदलते समय रिकॉर्ड पर था। विक्रेता मार्गदर्शन के अनुसार सामान्य MX बदलाव में एक से चार घंटे लगते हैं, और सबसे खराब स्थिति में 24 से 48 घंटे। RFC 2308 जोड़ता है कि नकारात्मक उत्तर ज़ोन के SOA रिकॉर्ड के TTL से कैश होते हैं, इसलिए जो रिकॉर्ड आपने अभी बनाया, वह कुछ रिज़ॉल्वर पर गायब दिख सकता है।
कैश छोड़ने के लिए, authoritative nameserver से पूछें: dig NS से उसे खोजें, फिर @ और उसके नाम के साथ क्वेरी दोहराएँ, जैसा ऊपर कोड ब्लॉक में है। यदि authoritative सर्वर नया मान दिखाता है और आपका रिज़ॉल्वर नहीं, तो इंतज़ार करें। यदि दोनों नहीं दिखाते, तो रिकॉर्ड सहेजा नहीं गया या होस्ट नाम गलत है, ज़्यादातर इसलिए कि DNS एडिटर ने डोमेन दो बार जोड़ दिया।
अगर रिकॉर्ड सही दिखने के बाद भी मेल नहीं आता, तो कस्टम डोमेन पर ईमेल क्यों नहीं आ रहा पर जाएँ।
कौन से ऑनलाइन टूल ईमेल रिकॉर्ड जाँच सकते हैं?
कोई भी ऑनलाइन DNS लुकअप या मेल प्रमाणीकरण जाँचकर्ता जो सार्वजनिक DNS से पूछता है, वही उत्तर देता है जो dig देता है, बस अधिक सुविधाजनक प्रदर्शन के साथ। ऐसा टूल चुनें जो रिकॉर्ड का मूल पाठ दिखाए, ताकि आप उसे अपने प्रदाता के मान से अक्षर-दर-अक्षर मिला सकें। कोई निजी डेटा वहाँ न चिपकाएँ: उसे केवल डोमेन नाम चाहिए।
Postelva की 12 नवंबर 2026 की गिनती के अनुसार पूरे Proton Mail सेटअप में 8 रिकॉर्ड लगते हैं (1 सत्यापन TXT, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) और 6 लुकअप, क्योंकि दो MX रिकॉर्ड एक क्वेरी साझा करते हैं, और सत्यापन व SPF रिकॉर्ड जड़ के TXT क्वेरी को साझा करते हैं। छह कमांड एक बार सहेज लें और हर बदलाव के बाद दोबारा चलाएँ। वही रिकॉर्ड SPF बनाम DKIM बनाम DMARC में भी तुलना किए गए हैं।
एक उद्धरण योग्य नियम: हर DNS बदलाव के बाद चार रिकॉर्ड प्रकार क्वेरी करें और एक परीक्षण संदेश भेजें; रिकॉर्ड तभी सही है जब लुकअप और संदेश दोनों एक ही बात कहें।
ईमेल रिकॉर्ड जाँचना: सवाल
dig TXT मान उद्धरण चिह्नों में क्यों दिखाता है?
उद्धरण चिह्न TXT स्ट्रिंग की सीमाएँ दिखाते हैं। 255 अक्षरों से लंबा मान कई उद्धृत स्ट्रिंग के रूप में दिखता है, जिन्हें रिसीवर बिना स्पेस के जोड़ते हैं।
क्या dig Windows पर काम करता है?
केवल तभी जब आप BIND टूल इंस्टॉल करें। Windows में nslookup पहले से है, और PowerShell में Resolve-DnsName है, जो दोनों एक ही रिकॉर्ड पढ़ते हैं।
एक असली संदेश का SPF, DKIM और DMARC परिणाम कैसे देखूँ?
प्राप्त संदेश के पूरे हेडर खोलें। प्राप्त करने वाला सर्वर अपने SPF, DKIM और DMARC परिणाम हेडर में दर्ज करता है, आम तौर पर pass या fail के रूप में।
मुझे कितनी देर इंतज़ार करने के बाद यह मानना चाहिए कि कोई रिकॉर्ड गलत है?
कम से कम उतना TTL इंतज़ार करें जितना पुराने रिकॉर्ड का था, फिर authoritative nameserver से पूछें। यदि वह सर्वर गलत मान दिखाए, तो रिकॉर्ड सुधारना होगा।
क्या मैं ऐसे डोमेन के रिकॉर्ड जाँच सकता हूँ जो मेरा नहीं है?
हाँ। DNS रिकॉर्ड सार्वजनिक हैं, और लुकअप के लिए केवल नाम चाहिए।
सार
- MX: dig MX example.com +short; प्राथमिकताएँ और होस्ट अपने प्रदाता से मिलाएँ।
- SPF: dig TXT example.com +short; ठीक एक पंक्ति जो v=spf1 से शुरू हो, अधिकतम 10 लुकअप।
- DKIM: dig CNAME selector._domainkey.example.com +short, अपने प्रदाता के selector के साथ।
- DMARC: dig TXT _dmarc.example.com +short; एक पंक्ति जो v=DMARC1 से शुरू हो, जिसमें p= और rua= हों।
- पूरे Proton Mail सेटअप में 8 रिकॉर्ड और 6 लुकअप लगते हैं।
- कैश छोड़ने के लिए authoritative nameserver से पूछें; बदलाव फैलने में लगभग पुराना TTL लगता है।
- Postelva मुफ़्त DNS में रिकॉर्ड रखता है; एक .com की कीमत हर साल $12.49/साल है।
स्रोत (7)
- RFC 5321, Simple Mail Transfer Protocol, खंड 5.1 — RFC Editor (पढ़ा गया 2026-11-12)
- RFC 7208, Sender Policy Framework — RFC Editor (पढ़ा गया 2026-11-12)
- RFC 6376, DKIM Signatures — RFC Editor (पढ़ा गया 2026-11-12)
- RFC 9989, DMARC — RFC Editor (पढ़ा गया 2026-11-12)
- RFC 2308, DNS क्वेरी का नकारात्मक कैश — RFC Editor (पढ़ा गया 2026-11-12)
- DNS रिकॉर्ड बदलाव फैलने में कितना समय लगता है — Suped (पढ़ा गया 2026-11-12)
- कस्टम डोमेन और स्पूफ़िंग से बचाव — Proton (पढ़ा गया 2026-11-12)