आपको ईमेल पर नियंत्रण मिलता है

ईमेल नियंत्रण प्राप्त करें

इस क्षेत्र के विषय:

ईमेल प्रमाणीकरण की मूल बातें

आवश्यक न्यूनतम सेटिंग्स

ईमेल प्रमाणीकरण उन्नत

अपने ईमेल की प्रतिष्ठा पर पूर्ण नियंत्रण प्राप्त करें

ईमेल डिलीवरी विश्लेषण

अपने ईमेल के साथ क्या होता है, इसे नियंत्रित करें

सिस्टम स्थिति पृष्ठ

यह हर दस मिनट में सेवाओं के सही संचालन की स्वचालित रूप से जाँच करता है।

आपको ईमेल नियंत्रण के उपखंड मिलते हैं

ईमेल प्रमाणीकरण की मूल बातें

इस क्षेत्र के विषय:

<spf>अपने एसएमटीपी सर्वरों की घोषणा करें

प्रेषक नीति ढांचा परिचय

<spf>ऑनलाइन जांच करें

ईमेल संदेश भेजते समय अपनी ईमेल एसपीएफ सेटिंग की पुष्टि करें

<dkim>ईमेल सामग्री को सील करें

डोमेन कुंजी पहचान मेल परिचय

<dkim>ऑनलाइन जांच करें

ईमेल संदेश भेजते समय अपनी ईमेल DKIM सेटिंग्स को सत्यापित करें

ईमेल प्रमाणीकरण की मूल बातों के उपखंड

<spf>अपने एसएमटीपी सर्वरों की घोषणा करें

एसपीएफ लोगो

एसपीएफ की व्याख्या

एसपीएफ, सेंडर पॉलिसी फ्रेमवर्क का संक्षिप्त रूप है, जो एक ईमेल प्रमाणीकरण मानक है,
जिसकी मदद से आप यह घोषित कर सकते हैं कि आपके डोमेन के लिए ईमेल भेजने के लिए कौन से एसएमटीपी सर्वर अधिकृत हैं।

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

इसे कॉन्फ़िगर करने की सलाह दी जाती है, क्योंकि यदि एसपीएफ बिल्कुल भी सेट नहीं है तो कुछ प्राप्तकर्ता आपके संदेशों को अस्वीकार कर सकते हैं।.


एसपीएफ को कैसे काम में लाया जाए

इसके लिए दो अलग-अलग दृष्टिकोण हैं:

  • एक "सॉफ्ट" (~all टैग) जो "सॉफ्टफेल" त्रुटि उत्पन्न करता है यदि संदेश किसी अघोषित सर्वर द्वारा भेजा गया हो।
  • एक "हार्ड" (-all टैग) जो किसी अघोषित सर्वर द्वारा संदेश भेजे जाने पर "फेल" त्रुटि उत्पन्न करता है।

“सॉफ्ट” सेटअप से प्राप्तकर्ताओं द्वारा संदेशों को अस्वीकार किए जाने की संभावना कम या न के बराबर होगी।
या ईमेल को रीडायरेक्ट करने या मेलिंग लिस्ट के माध्यम से भेजने पर कुछ संदेश अस्वीकार हो सकते हैं ।

“हार्ड” सेटअप गंतव्य मेल सर्वर को संदेश स्वीकार करने या न करने का निर्णय लेने के लिए अधिक क्षमता प्रदान करता है, यही वह दृष्टिकोण है जिसका हम सुझाव देते हैं।.


एसपीएफ को कैसे कॉन्फ़िगर करें

एसपीएफ सेटअप के लिए यह जानना आवश्यक है कि आप ईमेल संदेश भेजने के लिए किन सर्वरों का उपयोग करते हैं।.

RealSender के साथ, आपके डोमेन (example.com) के TXT रिकॉर्ड में a:example.realsender.com और यह इस तरह दिखना चाहिए:
स्ट्रिंग होनी चाहिए

example.com TXT "v=spf1 a:example.realsender.com ~all" 

HighSender के साथ, आपके डोमेन (example.com) के TXT रिकॉर्ड में "include:spf.realsender.com" और यह इस तरह दिखना चाहिए:
स्ट्रिंग होनी चाहिए

example.com TXT "v=spf1 include:spf.realsender.com ~all" 

ये टूल आपको कॉन्फ़िगरेशन को सत्यापित करने में मदद करेंगे:
www.kitterman.com/spf/validate.html *
   निर्दिष्ट डोमेन नाम के लिए SPF रिकॉर्ड प्राप्त करता है और निर्धारित करता है कि रिकॉर्ड मान्य है या नहीं।
ऑनलाइन SPF जांच
   ईमेल संदेश भेजकर आपकी ईमेल SPF सेटिंग्स को सत्यापित करती है।

* = बाहरी वेबसाइट का लिंक, यह एक नए पृष्ठ में खुलेगा


एसपीएफ के नुकसान

सब कुछ सही ढंग से सेट होने पर भी, यदि ईमेल को रीडायरेक्ट (फॉरवर्ड) किया गया है या किसी मेलिंग लिस्ट के माध्यम से भेजा गया है, तो
संदेश का सत्यापन विफल हो सकता है।

इन मामलों में, ईमेल प्रमाणीकरण को सुसंगत बनाए रखने के लिए,
डीकेआईएम हस्ताक्षर डोमेन को प्रेषक के 'प्रेषक' पते के साथ संरेखित करें।
देखें: ईमेल प्रमाणीकरण उन्नत » <dkim> alignment for dmarc.



<spf>ऑनलाइन जांच करें

<spf>ऑनलाइन जांच करें

एसपीएफ लोगो

  1. निम्नलिखित पते पर ईमेल संदेश भेजें:
spf@tester.realsender.com
  1. ऑनलाइन एसपीएफ सत्यापन परिणाम देखें:
    (परिणाम दिखने में एक मिनट लगेगा)
https://tester.realsender.com/spf

यदि संदेश का प्रमाणीकरण सही ढंग से नहीं हुआ है, तो RealSender SPF ऑनलाइन जांच में विषय उपसर्ग जोड़ दिया जाएगा:

!! spf-fail !! SMTP सर्वर अधिकृत सर्वरों की सूची में शामिल नहीं है और ईमेल को अस्वीकार या खारिज कर दिया जाना चाहिए !! spf-softfail !! SMTP सर्वर अधिकृत सर्वरों की सूची में शामिल नहीं है, लेकिन इस मामले को "सॉफ्टफेल" माना जाना चाहिए !! spf-neutral !! SPF रिकॉर्ड स्पष्ट रूप से बताता है कि वैधता के बारे में कुछ नहीं कहा जा सकता !! spf-none !! प्रेषक डोमेन में ईमेल को प्रमाणित करने के लिए कोई जानकारी नहीं है  

कभी-कभी डोमेन स्तर पर दर्ज की गई जानकारी सही/समझने योग्य नहीं होती है।.

!! spf-permerror !! एक स्थायी त्रुटि उत्पन्न हुई है (उदाहरण के लिए, गलत तरीके से स्वरूपित SPF रिकॉर्ड) !! spf-temperror !! एक अस्थायी त्रुटि उत्पन्न हुई है

ईमेल हेडर में छिपे हुए "मेल-फ्रॉम" ईमेल पते पर SPF जांच की जाती है।
केवल "फ्रॉम" ईमेल पता ही दिखाई देता है। यदि उनके रूट डोमेन अलग-अलग हैं, तो यह चेतावनी प्रदर्शित होती है:

!! spf-diff !! "Mail-From" और "From" रूट डोमेन अलग-अलग हैं

यदि संदेश DMARC (रिलैक्स्ड अलाइनमेंट) के लिए SPF जांच और SPF अलाइनमेंट जांच दोनों में सफल होता है, तो आपको यह मिलेगा:

|ठीक है| आपका ईमेल एसपीएफ जांच और एसपीएफ संरेखण जांच में सफल रहा

यदि SPF या DKIM में से केवल एक ही DMARC (रिलैक्स्ड अलाइनमेंट) के लिए अलाइनमेंट जांच पास करता है, तो
संदेश को अभी भी "ओके" (विश्वसनीय) माना जाता है और शुरुआत में ~ (टिल्ड) चिह्न जोड़ा जाता है:

|~ठीक है| spf-pass आपका ईमेल SPF जांच (अलाइनमेंट नहीं) और DKIM अलाइनमेंट जांच में पास हो गया है

<dkim>ईमेल सामग्री को सील करें

डीकेआईएम लोगो

डीकिम ने समझाया

डीकेआईएम डोमेनकीज़ आइडेंटिफाइड मेल का संक्षिप्त रूप है, जो एक ईमेल प्रमाणीकरण मानक है,
जिसे यह गारंटी देने के लिए डिज़ाइन किया गया है कि ईमेल (संलग्नक सहित) में "हस्ताक्षर" लगाए जाने के बाद से कोई बदलाव नहीं किया गया है।

यह प्रत्येक भेजे जाने वाले ईमेल संदेश में डोमेन नाम से जुड़ा एक डिजिटल हस्ताक्षर लगाकर ऐसा करता है।.

दो कुंजियों का उपयोग किया जाता है: एक "सार्वजनिक" कुंजी और एक "निजी" कुंजी:

  1. “सार्वजनिक” कुंजी, हस्ताक्षर डोमेन के TXT रिकॉर्ड में प्रकाशित होती है।
  2. “प्राइवेट” कुंजी एसएमटीपी सर्वर में सहेजी जाती है और इसका उपयोग ईमेल संदेशों पर “हस्ताक्षर” करने के लिए किया जाता है।

संदेश भेजते समय, एसएमटीपी सर्वर ईमेल संदेश की सामग्री और निजी कुंजी के आधार पर एक "एन्क्रिप्टेड हैश हस्ताक्षर" उत्पन्न करता है।.

प्राप्तकर्ता का सिस्टम ईमेल हेडर में मौजूद हस्ताक्षर को ईमेल की सामग्री और प्रेषक की "सार्वजनिक" कुंजी से तुलना करके सत्यापित कर सकता है।.


डीकेआईएम को कैसे काम में लाया जाए

डीकेआईएम हस्ताक्षर अंतिम उपयोगकर्ताओं को तुरंत दिखाई नहीं देते हैं, इन्हें ईमेल इंफ्रास्ट्रक्चर द्वारा जोड़ा और सत्यापित किया जाता है।.

RealSender के SMTP सर्वर सभी आउटगोइंग ईमेल संदेशों पर DKIM हस्ताक्षर का उपयोग करते हैं।.


डीकेआईएम को कैसे कॉन्फ़िगर करें

RealSender शुरू में SMTP सर्वर से जुड़े अपने स्वयं के डोमेन के साथ सभी आउटगोइंग संदेशों पर हस्ताक्षर करता है,
उपयोगकर्ता/प्रशासक पक्ष पर किसी सेटअप की आवश्यकता नहीं होती है।

“डीकेआईएम डोमेन अलाइनमेंट फॉर डीएमएआरसी” प्राप्त करने के लिए,
संदेश पर प्रेषक के समान डोमेन से हस्ताक्षर किए जाने चाहिए।

RealSender के साथ, आपको अपने डोमेन (example.com) की DNS सेटिंग्स में
दो CNAME रिकॉर्ड जोड़ने होंगे , जैसे कि ये वाले:

key1._domainkey.example.com CNAME key1._domainkey.yourcompany.realsender.com key2._domainkey.example.com CNAME key2._domainkey.yourcompany.realsender.com

यह टूल आपको कॉन्फ़िगरेशन को सत्यापित करने में मदद करेगा:
toolbox.googleapps.com *

* = बाहरी वेबसाइट का लिंक, यह एक नए पृष्ठ में खुलेगा


डीकेआईएम के नुकसान

एक डीकेआईएम सीलबंद संदेश को संशोधित नहीं किया जा सकता है, लेकिन इसे फिर भी कोई भी पढ़ सकता है।.

हस्ताक्षरित संदेश जो सत्यापन में विफल रहता है, आमतौर पर अस्वीकृत हो जाता है।
यदि प्रेषक से प्राप्तकर्ता तक पहुंचने के दौरान कोई परिवर्तन नहीं किया गया है, तो ऐसा नहीं होना चाहिए।

हमें कुछ दुर्लभ मामले देखने को मिले हैं, जो सभी लाइन की लंबाई से संबंधित हैं (यह अधिकतम 990 अक्षर होनी चाहिए)।
कुछ एप्लिकेशन सामग्री को एक ही लाइन में भेजते हैं या HTML के भीतर एक बहुत लंबी लाइन भेजते हैं।
इन मामलों में, DKIM हस्ताक्षर दूषित हो जाता है, जिसके कारण "dkim=fail" जांच परिणाम आता है।



<dkim>ऑनलाइन जांच करें

<dkim>ऑनलाइन जांच करें

डीकेआईएम लोगो

  1. निम्नलिखित पते पर ईमेल संदेश भेजें:
dkim@tester.realsender.com
  1. ऑनलाइन डीकेआईएम सत्यापन परिणाम देखें:
    (परिणाम दिखने में एक मिनट लगेगा)
https://tester.realsender.com/dkim

यदि संदेश पर सही ढंग से हस्ताक्षर नहीं किए गए हैं, तो RealSender DKIM ऑनलाइन जांच में विषय उपसर्ग जोड़ा जाएगा:

!! dkim-none !! कोई DKIM-Signature हेडर (वैध या अवैध) नहीं मिला !! dkim-fail !! एक वैध DKIM-Signature हेडर मिला, लेकिन हस्ताक्षर में संदेश के लिए सही मान नहीं है  

कभी-कभी जांच को निष्पादित करना संभव नहीं होता है:

!! dkim-invalid !! हस्ताक्षर या सार्वजनिक कुंजी रिकॉर्ड में कोई समस्या है। यानी हस्ताक्षर संसाधित नहीं हो सका। !! dkim-temperror !! कोई त्रुटि पाई गई है जो संभवतः अस्थायी है, जैसे कि सार्वजनिक कुंजी प्राप्त करने में अस्थायी असमर्थता।

जब संदेश पर किसी भिन्न डोमेन का उपयोग करके हस्ताक्षर किए गए हों, तो विषय में एक "अंतर" चेतावनी जोड़ दी जाएगी।
यदि प्रेषक SPF जांच और dmarc के लिए SPF संरेखण पास कर लेता है, तो यह चेतावनी प्रदर्शित नहीं होगी।

!! dkim-diff !! संदेश पर प्रेषक के डोमेन द्वारा हस्ताक्षर नहीं किए गए हैं

यदि संदेश DMARC (रिलैक्स्ड अलाइनमेंट) के लिए DKIM जांच और DKIM अलाइनमेंट जांच दोनों को पास कर लेता है, तो आपको यह मिलेगा:

|ठीक है| आपका ईमेल DKIM जांच और DKIM संरेखण जांच में सफल रहा

यदि DMARC (रिलैक्स्ड अलाइनमेंट) के लिए अलाइनमेंट जांच में केवल एक, DKIM या
तो संदेश को अभी भी "ओके" (विश्वसनीय) माना जाता है और शुरुआत में ~ (टिल्ड) चिह्न जोड़ा जाता है:

|~ठीक है| आपका ईमेल DKIM जांच (अलाइनमेंट नहीं) और SPF अलाइनमेंट जांच पास कर लेता है।

ईमेल प्रमाणीकरण उन्नत

इस क्षेत्र के विषय:

<spf>डीएमएआरसी के लिए संरेखण

SPF डोमेन के संरेखण में गड़बड़ी के कारण DMARC जांच विफल हो सकती है।

<dkim>डीएमएआरसी के लिए संरेखण

DKIM डोमेन के अलाइनमेंट में गड़बड़ी के कारण DMARC जांच विफल हो सकती है।

<dmarc>फर्जी ईमेल का पता लगाता है

डोमेन-आधारित संदेश प्रमाणीकरण, रिपोर्टिंग और अनुरूपता

<dmarc>रुआ ऑनलाइन रिपोर्ट करता है

रुआ संदेशों का संग्रह और दैनिक डीएमआरसी रिपोर्टों का ऑनलाइन निर्माण

ईमेल प्रमाणीकरण के उन्नत उपखंड

<spf>डीएमएआरसी के लिए संरेखण

एसपीएफ लोगो

डीएमएआरसी के लिए एसपीएफ डोमेन संरेखण

DMARC एक ईमेल प्रमाणीकरण मानक है, जिसे फर्जी डोमेन ईमेल से निपटने के लिए विकसित किया गया है।
डोमेन संरेखण के लिए यह आवश्यक है कि:

   जब कोई प्रेषक SPF और/या DKIM का उपयोग करके अपने ईमेल को प्रमाणित करता है, तो कम से कम एक डोमेन प्रेषक डोमेन के साथ मेल खाना चाहिए।

इसे एसपीएफ (सेंडर पॉलिसी फ्रेमवर्क) के अंतर्गत प्राप्त करने के लिए, आपको दो डोमेन से निपटना होगा:

  • प्रेषक का पता, जो प्राप्तकर्ताओं को दिखाई देता है
  • मेल भेजने वाले का पता (जिसे "लिफाफा प्रेषक" या "वापसी पथ" भी कहा जाता है), जो छिपा हुआ है

DMARC दो प्रकार के SPF संरेखण की अनुमति देता है: शिथिल संरेखण और सख्त संरेखण।
यदि आप सख्त संरेखण निर्दिष्ट नहीं करते हैं, तो शिथिल संरेखण को डिफ़ॉल्ट रूप से मान लिया जाता है।


आरामदेह संरेखण

शिथिल संरेखण के साथ, मेल भेजने वाले पते का मूल डोमेन और भेजने वाले पते का मूल डोमेन मेल खाना आवश्यक है।
शिथिल संरेखण किसी भी उपडोमेन के उपयोग की अनुमति देता है और फिर भी डोमेन संरेखण आवश्यकता को पूरा करता है।

उदाहरण:

  • यदि आपका मेल-फ्रॉम डोमेन mail.abc.com है और आपका फ़्रॉम डोमेन abc.com है, तो
    आपका ईमेल SPF अलाइनमेंट पास कर लेगा (रूट डोमेन "abc.com" मेल खाते हैं)।

  • यदि आपका मेल-फ्रॉम डोमेन abc.mail.com है और आपका फ़्रॉम डोमेन abc.com है, तो
    आपका ईमेल SPF अलाइनमेंट पास नहीं करेगा (रूट डोमेन "mail.com" और "abc.com" मेल नहीं खाते)।


सख्त संरेखण

सख्त संरेखण के साथ, मेल-फ्रॉम पते का डोमेन, फ्रॉम पते के डोमेन से बिल्कुल मेल खाना चाहिए।.

उदाहरण:

  • यदि आपका मेल-फ्रॉम डोमेन mail.abc.com है और आपका फ़्रॉम डोमेन भी mail.abc.com है, तो
    आपका ईमेल SPF अलाइनमेंट पास कर लेगा (डोमेन “mail.abc.com” मेल खाते हैं)।

  • यदि आपका मेल-फ्रॉम डोमेन mail.abc.com है और आपका फ़्रॉम डोमेन abc.com है, तो
    आपका ईमेल SPF अलाइनमेंट पास नहीं करेगा (डोमेन “mail.abc.com” और “abc.com” मेल नहीं खाते)।



<spf>ऑनलाइन जांच करें

<dkim>डीएमएआरसी के लिए संरेखण

डीकेआईएम लोगो

डीएमएआरसी के लिए डीकेआईएम डोमेन संरेखण

DMARC एक ईमेल प्रमाणीकरण मानक है, जिसे फर्जी डोमेन ईमेल से निपटने के लिए विकसित किया गया है।
डोमेन संरेखण के लिए यह आवश्यक है कि:

   जब कोई प्रेषक SPF और/या DKIM का उपयोग करके अपने ईमेल को प्रमाणित करता है, तो कम से कम एक डोमेन प्रेषक डोमेन के साथ मेल खाना चाहिए।

इसे डीकेआईएम (डोमेन कीज़ आइडेंटिफाइड मेल) के अंतर्गत प्राप्त करने के लिए,
डीकेआईएम हस्ताक्षर डोमेन (डीकेआईएम-हस्ताक्षर: d=…) प्रेषक डोमेन से मेल खाना चाहिए।

DMARC दो प्रकार के DKIM संरेखण की अनुमति देता है: शिथिल संरेखण और सख्त संरेखण।
यदि आप सख्त संरेखण निर्दिष्ट नहीं करते हैं, तो शिथिल संरेखण को डिफ़ॉल्ट रूप से मान लिया जाता है।


आरामदेह संरेखण

शिथिल संरेखण के साथ, केवल डीकेआईएम हस्ताक्षर डोमेन का मूल डोमेन ही प्रेषक डोमेन से मेल खाना चाहिए।
शिथिल संरेखण किसी भी उपडोमेन के उपयोग की अनुमति देता है और फिर भी डोमेन संरेखण आवश्यकता को पूरा करता है।

उदाहरण:

  • यदि आपका डीकेआईएम साइनिंग डोमेन mail.abc.com है और आपका फ्रॉम डोमेन abc.com है, तो
    आपका ईमेल डीकेआईएम अलाइनमेंट पास कर लेगा (रूट डोमेन "abc.com" मेल खाते हैं)।

  • यदि आपका डीकेआईएम साइनिंग abc.mail.com है और आपका 'प्रेषक' डोमेन भी abc.com है, तो
    आपका ईमेल डीकेआईएम संरेखण पास नहीं करेगा (रूट डोमेन "mail.com" और "abc.com" मेल नहीं खाते)।


सख्त संरेखण

सख्त संरेखण के साथ, डीकेआईएम हस्ताक्षर डोमेन को भेजने वाले पते के डोमेन से बिल्कुल मेल खाना चाहिए।.

उदाहरण:

  • यदि आपका डीकेआईएम साइनिंग डोमेन mail.abc.com है और आपका फ्रॉम डोमेन भी mail.abc.com है, तो
    आपका ईमेल डीकेआईएम अलाइनमेंट पास कर लेगा (डोमेन "mail.abc.com" मेल खाते हैं)।

  • यदि आपका डीकेआईएम साइनिंग डोमेन mail.abc.com है और आपका 'फ्रॉम' डोमेन abc.com है, तो
    आपका ईमेल डीकेआईएम अलाइनमेंट पास नहीं करेगा (डोमेन "mail.abc.com" और "abc.com" मेल नहीं खाते)।



<dkim>ऑनलाइन जांच करें

<dmarc>फर्जी ईमेल का पता लगाता है

डीएमएआरसी लोगो

डीएमार्क ने समझाया

DMARC का पूरा नाम है: डोमेन-आधारित संदेश प्रमाणीकरण, रिपोर्टिंग और अनुरूपता।
यह एक ईमेल प्रमाणीकरण मानक है, जिसे फर्जी डोमेन मेल से निपटने के लिए विकसित किया गया है।

प्रेषक:

  • उनके ईमेल को SPF और DKIM के साथ प्रमाणित करें
  • अनधिकृत ईमेल को संभालने के तरीके के लिए एक "डीएमएआरसी नीति" प्रकाशित करें।

रिसीवर:

  • प्रेषक की “डीएमएआरसी नीति” के आधार पर अप्रमाणित ईमेल पर कार्रवाई करें।
  • परिणाम की रिपोर्ट प्रेषक को भेजें

कुछ मेलबॉक्स प्रदाताओं के साथ, यह ईमेल डिलीवरी को काफी हद तक प्रभावित करता है, देखें:
2020 में Google Mail और Office 365 के साथ DMARC कैसे काम करता है *
“Office 365 आमतौर पर SPF और DKIM प्रमाणीकरण के प्रति प्रतिक्रियाशील होता है।
इनबॉक्स तक लगातार परिणाम प्राप्त करने का एकमात्र तरीका उन्हें DMARC से जोड़ना है।”

* = बाहरी वेबसाइट का लिंक, यह एक नए पृष्ठ में खुलेगा


डीएमआरसी को कैसे काम में लाया जाए

ईमेल प्रमाणीकरण परीक्षणों में विफल होने की स्थिति को नियंत्रित करने के लिए
DMARC, SPF (Sender Policy Framework) और DKIM (Domain Keys Identified Emails) का उपयोग करता है ।

SPF के लिए आपको यह बताना आवश्यक है कि आप ईमेल संदेश भेजने के लिए किन सर्वरों का उपयोग करते हैं।
SPF को कॉन्फ़िगर करने का तरीका जानने और इसे सही ढंग से सेट करने के लिए देखें ।

RealSender SMTP सर्वर सभी भेजे जाने वाले ईमेल संदेशों पर DKIM हस्ताक्षर का उपयोग करते हैं।
यदि आप प्रेषक के समान डोमेन से हस्ताक्षर करना चाहते हैं, तो एक सेटअप की आवश्यकता होती है।
अधिक जानने के लिए DKIM को कॉन्फ़िगर करने का तरीका देखें ।

RealSender आपको एक मेलबॉक्स प्रदान करता है जो प्राप्तकर्ताओं द्वारा उत्पन्न DMARC रिपोर्टों को एकत्रित करता है।.


डीएमएआरसी को कैसे कॉन्फ़िगर करें

  1. शुरुआत में आपको पॉलिसी टैग को “none” (p=none) पर सेट करना चाहिए,
    जिसका मतलब है कि मेलबॉक्स प्रोवाइडर नकली/फ़िशिंग ईमेल के साथ कुछ भी नहीं करेगा।
    आपको अपने डोमेन (example.com) पर एक TXT रिकॉर्ड जोड़ना चाहिए, जो इस तरह दिखेगा:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"
  1. अगले दिन से आपको DMARC RUA रिपोर्ट ऑनलाइन।

    हो सकता है कि आप किसी तीसरे पक्ष द्वारा भेजे जा रहे ईमेल अभियान को प्रमाणित करना भूल गए हों।
    अगर ऐसा होता है, तो बस उसे प्रमाणित करें और जांच लें कि अगली ईमेल DMARC परीक्षण पास कर लेती है।

  2. जब कुछ हफ्तों तक रिपोर्ट सही आती रहें, तो मेलबॉक्स प्रोवाइडर्स को उन फर्जी/फिशिंग वाले ईमेल को रिजेक्ट/ब्लॉक करने के लिए कहें।

    आपके डोमेन के _dmarc TXT रिकॉर्ड को इस तरह बदलना चाहिए:

"v=DMARC1; p=अस्वीकार; rua=mailto:dmarc.example@rsbox.com"

डीएमएआरसी की कमियां

यदि आपका संगठन डीएमआरसी को लागू करता है, तो ईमेल भेजने की कोई भी नई विधि शुरू करने से पहले
आपको सावधानीपूर्वक जांच करनी होगी ।

डीमार्क एसपीएफ और डीकेआईएम के परीक्षण के तरीके पर सख्त नीतियां लागू करता है,
जिसके कारण ऐसे ईमेल भी
मेलबॉक्स प्रदाताओं द्वारा अस्वीकार किए जा सकते हैं जो अन्यथा इन परीक्षणों में पास हो जाते।

सब कुछ सही ढंग से सेट होने पर भी, सत्यापन विफल हो सकता है:

  • एसपीएफ की जांच, यदि ईमेल को रीडायरेक्ट (फॉरवर्ड) किया गया है या मेलिंग सूची के माध्यम से भेजा गया है।
  • डीकेआईएम जांच से पता चलता है कि क्या संदेश में कोई बदलाव किया गया है, जिससे डीकेआईएम हस्ताक्षर टूट गया है।


<dmarc>रुआ ऑनलाइन रिपोर्ट करता है

<dmarc>रुआ ऑनलाइन रिपोर्ट करता है

डीएमएआरसी लोगो

RealSender आपके लिए dmarc rua(*) रिपोर्ट एकत्र करता है और उनका विश्लेषण करता है।.

* = rua का अर्थ है: समग्र डेटा के लिए रिपोर्टिंग यूआरआई।. 

RealSender में, "rua" ग्राहकों को प्रदान किया गया ईमेल पता है,
जिस पर उन डोमेन द्वारा समग्र रिपोर्ट भेजी जाती हैं
जिन्हें आपके डोमेन से होने का दावा करने वाले ईमेल प्राप्त हुए हैं।

ये रिपोर्टें प्रतिदिन दोपहर 13:00 बजे (CET) तैयार की जाती हैं और इनमें पिछले सात दिनों का डेटा शामिल होता है।.

यह डीएमएआरसी ऑनलाइन रिपोर्ट का नमूना पृष्ठ है:

डीएमएआरसी रिपोर्ट

ईमेल डिलीवरी विश्लेषण

इस क्षेत्र के विषय:

आंकड़े

प्रति माह, दिन, घंटे, होस्ट और प्रेषक के ईमेल पते के आधार पर विस्तृत रिपोर्ट

लॉग और डिलीवरी

ईमेल लॉग, डिलीवरी स्टेटस नोटिफिकेशन (डीएसएन), सफल डिलीवरी नोटिफिकेशन

ईमेल संदेशों की जाँच करें

क्या हो रहा है, यह समझने के लिए भेजे गए ईमेल संदेशों को ध्यान से पढ़ें।

ईमेल डिलीवरी विश्लेषण के उपखंड

आंकड़े

विस्तृत रिपोर्ट

RealSender प्रत्येक SMTP सर्वर/आउटगोइंग ईमेल गतिविधि की विस्तृत रिपोर्ट प्रदान करता है।.

डेटा हर पांच मिनट में स्वचालित रूप से अपडेट हो जाता है।.

अनुरोध करने पर हम ईमेल द्वारा साप्ताहिक सारांश भेज सकते हैं।.

इस पेज पर अधिक जानकारी:

सारांश

सारांश

शीर्ष पर वापस जाएं

मासिक इतिहास

मासिक इतिहास

शीर्ष पर वापस जाएं

महीने के दिन

महीने के दिन

शीर्ष पर वापस जाएं

सप्ताह के दिन

सप्ताह के दिन

शीर्ष पर वापस जाएं

घंटे

घंटे

शीर्ष पर वापस जाएं

मेजबान

मेजबान

शीर्ष पर वापस जाएं

प्रेषक का ईमेल

प्रेषक का ईमेल

शीर्ष पर वापस जाएं

एसएमटीपी त्रुटि कोड

एसएमटीपी त्रुटि कोड

ध्यान दें: ये त्रुटियाँ सर्वर के माध्यम से ईमेल भेजने के अनधिकृत प्रयासों के कारण उत्पन्न होती हैं।

शीर्ष पर वापस जाएं

लॉग और डिलीवरी

ईमेल डेटा

RealSender आपको ब्राउज़र के माध्यम से संसाधित ईमेल डेटा तक पहुंचने की सुविधा देता है:

  • आज भेजे गए अंतिम 100 ईमेल की जानकारी वाला स्टेटस पेज, जो वास्तविक समय में अपडेट होता रहता है।
  • दिन भर में भेजे गए सभी ईमेल के साथ पूरा पेज
  • पिछले सात दिनों में भेजे गए सभी ईमेल सहित पूरा पेज
  • दिन भर में भेजे गए सभी ईमेल का पूरा लॉग (कच्चा, अप्रसंस्कृत), कनेक्शन की जांच करने के लिए उपयोगी।
  • पिछले सात दिनों का पूरा लॉग (कच्चा, अप्रसंस्कृत)

प्रदर्शित डेटा को सीधे ब्राउज़र से स्थानीय रूप से सहेजा जा सकता है, या इतिहास बनाए रखने के लिए नियमित अंतराल पर (जैसे दिन में एक बार) स्वचालित रूप से पंजीकृत किया जा सकता है।.

इस पेज पर अधिक जानकारी:

लॉग में उपलब्ध जानकारी के उदाहरण

31 मई 06:26:22 rs336 v4V4QL1K030027: प्रेषक=sender@yourcompany.com
31 मई 06:26:25 rs336 v4V4QL1K030027: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=2.0.0, स्थिति=भेजा गया (संदेश डिलीवरी के लिए स्वीकार कर लिया गया)


31 मई 08:58:04 rs336 v4V6w3jN001390: प्रेषक=sender@yourcompany.com
31 मई 08:58:05 rs336 v4V6w3jN001390: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.0.0, स्थिति=स्थगित: 421 recipient@yourcustomer.com सेवा उपलब्ध नहीं - बहुत व्यस्त
31 मई 09:02:03 rs336 v4V6w3jN001390: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.0.0, स्थिति=स्थगित: 421 recipient@yourcustomer.com सेवा उपलब्ध नहीं - बहुत व्यस्त
31 मई 09:12:42 rs336 v4V6w3jN001390: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=2.0.0, stat=भेजा गया (संदेश डिलीवरी के लिए स्वीकार कर लिया गया)


31 मई 10:00:22 rs336 v4V80L9Z004176: प्रेषक=sender@yourcompany.com
31 मई 10:00:24 rs336 v4V80L9Z004176: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: प्राप्तकर्ता का पता अस्वीकृत: ग्रे लिस्टिंग लागू है, कृपया बाद में पुनः देखें
31 मई 10:02:03 rs336 v4V80L9Z004176: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com: प्राप्तकर्ता का पता अस्वीकृत: ग्रे लिस्टिंग लागू है, कृपया बाद में पुनः देखें बाद में
31 मई 10:12:04 rs336 v4V80L9Z004176: to=recipient@yourcustomer.com, dsn=2.0.0, stat=भेजा गया (संदेश डिलीवरी के लिए स्वीकार कर लिया गया)


31 मई 16:17:14 rs336 v4VEHCk6017038: प्रेषक=sender@yourcompany.com
31 मई 16:17:15 rs336 v4VEHCk6017038: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=5.1.1, stat=उपयोगकर्ता अज्ञात
31 मई 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: उपयोगकर्ता अज्ञात


25 मई 12:43:37 rs336 v4PAhZw1019212: प्रेषक=sender@yourcompany.com
25 मई 12:43:38 rs336 v4PAhZw1019212: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=5.0.0, स्थिति=सेवा अनुपलब्ध
25 मई 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: सेवा अनुपलब्ध


25 मई 09:17:41 rs336 v4P7Hc6P011481: प्रेषक=sender@yourcompany.com
25 मई 09:17:42 rs336 v4P7Hc6P011481: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.1.1, स्थिति=स्थगित: 452 4.1.1 recipient@yourcustomer.com 4.2.2 मेलबॉक्स भरा हुआ
[…] सिस्टम हर दस मिनट में डिलीवरी का पुनः प्रयास करता है* […]
25 मई 13:25:47 rs336 v4P7Hc6P011481: प्राप्तकर्ता=recipient@yourcustomer.com, dsn=4.1.1, स्थिति=स्थगित: 452 4.1.1 recipient@yourcustomer.com 4.2.2 मेलबॉक्स भरा हुआ
25 मई 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: प्रेषक सूचना: 4 घंटे तक संदेश नहीं भेजा जा सकता*

* = अगले पैराग्राफ के अंत में दिया गया नोट देखें

शीर्ष पर वापस जाएं

डिलीवरी स्टेटस नोटिफिकेशन (डीएसएन)

बाउंस हुए ईमेल (जैसे कि अज्ञात उपयोगकर्ता) प्रेषक के ईमेल पते पर या वापसी-पथ पते पर वापस भेज दिए जाते हैं (यदि निर्दिष्ट हो)।.

संदेशों की डिलीवरी में देरी होने की स्थिति में, आपको 30 मिनट* के बाद इस प्रकार की चेतावनी प्राप्त होगी:

विषय: चेतावनी: पिछले 30 मिनट से संदेश नहीं भेजा जा सका। मुख्य भाग: ********************************************** ** यह केवल एक चेतावनी संदेश है ** ** आपको अपना संदेश दोबारा भेजने की आवश्यकता नहीं है ** ********************************************** [...]  

सिस्टम चार घंटे तक स्वतः पुनः प्रयास करेगा*। यदि आपको आगे कोई सूचना प्राप्त नहीं होती है, तो इसका अर्थ है कि संदेश सफलतापूर्वक भेज दिया गया है। आप लॉग में विवरण देख सकते हैं (ऊपर दिए गए उदाहरण देखें)।.

चार घंटे* तक लगातार असफल प्रयासों के बाद, प्रेषक के ईमेल पते या वापसी-पथ पते (यदि निर्दिष्ट हो) पर एक निश्चित त्रुटि संदेश भेजा जाएगा, जैसा कि नीचे दिया गया है:

विषय: लौटा हुआ मेल: विवरण के लिए प्रतिलेख देखें। मुख्य भाग: मूल संदेश ... पर प्राप्त हुआ था। ----- निम्नलिखित पतों में स्थायी गंभीर त्रुटियाँ थीं।<recipient@yourcustomer.com> ----- सत्र का प्रतिलेख नीचे दिया गया है ----- स्थगित: yourcustomer.com के साथ कनेक्शन का समय समाप्त हो गया। संदेश 4 घंटे तक डिलीवर नहीं किया जा सका। संदेश को कतार से हटा दिया जाएगा [...]  

* = बल्क ईमेल भेजते समय:
विलंबित डिलीवरी स्थिति सूचनाएं अक्षम हो जाती हैं,
डिलीवरी प्रयासों के बीच का अंतराल बढ़ जाता है (दस से तीस मिनट तक), और
कतार में रहने का अधिकतम समय बढ़ जाता है (चार से चौबीस घंटे तक)।

शीर्ष पर वापस जाएं

सफल डिलीवरी सूचनाएं

अनुरोध करने पर, सफलतापूर्वक भेजे गए ईमेल के लिए भी "डिलीवरी नोटिफिकेशन" चालू किया जा सकता है। इस तरह, भेजे गए प्रत्येक संदेश के लिए, प्रेषक को गंतव्य सर्वर से डिलीवरी रसीद प्राप्त होगी, जैसा कि नीचे दिखाया गया है। यह विकल्प उन लोगों के लिए उपयोगी है जिन्हें भेजे गए प्रत्येक ईमेल के लिए डिलीवरी रसीद की आवश्यकता होती है।.

विषय: वापसी प्राप्ति • मूल संदेश ... पर प्राप्त हुआ था ----- निम्नलिखित पतों पर सफल डिलीवरी की सूचना प्राप्त हुई थी -----<recipient@yourcustomer.com> (मेलबॉक्स में सफलतापूर्वक डिलीवर हो गया) ----- सत्र का लिखित विवरण नीचे दिया गया है -----<recipient@yourcustomer.com> ... सफलतापूर्वक वितरित किया गया [...]

बहुत कम मामलों में (भेजे गए ईमेल के 1% से भी कम), प्रेषक को रसीद नहीं मिलती। ऐसा तब होता है जब प्राप्तकर्ता ने अपने ईमेल सर्वर पर "गोपनीयता / रसीद न मिलने" का विशेष विकल्प सक्रिय कर रखा हो। यह सेटिंग आमतौर पर अनुशंसित नहीं है क्योंकि इससे सामान्य डिलीवरी न होने की सूचनाएं भी अवरुद्ध हो जाती हैं।.

शीर्ष पर वापस जाएं

ईमेल संदेशों की जाँच करें

ईमेल के लिए आवर्धक लेंस

कभी-कभी, क्या हो रहा है यह समझने के लिए, भेजे गए ईमेल संदेशों की जांच करना आवश्यक होता है।.

अनुरोध करने पर, RealSender सभी भेजे गए ईमेल की स्वचालित प्रतिलिपि को एक समर्पित मेलबॉक्स में सहेजने की सुविधा सक्रिय कर सकता है।.

मेलबॉक्स को इस तरह से कॉन्फ़िगर किया गया है कि यह कम समय में बिना किसी परेशानी के बड़ी मात्रा में ईमेल प्राप्त कर सके।
ईमेल संदेश 7 दिनों के बाद स्वचालित रूप से हटा दिए जाते हैं।

ध्यान दें: यदि संदेश व्यक्तिगत ईमेल खातों से भेजे जाते हैं (भले ही वे कंपनी के खाते हों), तो
आपको प्रेषक को सूचित करना होगा कि उसके द्वारा भेजे गए संदेशों को तकनीकी जांच करने के लिए पढ़ा जा सकता है।


निःशुल्क परीक्षण का अनुरोध करें

सिस्टम स्थिति पृष्ठ

एसएमटीपी सर्वर जांच

सेवा के सही ढंग से काम करने की पुष्टि करने के लिए,
हमने एक स्वचालित नियंत्रण वातावरण सक्रिय कर दिया है।

एक बाहरी एप्लिकेशन हर दस मिनट में प्रत्येक SMTP सर्वर से कनेक्ट होता है
और एक वास्तविक संदेश भेजता है। ईमेल के सफलतापूर्वक भेजे जाने से हमें
सिस्टम की उपलब्धता और सही कार्यप्रणाली की गारंटी मिलती है।

इसका परिणाम आपके RealSender सर्वर के "स्टेटस पेज" पर प्रकाशित होता है, जिसे
rsXXX-realsender.com/status वेब पते पर आसानी से देखा जा सकता है।

डेटा वास्तविक समय में प्रदर्शित होता है, जैसे कि नीचे दिखाया गया उदाहरण डेटा।
प्रदर्शित जानकारी पिछले चौबीस घंटों की है।

2024-09-11 06:25:26 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 06:16:18 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 06:05:56 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:55:41 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:45:57 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:35:58 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:25:27 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:16:30 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 05:05:57 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है 2024-09-11 04:55:36 UTC rsXXX- हर दस मिनट में अपटाइम चेक (एक ईमेल सफलतापूर्वक भेजा गया है) - ठीक है