[ DMARC और नीति ]

DMARC p=none: प्रवर्तन से पहले क्या निगरानी स्थापित की जा सकती है

निगरानी से देखे गए प्रेषकों, प्रमाणीकरण अंतराल और नीति प्रभाव की पहचान करने में मदद मिलती है। यह पूर्ण कवरेज साबित नहीं करता है या अस्वीकृति के लिए एक निश्चित प्रतीक्षा अवधि को पर्याप्त नहीं बनाता है।

EmailAuth अनुसंधान टीम द्वारा · 7 मिनट पढ़ा

[ प्रमुख बिंदु ]

  • एक निगरानी विंडो देखे गए ट्रैफ़िक को कवर करती है, प्रत्येक संभावित प्रेषक को नहीं।
  • अज्ञात आरोप को तब तक सुरक्षित रखें जब तक साक्ष्य इसका समाधान न कर दे।
  • महत्वपूर्ण मार्गों, अप्रत्यक्ष मेल और पुनर्प्राप्ति तत्परता का उपयोग करके नीति चुनें।
इस पेज पर

अंतर्गत RFC 9989 §4.7, a DMARC की नीति p=none DMARC विफलताओं के लिए कोई डोमेन-स्वामी प्रबंधन प्राथमिकता व्यक्त नहीं करता है। जब रिपोर्टिंग कॉन्फ़िगर और समीक्षा की जाती है, तो यह जानने का अवसर मिलता है कि कौन सी सेवाएँ डोमेन का उपयोग करती हैं, वैध संदेश कहाँ विफल होते हैं और नीति परिवर्तन क्या प्रभावित कर सकता है।

जाँच के माध्यम से निगरानी उपयोगी हो जाती है। रिपोर्टों को एक संग्रह प्रणाली तक पहुंचने की आवश्यकता है, स्रोतों को मालिकों की आवश्यकता है और अनसुलझी विफलताओं को निर्णयों की आवश्यकता है। बीता हुआ समय या एक उच्च उत्तीर्ण प्रतिशत यह स्थापित नहीं कर सकता कि प्रत्येक महत्वपूर्ण सेवा को कवर किया गया है।

रिपोर्टिंग संग्रह को अवलोकनीय बनाएं

निगरानी परिनियोजन की शुरुआत करने वाले डोमेन के लिए, एक उदाहरणात्मक नीति है:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

उदाहरण इरादा मानता है _dmarc प्रकाशन और एक कार्यशील समान-डोमेन संग्रह पता। यदि डोमेन में पहले से ही एक मजबूत अनुमोदित नीति है, तो केवल एक उदाहरण से मिलान करने के लिए इसे कमजोर न करें। उपयोग रिकॉर्ड वर्कफ़्लो वास्तविक कॉन्फ़िगरेशन को सत्यापित करने के लिए।

अगले RFC 9990 §4 बाहरी अनुमति के लिए और RFC 9989 §5.3.8 रिसीवर रिपोर्टिंग के लिए, रिपोर्टिंग गंतव्य, किसी आवश्यक बाहरी-गंतव्य अनुमति, मेल डिलीवरी और पार्सिंग की जांच करें। रिपोर्टर की पहचान, अवधि और प्रासंगिक कॉन्फ़िगरेशन इतिहास बनाए रखें। एक प्रदाता से रिपोर्ट प्राप्त करना उस अवलोकन के लिए एक कार्य पथ प्रदर्शित करता है; यह सार्वभौमिक कवरेज साबित नहीं करता है.

सेवाओं को वर्गीकृत करें और अनिश्चितता को सुरक्षित रखें

प्रत्येक सार्थक स्रोत पैटर्न के लिए, एप्लिकेशन, ग्राहक-विशिष्ट खाते या रूट, डोमेन से दृश्यमान, लिफाफा पहचान, हस्ताक्षर करने वाली पहचान और मालिक की जांच करें।

स्पष्ट कार्य श्रेणियों का उपयोग करें:

  • श्रेणी: अपेक्षित संरेखित पथ के साथ स्वीकृत सेवा; अगली कार्रवाई: स्वामित्व बनाए रखें और परिवर्तनों की निगरानी करें
  • श्रेणी: अनुमोदित सेवा विफल प्रमाणीकरण या संरेखण; अगली कार्रवाई: समर्थित कॉन्फ़िगरेशन को सही करें और उसका परीक्षण करें
  • श्रेणी: वैध अप्रत्यक्ष मार्ग; अगली कार्रवाई: अग्रेषण, संशोधन और रिसीवर हैंडलिंग का विश्लेषण करें
  • श्रेणी: अज्ञात स्रोत; अगली कार्रवाई: अनिश्चितता बनाए रखें और जांच करें
  • श्रेणी: अनधिकृत उपयोग की पुष्टि; अगली कार्रवाई: सहायक साक्ष्य और प्रतिक्रिया रिकॉर्ड करें

किसी प्रेषक को स्वीकृत करने के लिए क्लाउड प्रदाता का नाम, ASN या देश पर्याप्त नहीं है। समान रूप से, एक विफल पंक्ति प्रत्येक संबद्ध संदेश को दुर्भावनापूर्ण घोषित करने के लिए पर्याप्त नहीं है।

कारगर उदाहरण: एक शांत खिड़की से पेरोल छूट जाता है

एक उदाहरणात्मक संगठन पर विचार करें जो दस दिनों के कर्मचारी और विपणन मेल की समीक्षा करता है। रिपोर्ट स्वस्थ लग रही है. उस अवधि के दौरान मासिक पेरोल सेवा नहीं भेजी गई है, और इसके हस्ताक्षर कॉन्फ़िगरेशन का परीक्षण नहीं किया गया है।

सही निष्कर्ष यह है कि उन दस दिनों में देखी गई धाराएँ स्वस्थ दिखीं। ऐसा नहीं है कि पूरा डोमेन अधिक प्रतिबंधात्मक नीति के लिए तैयार है।

टीम सीधे पेरोल मार्ग की जांच और परीक्षण कर सकती है, किसी अन्य आवधिक सेवाओं की पहचान कर सकती है और इसके साक्ष्य का विस्तार कर सकती है। अवलोकन विंडो को डैशबोर्ड से चुनी गई सार्वभौमिक संख्या के बजाय वास्तविक व्यापार चक्र और प्रासंगिक अंतरसंचालनीयता विचारों को प्रतिबिंबित करना चाहिए।

ऐसी नीति चुनें जो डोमेन के अनुकूल हो

यह निर्णय पास-रेट लक्ष्य से अधिक व्यापक है। महत्वपूर्ण-सेवा कवरेज, जवाबदेह मालिकों, एक मूल्यांकन की गई अप्रत्यक्ष-मेल आबादी, उच्च-प्रभाव वाली विफलताओं का समाधान और एक पुनर्प्राप्ति प्रक्रिया की आवश्यकता है।

RFC 9989 §7.4 के प्रति स्पष्ट रूप से सावधान करता है p=reject सामान्य प्रयोजन के ईमेल के लिए और उन डोमेन पर चर्चा करता है जिनके उपयोगकर्ता इंटरनेट मेलिंग सूचियों में भाग लेते हैं। इसके अंतरसंचालनीयता मार्गदर्शन में उन डोमेन के लिए विशिष्ट अवलोकन और तुलना चरण शामिल हैं। उस मार्गदर्शन को एक सामान्य वादे से न बदलें कि प्रत्येक मॉनिटर किए गए डोमेन को अंततः अस्वीकार कर दिया जाना चाहिए।

एक कसकर नियंत्रित लेन-देन भेजने वाले डोमेन और सामान्य कर्मचारी पत्राचार के लिए उपयोग किए जाने वाले डोमेन में अलग-अलग परिचालन बाधाएं हो सकती हैं। परिणामी कॉन्फ़िगरेशन और वास्तविक संदेशों को सत्यापित करते हुए, अलग-अलग पहचान धाराएं जहां यह वास्तविक शासन उद्देश्य को पूरा करती हैं।

अगले निर्णय के लिए साक्ष्य परिभाषित करें

प्रवर्तन समीक्षा को सबूत के साथ इन सवालों का जवाब देना चाहिए:

  • क्या महत्वपूर्ण वैध सेवाओं की पहचान, स्वामित्व और परीक्षण किया गया है?
  • क्या प्रत्येक प्रभावित सेवा के पास एक समर्थित संरेखित पथ है?
  • क्या आवधिक और कम मात्रा वाले प्रवाह पर विचार किया गया है?
  • क्या मेल सूचियाँ, अग्रेषण और अन्य अप्रत्यक्ष मार्ग समझ में आ रहे हैं?
  • क्या रिपोर्टिंग कवरेज को भेजे गए सभी ईमेल के रूप में माने बिना वर्णित किया गया है?
  • क्या अपवादों का दायरा, स्वामित्व और समीक्षा के लिए निर्धारित किया गया है?
  • क्या टीम प्रस्तावित परिवर्तन को मंजूरी दे सकती है, सत्यापित कर सकती है और उससे उबर सकती है?

निर्णय प्रेषक को बेहतर बनाने, डोमेन पृथक्करण को बदलने, निगरानी जारी रखने या डोमेन के दस्तावेजी उपयोग के लिए उपयुक्त नीति लागू करने का हो सकता है। तर्क को परिवर्तन रिकार्ड के साथ रखें।

निष्कर्षों के लिए स्वामियों को नियुक्त करें

पूछें कि टीम क्या सीखने की उम्मीद करती है और निष्कर्षों पर कौन कार्रवाई करेगा। व्यवसाय के लिए कौन सी सेवाएँ भेजी जाती हैं? कौन से महत्वपूर्ण संदेश विफल हो जाते हैं? कौन से स्पष्ट प्रेषक अज्ञात रहते हैं? कौन सा साक्ष्य अगला कदम निर्धारित करेगा?

आईटी टीम के तत्काल दृष्टिकोण से बाहर के कार्य को शामिल करें। एक मासिक पेरोल अधिसूचना या वार्षिक नवीनीकरण नोटिस महत्वपूर्ण हो सकता है जबकि समग्र संदेश में बहुत कम योगदान होता है।

एक मजबूत नीति के लिए स्वचालित उलटी गिनती से बचें। कुछ दृश्यमान विफलताओं वाले एक सप्ताह का मतलब स्वस्थ प्रेषण, अपूर्ण रिपोर्टिंग या ऐसी सेवा हो सकती है जो अभी तक नहीं भेजी गई है। केवल बीते हुए दिनों के लिए ही नहीं, बल्कि बनाए रखी गई इन्वेंट्री और बंद निष्कर्षों के लिए भी भुगतान करें।

नीति परिवर्तन के बाद निगरानी जारी रखें

नया सॉफ़्टवेयर, आपूर्तिकर्ता परिवर्तन, कुंजी रोटेशन और DNS संपादन ताज़ा अंतराल पैदा कर सकते हैं। किसी भी नीति परिवर्तन के बाद नए प्रेषकों और वैध विफलताओं की जांच जारी रखें।

व्यवसायिक नेताओं को अवशिष्ट जोखिम के बारे में बताएं: प्राप्तकर्ता अपने स्वयं के प्रबंधन विकल्पों को बनाए रखते हैं RFC 9989 §5.4, और डोमेन प्रमाणीकरण प्रत्येक समान दिखने वाले संदेश, खाते से छेड़छाड़ या धोखाधड़ी वाले अनुरोध को नहीं रोकता है। साक्ष्य व्याख्या के लिए, उपयोग करें समग्र-रिपोर्ट वॉकथ्रू. रॉ-पास विफलता के लिए, उपयोग करें संरेखण मार्गदर्शिका.

व्यावहारिक उपाय

निगरानी का आउटपुट एक स्वामित्व वाली प्रेषक सूची, सत्यापित महत्वपूर्ण मार्ग और एक तर्कसंगत नीति निर्णय होना चाहिए। जैसे-जैसे वातावरण बदलता है, निगरानी करते रहें ताकि बाद में कोई एप्लिकेशन, कुंजी या गेटवे परिवर्तन चुपचाप उसी अंतराल को फिर से न खोल दे।

निर्णय और उसकी सीमाएं रिकॉर्ड करें

काल्पनिक दस-दिवसीय विंडो के लिए, मासिक वेतन को स्वस्थ के रूप में चिह्नित करने के बजाय परीक्षण न किए गए के रूप में छोड़ दें। इसके स्वामी, अगले प्रतिनिधि वर्कफ़्लो और अंतर को पाटने के लिए आवश्यक साक्ष्य जोड़ें। यदि संग्रह काम कर रहा है लेकिन एप्लिकेशन कभी नहीं भेजा गया, तो उसी रिपोर्ट का अधिक विश्लेषण इसके प्रमाणीकरण को स्थापित नहीं कर सकता है। इस उदाहरण के लिए कोई रिपोर्ट या पेरोल परीक्षण एकत्र नहीं किए गए थे।

[ ले लेना ]

एक निगरानी विंडो देखे गए ट्रैफ़िक को कवर करती है, प्रत्येक संभावित प्रेषक को नहीं। अज्ञात आरोप को तब तक सुरक्षित रखें जब तक साक्ष्य इसका समाधान न कर दे। महत्वपूर्ण मार्गों, अप्रत्यक्ष मेल और पुनर्प्राप्ति तत्परता का उपयोग करके नीति चुनें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

संग्रह और वर्गीकरण प्रक्रिया को दृश्यमान बनाएं।

गंतव्य और अंतर्ग्रहण पथ को सत्यापित करें, रिपोर्ट संदर्भ को संरक्षित करें और संदेशों और सेवा कॉन्फ़िगरेशन के विरुद्ध स्रोत पैटर्न की जांच करें। अज्ञात विशेषता को स्पष्ट रखें.

अगले कदम

  1. जहां आवश्यक हो, बाहरी-गंतव्य अनुमति की जांच करें।
  2. आंख मूंदकर इंतजार करने के बजाय सीधे आवधिक सेवाओं का परीक्षण करें।
  3. प्रत्येक प्रेषक वर्गीकरण का समर्थन करने वाले साक्ष्य अपने पास रखें।

सीआईएसओ/सेकऑप्स

डोमेन के दस्तावेज़ी उपयोग के लिए नीति चुनें.

एक सामान्य पत्राचार डोमेन और एक कसकर नियंत्रित लेन-देन संबंधी पहचान में अलग-अलग बाधाएं हो सकती हैं। किसी नीति को मंजूरी देने से पहले वर्तमान अंतरसंचालनीयता मार्गदर्शन और महत्वपूर्ण-प्रवाह साक्ष्य की समीक्षा करें।

अगले कदम

  1. मेलिंग सूचियों, अग्रेषण और अपवादों का आकलन करें।
  2. स्वामित्व, पुनर्प्राप्ति शर्तों और समीक्षा तिथि की आवश्यकता है।
  3. किसी भी नीतिगत निर्णय के बाद निगरानी जारी रखें।

संस्थापक/गैर-तकनीकी

निगरानी को नामांकित कार्य में बदलें.

अवलोकन से आपके व्यवसाय द्वारा उपयोग की जाने वाली सेवाओं और उन महत्वपूर्ण संदेशों की पहचान होनी चाहिए जिन पर ध्यान देने की आवश्यकता है। पूछें कि टीम क्या सीखेगी, कौन इस पर कार्य करेगा और कौन से साक्ष्य अगले निर्णय का समर्थन करेंगे।

अगले कदम

  1. इन्वेंट्री में मासिक और मौसमी सेवाएं शामिल करें।
  2. स्वस्थ दिखने वाले कुल योग की तुलना में महत्वपूर्ण विफलताओं को प्राथमिकता दें।
  3. बंद निष्कर्षों के लिए पूछें, न कि केवल बीते हुए निगरानी दिनों के लिए।

[ पूछे जाने वाले प्रश्न ]

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

क्या p=none SPF या DKIM जाँच को अक्षम कर देता है?

नहीं, वे तंत्र और DMARC मूल्यांकन अभी भी चल सकते हैं। नीति DMARC विफलता के लिए कोई डोमेन-स्वामी प्रबंधन प्राथमिकता व्यक्त नहीं करती है; यह प्रमाणीकरण छोड़ने का निर्देश नहीं है।

RFC 9989 §4.7

क्या कोई प्राप्तकर्ता मेल को अस्वीकार कर सकता है जबकि डोमेन p=none?

हाँ। प्राप्तकर्ता अपनी फ़िल्टरिंग, प्रतिष्ठा, प्राप्तकर्ता और अन्य नीतियां लागू कर सकता है। कोई भी गारंटी-डिलीवरी सेटिंग नहीं है।

RFC 9989 §5.4

क्या निगरानी नीति स्वचालित रूप से उपयोगी रिपोर्ट तैयार करती है?

नहीं, रिपोर्टिंग अनुरोध, गंतव्य अनुमति जहां लागू हो, वितरण, पार्सिंग और परिचालन समीक्षा काम करनी चाहिए। भागीदारी की रिपोर्टिंग में भी रिसीवर भिन्न-भिन्न होते हैं।

RFC 9989 §5.3.8 RFC 9990 §4

क्या उच्च उत्तीर्ण दर निगरानी छोड़ने के लिए पर्याप्त है?

नहीं, अंतर्निहित जनसंख्या, महत्वपूर्ण सेवाओं, अनसुलझे स्वामित्व और अप्रत्यक्ष मार्गों की जाँच करें। एक उच्च-मात्रा वाली स्वस्थ धारा एक असफल महत्वपूर्ण धारा को छुपा सकती है।

अवलोकन अवधि कितने समय तक चलनी चाहिए?

इसे डोमेन के भेजने के चक्र, प्रासंगिक मानक मार्गदर्शन और साक्ष्य आवश्यकताओं से मिलाएं। कवरेज या सुरक्षा के प्रमाण के रूप में बीता हुआ समय अकेले उपयोग न करें।

क्या प्रत्येक डोमेन को अंततः प्रकाशित अस्वीकार कर देना चाहिए?

कोई भी सार्वभौमिक प्रगति उचित नहीं है। RFC 9989 सामान्य प्रयोजन डोमेन और मेलिंग-सूची अंतरसंचालनीयता के बारे में चेतावनी देता है। डोमेन उपयोग, वैध प्रवाह और लागू मार्गदर्शन के आधार पर नीति चुनें।

RFC 9989 §7.4

क्या एक मजबूत नीति लागू होने के बाद निगरानी बंद कर देनी चाहिए?

नहीं, नई सेवाएँ, परिवर्तित मार्ग और पुरानी अनुमतियाँ बाद में समस्याएँ ला सकती हैं। निष्कर्षों पर कार्रवाई के लिए संग्रह, स्वामित्व और एक प्रक्रिया बनाए रखें।

निगरानी से उपयोगी परिणाम क्या है?

एक स्वामित्व वाली प्रेषक सूची, सत्यापित वैध मार्ग, महत्वपूर्ण अंतराल को हल किया गया, सीमाओं को समझा गया और परिवर्तन और पुनर्प्राप्ति प्रक्रिया के साथ एक दस्तावेजी नीति निर्णय लिया गया।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 9989

    धारा §4.7 · §5.3.8 · §5.4 · §7.4

  2. RFC 9990

    धारा §3.1 · §4

[ शब्दकोष ]

शब्दकोष

रिपोर्टिंग कवरेज
रिपोर्ट द्वारा दर्शाए गए प्राप्तकर्ता और अवलोकन अवधि; समग्र रिपोर्टिंग भेजे गए मेल की संपूर्ण जनगणना नहीं है।

RFC 9989 §5.3.8 RFC 9990 §3.1

अज्ञात स्रोत
ऐसा अवलोकन जिसे अभी तक किसी अनुमोदित सेवा या पुष्टिकृत दुरुपयोग के लिए जिम्मेदार नहीं ठहराया गया है; जांच लंबित रहने तक अनिश्चितता बरकरार है।

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

पारंपरिक ईमेल प्रमाणीकरण प्लेटफ़ॉर्म आपको एक डैशबोर्ड बेचते हैं और आपके इंजीनियरों से काम करने के लिए कहते हैं। उच्च जोखिम वाले वातावरण में, मैन्युअल निरीक्षण का अर्थ है विलंबित प्रवर्तन, कॉन्फ़िगरेशन बहाव और अनियंत्रित छाया डोमेन।

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार