Defaults.Exposed › सुधार › Guides

"DMARC Policy Not Enabled": Checkers का क्या मतलब है, और ईमानदार 5-मिनट पहला कदम (2026)

प्रकाशित 2026-07-08

आंकड़े 2026-06-29 तक के · methodology v7. 261 मिलियन ग्रेडेड डोमेन में कुल जनगणना डेटा। देखें हम ग्रेड कैसे करते हैं।

“DMARC policy not enabled” का मतलब दो अलग-अलग चीजें हो सकती हैं: आपके domain का कोई DMARC record नहीं, या p=none पर set record। Defaults.Exposed जनगणना के अनुसार, केवल 10.59% domains — 27,640,987 of 261,086,232 — DMARC policy enforce करते हैं। Monitoring record publish करने में पांच मिनट लगते हैं; enforcement एक project है।

यह guide warning decode करती है, आपको publish करने के लिए exact TXT record और exactly कहां देती है, उन syntax slips के through walks जो first attempts fail करती हैं, और DMARC reports का आपका पहला हफ्ता कैसा दिखता है इसकी ईमानदार expectation set करती है। यह deliberately “5 मिनट में DMARC fix करें” guide नहीं है — पांच मिनट आपको visibility देते हैं, protection नहीं।

“DMARC policy not enabled” का वास्तव में क्या मतलब है?

MXToolbox जैसे checkers दो अलग-अलग findings को एक orange warning में collapse करते हैं, और fix path depend करता है आपके पास कौन सा है:

Data 2026-06-29 तक का।

पहली row वह है जहां internet का अधिकांश हिस्सा रहता है: 75.11% ग्रेडेड domains कोई DMARC record publish नहीं करते, और बाकी 14.29% p=none पर बैठे हैं। आखिरी row का inverse वह number है जो मायने रखती है: 89.41% domains का कोई enforced DMARC policy नहीं — जनगणना में 261,086,232 ग्रेडेड domains में से। यदि आपका checker warning दिखाता है, आप overwhelming majority में हैं। यह reassurance नहीं है; यह कारण है कि spoofing cheap रहती है।

एक clarification जो बाद में confusion बचाती है: DMARC SPF और DKIM के ऊपर policy layer है, आपके recipient द्वारा actually देखे गए From header के विरुद्ध checked। “Not enabled” का मतलब है आपने अभी receivers को कुछ करने के लिए नहीं कहा। यदि तीन policy values आपके लिए नए हैं, plain-English explainer है DMARC क्या है: none, quarantine, reject।

आप पांच मिनट में ईमानदारी से क्या fix कर सकते हैं?

एक record publish करना। यही पूरा honest claim है।

v=DMARC1; p=none; rua=mailto:[email protected]

यह TXT record live होने के पांच मिनट बाद, DMARC check करने वाले receivers daily reports compile करना शुरू करेंगे आपके domain के रूप में mail भेजने वाले सभी के बारे में — legitimate servers और imposters समान रूप से। वह visibility genuinely valuable और genuinely instant है।

यह नहीं करता: p=none कुछ protect नहीं करता। Spoofed mail exactly वैसे ही deliver होती है जैसे कल थी, और कल re-scanning करने वाला checker अभी भी “policy not enabled” कह सकता है — correctly, क्योंकि green tick quarantine या reject के लिए reserved है। हमने लिखा है कि क्यों p=none protection नहीं है में; staged path एक policy की ओर जो actually spoofing block करती है p=none से p=reject है। नीचे का five-minute step शुरू करने का तरीका है; वह guide finish करने का तरीका है।

आप अपना पहला DMARC record कैसे publish करते हैं?

1. DNS छूने से पहले मुफ़्त स्कैन चलाएं। यह बताता है कि आपके पास कौन सा दो findings हैं — no record बनाम p=none — और SPF और DKIM नीचे मौजूद हैं या नहीं, जो decide करता है कि आप बाद में enforcement की ओर कितनी जल्दी move कर सकते हैं।
2. Reports receive करने के लिए address चुनें। एक dedicated mailbox जैसे dmarc-reports@yourdomain शुरू करने के लिए fine है। यदि आप report-analysis service उपयोग करते हैं, नीचे FAQ देखें — third-party addresses में silent gotcha है।
3. Host _dmarc पर TXT record जोड़ें। अधिकांश DNS control panels में (worked example के लिए IONOS DMARC setup guide देखें) आप host/name field में _dmarc enter करते हैं — panel आपका domain automatically append करता है, _dmarc.yourdomain.com produce करता है। Value: v=DMARC1; p=none; rua=mailto:[email protected]
4. Verify करें कि resolve हुआ। dig TXT _dmarc.yourdomain.com (या कोई भी online checker) exactly एक record return करे जो v=DMARC1 से शुरू होता है। अधिकांश DNS changes मिनटों में visible हैं; low TTL helps।
5. Re-scan करें। आपकी report monitoring mode में DMARC present दिखाएगी — एक honest reflection of where you are: reporting on, enforcement pending।

एक record आपके subdomains को भी cover करता है: receivers जो mail.yourdomain.com पर कोई record नहीं पाते organizational domain की policy पर fall back करते हैं, इसलिए आपको monitoring शुरू करने के लिए per subdomain record की जरूरत नहीं।

Record add करते समय सबसे common mistakes क्या हैं?

लगभग हर failed first attempt इनमें से एक है — और वे मायने रखती हैं, क्योंकि unparseable record को no record की तरह treat किया जाता है। Census 48,648 published DMARC records count करता है जो parse fail करते हैं; misspellings जो लोग actually publish करते हैं DMARC typos census में catalogued हैं।

• गलत host। Record _dmarc.yourdomain.com पर live होना चाहिए, apex पर नहीं। Bare domain पर यह कुछ नहीं करता, और checkers “no DMARC record found” report करते रहते हैं।
• Domain double-appending। Panel में _dmarc.yourdomain.com type करने से जो auto-appends करता है _dmarc.yourdomain.com.yourdomain.com मिलता है। केवल _dmarc enter करें।
• Semicolons की जगह commas। Tags ; से separated होते हैं। Unparseable record को no record treat किया जाता है।
• Missing या misplaced v=DMARC1। यह first tag होना चाहिए, exactly spelled; p= से शुरू होने वाले records parsing fail करते हैं।
• rua में mailto: missing। rua=dmarc@yourdomain invalid है; यह rua=mailto:[email protected] होना चाहिए।
• दो DMARC records। Receivers जो एक से अधिक v=DMARC1 record find करते हैं सभी ignore करते हैं — multi-record SPF के same failure family।
• Copy-paste से smart quotes। एक document से smuggled curly quotes या non-breaking spaces parsing break करते हैं। Record retype करें यदि checker कहता है malformed है लेकिन यह सही दिखता है।

Week one में rua reports कैसे दिखेंगी?

Expectations अभी set करें ताकि आप यह न conclude करें कि यह broken है:

• वे roughly daily आती हैं, per receiver। Google typically हर 24 घंटे में एक aggregate report भेजता है; Microsoft, Yahoo और अन्य अपने cycles पर। एक small domain के लिए, week one में आमतौर पर कुछ emails होती हैं, mostly [email protected] से।
• वे compressed XML attachments हैं, dashboard नहीं। Raw, वे near-unreadable हैं; free parser उन्हें sender table में बदलता है।
• Volume आपके mail volume को track करता है। यदि आप कम mail भेजते हैं, या mostly उन providers को जो report नहीं करते, sparse data expect करें। दो quiet हफ्ते low-volume domain के लिए normal है — यह assume करने की बजाय कि fail हुआ, dig से record verify करें।
• Surprises expect करें। अधिकांश domains उन senders discover करते हैं जो भूल गए थे — CRM, invoicing tool, contact form। हर एक को SPF या DKIM aligned enforce करने से पहले चाहिए। यदि reports DMARC fail दिखाती हैं जबकि SPF और DKIM individually pass करते हैं, वह alignment problem है — DMARC fails but SPF and DKIM pass देखें।

और reports ask करें: 64.3% domains जिनके पास DMARC record है कोई rua= address publish नहीं करते, इसलिए उन्हें इससे कोई reports नहीं मिलती — उस पर census cut DMARC publishing blind में है। यहां सब कुछ जो आप सीखते हैं enforcement rollout को feed करता है — monitoring उस project का week one है, destination नहीं। p=none पर indefinitely parking वह सबसे common तरीका है जिससे domains 89.41% में end up होते हैं।

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

क्या p=none publish करने से मेरी email deliverability hurt होगी? नहीं। p=none receivers के आपकी mail treat करने के तरीके में कुछ नहीं बदलता — यह केवल reports request करता है। यह help कर सकता है: Google और Yahoo के bulk-sender requirements high-volume senders से कम से कम p=none DMARC record demand करते हैं, इसलिए इसे publish करना compliance floor है, risk नहीं।

मैंने record publish किया — checker अभी भी “policy not enabled” क्यों कहता है? क्योंकि यह सच बोल रहा है: आपकी policy none है, और checkers pass quarantine या reject के लिए reserve करते हैं। आप उन domains में join हो गए जो monitor करते हैं लेकिन enforce नहीं करते — 2026-06-29 तक, केवल 10.59% of 261,086,232 ग्रेडेड domains enforce करते हैं। Warning तब clear होती है जब आप enforcement rollout complete करते हैं।

क्या DMARC add करने से पहले SPF और DKIM set up होने चाहिए? आपकी mail को DMARC pass करने के लिए aligned उनमें से कम से कम एक चाहिए — लेकिन p=none publish करने से पहले आपको उन्हें perfect नहीं चाहिए। Monitoring precisely वह है कि आप क्या broken है पाते हैं: 70,368,600 of 261,086,232 ग्रेडेड domains (2026-06-29 तक) soft SPF और कोई DMARC enforcement नहीं है, और reports वह है जिससे उन्हें पता चलेगा कि उन्हें क्या stall कर रहा है।

क्या मैं अपनी mailbox की बजाय third-party analyzer को reports भेज सकता हूं? हां — लेकिन किसी अलग domain पर rua address को vendor को authorization record (yourdomain._report._dmarc.vendor.com) publish करने की require है, या receivers silently reports withhold करते हैं। Reputable services यह automatically करती हैं; यदि reports कभी नहीं आतीं, पहले यह check करें।

मालिक को रिपोर्ट भेजें

यदि आप किसी client या नियोक्ता के लिए यह fix कर रहे हैं, work को invisible न होने दें। Record resolve होने के बाद मुफ़्त स्कैन फिर से चलाएं और graded report forward करें: यह DMARC को absent से monitored की ओर move होते हुए दिखाता है, timestamped और plain English में — और यह दिखाता है कि enforcement के path पर आगे क्या है। Owners increasingly cyber-insurance renewals और supplier security questionnaires के लिए exactly यह evidence चाहते हैं, और एक-page graded report उन questions का DNS panel screenshot से बेहतर जवाब देती है।

अपना डोमेन मुफ़्त में जांचें

देखें आपके पास दो findings में से कौन सा है — no record या p=none — और इसके नीचे क्या है, privately और owner-only।

अपना डोमेन जांचें → · DMARC ठीक करें → · p=none से p=reject → · हम ग्रेड कैसे करते हैं → · केवल समग्र डेटा। डेटा EU में संग्रहीत और संसाधित।