इसका इस्तेमाल कैसे करें
- संदेश अपने मेल प्रोग्राम में खोलें, उसके मूल या पूरे हेडर ढूँढें, और पहली लाइन से खाली लाइन तक कॉपी करें।
- उन्हें कच्चे हेडर में चिपकाएँ। पेज उन्हें आपके ब्राउज़र में पढ़ता है।
- हॉप क्रम से पहले हॉप से आखिरी तक पढ़ें, और हर हॉप में लगे समय के लिए देरी कॉलम।
- SPF परिणाम, DKIM परिणाम और DMARC परिणाम पढ़ें। पास होना हरे रंग में है; कोई और परिणाम लाल रंग में।
मेल अपना रास्ता कैसे दर्ज करता है
मेल संभालने वाला हर सर्वर हेडर के सबसे ऊपर एक Received लाइन जोड़ता है (RFC 5321, खंड 4.4)। लाइन उस होस्ट का नाम देती है जिससे उसे मेल मिला (from), जिस होस्ट को उसने भेजा (by), प्रोटोकॉल (with), और सेमीकोलन के बाद एक तारीख (RFC 5322, खंड 3.6.7)। नीचे से पढ़ें, तो लाइनें रास्ता क्रम से देती हैं।
- किसी हॉप की देरी उसके समय में से उससे पहले वाले हॉप का समय घटाने पर मिलती है, नीचे से ऊपर पढ़ते हुए।
- सर्वर की घड़ी गलत हो सकती है, इसलिए ऋणात्मक या लंबी देरी नेटवर्क से ज्यादा घड़ी के बारे में बताती है।
पते और अलाइनमेंट
From लेखक का पता है। Return-Path वह जगह है जहाँ बाउंस जाते हैं, और यही वह पता है जिसे SPF जाँचता है (RFC 5322, खंड 3.6.2 और 3.6.7)। DMARC From के डोमेन की तुलना उस डोमेन से करता है जिसे SPF या DKIM ने जाँचा। ढीले अलाइनमेंट के तहत, जो डिफॉल्ट है, दोनों का केवल एक संगठन डोमेन होना काफी है; सख्त अलाइनमेंट में उन्हें एक ही नाम होना चाहिए (RFC 7489, खंड 3.1 और 3.1.1)। Reply-To वह जगह है जहाँ जवाब जाते हैं, जब यह सेट हो (RFC 5322, खंड 3.6.2)।
प्रमाणीकरण के परिणाम
प्राप्त करने वाला सर्वर अपनी जाँच Authentication-Results हेडर में दर्ज करता है। उसका पहला शब्द उस सर्वर का authserv-id है, और हर परिणाम एक तरीका है जिसका मान है, जैसे spf=pass, dkim=pass या dmarc=pass (RFC 8601, खंड 2.2 और 2.7)। Received-SPF पुराना हेडर है जो एक SPF जाँच दर्ज करता है (RFC 7208, खंड 9.1)।
उदाहरण: तीन सर्वरों से गुजरता संदेश
डिफॉल्ट हेडर दिखाते हैं कि client.example.net से आया संदेश relay.example.net और mx.example.org से गुजरकर mail.example.net तक पहुँचा। नीचे से पढ़ें, तो तीनों Received लाइनों का समय 09:59:21, 10:00:03 और 10:02:14 है, इसलिए दूसरे हॉप में 42 सेकंड लगे और तीसरे में 2 मिनट 11 सेकंड।
Authentication-Results हेडर example.net के लिए spf=pass, dkim=pass और dmarc=pass बताता है। जवाब [email protected] पर जाते हैं, जो एक दूसरा डोमेन है, और पेज इसे चिह्नित करता है, क्योंकि भेजने वाले के डोमेन से बाहर जाने वाले जवाब की जाँच करना सही है।
| माप | मान |
|---|---|
| Received लाइनें | 3 |
| पहले से आखिरी हॉप तक का समय | 2 min 53 s |
| SPF | pass (example.net) |
| Reply-To | जवाब example.org पर जाते हैं, example.net पर नहीं। जाँच लें कि यह जानबूझकर है (RFC 5322, खंड 3.6.2)। |
अक्सर पूछे जाने वाले सवाल
हॉप Received लाइनों के उल्टे क्रम में क्यों हैं?
हर सर्वर अपनी Received लाइन सबसे ऊपर रखता है, इसलिए सबसे नया हॉप हेडर में पहले आता है (RFC 5321, खंड 4.4)। पेज उन्हें उलट देता है, ताकि पहली पंक्ति वह सर्वर हो जहाँ से मेल निकला।
क्या Received लाइनों पर भरोसा किया जा सकता है?
हर सर्वर अपनी लाइन लिखता है, पर उसमें दिए नाम और पते वही हैं जो वह सर्वर बताता है, और भेजने वाला अपनी लाइनें भी जोड़ सकता है। सबसे ऊपर की लाइनें सबसे हाल में, आपके सबसे करीब के सर्वरों ने जोड़ी हैं, और उन पर सबसे ज्यादा ध्यान देना चाहिए।
ऋणात्मक देरी का क्या मतलब है?
अगर एक हॉप का समय उससे पहले वाले से पहले दर्ज है, तो दो सर्वरों की घड़ियाँ मेल नहीं खातीं, या समय क्षेत्र गलत पढ़ा गया। यह घड़ी की गलती का संकेत है, तेज नेटवर्क का नहीं।
Authentication-Results क्या है?
यह एक हेडर है जो प्राप्त करने वाला सर्वर जोड़ता है, यह बताने के लिए कि उसने क्या जाँचा, जैसे SPF, DKIM और DMARC, और हर जाँच का परिणाम (RFC 8601)। उसका पहला शब्द उस सर्वर का नाम है, और केवल आपके अपने प्राप्त करने वाले सर्वर के हेडर पर भरोसा करना चाहिए (खंड 2.5)।
Reply-To डोमेन क्यों मायने रखता है?
जब Reply-To सेट हो, तो जवाब उसी पर जाते हैं, वरना From पर (RFC 5322, खंड 3.6.2)। अगर वह कोई दूसरा डोमेन है, तो जवाब उस डोमेन से बाहर जाते हैं जहाँ से संदेश आया। यह अपने आप में गलत नहीं है, पर जाँचने लायक है।
क्या यह टूल मेरे हेडर कहीं भेजता है?
नहीं। हेडर आपके ब्राउज़र में पढ़े जाते हैं। कुछ भी भेजा या सहेजा नहीं जाता।
स्रोत
- RFC 5322 (अंग्रेजी में): Internet Message Format
- RFC 5321 (अंग्रेजी में): Simple Mail Transfer Protocol, trace information
- RFC 8601 (अंग्रेजी में): Message Header Field for Indicating Message Authentication Status
- RFC 7208 (अंग्रेजी में): Sender Policy Framework (SPF)
- RFC 7489 (अंग्रेजी में): DMARC
आँकड़े और टेक्स्ट आखिरी बार मंगलवार, 10 नवंबर 2026 को जाँचे गए।