सामान्य इंटरव्यू: आप SPF और DKIM अलाइनमेंट के साथ DMARCbis को कैसे रोल आउट करेंगे?

प्रश्न और परिदृश्य

एक कंपनी कई ईमेल प्रोवाइडर्स को एक सेंडिंग डोमेन के तहत कंसोलिडेट कर रही है। DMARC अलाइनमेंट और RFC 9989, 9990, और 9991 की भूमिकाओं को समझाएं, फिर p=none से reject तक वैलिडेशन और रोलबैक डिज़ाइन करें।

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

इंटरव्यूअर क्या जांच रहा है

• क्या आप SPF, DKIM और DMARC की भूमिकाओं और इनपुट को अलग-अलग समझते हैं।
• क्या आप जानते हैं कि DMARC को कम से कम एक पासिंग, अलाइन्ड SPF या DKIM पाथ की आवश्यकता होती है।
• क्या आप RFC 9989 कोर DMARC, RFC 9990 एग्रीगेट रिपोर्ट और RFC 9991 फेलियर रिपोर्ट के बीच अंतर कर सकते हैं।
• क्या आप सीधे p=reject पर स्विच करने के बजाय अवलोकनों (observations) के आधार पर पॉलिसी को सख्त कर सकते हैं।
• क्या आप फ़ॉरवर्डिंग, थर्ड पार्टीज़, सबडोमेन, रिपोर्ट प्राइवेसी और रोलबैक को संभाल सकते हैं।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

1. क्या संरक्षित पहचान एक संगठनात्मक डोमेन है या कई सबडोमेन हैं, और प्रत्येक प्रेषक के लिए From, Return-Path और DKIM d डोमेन क्या हैं?
2. प्रोवाइडर और सबडोमेन के अनुसार SPF, DKIM और DMARC पास और अलाइनमेंट दरें कैसी दिखती हैं, और क्या एग्रीगेट रिपोर्ट प्राप्त की जा सकती हैं?
3. क्या मार्केटिंग, ट्रांज़ैक्शनल और कर्मचारी संदेश एक ही डोमेन से भेजे जाते हैं, या उन्हें अलग किया जा सकता है?
4. क्या रिसीवर के व्यवहार को परीक्षणों और प्रोवाइडर दस्तावेज़ीकरण के माध्यम से सत्यापित किया गया है, या हम केवल मानक समर्थन मान रहे हैं?

30-सेकंड उत्तर ढांचा

DMARC जाँचता है कि क्या दृश्यमान From डोमेन किसी प्रमाणित SPF डोमेन या DKIM d डोमेन के साथ अलाइन होता है; कम से कम एक पाथ पास और अलाइन होना चाहिए। RFC 9989 कोर DMARC को परिभाषित करता है, जबकि RFC 9990 और RFC 9991 एग्रीगेट और फेलियर रिपोर्ट को परिभाषित करते हैं। एक अवलोकन मोड के रूप में p=none से शुरुआत करें, रिपोर्ट को पार्स करें, प्रोवाइडर, सबडोमेन और संदेश-प्रकार के अलाइनमेंट को ठीक करें, फिर धीरे-धीरे quarantine और reject की ओर बढ़ें। प्रत्येक चरण के लिए मेट्रिक्स, प्रतिनिधि परीक्षणों और एक तेज़ रोलबैक की आवश्यकता होती है। एक नया RFC नंबर इस बात का प्रमाण नहीं है कि प्रत्येक रिसीवर आज समान रिपोर्ट तैयार करता है।

चरण-दर-चरण विस्तृत उत्तर

1. तीन पहचान पाथ बनाएं

SPF प्रमाणित करता है कि क्या कोई सेंडिंग सर्वर अधिकृत है, आमतौर पर SMTP एन्वेलप MAIL FROM डोमेन का उपयोग करके। DKIM एक हस्ताक्षर को सत्यापित करता है, जिसमें इसका d डोमेन अलाइनमेंट में भाग लेता है। DMARC प्राप्तकर्ता को दिखाई देने वाले From डोमेन का मूल्यांकन करता है और अलाइनमेंट के आधार पर पॉलिसी लागू करता है। ये इनपुट अलग-अलग हैं, इसलिए एक Authentication-Results लाइन वास्तविक डोमेन की जाँच का विकल्प नहीं है।

2. केवल पास होने के बजाय अलाइनमेंट का आकलन करें

प्रमुख DMARC शर्त यह है कि SPF या DKIM पास हो और इसका प्रमाणित डोमेन संगठन के रिलैक्स्ड या स्ट्रिक्ट मोड के तहत From के साथ अलाइन हो। किसी प्रोवाइडर के पास SPF पास हो सकता है जबकि उसका envelope-from मिसअलाइन्ड हो, या प्रोवाइडर के स्वामित्व वाले d डोमेन के साथ DKIM पास हो सकता है। दोनों ही मामलों में डोमेन, हस्ताक्षर या सेंडिंग बाउंड्री को बदलने की आवश्यकता होती है।

3. 2026 RFC बाउंड्री समझाएं

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

4. क्रमिक पॉलिसी परिवर्तन डिज़ाइन करें

एक नियंत्रित rua गंतव्य और एक एक्सेस-नियंत्रित विश्लेषण मेलबॉक्स या पाइपलाइन के साथ पहले p=none प्रकाशित करें। प्रेषक के अनुसार SPF, DKIM, From, सबडोमेन और फेलियर आयामों को एग्रीगेट करें, फिर वैध स्रोतों की मरम्मत करें। सावधानीपूर्वक सीमित सबडोमेन के लिए या ट्रांज़ैक्शनल और मार्केटिंग सबडोमेन को अलग करने के लिए sp का उपयोग करें। केवल तभी quarantine पर जाएँ जब वैध ट्रैफ़िक स्थिर हो और अज्ञात स्रोत व्याख्या योग्य हों, फिर reject पर विचार करें।

5. परिवर्तन रिकॉर्ड में सत्यापन और रोलबैक शामिल करें

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

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं प्रत्येक प्रेषक के From, MAIL FROM, और DKIM d डोमेन की एक सूची तैयार करूँगा, फिर प्रोवाइडर और सबडोमेन द्वारा पास और अलाइनमेंट की गणना करूँगा। DMARC को SPF और DKIM दोनों को एक साथ पास करने की आवश्यकता नहीं है; एक पासिंग, अलाइन्ड पाथ पर्याप्त है। RFC 9989 मुख्य पॉलिसी को संभालता है, जबकि RFC 9990 और RFC 9991 दो रिपोर्ट प्रकारों को कवर करते हैं, जिनके रिसीवर कवरेज को केवल मानने के बजाय मापा जाना चाहिए। मैं p=none से शुरुआत करूँगा, एग्रीगेट रिपोर्ट एकत्र करूँगा, थर्ड-पार्टी, फ़ॉरवर्डिंग और सबडोमेन समस्याओं को ठीक करूँगा, फिर reject से पहले एक सीमित सेगमेंट को quarantine पर कड़ा करूँगा। प्रत्येक चरण के लिए वैध डिलीवरी, अलाइनमेंट और अस्पष्टीकृत स्रोतों के लिए थ्रेशोल्ड, साथ ही एक DNS रोलबैक और सबडोमेन आइसोलेशन पाथ निर्धारित किया जाता है। इससे परिवर्तन ऑडिट करने योग्य हो जाता है और जब कोई धारणा गलत होती है तो नुकसान सीमित रहता है।

सामान्य त्रुटियाँ

• From-डोमेन अलाइनमेंट की जाँच किए बिना SPF या DKIM पास होने के बाद DMARC को पास घोषित करना।
• SPF MAIL FROM, DKIM d, और दृश्यमान From को एक ही फ़ील्ड मानना।
• रिपोर्ट की जिम्मेदारियों को अलग किए बिना तीनों 2026 RFC को "DMARC कोर" कहना।
• रिपोर्ट बेसलाइन के बिना p=reject पर स्विच करना और वैध थर्ड-पार्टी मेल को ब्लॉक करना।
• लिस्ट और फ़ॉरवर्डिंग पाथ का परीक्षण किए बिना यह मान लेना कि फ़ॉरवर्डिंग SPF या DKIM को सुरक्षित रखती है।
• उन रिपोर्टों में पते और संगठन की जानकारी पर विचार किए बिना रिपोर्ट डेटा प्रकाशित करना।

फॉलो-अप प्रश्न और उत्तर

SPF पास होता है लेकिन DMARC फेल हो जाता है। आप सबसे पहले क्या निरीक्षण करेंगे?

SPF प्रमाणित डोमेन की From के साथ तुलना करें और रिलैक्स्ड या स्ट्रिक्ट अलाइनमेंट की पुष्टि करें। फिर सबडोमेन इनहेरिटेंस, रीराइट्स और वास्तविक संदेश हेडर का निरीक्षण करें; केवल एक अधिकृत सेंडिंग IP ही पर्याप्त नहीं है।

DKIM पास होता है लेकिन फ़ॉरवर्डिंग के बाद फेल हो जाता है। आगे क्या?

जाँचें कि क्या फ़ॉरवर्डर बॉडी या हस्ताक्षरित हेडर को फिर से लिखता है और क्या d डोमेन और चयनकर्ता (selector) अभी भी रिज़ॉल्व होते हैं। अनियंत्रित फ़ॉरवर्डिंग के लिए, पॉलिसी को कमजोर करके अज्ञात स्रोतों को छिपाने के बजाय स्थिर साइनिंग, लिस्ट हैंडलिंग और एक पृथक सबडोमेन का मूल्यांकन करें।

आप quarantine से reject पर जाने का निर्णय कैसे लेते हैं?

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

जब रिपोर्ट का पता दूसरे डोमेन में हो तो क्या मायने रखता है?

पुष्टि करें कि प्राप्त करने वाला डोमेन स्पष्ट रूप से रिपोर्टिंग संबंध को अधिकृत करता है, और रिपोर्ट पाइपलाइन में एक्सेस और रिटेंशन को प्रतिबंधित करें। क्रॉस-डोमेन रिपोर्टिंग अपने आप में एक विश्वसनीय डेटा निर्यात नहीं है।

स्रोत: RFC 9989, RFC 9990, RFC 9991, Google Gmail “Email sender guidelines,” और Dataford “Explaining Email Authentication Clearly” (पूर्ण URL meta.json में दर्ज हैं)।