ईमेल डिलीवरेबिलिटी चेकर

सर्वर सहायता नया वेब यूटिलिटीज़

जिस डोमेन से आप मेल भेजते हैं वह डालें और Mutqan सर्वर सार्वजनिक DNS-over-HTTPS resolver से उसके मेल रिकॉर्ड पढ़ता है — MX, SPF, DMARC, MTA-STS, TLS-RPT और BIMI ज़्यादा से ज़्यादा आठ query में, फिर अधिकतम तीन MX होस्ट के पते और उनका reverse DNS — और उन्हें पास, चेतावनी और विफल वाली चेकलिस्ट में बदलता है, हर आइटम के सुधार के साथ। यह वही जाँचता है जो डोमेन DNS में प्रकाशित करता है, न कि मेल इनबॉक्स में पहुँचेगा या नहीं, भेजने वाले की साख या मेल की सामग्री, और नतीजा बताता है कि वह क्या नहीं देख सका।

गोपनीयता: आप जो नाम खोजते हैं वह Mutqan सर्वर से नतीजों में बताए गए सार्वजनिक DNS रिज़ॉल्वर को भेजा जाता है। कुछ भी स्टोर नहीं होता।

ईमेल भेजने से पहले डोमेन को कौन-से DNS रिकॉर्ड चाहिए?

डोमेन के लिए भेजने वाले सर्वरों की सूची वाला SPF रिकॉर्ड (RFC 7208), हर सेंडिंग सर्विस की DKIM key (RFC 6376), DMARC रिकॉर्ड — कम से कम p=none और रिपोर्ट के लिए rua= पते के साथ (RFC 7489) — MX रिकॉर्ड ताकि जवाब और बाउंस कहीं पहुँचें, और ऐसे सेंडिंग सर्वर जिनके पते का PTR नाम वापस उसी पते पर resolve हो। Gmail जैसे मेलबॉक्स प्रोवाइडर बड़ी मात्रा में मेल लेने से पहले ये माँगते हैं; इनबॉक्स के लिए ये ज़रूरी हैं पर काफ़ी नहीं, क्योंकि प्लेसमेंट साख और सामग्री से तय होती है।

सुरक्षा नोट: जो डोमेन मेल नहीं भेजता, उसे भी "v=spf1 -all" और p=reject वाला DMARC रिकॉर्ड प्रकाशित करना चाहिए, ताकि कोई उसके नाम से मेल न भेज सके।

ईमेल डिलीवरेबिलिटी चेकर कैसे इस्तेमाल करें

  1. अपने From पते का डोमेन डालें (example.com); news@example.com जैसा पता या URL डोमेन में बदल दिया जाता है।
  2. "MX के अधिकतम 3 होस्ट के पते और reverse DNS भी जाँचें" चुना रहने दें, जब तक आपको सिर्फ़ रिकॉर्ड न चाहिए हों।
  3. "डोमेन जाँचें" दबाएँ और चेकलिस्ट में ऊपर से नीचे चलें: पहले विफल आइटम, फिर चेतावनियाँ।
  4. अपने DNS प्रोवाइडर पर रिकॉर्ड ठीक करें, उनका TTL बीतने दें और फिर जाँचें; उसके बाद आपके नाम से भेजने वाली हर सर्विस की DKIM key DKIM रिकॉर्ड चेकर से जाँचें।

ईमेल डिलीवरेबिलिटी चेकर की खूबियाँ

  • सेंडिंग डोमेन के MX, SPF, DMARC, MTA-STS, TLS-RPT और BIMI एक ही बार में सार्वजनिक DNS-over-HTTPS resolver से पढ़ता है
  • इन्हें चेकलिस्ट में बदलता है — पास, चेतावनी, विफल, जानकारी, अज्ञात या यहाँ नहीं जाँचा जाता — और बताता है कि रिसीवर के लिए हर नतीजे का मतलब क्या है
  • अधिकतम तीन MX होस्ट का पता खोजता है और forward-confirmed reverse DNS जाँचता है: ऐसा PTR नाम जो वापस उसी पते पर resolve हो
  • SPF की वे गलतियाँ पकड़ता है जिनकी रिसीवर सज़ा देते हैं: रिकॉर्ड न होना, दो रिकॉर्ड, "+all", टूटा रिकॉर्ड, 10 से ज़्यादा lookup terms और कुछ न बचाने वाला अंत
  • DMARC को वैसे जाँचता है जैसे Gmail के bulk-sender नियम पढ़ते हैं — कम से कम p=none वाला रिकॉर्ड — और देखता है कि aggregate रिपोर्ट (rua) आप तक पहुँचती हैं या नहीं
  • अगले क़दम क्रम से बताता है और उतनी ही साफ़ी से यह भी कि DNS जाँच क्या नहीं देख सकती: इनबॉक्स प्लेसमेंट, साख, सामग्री और DKIM साइनिंग

इनपुट और आउटपुट

इनपुट

  • सेंडिंग डोमेन — आपके From पते का डोमेन; ईमेल पता या URL उसमें बदल दिया जाता है। IP पते स्वीकार नहीं होते।
  • "MX के अधिकतम 3 होस्ट के पते और reverse DNS भी जाँचें" — डिफ़ॉल्ट रूप से चालू; सिर्फ़ रिकॉर्ड पढ़ने हों तो हटा दें।

आउटपुट

  • सारांश और चेकलिस्ट — पास, चेतावनी, विफल और न जाँचे गए आइटम की गिनती, और हर जाँच उसकी स्थिति और मतलब के साथ।
  • आगे क्या करें — विफल और चेतावनी वाले आइटम के सुधार, क्रम से।
  • मेल सर्वर (MX), SPF और DMARC — MX होस्ट उनके पते, PTR नाम और forward-confirmed है या नहीं के साथ; SPF रिकॉर्ड और उसके lookup terms; DMARC रिकॉर्ड, वह कहाँ मिला, उसकी नीति और रिपोर्ट का पता।
  • यह जाँच क्या नहीं देखती — इनबॉक्स प्लेसमेंट, साख, सामग्री, DKIM साइनिंग और उन सेंडिंग सर्वरों का reverse DNS जो MX होस्ट नहीं हैं।

ईमेल डिलीवरेबिलिटी चेकर का उदाहरण

example.com, एक आरक्षित डोमेन जिसे इस तरह बंद किया गया है कि वह कभी मेल न भेजे

इनपुट:

example.com (टूल का Load example)

आउटपुट:

सारांश: पास 3 · चेतावनियाँ 1 · विफल 1 · यहाँ नहीं जाँचा जाता 1
चेकलिस्ट: MX रिकॉर्ड — विफल (Null MX, RFC 7505: डोमेन घोषित करता है कि वह कोई मेल स्वीकार नहीं करता) · SPF रिकॉर्ड — पास (-all पर ख़त्म) · SPF के DNS lookup — पास · DMARC रिकॉर्ड — पास (लागू करने वाली नीति) · DMARC रिपोर्ट — चेतावनी (rua= पता नहीं) · DKIM — यहाँ नहीं जाँचा जाता · MTA-STS, TLS-RPT, BIMI — जानकारी (प्रकाशित नहीं)
SPF: v=spf1 -all · DMARC: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s, _dmarc.example.com पर, नीति (p) reject
आगे क्या करें: डोमेन के MX रिकॉर्ड प्रकाशित करें (या मेल पाने वाला सेंडिंग डोमेन इस्तेमाल करें) · DMARC रिकॉर्ड में rua= पता जोड़ें · आपके लिए भेजने वाली हर सर्विस की DKIM key जाँचें

ईमेल डिलीवरेबिलिटी चेकर के नतीजे कैसे पढ़ें

विफल का मतलब है कि ठीक होने तक रिसीवर डोमेन के मेल को शायद ठुकराएँगे या उस पर भरोसा नहीं करेंगे: SPF न होना, टूटा या "+all" SPF, अमान्य DMARC रिकॉर्ड, बिना पते वाले MX होस्ट, या जिस डोमेन से आप भेजते हैं उस पर Null MX।

चेतावनी का मतलब है कि मेल पहुँच सकता है पर कम भरोसे के साथ, या आप अंधेरे में हैं: DMARC रिकॉर्ड नहीं, rua= रिपोर्ट नहीं, "?all" वाला अंत, या मेल खाते reverse DNS के बिना MX पते।

पास सिर्फ़ प्रकाशित रिकॉर्ड के बारे में है: p=none वाला DMARC रिकॉर्ड पास होता है क्योंकि Gmail bulk sender से इसे स्वीकार करता है, भले ही यह जालसाज़ी न रोके — उस पहलू को ईमेल डोमेन स्पूफ़िंग चेकर आँकता है।

"यहाँ नहीं जाँचा जाता" और "अज्ञात" पास नहीं हैं: DKIM को selector चाहिए, और फ़ेल हुई lookup किसी भी तरफ़ कुछ नहीं कहती।

सब कुछ पास होना अच्छी शुरुआत है, इनबॉक्स का वादा नहीं: प्लेसमेंट साख, सामग्री और शिकायत दर से तय होती है।

ईमेल डिलीवरेबिलिटी चेकर कब इस्तेमाल करें

  • पहले कैंपेन से पहले नया डोमेन या नई सेंडिंग सर्विस तैयार करना।
  • DNS या प्रोवाइडर बदलने के बाद किसी डोमेन का मेल स्पैम में क्यों जाने लगा, यह पता करना।
  • लॉन्च से पहले किसी क्लाइंट या विभाग का डोमेन Gmail की bulk-sender शर्तों के सामने जाँचना।
  • सेल्फ़-होस्टेड मेल सर्वर की समीक्षा: MX पते, PTR नाम और SPF रिकॉर्ड एक साथ।

समस्या निवारण

  • "सार्वजनिक DNS resolver इस डोमेन का जवाब नहीं दे सके": डोमेन मौजूद नहीं, या उसका DNS SERVFAIL देता है (अक्सर टूटे DNSSEC से)। पहले DNS ठीक करें — रिसीवर भी आपके रिकॉर्ड नहीं पढ़ पाते।
  • अभी प्रकाशित रिकॉर्ड अब भी ग़ायब दिखता है: resolver जवाब रिकॉर्ड के TTL तक कैश रखते हैं। TTL बीतने दें और फिर जाँचें।
  • प्रोवाइडर के चलाए होस्ट के लिए reverse DNS "PTR रिकॉर्ड नहीं" दिखता है: PTR सिर्फ़ पते के ब्लॉक का मालिक सेट कर सकता है। अपने होस्टिंग या नेटवर्क प्रोवाइडर से कहें, या अगर वह होस्ट कभी मेल नहीं भेजता तो इसे नज़रअंदाज़ करें।
  • "नहीं खोजा गया: इस मिनट का DNS कोटा ख़त्म हो गया": MX lookup बाक़ी DNS टूल्स के साथ साझा प्रति-मिनट कोटे में गिनी जाती हैं। एक मिनट रुककर फिर जाँचें।

ईमेल डिलीवरेबिलिटी चेकर के बारे में अक्सर पूछे जाने वाले सवाल

क्या साफ़ नतीजे का मतलब है कि मेरा मेल इनबॉक्स में पहुँचेगा?

नहीं। इनबॉक्स प्लेसमेंट आपके सेंडिंग पतों और डोमेन की साख, शिकायत और बाउंस दर, लिस्ट की गुणवत्ता, सामग्री और हर मेलबॉक्स प्रोवाइडर के अपने फ़िल्टर पर निर्भर है, और इनमें से कुछ भी DNS से नहीं पढ़ा जा सकता। यह जाँच प्रकाशित पूर्व-शर्तें देखती है: उनके बिना मेल के ठुकराए या फ़िल्टर होने की संभावना है, पर सिर्फ़ उन्हें पूरा करना काफ़ी नहीं।

DKIM "यहाँ नहीं जाँचा जाता" क्यों दिखता है?

DKIM key selector._domainkey.domain पर प्रकाशित होती है, और DNS किसी डोमेन के selector की सूची देने का कोई तरीका नहीं देता। अपने भेजे किसी मेल के DKIM-Signature हेडर से s= का मान लें (ईमेल हेडर एनालाइज़र इसे दिखाता है) और वह key DKIM रिकॉर्ड चेकर से जाँचें।

Gmail की sender requirements क्या माँगती हैं?

Google की sender guidelines हर भेजने वाले से SPF या DKIM, सेंडिंग डोमेन या पतों के लिए सही forward और reverse DNS, TLS और 0.3% से कम रिपोर्ट हुई स्पैम दर माँगती हैं। Gmail को रोज़ 5,000 से ज़्यादा मेल भेजने वालों को SPF और DKIM दोनों, एक DMARC रिकॉर्ड (none नीति चलती है), SPF या DKIM से aligned From डोमेन और मार्केटिंग मेल में one-click unsubscribe भी चाहिए। यह टूल उस सूची का DNS वाला हिस्सा जाँचता है।

MX होस्ट का reverse DNS क्यों देखा जाता है?

MX होस्ट मेल पाते हैं, पर जब वही सर्वर मेल भेजते भी हैं — सेल्फ़-होस्टेड मेल में यह आम है — तो रिसीवर उम्मीद करते हैं कि हर पते का ऐसा PTR नाम हो जो वापस उसी पते पर resolve हो। अगर आप किसी प्रोवाइडर (Google Workspace, Microsoft 365 या कोई ईमेल सर्विस) से भेजते हैं, तो उसके सेंडिंग सर्वरों का reverse DNS प्रोवाइडर की ज़िम्मेदारी है और यहाँ नहीं दिखता।

एक जाँच में कितनी DNS query होती हैं?

मेल रिकॉर्ड के लिए ज़्यादा से ज़्यादा आठ, फिर हर MX होस्ट के लिए दो से चार — उसका IPv4 पता (IPv4 न हो तो IPv6), उस पते का PTR नाम और, PTR नाम होस्ट से अलग हो तो उस नाम का पता — अधिकतम तीन होस्ट के लिए। Query Cloudflare edge से सार्वजनिक DNS-over-HTTPS resolver तक जाती हैं और कुछ भी सहेजा नहीं जाता।

तकनीकी नोट्स

ओवरव्यू Mutqan सर्वर को एक रिक्वेस्ट है, जो Cloudflare edge से ज़्यादा से ज़्यादा आठ DNS-over-HTTPS query भेजता है: MX, डोमेन के TXT रिकॉर्ड (SPF के लिए, RFC 7208), _dmarc से organizational डोमेन तक DMARC की खोज (RFC 7489), _mta-sts (RFC 8461), _smtp._tls (RFC 8460) और default._bimi। Null MX ("0 .", RFC 7505) घोषित करता है कि डोमेन कोई मेल नहीं पाता।

SPF स्थिर रूप से पढ़ा जाता है: रिकॉर्ड के अपने DNS-lookup terms RFC 7208 §4.6.4 की 10 की सीमा से गिने जाते हैं, include: और redirect= गिने जाते हैं पर फ़ॉलो नहीं होते, और एक से ज़्यादा v=spf1 रिकॉर्ड स्थायी त्रुटि है। SPF रिकॉर्ड चेकर पूरी चेन फ़ॉलो करता है।

Reverse DNS वैसे ही जाँचा जाता है जैसे रिसीवर जाँचते हैं (forward-confirmed reverse DNS): MX होस्ट का IPv4 पता (न हो तो IPv6) resolve होता है, उसका PTR रिकॉर्ड (RFC 1035) पढ़ा जाता है, और PTR नाम को वापस उसी पते पर resolve होना चाहिए। हर lookup आपके ब्राउज़र से Mutqan सर्वर को अलग रिक्वेस्ट है, हर होस्ट के लिए दो से चार, अधिकतम तीन होस्ट।

Google की sender guidelines हर भेजने वाले से SPF या DKIM, सेंडिंग सर्वरों के लिए सही forward और reverse DNS, TLS और 0.3% से कम स्पैम दर माँगती हैं, और रोज़ 5,000 से ज़्यादा मेल भेजने वालों से SPF और DKIM दोनों, कम से कम p=none वाला DMARC, From alignment और one-click unsubscribe (RFC 8058)। बाहर से उस सूची का सिर्फ़ DNS में प्रकाशित हिस्सा जाँचा जा सकता है।

सीमाएँ और कार्यप्रणाली

सिर्फ़ प्रकाशित DNS जाँचा जाता है: इनबॉक्स प्लेसमेंट, भेजने वाले की साख या ब्लैकलिस्ट, मेल की सामग्री, शिकायत दर, DKIM साइनिंग, बाहर जाते कनेक्शन का TLS या unsubscribe हेडर नहीं।

DKIM key नहीं जाँची जातीं क्योंकि selector DNS से पता नहीं चलता; इस ओवरव्यू में SPF के include: और redirect= फ़ॉलो नहीं होते।

Reverse DNS अधिकतम तीन MX होस्ट और हर एक के पहले पते के लिए ही जाँचा जाता है। प्रोवाइडर से भेजा मेल प्रोवाइडर के सर्वरों से निकलता है, जो यहाँ नहीं देखे जाते।

Lookup Cloudflare edge से सार्वजनिक DNS-over-HTTPS resolver तक जाती हैं और दिखाती हैं कि उस पल उनके कैश में क्या था।

सुरक्षा और गोपनीयता

डोमेन, उसके MX होस्ट के नाम और उनके पते Mutqan सर्वर से सार्वजनिक DNS resolver तक भेजे जाते हैं; कुछ भी सहेजा नहीं जाता और कोई मेल नहीं भेजा जाता।

संदर्भ

  • Email sender guidelinesGoogle (Gmail Help)Gmail हर भेजने वाले से क्या माँगता है (SPF या DKIM, forward और reverse DNS, TLS, 0.3% से कम स्पैम दर) और रोज़ 5,000 से ज़्यादा मेल भेजने वालों से क्या (SPF और DKIM दोनों, DMARC, alignment, one-click unsubscribe)।
  • RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1IETF · 2014SPF का मानक: v=spf1 रिकॉर्ड, उसके mechanism और qualifier, मूल्यांकन का क्रम, और हर जाँच में दस DNS लुकअप व दो void लुकअप की सीमा।
  • RFC 6376: DomainKeys Identified Mail (DKIM) SignaturesIETF · 2011DKIM सिग्नेचर और selector._domainkey पर पब्लिक-कुंजी रिकॉर्ड: उसके टैग (v, k, p, t, s, h, n) और verifier कुंजी को कैसे ढूँढकर इस्तेमाल करता है।