कॉम्बेल के माध्यम से भेजे गए ईमेल को प्रमाणित करें: कॉन्फ़िगरेशन और सत्यापन

रिकॉर्ड चुनने से पहले कॉम्बेल मेल उत्पाद का चयन करें

कॉम्बेल एकल प्रमाणीकरण कॉन्फ़िगरेशन नहीं है। इसका SPF निर्देश बेसिक ई-मेल, एक्सचेंज ई-मेल और Microsoft 365 में अंतर करते हैं। यह अलग है DMARC लेख में कहा गया है कि DKIM मानक मेलबॉक्सों पर उपलब्ध नहीं है और कॉम्बेल मेलसर्वर पर एक समर्थन-स्थापित विकल्प का वर्णन करता है। वे अंतर यह निर्धारित करते हैं कि एक जिम्मेदार कॉन्फ़िगरेशन योजना क्या वादा कर सकती है। यह मार्गदर्शिका प्रलेखित उत्पाद विकल्पों और DNS तैयारी को कवर करती है, न कि सत्यापित किरायेदार कार्यान्वयन या सार्वभौमिक DKIM रेसिपी को। SPF लेख 1 अप्रैल 2025 को अद्यतन किया गया था; DMARC लेख 2 सितंबर 2026 को अद्यतन किया गया था। परिवर्तन करने से पहले वास्तविक सदस्यता पर उनकी प्रयोज्यता की पुष्टि करें। कॉम्बेल SPF मार्गदर्शन कॉम्बेल DMARC मार्गदर्शन

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

वास्तविक प्रेषण मार्ग के साथ SPF का मिलान करें

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

SMTP के लिए SPF मूल्यांकन किया जाता है मेल प्रेषक पहचान, या HELO पहचान प्रासंगिक मामलों में; यह दृश्यमान लेखक पते को सीधे प्रमाणित नहीं करता है। इसलिए आउटबाउंड सेवा को अधिकृत करने वाली नीति सही हो सकती है जबकि संदेश में अभी भी DMARC अभाव है संरेखण. लिफाफा डोमेन, दृश्यमान डोमेन और प्रेक्षित आउटबाउंड मार्ग को अलग-अलग फ़ील्ड के रूप में रखें। सही वर्णन करने से बचें SPF रिकॉर्ड सबूत के तौर पर कि संगठन के प्रदर्शन नाम वाले सभी मेल असली हैं। RFC 7208 , अनुभाग 2.3-2.4

पहले से मौजूद सेवाओं सहित विस्तारित SPF निर्भरता पथ की समीक्षा करें। प्रोटोकॉल सीमाएँ DNS-क्वेरी शर्तों का मूल्यांकन करती हैं; यह केवल पाठ्य प्रविष्टियों, पैकेटों या कैश्ड उत्तरों की गिनती नहीं है। किसी वैध प्रेषक को चुपचाप हटाए बिना अतिरिक्त प्राधिकरण मूल्यांकन नियमों के अंतर्गत रहना चाहिए। अंतिम सभी तंत्र एक नीति परिणाम व्यक्त करते हैं, जबकि रिसीवर हैंडलिंग एक अलग निर्णय रहता है। न तो कोई हार्ड फेल और न ही प्रदाता की डिलीवरी-उन्मुख शब्दावली किसी विशेष इनबॉक्स या अस्वीकृति परिणाम की गारंटी देती है। RFC 7208 , अनुभाग 4.6.4 और 8

आधिकारिक DNS संदर्भ में प्रकाशित करें

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

प्रकाशन से पहले, इच्छित पूर्णतः योग्य स्वामी का नाम, रिकॉर्ड प्रकार, संपूर्ण सामग्री, टीटीएल और रोलबैक मान रिकॉर्ड करें। उस इच्छित स्वामी की तुलना संपादक के पूर्वावलोकन से करें। अधिकृत परिवर्तन के बाद, संग्रहीत नियंत्रण-पैनल दृश्य को आधिकारिक उत्तरों और रिज़ॉल्वर टिप्पणियों से अलग करें। TXT प्रस्तुति में उद्धरण चिह्न या एकाधिक वर्ण स्ट्रिंग शामिल हो सकते हैं; उन प्रदर्शन विवरणों को कई स्वतंत्र SPF नीतियों के रूप में समझने की भूल नहीं की जानी चाहिए। ऑपरेटर को इच्छित तार्किक मान और रिकॉर्ड सीमाओं को संरक्षित करना चाहिए। RFC 1035 , अनुभाग 3.3.14 और 5.1 RFC 7208 , अनुभाग 3.1-3.3

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

मानक-मेलबॉक्स DKIM सीमा का सम्मान करें

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

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

नमूने से अलग DMARC नीति तय करें

कॉम्बेल _dmarc पर DMARC TXT रिकॉर्ड के रूप में जोड़ने का वर्णन करता है और उन उपयोगकर्ताओं के लिए एक निगरानी-नीति उदाहरण देता है जो एक विशिष्ट प्रवर्तन नीति नहीं चाहते हैं। वह उदाहरण मौजूदा संगरोध या अस्वीकार नीति को बदलने की अनुमति नहीं है। नीति बदलने से पहले संगठन की संपूर्ण प्रेषक सूची और अनुमोदित रिपोर्टिंग व्यवस्था की समीक्षा करें। एक जनरेटर किसी निर्णय को प्रारूपित कर सकता है; यह अप्रामाणिक मेल के प्रति संगठन की सहनशीलता का निर्णय नहीं कर सकता। कॉम्बेल DMARC मार्गदर्शन

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

काल्पनिक निदान: गलत उत्पाद धारणा

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

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

रिक्त स्वीकृति कार्यपत्रक

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

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