DMARC रिकॉर्ड चेकर — लागू होने वाली DMARC नीति देखें

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

DMARC रिकॉर्ड (RFC 9989, जिसने मई 2026 में RFC 7489 की जगह ली) डोमेन के आगे लगे _dmarc नाम (_dmarc.example.com) पर एक TXT रिकॉर्ड है जो मेल लेने वाले सर्वरों को बताता है कि जिस मेल का From डोमेन aligned SPF या DKIM pass से प्रमाणित न हो, उसके साथ क्या करें — कुछ नहीं (p=none), quarantine या reject — और रिपोर्ट कहाँ भेजें। जिस सबडोमेन का अपना रिकॉर्ड नहीं, वह organizational डोमेन के रिकॉर्ड के तहत आता है, और sp= हो तो उसी नीति के तहत।

सुरक्षा नोट: लागू DMARC नीति (quarantine या reject) के बिना DMARC लागू करने वाले सर्वरों से उस मेल को रोकने को नहीं कहा जाता जिसके From एड्रेस में ठीक आपका डोमेन हो पर जो SPF और DKIM alignment में fail हो। p=reject भी मिलते-जुलते दिखने वाले डोमेन या पते के साथ दिखने वाले display name पर लागू नहीं होती।

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

From एड्रेस का डोमेन या उसका कोई सबडोमेन लिखें; _dmarc.example.com या पूरा ईमेल एड्रेस भी चलेगा।
«DMARC जाँचें» दबाएँ। Mutqan सर्वर उस नाम पर _dmarc पढ़ता है, और रिकॉर्ड न मिले तो पैरेंट डोमेन पर।
लागू नीति और रिकॉर्ड कहाँ मिला, यह पढ़ें; सबडोमेन के लिए देखें कि फ़ैसला sp= करता है या p=।
टैग टेबल, रिपोर्ट पते, ग़लतियाँ और चेतावनियाँ देखें, और अगले क़दम अपनाएँ।
रिकॉर्ड पब्लिश करने से पहले आज़माना हो तो उसे दूसरे फ़ील्ड में पेस्ट करें; वह आपके ब्राउज़र में पार्स होता है।

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

जो नीति आपके लिखे नाम पर सच में लागू होती है: डोमेन का अपना रिकॉर्ड, या बिना रिकॉर्ड वाले सबडोमेन के लिए organizational डोमेन की sp= या p=
खोज का रास्ता नाम-दर-नाम: डोमेन पर _dmarc, फिर हर पैरेंट डोमेन पर, जब तक रिकॉर्ड न मिले
RFC 9989 का हर टैग — np, psd और t समेत — अपने अर्थ और वैल्यू के साथ, जो टैग रिकॉर्ड में नहीं लिखे उनकी डिफ़ॉल्ट वैल्यू, और रिकॉर्ड अब भी इस्तेमाल करे तो RFC 7489 के pct, rf और ri
दूसरे organizational डोमेन के रिपोर्ट पतों के लिए उस authorisation रिकॉर्ड की जाँच, जिसे उस डोमेन को रिपोर्ट मिलने से पहले पब्लिश करना होता है
कमज़ोर सेटिंग की व्याख्या: p=none, टेस्ट मोड (t=y), 100 से कम pct, rua= पता न होना, p= से कमज़ोर sp=, एक नाम पर दो DMARC रिकॉर्ड
दूसरे फ़ील्ड में पेस्ट किया ड्राफ़्ट रिकॉर्ड पब्लिश करने से पहले आपके ब्राउज़र में जाँचा जाता है
पहले p=none रिकॉर्ड से लागू p=reject तक, सरल भाषा में अगले क़दम

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

इनपुट

डोमेन नाम — डोमेन या सबडोमेन, नाम, ईमेल एड्रेस या _dmarc.example.com जैसे _dmarc नाम के रूप में; internationalised नाम भी चलते हैं।
पेस्ट किया DMARC रिकॉर्ड (वैकल्पिक) — v=DMARC1 से शुरू होने वाला एक रिकॉर्ड, सादा या उद्धरण-चिह्नों में। यह भरा हो तो जाँच ब्राउज़र में होती है और कोई लुकअप नहीं होता; साथ में डोमेन भी लिखा हो तो वह सिर्फ़ अपने और बाहरी रिपोर्ट पतों का फ़र्क़ बताने के काम आता है।

आउटपुट

सारांश — लागू नीति, रिकॉर्ड कहाँ मिला, रिकॉर्ड में हो तो pct=, t=y हो तो टेस्ट मोड, और aggregate रिपोर्ट पतों की संख्या।
रिकॉर्ड — जाँचा गया नाम, मिला रिकॉर्ड, और सबडोमेन के लिए वह टैग (sp= या p=) जिसके ज़रिए नीति लागू होती है।
जाँचे गए नाम — खोज में पूछा गया हर _dmarc नाम, «कोई रिकॉर्ड नहीं», «कई रिकॉर्ड, सब छोड़ दिए गए» या «रिकॉर्ड मिला» के साथ।
रिकॉर्ड के टैग — RFC 9989 के हर टैग का अर्थ और वैल्यू, डिफ़ॉल्ट वैल्यू अलग से चिह्नित, और रिकॉर्ड में हों तो pct, rf और ri।
रिपोर्ट पते — हर rua= और ruf= पता, और यह कि authorisation चाहिए या नहीं और मिला या नहीं।
त्रुटियाँ, चेतावनियाँ और आगे क्या करें — हर बात सरल भाषा में, और नतीजे से निकलने वाले अगले क़दम।

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

नीति विरासत में पाने वाला सबडोमेन (docs.github.com, अक्टूबर 2026)

इनपुट:

docs.github.com

आउटपुट:

लागू नीति: reject (fail होने वाली मेल अस्वीकार होती है) · रिकॉर्ड कहाँ मिला: _dmarc.github.com (organizational डोमेन) · प्रतिशत (pct): 100 · aggregate रिपोर्ट पते: 1
जाँचे गए नाम: _dmarc.docs.github.com — कोई रिकॉर्ड नहीं · _dmarc.github.com — रिकॉर्ड मिला (organizational डोमेन)
रिकॉर्ड: v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1
इस सबडोमेन पर इसके ज़रिए लागू: sp=reject

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

reject: लागू करने वाली नीति — DMARC लागू करने वाले सर्वरों से कहा जाता है कि इसी डोमेन के लिए alignment में fail होने वाली मेल अस्वीकार करें। यह मिलते-जुलते दिखने वाले डोमेन या पते के साथ दिखने वाले display name पर लागू नहीं होती।

quarantine: fail मेल स्पैम में जाती है या रोकी जाती है; नक़ली मेल कम दिखती है, पर कहीं न कहीं पहुँचती है।

none: नीति सिर्फ़ रिपोर्ट इकट्ठा करती है। DMARC में fail मेल हमेशा की तरह पहुँचती है, इसलिए सर्वरों से अभी डोमेन की नक़ल करने वाली मेल रोकने को नहीं कहा गया।

«कोई DMARC रिकॉर्ड नहीं»: न नाम पर, न उसके पैरेंट डोमेन पर कोई रिकॉर्ड है; fail मेल का क्या करना है, यह सर्वर ख़ुद तय करते हैं।

«अमान्य रिकॉर्ड»: सर्वर इसे अनदेखा करते हैं — अक्सर इसलिए कि रिकॉर्ड v=DMARC1 से शुरू नहीं होता, एक नाम पर कई DMARC रिकॉर्ड हैं और किसी पैरेंट पर काम का रिकॉर्ड नहीं (सब छोड़ दिए जाते हैं, RFC 9989 §4.10), या p= ग़ायब या ग़लत है और काम का कोई rua= पता नहीं। काम का rua= हो, तो ग़ायब या ग़लत p= (या ग़लत sp= या np=) पर सर्वर रिकॉर्ड को p=none मानते हैं (RFC 9989 §4.10.1)।

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

DMARC लागू करना शुरू करते समय पक्का करना कि rua= पते वाला पहला p=none रिकॉर्ड सही पब्लिश हुआ है।
none से quarantine या reject पर जाकर पुष्टि करना कि बदलाव लागू हो गया।
यह पता करना कि बिना अपने रिकॉर्ड वाले सबडोमेन को कौन-सी नीति बचाती है।
पक्का करना कि DMARC रिपोर्टिंग सेवा को भेजी जाने वाली रिपोर्ट authorised हैं, ताकि वे सच में पहुँचें।

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

रिकॉर्ड बनाने के बाद भी «कोई DMARC रिकॉर्ड नहीं»: रिकॉर्ड डोमेन के आगे लगे _dmarc (_dmarc.example.com) पर TXT होना चाहिए, डोमेन पर ही नहीं। कई DNS पैनल डोमेन ख़ुद जोड़ देते हैं, इसलिए नाम में सिर्फ़ _dmarc लिखें।
«इस नाम पर एक से ज़्यादा DMARC रिकॉर्ड»: दो रिकॉर्ड v=DMARC1 से शुरू हों तो सर्वर दोनों छोड़कर पैरेंट नामों पर खोज जारी रखते हैं (RFC 9989 §4.10), इसलिए नाम पर किसी पैरेंट डोमेन की नीति लागू होती है या कोई नहीं। एक हटा दें और ज़रूरी टैग दूसरे में रखें।
रिपोर्ट पते का authorisation रिकॉर्ड नहीं: रिपोर्टिंग सेवा के डोमेन को your-domain._report._dmarc.their-domain पब्लिश करना होता है। ज़्यादातर DMARC रिपोर्टिंग सेवाएँ यह तब करती हैं जब आप अपने अकाउंट में डोमेन जोड़ते हैं।
rua= होते हुए भी रिपोर्ट नहीं आतीं: पते की वर्तनी जाँचें (यह mailto: से शुरू होना चाहिए), बाहरी डोमेन का authorisation जाँचें, और देखें कि मेलबॉक्स compressed XML अटैचमेंट लेता है।
अनुरोध-सीमा वाला संदेश: एक DMARC जाँच में पाँच तक DNS क्वेरी और हर जाँचे गए रिपोर्ट डोमेन की एक क्वेरी लगती है, जो बाक़ी DNS टूल्स के साथ साझा बजट से जाती है; दिखाए गए सेकंड रुकें।

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

DMARC की शुरुआत किस नीति से करें?

p=none और एक rua= पते से शुरू करें, कुछ हफ़्ते aggregate रिपोर्ट पढ़ें जब तक पक्का न हो जाए कि आपके नाम से मेल भेजने वाली हर सेवा alignment के साथ SPF या DKIM में pass होती है, फिर p=quarantine और आख़िर में p=reject पर जाएँ। सीधे reject पर जाने से किसी भूले हुए सेंडर की असली मेल bounce हो सकती है।

क्या सबडोमेन को अपना DMARC रिकॉर्ड चाहिए?

नहीं। सबडोमेन का अपना रिकॉर्ड न हो (मसलन _dmarc.mail.example.com पर कुछ नहीं), तो मेल लेने वाले सर्वर organizational डोमेन का रिकॉर्ड इस्तेमाल करते हैं: उसमें sp= हो तो वह, वरना p=। चेकर भी इसी तरह ऊपर चढ़ता है और बताता है कि कौन-सा रिकॉर्ड और कौन-सा टैग लागू है। सबडोमेन का अलग रिकॉर्ड तभी बनाएँ जब उसे अलग नीति चाहिए।

DMARC में rua और ruf में क्या फ़र्क़ है?

rua= पर aggregate रिपोर्ट आती हैं: रोज़ाना XML सारांश कि किन सर्वरों ने आपके नाम से मेल भेजी और वह pass हुई या नहीं। ruf= अलग-अलग मेल की failure रिपोर्ट माँगता है, जो कुछ ही बड़े सर्वर भेजते हैं। दूसरे organizational डोमेन का पता तभी रिपोर्ट पाता है जब वह डोमेन उसकी अनुमति दे: example.com की रिपोर्ट reports.example.net के पते पर जाएँ तो example.com._report._dmarc.reports.example.net पर रिकॉर्ड चाहिए (RFC 9990 §4)।

DMARC में pct= और t= क्या करते हैं?

pct= RFC 7489 का टैग है: यह नीति को fail होने वाली मेल के उतने प्रतिशत पर लागू करता था और बाक़ी मेल को एक स्तर नरम मानता था (quarantine की जगह none, reject की जगह quarantine)। मई 2026 में RFC 7489 की जगह लेने वाले RFC 9989 ने इसे हटाकर t=y जोड़ा — एक टेस्ट मोड, जिसमें सर्वर हर fail मेल पर नीति एक स्तर नरम लागू करते हैं। RFC 9989 मानने वाले सर्वर pct= अनदेखा करते हैं; धीरे-धीरे लागू करने का काम पूरा हो जाए तो t=y और pct= दोनों हटा दें।

मेरा DMARC रिकॉर्ड अमान्य क्यों दिख रहा है?

आम कारण: रिकॉर्ड v=DMARC1 से शुरू नहीं होता, बिना काम के rua= पते वाले रिकॉर्ड में p= टैग ग़ायब या ग़लत लिखा है (rua= हो तो सर्वर रिकॉर्ड को p=none मानते हैं), एक ही नाम पर v=DMARC1 वाले दो TXT रिकॉर्ड हैं और किसी पैरेंट पर काम का रिकॉर्ड नहीं (सर्वर दोनों छोड़ देते हैं, RFC 9989 §4.10), या रिकॉर्ड _dmarc की जगह डोमेन पर ही पब्लिश है (_dmarc.example.com की जगह example.com पर)।

तकनीकी नोट्स

DMARC (RFC 9989, जिसने मई 2026 में RFC 7489 की जगह ली) पढ़ने वाले को दिखने वाले From एड्रेस को SPF और DKIM से जोड़ता है: मेल तब pass होती है जब SPF या DKIM ऐसे डोमेन के लिए pass हो जो From डोमेन से aligned हो — strict alignment (adkim=s, aspf=s) में वही डोमेन, relaxed alignment में, जो डिफ़ॉल्ट है, उसी organizational डोमेन वाला कोई डोमेन। डोमेन के आगे लगे _dmarc पर रिकॉर्ड सर्वरों को बताता है कि fail मेल का क्या करें: p=none (सिर्फ़ रिपोर्ट), quarantine या reject, साथ में टेस्ट के दौर के लिए t=y (RFC 7489 धीरे-धीरे लागू करने के लिए pct= इस्तेमाल करता था) और रिपोर्ट के लिए rua=/ruf=।

जब किसी नाम का रिकॉर्ड न हो, तो सर्वर organizational डोमेन का रिकॉर्ड इस्तेमाल करते हैं: उसमें sp= हो तो वह सबडोमेन पर लागू होती है, और np= उन सबडोमेन पर जो मौजूद नहीं। RFC 7489 organizational डोमेन Public Suffix List से तय करता था; RFC 9989 इसकी जगह DNS ट्री वॉक रखता है — ज़्यादा से ज़्यादा आठ क्वेरी, जो टॉप-लेवल डोमेन तक जा सकती है, psd= फ़्लैग मानती है और सबसे कम लेबल वाला रिकॉर्ड चुनती है। Mutqan सर्वर इसका अनुमान लगाता है: पहले नाम पर _dmarc, फिर दो लेबल तक हर पैरेंट पर, ज़्यादा से ज़्यादा पाँच नाम, और ठीक एक रिकॉर्ड वाला पहला नाम इस्तेमाल होता है (कई रिकॉर्ड वाला नाम छोड़ दिया जाता है, जैसा RFC 9989 §4.10 कहता है) — नतीजा वही रहता है, जब तक कोई बीच का नाम या पब्लिक suffix भी रिकॉर्ड पब्लिश न करे।

दूसरे organizational डोमेन के पते पर रिपोर्ट तभी भेजी जाती हैं जब वह डोमेन अपने _report._dmarc नाम के नीचे v=DMARC1 वाला TXT रिकॉर्ड पब्लिश करे — reports.example.net पर जाने वाली example.com की रिपोर्ट के लिए यह example.com._report._dmarc.reports.example.net पर होना चाहिए (RFC 9990 §4, उससे पहले RFC 7489 §7.1)। organizational डोमेन Public Suffix List से मिलाए जाते हैं, इसलिए mail.example.com के लिए reports.example.com वाले पते को यह रिकॉर्ड नहीं चाहिए। ऐसे ज़्यादा से ज़्यादा दो बाहरी डोमेन के लिए चेकर यह रिकॉर्ड खोजता है और बताता है कि वह मौजूद है या नहीं।

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

चेकर पब्लिश हुए रिकॉर्ड पढ़ता है; यह नहीं देख सकता कि किसी ख़ास सर्वर ने किसी ख़ास मेल पर नीति कैसे लागू की — यह aggregate रिपोर्ट बताती हैं।

खोज RFC 9989 के DNS ट्री वॉक का अनुमान है: यह ज़्यादा से ज़्यादा पाँच नाम जाँचती है और दो लेबल पर रुक जाती है, इसलिए न टॉप-लेवल डोमेन क्वेरी करती है न psd= फ़्लैग पढ़ती है, और सबसे कम लेबल वाले रिकॉर्ड की जगह पहला मिला रिकॉर्ड लेती है। नीति तभी अलग होती है जब कोई बीच का नाम या पब्लिक suffix भी रिकॉर्ड पब्लिश करे। co.uk जैसे पब्लिक suffix के नीचे यह _dmarc.co.uk जैसा नाम भी जाँच सकती है।

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

एक बार में ज़्यादा से ज़्यादा दो बाहरी रिपोर्ट डोमेन का authorisation जाँचा जाता है।

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

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

संदर्भ

RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)IETF · 2026मौजूदा DMARC मानक (मई 2026, RFC 7489 और RFC 9091 की जगह): नीति रिकॉर्ड और उसके टैग — np, psd और t समेत — identifier alignment, और ज़्यादा से ज़्यादा आठ क्वेरी में organizational डोमेन ढूँढने वाला DNS ट्री वॉक।
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 टैग अब भी पब्लिश हुए रिकॉर्ड में मिलते हैं।
RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate ReportingIETF · 2026DMARC की aggregate रिपोर्ट (rua=): उनका XML फ़ॉर्मेट और भेजने का तरीक़ा, और दूसरे organizational डोमेन का रिपोर्ट पता _report._dmarc के नीचे TXT रिकॉर्ड से रिपोर्ट लेने की अनुमति कैसे देता है (§4)।