ईमेल हेडर फ़ील्ड की व्याख्या: Received, From, Return-Path और अन्य

संक्षेप में

1. हेडर कहाँ मिलते हैं। हर मेल ऐप में पूरे हेडर दिखाने का तरीका होता है, जिसे अक्सर Show original, View source या Message details कहा जाता है।
2. लोगों को दिखने वाले फ़ील्ड: From, To, Subject, Date। From, To, Subject और Date वे फ़ील्ड हैं जो मेल ऐप दिखाता है।
3. Received: रूट। संदेश को संभालने वाला हर सर्वर सबसे ऊपर एक Received लाइन जोड़ता है।
4. Return-Path, Reply-To और Message-ID। Return-Path में एनवेलप सेंडर होता है, यानी वह पता जहाँ बाउंस भेजे जाते हैं और जिसके विरुद्ध SPF जाँचा जाता है।
5. Authentication-Results। प्राप्त करने वाला सर्वर अपने SPF, DKIM और DMARC के नतीजे Authentication-Results लाइन में दर्ज करता है, साथ में वे पहचानकर्ता भी जो उसने जाँचे, जैसे smtp.mailfrom और header.d।
6. DKIM-Signature। DKIM-Signature फ़ील्ड में d= में साइन करने वाला डोमेन, s= में सेलेक्टर, a= में साइनिंग एल्गोरिद्म और h= में साइन किए गए फ़ील्ड की सूची होती है।

हेडर कहाँ मिलते हैं

हर मेल ऐप में पूरे हेडर दिखाने का तरीका होता है, जिसे अक्सर Show original, View source या Message details कहा जाता है। पहली लाइन से लेकर पहली खाली लाइन तक सब कुछ कॉपी करें, क्योंकि खाली लाइन ही वह जगह है जहाँ हेडर खत्म होते हैं और संदेश की बॉडी शुरू होती है।

आप उन्हें हमारे ईमेल हेडर एनालाइज़र में पेस्ट कर सकते हैं, जो रूट, देरी और ऑथेंटिकेशन के नतीजों को क्रम से सामने रख देता है।

लोगों को दिखने वाले फ़ील्ड: From, To, Subject, Date

From, To, Subject और Date वे फ़ील्ड हैं जो मेल ऐप दिखाता है। इन्हें भेजने वाला तय करता है और ये कुछ भी कह सकते हैं, इसलिए अकेले ये इस बात का प्रमाण नहीं हैं कि संदेश कहाँ से आया। डिस्प्ले नेम में असली पते से अलग कोई पता हो सकता है, जो स्पूफ़िंग की एक आम चाल है।

Date फ़ील्ड बताता है कि भेजने वाले ने संदेश कब लिखा। लंबी देरी पहचानने के लिए इसकी तुलना Received लाइनों के समय से करें।

Received: रूट

संदेश को संभालने वाला हर सर्वर सबसे ऊपर एक Received लाइन जोड़ता है। हर लाइन दर्ज करती है कि उसने संदेश किस सर्वर से प्राप्त किया, वह स्वयं कौन-सा सर्वर है, प्रोटोकॉल क्या था और टाइमस्टैम्प क्या है। रूट को क्रम से समझने के लिए इन्हें नीचे से ऊपर की ओर पढ़ें।

Received: from mail.example.net (mail.example.net [203.0.113.5])
        by mx.example.org with ESMTPS id abc123
        for <you@example.org>; Tue, 13 Oct 2026 16:14:12 +0000

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

Return-Path, Reply-To और Message-ID

Return-Path में एनवेलप सेंडर होता है, यानी वह पता जहाँ बाउंस भेजे जाते हैं और जिसके विरुद्ध SPF जाँचा जाता है। इसे प्राप्त करने वाला सर्वर जोड़ता है। Reply-To बताता है कि जवाब कहाँ जाने चाहिए, और जब यह From से अलग हो तो इसे दोबारा देखना ज़रूरी है। Message-ID संदेश का एक अनूठा पहचानकर्ता है, जो आमतौर पर भेजने वाले सिस्टम के डोमेन पर समाप्त होता है।

जब कोई सेवा आपकी ओर से भेजती है तो Message-ID का डोमेन From डोमेन से अलग होना आम बात है, और यह अपने आप में कोई गड़बड़ी नहीं है।

Authentication-Results

प्राप्त करने वाला सर्वर अपने SPF, DKIM और DMARC के नतीजे Authentication-Results लाइन में दर्ज करता है, साथ में वे पहचानकर्ता भी जो उसने जाँचे, जैसे smtp.mailfrom और header.d। मेल विफल होने पर सबसे पहले यही लाइन पढ़नी चाहिए, और यह तभी भरोसेमंद है जब इसे आपके अपने प्राप्त करने वाले सर्वर ने लिखा हो।

Authentication-Results: mx.example.org;
 spf=pass smtp.mailfrom=bounce.example.net;
 dkim=pass header.d=example.net header.s=s1;
 dmarc=fail header.from=example.com

Pass, fail, softfail, neutral, none, temperror और permerror सामान्य मान हैं। SPF और DKIM दोनों के पास होने के बावजूद DMARC का fail होना लगभग हमेशा इसका मतलब होता है कि पास होने वाले डोमेन From के साथ अलाइन नहीं हैं।

DKIM-Signature

DKIM-Signature फ़ील्ड में d= में साइन करने वाला डोमेन, s= में सेलेक्टर, a= में साइनिंग एल्गोरिद्म और h= में साइन किए गए फ़ील्ड की सूची होती है। प्राप्तकर्ता d= और s= का उपयोग करके DNS में सार्वजनिक कुंजी ढूँढता है और हस्ताक्षर की जाँच करता है।

जाँचें कि d= आपका अपना डोमेन है और h= में From शामिल है। a=rsa-sha1 से बना हस्ताक्षर पुराना और कमज़ोर है, और l= टैग, जो सीमित करता है कि बॉडी का कितना हिस्सा साइन किया जाए, साइन होने के बाद टेक्स्ट जोड़े जाने की गुंजाइश छोड़ देता है।

List-Unsubscribe और अन्य उपयोगी फ़ील्ड

मार्केटिंग मेल में List-Unsubscribe होना चाहिए, और वन-क्लिक अनसब्सक्राइब के लिए List-Unsubscribe-Post, जिसका समर्थन करने के लिए Gmail और Yahoo बल्क भेजने वालों से कहते हैं। कुछ प्राप्तकर्ता स्पैम-फ़िल्टर फ़ील्ड जोड़ते हैं, जैसे X-Spam-Status, जो दिखाते हैं कि संदेश को कैसे स्कोर किया गया।

ARC फ़ील्ड दिखाते हैं कि किसी फ़ॉरवर्डर या मेलिंग लिस्ट ने वह ऑथेंटिकेशन नतीजा दर्ज किया जो उसने देखा था, जिससे समझ आता है कि फ़ॉरवर्ड किए गए संदेश के अंत में SPF क्यों विफल हो सकता है।

आगे पढ़ें और स्रोत

• RFC 5322: Internet Message Format
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 5321: Simple Mail Transfer Protocol

MigoSMTP में करें: हेल्प-सेंटर लेख

• ऑथेंटिकेशन की समस्या खोजने के लिए ईमेल हेडर पढ़ें
• SMTP बाउंस कोड की व्याख्या
• कस्टम रिटर्न-पाथ और ट्रैकिंग डोमेन

संबंधित गाइड और टूल

• ईमेल हेडर एनालाइज़र: हेडर पेस्ट करें, रूट और नतीजे पाएँ।
• SPF, DKIM और DMARC चेकर: लाइव रिकॉर्ड जाँचें।
• SPF, DKIM और DMARC विफलताएँ ठीक करें: एरर पढ़ें और ठीक करें।
• DMARC पॉलिसी की व्याख्या: अलाइनमेंट का क्या अर्थ है।