ईमेल डिलीवरेबिलिटी जांच
प्रतिष्ठा से पहले, सामग्री से पहले, प्राप्तकर्ता एक ही सवाल पूछते हैं: क्या यह डोमेन साबित कर सकता है कि मेल सचमुच उसी का है? यह जांच उस सबूत को पढ़ती है — MX रिकॉर्ड्स, SPF प्रेषक सूची (एक प्राप्तकर्ता जिस तरह गिनता है वैसे फैलाकर और गिनकर), _dmarc पर DMARC नीति, और आम सेलेक्टरों के नीचे DKIM कुंजियाँ — और सरल भाषा में निष्कर्ष देती है, उस क्रम में जिस क्रम में कोई ऑपरेटर उन्हें ठीक करेगा।
क्या आप चाहते हैं कि इस पर लगातार नज़र रखी जाए? myeventwatch से इसे मुफ़्त मॉनिटर करें — समाप्ति और डाउनटाइम अलर्ट, कार्ड की ज़रूरत नहीं।
यह जांच क्या मापती है
स्पैम फ़िल्टरिंग पहचान से शुरू होती है क्योंकि पहचान मिलीसेकंड में जांची जा सकती है। जब कोई मेल किसी डोमेन से होने का दावा करके आता है, तो प्राप्त करने वाला सर्वर उस डोमेन के प्रकाशित नियमों को देखता है। SPF उन सर्वरों के नाम बताता है जिन्हें भेजने की अनुमति है। DKIM एक हस्ताक्षर देता है जिसे प्रकाशित कुंजी से सत्यापित किया जा सकता है। DMARC मांग करता है कि दिखने वाला From डोमेन उन दो सबूतों में से किसी एक के साथ संरेखित हो और उस मेल के लिए दंड — कोई नहीं, क्वारंटीन, अस्वीकार — बताता है जिसके पास कोई भी नहीं है। यह पेज sysosx के सर्वर पर GET /api/check/email-auth को कॉल करता है, जो उन्हीं DNS पार्सरों से वही रिकॉर्ड पढ़ता है जिनका उपयोग हेल्थ चेक करता है, और उन्हें निष्कर्षों में बदलता है: हर प्रोटोकॉल, हर समस्या, एक गंभीरता, उस क्रम में जिसमें उन्हें ठीक करना सार्थक है।
निष्कर्षों में से दो ईमानदारी पर एक शब्द के हकदार हैं, क्योंकि दोनों वे जगहें हैं जहाँ जांचकर्ता अक्सर सटीकता का दिखावा करते हैं। SPF लुकअप गिनती असली है: जांचकर्ता प्राप्तकर्ता द्वारा लागू किए जाने वाले उन्हीं नियमों के तहत include और redirect शृंखलाओं को पद-दर-पद फैलाता है, इसलिए जो संख्या वह रिपोर्ट करता है वही है जो कोई सख़्त प्राप्तकर्ता गिनेगा — इसमें वह मामला भी शामिल है जब रिकॉर्ड चुपचाप दस-लुकअप सीमा से ऊपर बह गया हो, जैसे-जैसे विक्रेता अपने रिकॉर्ड बदलते गए। और DKIM परिणाम एक जांच है, जनगणना नहीं: कुंजियाँ मालिक द्वारा चुने गए सेलेक्टर नामों के नीचे प्रकाशित होती हैं, जांच आम नामों को आज़माती है, और उनमें से कोई न मिलना यह साबित नहीं करता कि DKIM अनुपस्थित है — किसी अन्य सेलेक्टर के नीचे की कुंजी बाहर से अदृश्य होती है, और परिणाम यह बात किसी डोमेन को अहस्ताक्षरित घोषित करने के बजाय साफ़-साफ़ कहता है। एकमात्र पूर्ण DKIM परीक्षण अब भी एक असली संदेश और उसका Authentication-Results हेडर ही है।
परिणाम कैसे पढ़ें
विफलताओं से शुरू करें; वे स्पैम फ़ोल्डर के पसंदीदा कारण हैं। कोई MX नहीं होने का मतलब है कि डोमेन बिल्कुल भी मेल प्राप्त नहीं कर सकता। कोई SPF नहीं, या +all पर समाप्त होने वाला SPF रिकॉर्ड, इसका मतलब है कोई भी आपके होने का दावा कर सकता है — दूसरा बदतर है, क्योंकि वह दावा आधिकारिक तौर पर अनुमत है। कई SPF रिकॉर्ड चुपचाप पूरी SPF मूल्यांकन को शून्य कर देते हैं। DMARC रिकॉर्ड न होने का मतलब है कि विफल मेल के लिए कोई बताया गया दंड नहीं है और, उतना ही महँगा, कोई भी वे समग्र रिपोर्टें एकत्र नहीं कर रहा है जो दिखाती हैं कि आपके डोमेन के रूप में कौन भेज रहा है — वे रिपोर्टें ही वह तरीका हैं जिनसे स्पूफ़िंग अभियान आमतौर पर खोजे जाते हैं। जब रिपोर्टें आती हैं, तो वे कच्चे XML के रूप में आती हैं; DMARC रिपोर्ट विश्लेषक .xml, .gz और .zip फ़ाइलों को स्थानीय रूप से खोलता है और उन्हें स्रोत-दर-स्रोत तालिका में बदल देता है कि कौन पास हुआ, कौन फ़ेल हुआ, और क्या ठीक करना है। चेतावनियाँ बीच की अवस्था हैं: p=none DMARC शुरू करने के लिए अच्छी जगह है और रुकने के लिए बुरी जगह; ~all परीक्षण मोड है, गंतव्य नहीं। फिर तस्वीर का दूसरा आधा हिस्सा लें: प्रमाणीकरण पहचान साबित करता है, जबकि DNS ब्लैकलिस्ट जांचकर्ता प्रतिष्ठा मापता है — दोनों चलाएँ, क्योंकि पूरी तरह प्रमाणित डोमेन भी सूचीबद्ध IP पर स्पैम में जाता है, और साफ़ IP भी टूटे SPF के साथ। जो गाइड इन सबको एक साथ जोड़ती है वह है आपका ईमेल स्पैम में क्यों जाता है।
अक्सर पूछे जाने वाले सवाल
SPF, DKIM और DMARC क्या हैं, और वे एक साथ कैसे फिट होते हैं?
वे इस सवाल के DNS में प्रकाशित तीन जवाब हैं: “क्या यह मेल सचमुच उस डोमेन से है जिसका वह दावा करता है?” SPF उन सर्वरों की सूची देता है जिन्हें किसी डोमेन के लिए भेजने की अनुमति है। DKIM किसी डोमेन को संदेशों पर क्रिप्टोग्राफ़िक हस्ताक्षर करने देता है, ताकि प्राप्तकर्ता DNS में प्रकाशित कुंजी से हस्ताक्षर सत्यापित कर सके। DMARC उन्हें एक साथ जोड़ता है: इसके लिए ज़रूरी है कि दिखने वाले From हेडर में भेजने वाला डोमेन SPF या DKIM परिणाम के साथ संरेखित हो, और यह प्राप्तकर्ताओं को बताता है कि जब कोई भी संरेखित न हो तो क्या करना है — निगरानी, क्वारंटीन, या अस्वीकार। DMARC के बिना SPF एक अहस्ताक्षरित सुझाव है; DMARC ही वह है जो अन्य दो को नीति में बदलता है।
तीनों पास होने पर भी मेरा मेल स्पैम में क्यों जाता है?
क्योंकि प्रमाणीकरण प्रवेश टिकट है, बैठने की योजना नहीं। SPF, DKIM और DMARC पास करने का मतलब है कि प्राप्तकर्ता मानते हैं कि मेल सचमुच आपका है — उसके बाद, प्लेसमेंट प्रतिष्ठा और सामग्री पर निर्भर करता है: ब्लैकलिस्ट लिस्टिंग (इस साइट पर ब्लैकलिस्ट जांचकर्ता से उन्हें जांचें), प्राप्तकर्ता जुड़ाव, शिकायत दरें, भेजने की मात्रा के पैटर्न और संदेश स्वयं। प्रमाणीकरण विफलताएँ स्पैम प्लेसमेंट का सबसे आम ठीक करने योग्य कारण हैं, इसीलिए यह जांच पहले आती है, लेकिन यहाँ साफ़ परिणाम के साथ लगातार स्पैम प्लेसमेंट का मतलब है कि समस्या पहचान में नहीं, प्रतिष्ठा या सामग्री में है।
जांच कहती है कि कोई DKIM कुंजी नहीं मिली। क्या इसका मतलब है कि मेरा डोमेन हस्ताक्षर नहीं करता?
नहीं — और परिणाम यह बात उन्हीं शब्दों में कहता है। DKIM कुंजियाँ डोमेन मालिक द्वारा चुने गए सेलेक्टर नामों के नीचे रहती हैं, और किसी डोमेन के सेलेक्टरों को बाहर से गिनने का कोई तरीका नहीं है। यह जांच प्रमुख प्रदाताओं द्वारा उपयोग किए जाने वाले आम सेलेक्टरों (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill और कुछ अन्य) की जांच करती है। किसी अन्य नाम के नीचे की कुंजी जांच के लिए अदृश्य होती है। निर्णायक परीक्षण एक असली संदेश है: अपने नियंत्रण वाले मेलबॉक्स में मेल भेजें और Authentication-Results हेडर देखें, जो उपयोग किए गए सेलेक्टर और हस्ताक्षर सत्यापित हुआ या नहीं, यह रिपोर्ट करता है।
जांच SPF लुकअप क्यों गिनती है, और सीमा 10 क्यों है?
SPF रिकॉर्ड का मूल्यांकन करने के लिए और DNS लुकअप की ज़रूरत पड़ सकती है — हर include, a, mx, ptr, exists और redirect पद की कीमत एक है। RFC 7208 कुल को 10 पर सीमित करता है; इससे ऊपर, प्राप्तकर्ता स्थायी त्रुटि लौटाते हैं और SPF परिणाम शून्य हो जाता है, जो एक साधारण रिकॉर्ड से बदतर हो सकता है जो साफ़-साफ़ मूल्यांकन हो जाता है। प्रदाताओं के जुड़ने पर रिकॉर्ड चुपचाप लुकअप बढ़ाते हैं (हर include अपने पद लाता है), इसलिए कोई रिकॉर्ड जो सेटअप के समय वैध था, विक्रेताओं के अपने रिकॉर्ड बदलने पर सीमा से ऊपर बह सकता है। यह जांच रिकॉर्ड को वैसे ही फैलाती है जैसे कोई प्राप्तकर्ता करेगा और असली गिनती रिपोर्ट करती है, ताकि बहाव आपकी प्रमाणीकरण को शून्य करने से पहले दिख जाए।
अगर कई निष्कर्ष विफलताएँ हैं तो मुझे पहले क्या ठीक करना चाहिए?
क्रम में: कई SPF रिकॉर्ड (एक में मिला दें — जब तक वह ठीक न हो जाए, उसके बाद की हर चीज़ अविश्वसनीय है), गायब या +all SPF रिकॉर्ड (असली प्रेषक सूची प्रकाशित करें, -all से समाप्त), गायब DMARC रिकॉर्ड (रिपोर्टिंग पते के साथ p=none से शुरू करें, ताकि लागू करने से पहले आप देख सकें कि आपके रूप में कौन भेज रहा है), फिर जैसे-जैसे रिपोर्टें साफ़ आती जाएँ, DMARC को p=none से p=reject की ओर बढ़ाएँ। ब्लैकलिस्ट लिस्टिंग, अगर कोई है, तो समानांतर काम है — रिकॉर्ड ठीक किए जाने के दौरान उनका कारण ठीक करें और हटाने का अनुरोध करें। हमारी गाइड तर्क के साथ क्रम समझाती है: आपका ईमेल स्पैम में क्यों जाता है।