लिंक समाप्त होने के बाद आने वाला पासवर्ड रीसेट ग्राहक के लिए विफल हो गया है, भले ही उसका प्रमाणीकरण सही हो। एक रसीद जो कभी भी इच्छित मेलबॉक्स तक नहीं पहुंचती है, भेजने वाले प्लेटफ़ॉर्म से सफल एपीआई प्रतिक्रिया के बावजूद समर्थन कार्य बना सकती है।
DMARC लेन-देन संबंधी मेल को भरोसेमंद बनाने का एक हिस्सा है। प्रत्येक ग्राहक वर्कफ़्लो के आसपास प्रमाणीकरण कॉन्फ़िगरेशन बनाएं, फिर उन चरणों को मापें जो यह तय करते हैं कि संदेश उपयोगी रहेगा या नहीं।
सेवा को परिभाषित करें, न कि केवल डोमेन को
डोमेन द्वारा भेजे जाने वाले संदेशों की सूची बनाएं: लॉगिन कोड, पासवर्ड रीसेट, चालान, भुगतान नोटिस, रसीदें और खाता परिवर्तन। एप्लिकेशन स्वामी, भेजने वाले खाते, पहचान से, वापसी पथ, हस्ताक्षरित पहचान और प्रासंगिक फ़ॉलबैक मार्ग को रिकॉर्ड करें।
प्रत्येक प्रवाह को एक व्यावसायिक परिणाम दें। एक संक्षिप्त समाप्ति से पहले एक लॉगिन कोड आने की आवश्यकता हो सकती है। एक रसीद अधिक देरी को सहन कर सकती है लेकिन फिर भी उसे खोजने योग्य लेनदेन संदर्भ की आवश्यकता होती है। ये आपके सेवा उद्देश्य हैं, DMARC द्वारा बनाए गए डिलीवरी वादे नहीं।
उपयोग प्रेषक सूची उन अपेक्षाओं को वास्तविक प्रेषण कॉन्फ़िगरेशन से जोड़ने के लिए। यह मानने के बजाय कि प्राथमिक प्रदाता की सेटिंग्स उन्हें कवर करती हैं, बैकअप क्षेत्रों और खातों को शामिल करें।
प्रत्येक एप्लिकेशन रूट द्वारा उपयोग की गई पहचान सत्यापित करें
नियंत्रित प्रतिनिधि संदेश के लिए, वास्तविक फ्रॉम डोमेन, एसपीएफ़-मूल्यांकित पहचान और प्रत्येक का निरीक्षण करें DKIM डोमेन पर हस्ताक्षर करना. कच्चे प्रमाणीकरण और दोनों को सत्यापित करें संरेखण DMARC के लिए प्रासंगिक।
अंतर्गत RFC 9989 §5.3.5, एक गुजरता हुआ संरेखित SPF या DKIM पथ लागू नीति मौजूद होने पर संदेश-स्तरीय DMARC शर्त को पूरा कर सकता है। के अंतर्गत पूर्ण भागीदारी RFC 9989 §8 इसके अतिरिक्त संरेखित SPF और DKIM , रिपोर्टिंग और नीति प्रकाशन की आवश्यकता होती है। अंतर्गत RFC 9989 §7.4, एक अस्वीकार-नीति डोमेन को केवल SPF पर निर्भर नहीं होना चाहिए और वैध DKIM हस्ताक्षर लागू करना चाहिए।
यह अंतर तब मायने रखता है जब क्लाउड प्लेटफ़ॉर्म व्यापक "प्रमाणीकृत" स्थिति लौटाता है। एक डोमेन कॉन्फ़िगरेशन पृष्ठ यह स्थापित नहीं करता है कि एप्लिकेशन खाता, उत्पादन क्षेत्र और संदेश प्रकार ने परीक्षण किए गए संदेश पर अपेक्षित पहचान का उपयोग किया है।
किसी लेन-देन का उसके सभी मील के पत्थर पर नज़र रखें
आवेदन घटना, प्रस्तुतिकरण और प्राप्तकर्ता साक्ष्य को अलग रखें। एक प्रदाता द्वारा एपीआई अनुरोध स्वीकार करना, ट्रांसमिशन के बाद संदेश स्वीकार करने वाले SMTP रिसीवर के समान घटना नहीं है। डेटा ट्रांसफर की समाप्ति के बाद सकारात्मक समापन वितरण जिम्मेदारी के तहत RFC 5321 §4.2.5; रिसीवर की स्वीकृति इनबॉक्स प्लेसमेंट, डिस्प्ले या रीडिंग को साबित नहीं करती है।
यह काल्पनिक परीक्षण उदाहरण एप्लिकेशन द्वारा चुने गए पांच मिनट के रीसेट-लिंक जीवनकाल का उपयोग करता है:
- यूटीसी समय: 12:00:00 ; मील का पत्थर: रीसेट अनुरोध बनाया गया; अर्थ: एप्लिकेशन लेनदेन शुरू करता है
- यूटीसी समय: 12:00:02 ; मील का पत्थर: भेजने वाला प्लेटफ़ॉर्म सबमिशन स्वीकार करता है; अर्थ: सबमिशन उस प्लेटफ़ॉर्म सीमा पर सफल हुआ
- यूटीसी समय: 12:00:20 ; मील का पत्थर: प्राप्तकर्ता सर्वर डेटा के बाद संदेश स्वीकार करता है; अर्थ: उस रिसीवर को SMTP हैंडऑफ़ सफल हुआ
- यूटीसी समय: 12:00:27 ; मील का पत्थर: नियंत्रित परीक्षण मेलबॉक्स संदेश को उजागर करता है; अर्थ: इस परीक्षण प्राप्तकर्ता के लिए उपलब्धता देखी गई
- यूटीसी समय: 12:05:00 ; मील का पत्थर: रीसेट लिंक समाप्त हो रहा है; अर्थ: आवेदन की उपयोगिता की समय सीमा
परीक्षण संदेश चार मिनट और तैंतीस सेकंड शेष रहते उपलब्ध था। यह काल्पनिक परीक्षण में एक अवलोकन है, प्रत्येक ग्राहक के लिए कोई बेंचमार्क या गारंटी नहीं है।
यदि कोई प्राप्तकर्ता अस्थायी रूप से 12:06 तक संदेश को स्थगित कर देता है, तो बाद में सफल डिलीवरी अभी भी इस वर्कफ़्लो की समय सीमा से चूक जाएगी। घटना को समाप्ति विफलता के रूप में दर्ज किया जाना चाहिए, भले ही अंतिम संदेश DMARC पास हो जाए।
देरी का पता लगाने के लिए पर्याप्त सबूत रखें
एक लेन-देन पहचानकर्ता का उपयोग करें जिसका एप्लिकेशन लॉग और भेजने वाली सेवा से मिलान किया जा सके। लौटाए गए SMTP टेक्स्ट, कतार घटनाओं और उपलब्ध प्राप्त-संदेश हेडर को रिकॉर्ड करें। समय को एक सुसंगत समय क्षेत्र में रखें।
विलंबित ग्राहक शिकायत से DMARC अस्वीकृति का अनुमान न लगाएं। प्रमाणीकरण विफलताओं, अस्थायी स्थगन, स्थानीय फ़िल्टरिंग, पता समस्याओं और एप्लिकेशन त्रुटियों के लिए अलग-अलग उपचार की आवश्यकता होती है। अस्वीकृति के लिए, पूर्ण लौटाई गई प्रतिक्रिया और भेजने-प्लेटफ़ॉर्म ईवेंट उपलब्ध साक्ष्य हो सकते हैं क्योंकि कोई वितरित संदेश मौजूद नहीं है।
वितरित परीक्षण के लिए, विश्वसनीय रिसीवर द्वारा वर्णित सीमा के भीतर परिणाम मिलता है RFC 8601 §7.1 प्रमाणीकरण और संरेखण दिखा सकते हैं। रखे गए नमूनों और लॉग को जांच की आवश्यकता तक सीमित रखें; रीसेट टोकन या पूर्ण संदेश सामग्री को साझा टिकट में लापरवाही से कॉपी नहीं किया जाना चाहिए।
उस मार्ग का परीक्षण करें जिसका ग्राहक वास्तव में उपयोग कर सकता है
एक प्रत्यक्ष परीक्षण मेलबॉक्स उपयोगी है लेकिन प्रत्येक प्राप्तकर्ता पथ का प्रतिनिधित्व नहीं करता है। ग्राहक अग्रेषण पते या भूमिका-आधारित उपनाम प्रदान कर सकते हैं। अप्रत्यक्ष हैंडलिंग SPF द्वारा देखे गए कनेक्टिंग स्रोत को बदल सकती है या DKIM से संबंधित सामग्री को बदल सकती है।
अपनी ग्राहक आबादी के लिए महत्वपूर्ण मार्गों के लिए प्रतिनिधि परीक्षणों का उपयोग करें और वास्तविक विफलताओं की जांच करें। एक लेन-देन-मात्र डोमेन एक कर्मचारी पत्राचार डोमेन की तुलना में अधिक नियंत्रित हो सकता है, लेकिन प्राप्तकर्ता अभी भी अप्रत्यक्ष वितरण शुरू कर सकते हैं।
वर्तमान अस्वीकार-नीति आवश्यकताएँ वैध DKIM हस्ताक्षर को आवश्यक बनाती हैं; वे प्रत्येक अग्रेषित संदेश को सत्यापित करने या पहुंचने की गारंटी नहीं देते हैं। नीति-चयन मार्गदर्शिका यह बताता है कि परिणामी व्यापार-बंद का आकलन कैसे किया जाए।
एक ऐसी पुनर्प्राप्ति को परिभाषित करें जो भ्रम को न बढ़ाए
एप्लिकेशन के पुनः प्रयास और उपयोगकर्ता-सामना वाली पुनर्प्राप्ति को उसके स्वयं के समाप्ति मॉडल के आसपास डिज़ाइन करें। रीसेट लिंक के लिए, तय करें कि नया जारी किया गया टोकन पहले वाले टोकन को कैसे प्रभावित करता है और यदि विलंबित संदेश क्रम से बाहर आते हैं तो उपयोगकर्ता क्या देखता है। वे विकल्प एप्लिकेशन टीम के हैं।
प्रदाता फ़ेलओवर रूट को प्राथमिक रूट के समान पहचान सत्यापन के अधीन रखें। एक बैकअप जो असंबंधित पहचान के साथ भेजना शुरू करता है वह उपलब्धता घटना के दौरान एक प्रमाणीकरण घटना बना सकता है।
रूट की जांच के विकल्प के रूप में प्रभावित डोमेन को चुपचाप कमजोर नीति पर न ले जाएं। यदि नीति पुनर्स्थापना की आवश्यकता है, तो इसके सटीक दायरे को अधिकृत करें, कॉन्फ़िगरेशन इतिहास को संरक्षित करें और महत्वपूर्ण प्रवाह को फिर से जांचें।
संदेश प्रकार के आधार पर परिणामों की निगरानी करें
एकल डोमेन-व्यापी सफलता संख्या की रिपोर्ट करने के बजाय अलग-अलग रीसेट, बिलिंग और रसीद परिणाम। सेवा के परिभाषित परिणाम के विरुद्ध देरी, स्थगन, बाउंस और उपलब्ध प्रमाणीकरण साक्ष्य की समीक्षा करें।
समग्र DMARC रिपोर्टें नीचे दी गई हैं RFC 9990 §3.1 देखे गए प्रमाणीकरण पैटर्न की पहचान करने में सहायता करें। वे प्रत्येक लेनदेन के लिए वास्तविक समय पर डिलीवरी रसीद प्रदान नहीं करते हैं। उन्हें एप्लिकेशन और भेजने वाली सेवा के साक्ष्य के साथ संयोजित करें, बिना यह दावा किए कि रिपोर्ट पंक्ति साबित करती है कि किसी विशेष उपयोगकर्ता को एक विशेष ईमेल प्राप्त हुआ है।
तैयार परिचालन रिकॉर्ड में यह दिखाया जाना चाहिए कि प्रवाह का मालिक कौन है, इसने किस पहचान का उपयोग किया, इसे कहां स्वीकार किया गया या विलंबित किया गया और क्या यह ग्राहक की समय सीमा को पूरा करता है। DMARC उस रिकॉर्ड में सत्यापित डोमेन साक्ष्य का योगदान देता है; सेवा तभी सफल होती है जब ग्राहक का वास्तविक कार्य सफल हो जाता है।
अगली कार्रवाई विशिष्ट रखें
रीसेट फिक्सचर में, 12:05:00 घटा 12:00:27 , उपयोगिता के 273 सेकंड या 4 मिनट 33 सेकंड छोड़ता है। प्रमाणीकरण पास होने पर भी 12:06:00 पर उपलब्धता समाप्ति के 60 सेकंड बाद होगी। विलंब चरण और आवेदन समाप्ति विफलता को अलग से रिकॉर्ड करें। ये गणनाएँ काल्पनिक इनपुट का वर्णन करती हैं, न कि मापा वितरण प्रदर्शन या अनुशंसित टोकन जीवनकाल का।