SPF रिकॉर्ड चेकर

सर्वर सहायता नया DNS और डोमेन

किसी डोमेन का TXT में छपा SPF रिकॉर्ड पढ़ें और उसे वैसे ही जाँचें जैसे मेल लेने वाला सर्वर जाँचता है: हर include, redirect, a और mx टर्म resolve होकर RFC 7208 की दस DNS लुकअप वाली सीमा में गिना जाता है, void लुकअप और loop पकड़े जाते हैं, और सूची से बाहर के सेंडरों का फ़ैसला करने वाला "all" समझाया जाता है। पेस्ट किया गया रिकॉर्ड आपके ब्राउज़र में ही पार्स होता है, ताकि पब्लिश करने से पहले उसे जाँच सकें।

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

SPF रिकॉर्ड क्या है?

SPF रिकॉर्ड v=spf1 से शुरू होने वाला एक TXT रिकॉर्ड है जो उन सर्वरों की सूची देता है जिन्हें SMTP envelope (Return-Path एड्रेस) में डोमेन के नाम से मेल भेजने की अनुमति है। मेल लेने वाला सर्वर कनेक्ट करने वाले एड्रेस को रिकॉर्ड के टर्म से मिलाकर pass, fail, softfail या neutral पाता है; यह काम सीमित रखने के लिए RFC 7208 हर मूल्यांकन में ज़्यादा से ज़्यादा दस DNS लुकअप की अनुमति देता है, और उससे आगे जाना permerror है।

SPF रिकॉर्ड चेकर कैसे इस्तेमाल करें

  1. सेंडर एड्रेस का डोमेन लिखें, जैसे example.com; billing@example.com जैसा पूरा एड्रेस भी चलेगा।
  2. «SPF जाँचें» दबाएँ। Mutqan सर्वर डोमेन के TXT रिकॉर्ड पढ़ता है और हर include और redirect फ़ॉलो करता है।
  3. सारांश पढ़ें: नतीजा, 10 में से इस्तेमाल हुए DNS लुकअप, void लुकअप और सूची से बाहर के सेंडरों का क्या होगा।
  4. लुकअप टेबल, ग़लतियाँ और चेतावनियाँ देखें, अपने DNS होस्ट पर रिकॉर्ड ठीक करें और दोबारा जाँचें।
  5. बदलाव पब्लिश करने से पहले आज़माना हो तो नया रिकॉर्ड दूसरे फ़ील्ड में पेस्ट करें; वह ब्राउज़र में पार्स होता है और कुछ भी भेजा नहीं जाता।

SPF रिकॉर्ड चेकर की खूबियाँ

  • RFC 7208 के अनुसार पूरा मूल्यांकन: include और redirect की चेन फ़ॉलो होती है, a और mx टर्म resolve होते हैं, ptr और exists गिने जाते हैं
  • पूरी चेन पर 10 लुकअप की सीमा की गिनती — दसवें के बाद का हर लुकअप सूची में दिखता है, पर कभी भेजा नहीं जाता
  • void लुकअप (ऐसे नाम जिन पर कोई रिकॉर्ड नहीं — ज़्यादा से ज़्यादा दो की इजाज़त), loop और बिना SPF वाले include target को permerror के रूप में दिखाना
  • रिकॉर्ड का हर टर्म: मैच होने पर उसका नतीजा (Pass, Fail, SoftFail, Neutral), उसमें DNS लुकअप लगता है या नहीं, और वह किसमें resolve हुआ
  • किसी भी redirect= के बाद आख़िर में फ़ैसला करने वाला "all" — यानी जिन सर्वरों को आपने सूची में नहीं रखा, उनकी मेल का क्या होगा
  • दूसरे फ़ील्ड में पेस्ट किया गया ड्राफ़्ट रिकॉर्ड पब्लिश से पहले आपके ब्राउज़र में जाँचा जाता है
  • ग़लतियाँ, चेतावनियाँ और अगले क़दम सरल भाषा में, हर एक के साथ वह रिकॉर्ड या नाम जिससे वह जुड़ी है

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

इनपुट

  • डोमेन नाम — envelope सेंडर का डोमेन, नाम, ईमेल एड्रेस या URL के रूप में; internationalised नाम भी चलते हैं।
  • पेस्ट किया गया SPF रिकॉर्ड (वैकल्पिक) — v=spf1 से शुरू होने वाला एक रिकॉर्ड, सादा या ज़ोन फ़ाइल से कॉपी किए उद्धरण-चिह्नों में। यह भरा हो तो जाँच ब्राउज़र में होती है और कोई लुकअप नहीं होता।

आउटपुट

  • सारांश — नतीजा, 10 में से इस्तेमाल हुए DNS लुकअप, 2 में से void लुकअप, सूची से बाहर के सेंडरों का क्या होगा, और एक से ज़्यादा हों तो पब्लिश हुए SPF रिकॉर्ड की संख्या।
  • रिकॉर्ड — मिला हुआ SPF रिकॉर्ड, जाँचा गया नाम, नीति सौंपी गई हो तो redirect= target, और जाँच में हुई DNS क्वेरी की संख्या।
  • रिकॉर्ड के टर्म — हर टर्म का टाइप, मैच होने पर उसका नतीजा, लुकअप लगता है या नहीं, और वह किसमें resolve हुआ।
  • क्रम से DNS लुकअप — पूरी चेन का हर लुकअप उसकी गहराई और परिणाम के साथ, सीमा से आगे वाले भी जो भेजे नहीं गए।
  • त्रुटियाँ, चेतावनियाँ और आगे क्या करें — हर बात सरल भाषा में, उस नाम या टर्म के साथ जिससे वह जुड़ी है।

SPF रिकॉर्ड चेकर का उदाहरण

ऐसा डोमेन जिसकी SPF नीति एक include है (google.com, अक्टूबर 2026)

इनपुट:

google.com

आउटपुट:

परिणाम: काम करता है, चेतावनियों के साथ · DNS लुकअप: 1 / 10 · void लुकअप: 0 / 2 · सूची से बाहर के सेंडर: ~all (softfail: सूची से बाहर के सर्वरों की मेल पर निशान लगता है, अस्वीकार नहीं होती)
रिकॉर्ड: v=spf1 include:_spf.google.com ~all
क्रम से DNS लुकअप: 1 · include:_spf.google.com · _spf.google.com · डेप्थ 0 · SPF रिकॉर्ड मिला
चेतावनियाँ: "~all" (softfail) मेल लेने वाले सर्वरों से कहता है कि सूची से बाहर के सर्वरों की मेल स्वीकार करें पर उस पर निशान लगाएँ; सख़्त रूप "-all" है। DMARC लागू हो तो फ़र्क़ छोटा रह जाता है।

SPF रिकॉर्ड चेकर के नतीजे कैसे पढ़ें

«कोई समस्या नहीं मिली»: रिकॉर्ड -all पर ख़त्म होता है, आख़िर तक किसी टर्म से मैच न होने वाला सेंडर भी 10 लुकअप और 2 void लुकअप के भीतर रहता है, और चेतावनी लायक़ कुछ नहीं।

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

«काम करता है, चेतावनियों के साथ»: सर्वर रिकॉर्ड जाँच सकते हैं, पर कुछ उसे कमज़ोर करता है — अक्सर ~all या ?all, "all" का न होना, पुराना पड़ चुका ptr टर्म, या जाँच के दौरान अस्थायी रूप से विफल DNS लुकअप।

«ग़लतियाँ हैं»: सर्वर permerror पर रुक जाएगा (10 से ज़्यादा लुकअप, दो SPF रिकॉर्ड, सिंटैक्स की ग़लती, बिना SPF वाला include, loop), या +all हर सर्वर को pass कर देता है। तब कई सर्वर डोमेन को बिना SPF वाला मान लेते हैं।

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

«कोई SPF रिकॉर्ड नहीं»: नाम पर v=spf1 से शुरू होने वाला कोई TXT रिकॉर्ड नहीं। सर्वरों को नतीजा "none" मिलता है, और तब DMARC सिर्फ़ DKIM के ज़रिए pass हो सकता है।

SPF रिकॉर्ड चेकर कब इस्तेमाल करें

  • नई मेल भेजने वाली सेवा — CRM, न्यूज़लेटर प्लेटफ़ॉर्म, हेल्प डेस्क — जोड़ते समय देखना कि उसका include डोमेन को 10 लुकअप से आगे न ले जाए।
  • पता करना कि किसी सेवा की मेल Gmail या Outlook पर SPF में, या DMARC alignment में, क्यों fail हो रही है।
  • बदलाव से पहले ड्राफ़्ट रिकॉर्ड को बिना पब्लिश किए जाँचना।
  • पार्क किए और इस्तेमाल न होने वाले डोमेन जाँचना कि वे "v=spf1 -all" पब्लिश करते हैं।

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

  • «10 से ज़्यादा DNS लुकअप»: लुकअप टेबल खोलकर देखें कि कौन-सा include सबसे ज़्यादा लेता है, जिन सेवाओं को अब इस्तेमाल नहीं करते उन्हें हटाएँ, या स्थिर रेंज छापने वाले प्रोवाइडर के include की जगह वही ip4 और ip6 रेंज लिखें।
  • «डोमेन एक से ज़्यादा SPF रिकॉर्ड पब्लिश करता है»: दो TXT रिकॉर्ड v=spf1 से शुरू होते हैं, अक्सर पुराने प्रोवाइडर का छोड़ा हुआ। दोनों को एक रिकॉर्ड में मिला दें।
  • «include या redirect target कोई SPF रिकॉर्ड पब्लिश नहीं करता»: include ऐसे नाम की ओर इशारा करता है जिस पर SPF नहीं — टाइपिंग की ग़लती, या प्रोवाइडर ने अपना include होस्ट बदल दिया। प्रोवाइडर की मौजूदा सेटअप गाइड से मिलाएँ।
  • नतीजों में temperror: चेन का कोई डोमेन समय पर जवाब नहीं दे पाया। दोबारा जाँचें; विफलता बनी रहे तो उस डोमेन के nameserver में दिक़्क़त है।
  • अनुरोध-सीमा वाला संदेश: हर SPF जाँच DNS टूल्स के आपके हिस्से से 21 तक DNS क्वेरी के बराबर गिनी जाती है, इसलिए लगातार कुछ जाँचें उसे ख़त्म कर सकती हैं। दिखाए गए सेकंड रुककर फिर कोशिश करें।

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

SPF में 10 DNS लुकअप की सीमा क्या है?

RFC 7208 का §4.6.4 मेल लेने वाले सर्वर को SPF जाँचते समय ज़्यादा से ज़्यादा दस DNS लुकअप की अनुमति देता है। हर include, a, mx, ptr और exists टर्म और redirect मॉडिफ़ायर एक लुकअप लेता है, include किए गए रिकॉर्ड के अंदर वाले भी; ip4, ip6 और all मुफ़्त हैं। ग्यारहवाँ लुकअप permerror है, और कई सर्वर तब डोमेन को बिना काम के SPF वाला मान लेते हैं। चेकर पूरी चेन पर लुकअप गिनता है और दसवें के बाद वाले हर लुकअप को बिना भेजे सूची में दिखाता है।

SPF में -all, ~all और ?all में क्या फ़र्क़ है?

आख़िर का "all" टर्म तय करता है कि रिकॉर्ड में न लिखे सेंडर का क्या हो। -all fail माँगता है, ~all softfail (स्वीकार करो पर संदिग्ध मानकर निशान लगाओ), ?all neutral (कोई राय नहीं), और +all इंटरनेट के हर सर्वर को pass कर देता है। DMARC p=quarantine या p=reject पर हो तो -all और ~all का फ़र्क़ छोटा रह जाता है क्योंकि फ़ैसला DMARC करता है; +all कभी सुरक्षित नहीं।

क्या एक डोमेन पर दो SPF रिकॉर्ड रख सकते हैं?

नहीं। RFC 7208 का §4.5 कहता है कि एक नाम पर v=spf1 से शुरू होने वाले एक से ज़्यादा TXT रिकॉर्ड मिलें तो सर्वर permerror लौटाता है। दोनों के mechanism एक रिकॉर्ड में मिला दें — जैसे दोनों include: टर्म वाला एक रिकॉर्ड — और दूसरा हटा दें।

चेकर permerror दिखाता है, फिर भी मेरी मेल क्यों पहुँच रही है?

मेल लेने वाले सर्वर टूटे SPF रिकॉर्ड को अलग-अलग तरह संभालते हैं: कई उसे ऐसे मानते हैं जैसे SPF है ही नहीं, कुछ SPF छोड़कर DKIM पर भरोसा करते हैं, और कुछ ही मेल अस्वीकार करते हैं। DKIM साइन की हुई मेल DMARC में फिर भी pass हो सकती है। फिर भी permerror ठीक करना ज़रूरी है, क्योंकि अभी आपकी मेल ऑथेंटिकेशन का SPF हिस्सा कुछ नहीं कर रहा।

क्या पेस्ट किया गया रिकॉर्ड कहीं भेजा जाता है?

नहीं। पेस्ट किया गया रिकॉर्ड आपके ब्राउज़र में पार्स होता है और कोई लुकअप नहीं होता, इसलिए उसके include और redirect target फ़ॉलो नहीं होते और सिर्फ़ रिकॉर्ड में लिखे लुकअप टर्म गिने जाते हैं। पूरी चेन देखने के लिए पब्लिश हुआ डोमेन जाँचें।

तकनीकी नोट्स

SPF (RFC 7208) उस डोमेन पर एक TXT रिकॉर्ड है जिसे मेल SMTP envelope में इस्तेमाल करती है — MAIL FROM एड्रेस, जिसे मेल लेने वाले सर्वर Return-Path के रूप में दर्ज करते हैं — या HELO नाम में। सर्वर टर्म बाएँ से दाएँ जाँचता है: ip4 और ip6 कनेक्ट करने वाले एड्रेस को एक रेंज से मिलाते हैं, a और mx उसे डोमेन के एड्रेस या मेल सर्वरों से, include पूछता है कि किसी दूसरे डोमेन का SPF pass होता है या नहीं, और पहला मैच अपने qualifier से फ़ैसला करता है। कुछ मैच न हो और रिकॉर्ड में "all" न हो, तो redirect= फ़ैसला दूसरे रिकॉर्ड को सौंप देता है।

सर्वर का काम सीमित रखने के लिए §4.6.4 पूरे मूल्यांकन में DNS क्वेरी करने वाले ज़्यादा से ज़्यादा 10 टर्म — include, a, mx, ptr, exists और redirect — और ज़्यादा से ज़्यादा दो void लुकअप की अनुमति देता है; किसी भी सीमा से आगे जाना permerror है। चेकर पब्लिश हुए रिकॉर्ड का हर टर्म फ़ॉलो करता है: लुकअप उसी क्रम में गिनता है जिसमें सर्वर उनसे मिलता, include और redirect target व a और mx टर्म के एड्रेस resolve करता है, और दसवें के बाद वाले लुकअप बिना क्वेरी किए सूची में रखता है। सर्वर पहले मैच होने वाले टर्म पर रुक जाता है (§4.6.2), इसलिए यह गिनती उतने लुकअप हैं जितने कोई सेंडर ज़्यादा से ज़्यादा करवा सकता है; रिकॉर्ड में पहले लिखे सर्वर की मेल पर कम लुकअप लगते हैं। ptr और exists कनेक्ट करने वाले एड्रेस या macro पर निर्भर हैं, इसलिए गिने जाते हैं पर resolve नहीं होते।

नतीजा इसी रास्ते से निकलता है: «ग़लतियाँ हैं» जब permerror हो या +all हर सर्वर को pass करे, include के ज़रिए भी; «काम करता है, चेतावनियों के साथ» अस्थायी विफलता, ~all, ?all, "all" न होने या किसी और चेतावनी पर; «कोई समस्या नहीं मिली» सिर्फ़ उस रिकॉर्ड के लिए जो -all पर ख़त्म हो और जिसमें बताने लायक़ कुछ न हो।

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

रिकॉर्ड Cloudflare एज पर चल रहा Mutqan सर्वर Cloudflare के पब्लिक रिज़ॉल्वर से पढ़ता है। कुछ मिनट पहले किया बदलाव तब तक न दिखे जब तक कैश जवाबों की मियाद ख़त्म न हो।

चेकर पब्लिश हुई नीति जाँचता है, कोई ख़ास मेल नहीं: वह नहीं बता सकता कि कोई ख़ास भेजने वाला एड्रेस pass होगा या नहीं, क्योंकि ptr, exists और macro को वही एड्रेस चाहिए — वे गिने जाते हैं, resolve नहीं होते।

लुकअप की गिनती उतनी है जितनी कोई सेंडर ज़्यादा से ज़्यादा करवा सकता है: सर्वर पहले मैच होने वाले टर्म पर रुक जाता है, इसलिए रिकॉर्ड में पहले लिखे सर्वर की मेल पर कम लुकअप लगते हैं, और सीमा से आगे वाला रिकॉर्ड सिर्फ़ उन सेंडरों को permerror देता है जो ग्यारहवें लुकअप तक पहुँचते हैं।

पेस्ट किए गए रिकॉर्ड में सिर्फ़ रिकॉर्ड ही पार्स होता है। include और redirect target फ़ॉलो नहीं होते, इसलिए कुल लुकअप और include किए गए रिकॉर्ड की समस्याएँ सिर्फ़ लाइव जाँच में दिखती हैं।

मेल लेने वाले सर्वर सीमाएँ कितनी सख़्ती से लागू करते हैं और permerror को कैसे लेते हैं, इसमें फ़र्क़ होता है; नतीजा RFC 7208 बताता है, हर सर्वर की अपनी नीति नहीं।

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

लाइव जाँच में आपका लिखा डोमेन Mutqan सर्वर तक जाता है, जो HTTPS पर Cloudflare के पब्लिक DNS से उसके और उसके रिकॉर्ड में आए नामों के बारे में पूछता है; रिज़ॉल्वर को क्वेरी Mutqan से आती दिखती हैं, आपसे नहीं। पेस्ट किया गया रिकॉर्ड आपके ब्राउज़र से बाहर नहीं जाता। कुछ भी स्टोर नहीं होता।

संदर्भ

  • RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1IETF · 2014SPF का मानक: v=spf1 रिकॉर्ड, उसके mechanism और qualifier, मूल्यांकन का क्रम, और हर जाँच में दस DNS लुकअप व दो void लुकअप की सीमा।
  • RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)IETF · 2015DMARC का पहला प्रकाशित रूप (2015): _dmarc पर रिकॉर्ड, p, sp, pct, adkim, aspf, rua और ruf टैग, SPF और DKIM के साथ identifier alignment, और Public Suffix List से तय organizational डोमेन पर लौटना। मई 2026 में RFC 9989 ने इसकी जगह ली; इसके pct, rf और ri टैग अब भी पब्लिश हुए रिकॉर्ड में मिलते हैं।