रिपोर्ट किया गया आईपी एक अनुमोदित प्रेषण सेवा नहीं है

प्राप्तकर्ता ने वास्तव में क्या रिपोर्ट की, उससे प्रारंभ करें

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

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

अवलोकन को समृद्ध करने से पहले उसे सुरक्षित रखें

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

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

प्रमाणीकरण को सेवा अनुमति से अलग करें

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

SPF विशेष रूप से अधिक पढ़ना आसान है। RFC 7208 एक परिभाषित SMTP पहचान के लिए होस्ट प्राधिकरण का मूल्यांकन करता है, न कि उस मेल इंफ्रास्ट्रक्चर को साझा करने वाले प्रत्येक उपयोगकर्ता की व्यावसायिक वैधता का। इच्छित सेवा सही ढंग से कॉन्फ़िगर की गई हो सकती है, एक अप्रचलित खाता अभी भी भेज सकता है, या एक स्वीकृत खाते का दुरुपयोग किया जा सकता है। प्रमाणीकरण परिणाम समान दिखने पर भी उन संभावनाओं के लिए अलग-अलग साक्ष्य की आवश्यकता होती है।

कोई निष्कर्ष निकाले बिना एक काल्पनिक रिपोर्ट पर काम करें

ड्राफ्टिंग से पहले रखे गए एक पेपर उदाहरण पर विचार करें: एक काल्पनिक रिसीवर 24 संदेशों की रिपोर्ट करता है 192.0.2.40 साथ हेडर_फ्रॉम = notices.example, DKIM संरेखण पास के रूप में और SPF संरेखण को विफल के रूप में रिपोर्ट किया गया। पता और डोमेन उदाहरणात्मक हैं, और ये पूर्ण या मान्य XML फ़िक्स्चर के बजाय चयनित फ़ील्ड मान हैं। कोई प्रश्न, संदेश वितरण या हस्ताक्षर सत्यापन ने उन्हें प्रस्तुत नहीं किया।

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

पते को किसी जवाबदेह सेवा से जोड़ें

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

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

रिपोर्ट कवरेज और समय सीमा दृश्यमान रखें

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

प्रत्येक सहायक कलाकृति की तिथि सुरक्षित रखें। A current DNS answer or registry label cannot automatically recreate the conditions of an older report. यदि समय भिन्न है, तो बताएं कि क्या ऐतिहासिक है और क्या बाद में जांचा गया। एक प्रस्तावित निर्णय रिकॉर्ड में अनसुलझे विरोधाभासों को रखा जाना चाहिए, जिसमें एक व्यवसाय स्वामी भी शामिल है जो आवेदन को पहचानता है लेकिन खाते या प्रेषण भेजने वाली पहचान की पुष्टि नहीं कर सकता है।

वर्गीकरण को एक स्पष्ट समीक्षा निर्णय बनाएं

उन स्थितियों का उपयोग करें जो यह बताती हैं कि क्या ज्ञात है: देखी गई लेकिन जिम्मेदार नहीं, उम्मीदवार सेवा, सत्यापित सेवा मानचित्रण, अनुमोदित उपयोग, या बढ़ी हुई चिंता। ये प्रस्तावित वर्कफ़्लो लेबल हैं, EmailAuth सुविधाएँ नहीं। अनुमोदन में अनुमत उद्देश्य और पहचान निर्दिष्ट होनी चाहिए, न कि केवल प्रदाता का नाम। अपरिचित ट्रैफ़िक की खोज न तो उत्पादन DNS परिवर्तनों को अधिकृत करती है और न ही किसी बाहरी पक्ष के साथ पूरी रिपोर्ट साझा करने की अनुमति देती है।

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