No DMARC record found: वह एक पंक्ति जो आपके डोमेन में नहीं है

संक्षेप में

• इस संदेश का मतलब है कि _dmarc.yourdomain.com पर कोई TXT रिकॉर्ड नहीं है। आपका मेल सर्वर ख़राब नहीं है।
• होस्ट _dmarc और मान v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com के साथ एक TXT रिकॉर्ड जोड़ें। p=none के साथ डिलीवरी ठीक वैसी ही रहती है जैसी थी।
• Gmail, Yahoo और Outlook.com यह रिकॉर्ड केवल बड़े पैमाने पर ईमेल भेजने वालों से माँगते हैं। फिर भी इसे जोड़ें: Google पूरे डोमेन को गिनता है और बल्क का दर्जा कभी नहीं हटाता, और रिपोर्ट तभी शुरू होती हैं जब रिकॉर्ड मौजूद हो।
• अगर कोई जाँच टूल अब भी कुछ नहीं पाता, तो ग़लत DNS होस्ट, दोहराया गया होस्ट नाम या दो DMARC रिकॉर्ड ढूँढ़ें। दो रिकॉर्ड एक-दूसरे को रद्द कर देते हैं।
• मई 2026 में RFC 9989 के साथ मानक बदला: pct हट गया, t और np नए हैं। Google की सहायता अक्टूबर 2026 की स्थिति के अनुसार अब भी pct का वर्णन करती है।

“No DMARC record found” (कोई DMARC रिकॉर्ड नहीं मिला) का मतलब है कि किसी जाँच टूल ने DNS से _dmarc.yourdomain.com पर TXT रिकॉर्ड माँगा और जवाब में कुछ नहीं मिला। आपके मेल सर्वर में कुछ ख़राब नहीं है। इसका हल एक TXT रिकॉर्ड है, जिसका होस्ट _dmarc और मान v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com है। p=none के साथ आपके ईमेल ठीक पहले की तरह पहुँचते हैं। आप प्राप्त करने वाले सर्वरों को केवल यह बताते हैं कि आप इसमें शामिल हैं, और आपको रिपोर्ट मिलने लगती हैं।

DMARC ईमेल के तीन रिकॉर्ड में तीसरा है, SPF और DKIM के साथ। SPF उन सर्वरों की सूची देता है जो आपके डोमेन की ओर से भेज सकते हैं। DKIM हर संदेश पर हस्ताक्षर करता है। DMARC प्राप्त करने वाले सर्वर को बताता है कि जब दोनों में से कोई भी आपके From पते के डोमेन की पुष्टि न करे तो क्या करना है, और रोज़ का सार कहाँ भेजना है। मई 2026 से यह RFC 9989 में परिभाषित है, जिसने पुराने RFC 7489 की जगह ली। कई गाइड अब भी पुराने संस्करण का वर्णन करती हैं, और अक्टूबर 2026 की स्थिति के अनुसार Google का सहायता पेज भी।

जोड़ने वाला रिकॉर्ड

वहाँ लॉगिन करें जहाँ आपके डोमेन का DNS मैनेज होता है। यह वह कंपनी है जिसकी ओर आपके नेमसर्वर इशारा करते हैं, और यह हमेशा वही नहीं होती जिससे आपने डोमेन ख़रीदा। इन मानों के साथ एक नया रिकॉर्ड जोड़ें:

ज़ोन फ़ाइल की एक पंक्ति के रूप में लिखा जाए, तो तैयार रिकॉर्ड ऐसा दिखता है:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

example.com की जगह अपना डोमेन लिखें। तीनों हिस्से यह करते हैं:

• v=DMARC1 पंक्ति को DMARC रिकॉर्ड के रूप में चिह्नित करता है। इसे सबसे पहले आना चाहिए, और DMARC1 बड़े अक्षरों में। ऐसा न हो तो प्राप्त करने वाले सर्वर पूरे रिकॉर्ड को अनदेखा कर देते हैं।
• p=none नीति है: मेरे ईमेल के साथ वैसा ही करें जैसा आप वैसे भी करते। इस रिकॉर्ड की वजह से न कुछ ब्लॉक होता है, न स्पैम में जाता है।
• rua=mailto:… रोज़ की रिपोर्ट का पता है। रिकॉर्ड प्रकाशित करने से पहले वह पता बना लें, या ऐसा एलियास जो आप तक फ़ॉरवर्ड हो।

Google यही तीन फ़ील्ड Set up DMARC (DMARC सेट अप करें) में बताता है। वह यह भी कहता है कि DMARC जोड़ने से पहले SPF और DKIM 48 घंटे से काम कर रहे हों। अगर आपका जाँच टूल उन दोनों पर भी चेतावनी देता है, तो पहले उन्हें ठीक करें।

कैसे जाँचें कि यह काम कर गया

DNS से ख़ुद पूछें। macOS या Linux पर टर्मिनल खोलें और dig इस्तेमाल करें। Windows पर nslookup इस्तेमाल करें।

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

अगर रिकॉर्ड लाइव है, तो पंक्ति उद्धरण चिह्नों में वापस आती है। 5 अक्टूबर 2026 को Google के अपने डोमेन ने यह जवाब दिया:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

ख़ाली जवाब का मतलब है कि रिकॉर्ड अभी वहाँ नहीं है, या वहाँ नहीं है जहाँ प्राप्त करने वाले सर्वर उसे ढूँढ़ते हैं। जब आपकी अपनी क्वेरी पंक्ति दिखा दे, तो वह जाँच टूल दोबारा चलाएँ जिसने आपको यह संदेश दिया था। उदाहरण के लिए, MXToolbox इस समस्या को “No DMARC Record found” लिखता है और समझाता है कि “आपके डोमेन का कोई प्रकाशित DMARC रिकॉर्ड नहीं है”।

DMARC रिकॉर्ड के हर हिस्से का क्या मतलब है

रिकॉर्ड tag=value जोड़ियों की सूची है, जिन्हें सेमीकोलन अलग करते हैं। मानक में केवल v अनिवार्य है, और उसे पहले आना चाहिए। p को दूसरे स्थान पर रखें: Google की सहायता कहती है कि “v और p टैग सबसे पहले होने चाहिए”, और पुराना मानक भी यही क्रम चाहता था। ये RFC 9989, सेक्शन 4.7 के टैग हैं:

पुराने रिकॉर्ड अक्सर pct=100 पर ख़त्म होते हैं। यह टैग फ़ेल होने वाले ईमेल के एक हिस्से पर नीति लागू करने के लिए था। RFC 9989 ने इसे rf और ri के साथ हटा दिया और कारण बताया:

कामकाज के अनुभव ने दिखाया कि “pct” टैग आम तौर पर सटीक रूप से लागू नहीं होता था, जब तक कि दिया गया मान 0 या 100 (डिफ़ॉल्ट) न हो, और दूसरे मानों के साथ होने वाली अशुद्धियाँ एक इम्प्लीमेंटेशन से दूसरे में बहुत अलग-अलग थीं।

प्राप्त करने वाले सर्वरों को वे टैग अनदेखे करने होते हैं जिन्हें वे नहीं जानते, इसलिए पुराना pct=100 कोई नुक़सान नहीं करता। 5 अक्टूबर 2026 को yahoo.com और microsoft.com के रिकॉर्ड में यह अब भी था, और Google का सहायता पेज धीरे-धीरे लागू करने के लिए अब भी pct की सलाह देता है। नए रिकॉर्ड में इसे छोड़ दें।

अगर आप हर दिन कुछ ही ईमेल भेजते हैं, तो क्या आपको DMARC चाहिए?

बड़े मेल प्रदाताओं के प्रकाशित नियमों के अनुसार DMARC रिकॉर्ड तब अनिवार्य है जब आप बड़े पैमाने पर भेजते हैं। उससे नीचे यह एक सिफ़ारिश है।

स्रोत हैं Google के ईमेल भेजने वालों के लिए दिशा-निर्देश, Yahoo के Sender Best Practices और Microsoft की बड़ी मात्रा में भेजने वालों के लिए घोषणा, सभी अक्टूबर 2026 की स्थिति के अनुसार। अगर आप एक मेलबॉक्स से हर दिन तीस ईमेल भेजते हैं, तो इनमें से कोई भी यह रिकॉर्ड नहीं माँगता। फिर भी इसे अभी जोड़ने के तीन कारण हैं।

• सीमा डोमेन के हिसाब से गिनी जाती है और रीसेट नहीं होती। Google निजी Gmail खातों को भेजे गए उन सभी संदेशों को जोड़ता है जो एक ही प्राइमरी डोमेन से आते हैं, सबडोमेन समेत। उसका भेजने वालों के लिए FAQ कहता है: “जो भेजने वाले ऊपर की शर्तें कम से कम एक बार पूरी करते हैं, उन्हें स्थायी रूप से बड़े पैमाने पर भेजने वाला माना जाता है।”
• Google और Yahoo दोनों सबके लिए इसकी सलाह देते हैं। Google लिखता है कि “हमारी सलाह है कि आप अपने डोमेन के लिए हमेशा SPF, DKIM और DMARC सेट अप करें”। Yahoo “सभी भेजने वालों से पुरज़ोर आग्रह करता है कि ईमेल भेजने वाले हर डोमेन के लिए DMARC नीति प्रकाशित करें”।
• रिकॉर्ड के बिना आपको कोई रिपोर्ट नहीं मिलती। उन्हीं से आप देखते हैं कि कौन-से सर्वर From पंक्ति में आपके डोमेन के साथ ईमेल भेजते हैं, आपके अपने टूल भी और अजनबी भी।

बड़े पैमाने पर भेजने वालों के लिए गायब रिकॉर्ड के नतीजे होते हैं। Google का भेजने वालों के लिए FAQ इसके लिए अस्थायी एरर 4.7.31 बताता है: “भेजने वाले डोमेन का कोई DMARC रिकॉर्ड नहीं है, या DMARC रिकॉर्ड में कोई DMARC नीति नहीं दी गई है”। वही पेज कहता है कि नवंबर 2025 से जो ईमेल शर्तें पूरी नहीं करते उन्हें “अस्थायी और स्थायी अस्वीकृति” का सामना करना पड़ता है।

रिकॉर्ड जोड़ दिया, और जाँच टूल को अब भी कुछ नहीं मिलता?

तो आम तौर पर इनमें से कोई एक कारण होता है। ऊपर वाली dig क्वेरी से इन्हें एक-एक करके देखें।

• आपने DNS ग़लत जगह बदला। अगर आपके नेमसर्वर आपके रजिस्ट्रार से अलग किसी कंपनी के पास हैं, तो रजिस्ट्रार के यहाँ डाले गए रिकॉर्ड कभी पूछे ही नहीं जाते। dig +short NS example.com दिखाता है कि आपके डोमेन के लिए कौन जवाब देता है।
• होस्ट ग़लत है। रिकॉर्ड ख़ुद example.com पर है, या दोहराए गए नाम पर, जैसा ऊपर बताया गया। प्राप्त करने वाले सर्वर केवल _dmarc.example.com माँगते हैं।
• दो DMARC रिकॉर्ड हैं। यहाँ मानक सख़्त है: “अगर एक ही लक्ष्य के लिए कई DMARC नीति रिकॉर्ड लौटते हैं, तो वे सभी छोड़ दिए जाते हैं।” उन्हें मिलाकर एक करें। रिपोर्ट के दो पते एक ही rua में जाते हैं, कॉमा से अलग।
• पहला टैग ठीक v=DMARC1 नहीं है। छोटे अक्षर, DMARC 1 जैसी टाइपिंग की ग़लती, या उसके आगे p= रिकॉर्ड को अमान्य कर देते हैं।
• रिकॉर्ड का प्रकार TXT नहीं है, या मान किसी दस्तावेज़ से टेढ़े उद्धरण चिह्नों (curly quotes) के साथ पेस्ट हुआ। मान को सादे टेक्स्ट के रूप में टाइप करें, बिना उद्धरण चिह्नों के, जब तक आपके DNS होस्ट की सहायता उन्हें न माँगे।
• पुराना जवाब अब भी कैश में है। रिज़ॉल्वर “ऐसा कोई रिकॉर्ड नहीं” को कुछ समय याद रखते हैं। क्वेरी में अपने किसी नेमसर्वर का नाम जोड़कर सीधे उसी से पूछें, उदाहरण के लिए dig +short TXT _dmarc.example.com @ns1.example.net। अगर रिकॉर्ड वहाँ दिखता है, तो जाँच टूल भी उसे दिखाने लगेंगे।

रिपोर्ट कहाँ जाती हैं और उनका क्या करें

हर वह प्राप्त करने वाला सर्वर जिसे From पंक्ति में आपके डोमेन वाला ईमेल मिला, rua पते पर एक रिपोर्ट भेजता है। Google के पेज About DMARC reports (DMARC रिपोर्ट के बारे में) के अनुसार वे “आम तौर पर दिन में एक बार ईमेल से भेजी जाती हैं”। रिपोर्ट एक XML फ़ाइल होती है, आम तौर पर कंप्रेस की हुई, जो ईमेल के साथ अटैच होती है। RFC 9990 इसका फ़ॉर्मैट बताता है।

Google चेतावनी देता है कि बड़े संगठनों को “रोज़ सैकड़ों या हज़ारों तक रिपोर्ट मिल सकती हैं” और एक ग्रुप या अलग मेलबॉक्स की सलाह देता है। संख्या इस पर निर्भर है कि आप कितना भेजते हैं और कितने डोमेन को, इसलिए एक-दो मेलबॉक्स से कहीं कम रिपोर्ट बनती हैं। dmarc@ जैसा एलियास और उसका अपने फ़ोल्डर में जाने वाला फ़िल्टर काफ़ी है।

पता उसी डोमेन पर होना चाहिए जिस पर रिकॉर्ड है। अगर आप रिपोर्ट कहीं और चाहते हैं, तो दूसरे डोमेन को अपना एक रिकॉर्ड प्रकाशित करके सहमति देनी होगी। उसके बिना प्राप्त करने वाले सर्वरों को वह पता अनदेखा करना होता है (RFC 9990, सेक्शन 4)।

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

इसी वजह से मुफ़्त Gmail पता रिपोर्ट के पते के रूप में काम नहीं करता: 5 अक्टूबर 2026 को जब हमने जाँचा, तब gmail.com ने ऐसा कोई रिकॉर्ड प्रकाशित नहीं किया था।

फ़ाइल में हर record ब्लॉक एक भेजने वाले सर्वर के लिए है: उसका IP पता, संदेशों की संख्या, और policy_evaluated के तहत यह कि आपके डोमेन के लिए DKIM और SPF पास हुए या नहीं। आप दो चीज़ें ढूँढ़ रहे हैं। जिन सर्वरों को आप जानते हैं और जो fail दिखाते हैं उन्हें ठीक करना है, और SPF और DKIM पास, फिर भी DMARC फ़ेल बताता है कि कैसे। जिन सर्वरों को आप नहीं जानते वे या तो कोई टूल हैं जिसे आप भूल गए, या कोई आपका नाम इस्तेमाल कर रहा है।

p=none के बाद: नीति कब सख़्त करें

p=none निगरानी का मोड है। यह वह न्यूनतम पूरा करता है जो मेल प्रदाता माँगते हैं, और यह किसी को आपका पता जाली बनाने से नहीं रोकता। यह काम केवल p=quarantine, जो प्राप्त करने वाले सर्वरों से फ़ेल होने वाले ईमेल को संदिग्ध मानने को कहता है, और p=reject, जो उनसे उसे अस्वीकार करने को कहता है, करते हैं।

सख़्त करने से पहले आपके ईमेल के हर जायज़ स्रोत का पास होना ज़रूरी है। RFC 9989 कहता है कि ऐसी कमियों को लागू करने की “किसी भी कोशिश से पहले दूर किया जाना ही चाहिए (MUST)”, और यह कि आप कितनी बार भेजते हैं इसके आधार पर पक्का होने में रिपोर्ट के “कई महीने लग सकते हैं”। Google का रोलआउट पेज एक हफ़्ते की रिपोर्ट को “आम तौर पर काफ़ी” मानता है। एक मेलबॉक्स और एक-दो टूल के साथ आप Google के आँकड़े के ज़्यादा क़रीब हैं, पर कुछ हफ़्ते दें ताकि महीने में एक बार जाने वाले इनवॉइस और संपर्क फ़ॉर्म भी रिपोर्ट में दिख जाएँ।

ख़ुद इस क़दम पर दोनों स्रोत एकमत नहीं हैं। Google अब भी p=quarantine; pct=5 और फिर संख्या बढ़ाने का सुझाव देता है। मानक ने pct हटा दिया है और उसकी जगह यह देता है:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y प्राप्त करने वाले सर्वरों से कहता है कि फ़िलहाल फ़ेल होने वाले ईमेल को एक स्तर नीचे मानें, यानी none की तरह। जब रिपोर्ट साफ़ रहें, तो t=y हटा दें। ध्यान रखें कि जो प्राप्त करने वाला सर्वर इस टैग को नहीं जानता वह इसे अनदेखा करके quarantine पूरी तरह लागू करता है, और अक्टूबर 2026 की स्थिति के अनुसार Google के पेज t का ज़िक्र नहीं करते। अगर सख़्त नीति ऐसे ईमेल पर पड़े जिन्हें आप अभी ठीक नहीं कर सकते, तो p=none पर बने रहें।

WarmupBay की भूमिका

जब आप मेलबॉक्स जोड़ते हैं, WarmupBay उसके डोमेन के SPF, DKIM और DMARC जाँचता है। अगर DMARC रिकॉर्ड गायब है, तो वह आपको कॉपी करने के लिए एक तैयार रिकॉर्ड दिखाता है। आप फिर भी वॉर्मअप शुरू कर सकते हैं। अगर 72 घंटे बाद भी रिकॉर्ड गायब रहें, तो वॉर्मअप रुक जाता है।

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

अक्सर पूछे जाने वाले सवाल

क्या example.com का DMARC रिकॉर्ड news.example.com जैसे सबडोमेन पर भी लागू होता है?

हाँ। प्राप्त करने वाला सर्वर पहले _dmarc.news.example.com पर रिकॉर्ड माँगता है। अगर वहाँ कोई नहीं है, तो वह संगठन के डोमेन example.com के रिकॉर्ड पर लौट आता है। सबडोमेन पर लागू नीति वह है जो sp में है, अगर आपने उसे सेट किया है; नहीं तो वह जो p में है।

क्या मैं rua पते के बिना v=DMARC1; p=none प्रकाशित कर सकता हूँ?

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

क्या मुझे ऐसे दूसरे डोमेन के लिए DMARC रिकॉर्ड चाहिए जिसे मैं केवल आउटरीच के लिए इस्तेमाल करता हूँ?

हाँ। प्राप्त करने वाले सर्वर हर संदेश के From पते का डोमेन देखते हैं, इसलिए आपके मुख्य डोमेन का रिकॉर्ड किसी दूसरे डोमेन पर लागू नहीं होता। दूसरे डोमेन पर वही पंक्ति इस्तेमाल करें। अगर उसकी रिपोर्ट आपके मुख्य डोमेन के किसी पते पर जानी हैं, तो मुख्य डोमेन को वह अनुमति रिकॉर्ड प्रकाशित करना होगा जो “रिपोर्ट कहाँ जाती हैं” के तहत बताया गया है।

ऐसे डोमेन को क्या प्रकाशित करना चाहिए जो कभी ईमेल नहीं भेजता?

सख़्त जोड़ी। M3AAWG उन डोमेन के लिए SPF रिकॉर्ड v=spf1 -all और p=reject वाला DMARC रिकॉर्ड सुझाता है जो कभी ईमेल नहीं भेजते, ताकि कोई उन्हें From पते में इस्तेमाल न कर सके। DMARC के लिए यह _dmarc पर v=DMARC1; p=reject वाली पंक्ति है।

क्या p=none मेरे ईमेल के लिए p=quarantine या p=reject से बुरा है?

Gmail, Yahoo और Outlook.com के भेजने वालों के प्रकाशित नियम कम से कम p=none माँगते हैं और इससे सख़्त कुछ नहीं। नीति तय करती है कि DMARC में फ़ेल होने वाले ईमेल का क्या हो, जिसमें आपके नाम से भेजे गए जाली ईमेल भी शामिल हैं। एक सुविधा को ज़्यादा चाहिए: BIMI, यानी आपके संदेशों के पास दिखने वाला लोगो, Google की सहायता के अनुसार quarantine या reject माँगता है।

स्रोत

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)