<spf> declare your smtp servers

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

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

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

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

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

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

• एक "सॉफ्ट" (~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 रिकॉर्ड प्राप्त करता है और निर्धारित करता है कि रिकॉर्ड वैध है या नहीं।
एसपीएफ की ऑनलाइन जांच करें
ईमेल संदेश भेजते समय आपकी ईमेल एसपीएफ सेटिंग की पुष्टि करता है

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

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

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

In these cases, to keep the email authentication consistent,
configure the dkim signature domain to be aligned with the sender’s From address.
See: email authentication advanced » <dkim> alignment for dmarc.

<spf> check online

1. निम्नलिखित पते पर ईमेल संदेश भेजें:

spf@tester.realsender.com

2. एसपीएफ सत्यापन के परिणाम ऑनलाइन देखें:
   (दिखने में एक मिनट लगेगा)

https://tester.realsender.com/spf

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

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

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

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

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

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

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

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

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

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

<dkim> seal the email content

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<dkim> check online

1. निम्नलिखित पते पर ईमेल संदेश भेजें:

dkim@tester.realsender.com

2. डीकेआईएम सत्यापन परिणामों की ऑनलाइन जांच करें:
   (दिखने में एक मिनट लगेगा)

https://tester.realsender.com/dkim

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

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

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

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

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

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

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

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

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

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

<spf> alignment for dmarc

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

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

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

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

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

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

शिथिल संरेखण

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

उदाहरण:

• यदि आपका मेल-फ्रॉम डोमेन 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> alignment for dmarc

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

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

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

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

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

शिथिल संरेखण

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

उदाहरण:

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

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

सख्त संरेखण

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

उदाहरण:

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

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

<dmarc> detects fake emails

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

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

प्रेषक:

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

रिसीवर:

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

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

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

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

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

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

RealSender के SMTP सर्वर सभी आउटगोइंग ईमेल संदेशों पर 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"

2. अगले दिन से आपको डीएमएआरसी आरयूए रिपोर्ट ऑनलाइन मिलनी शुरू हो जाएंगी।
   
   आपको शायद पता चले कि आप किसी तीसरे पक्ष द्वारा चलाई जा रही ईमेल कैंपेन को प्रमाणित करना भूल गए हैं।
   यदि ऐसा कुछ होता है, तो बस इसे प्रमाणित करें और जांच लें कि अगली मेलिंग डीएमएआरसी परीक्षण पास करती है या नहीं।

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

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

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

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

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

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

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

<dmarc> rua reports online

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: to= recipient@yourcustomer.com , dsn=2.0.0, stat=भेजा गया (संदेश डिलीवरी के लिए स्वीकार कर लिया गया)

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

31 मई 10:00:22 rs336 v4V80L9Z004176: प्रेषक= sender@yourcompany.com
31 मई 10:00:24 rs336 v4V80L9Z004176: to= recipient@yourcustomer.com , dsn=4.7.1, stat=Deferred: 451 4.7.1 recipient@yourcustomer.com : प्राप्तकर्ता का पता अस्वीकृत: ग्रे लिस्टिंग लागू है, कृपया बाद में पुनः देखें
31 मई 10:02:03 rs336 v4V80L9Z004176: to= 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: to= 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: to= recipient@yourcustomer.com , dsn=5.0.0, stat=सेवा अनुपलब्ध
25 मई 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: सेवा अनुपलब्ध

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

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

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

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

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

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

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

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

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

Subject:  
      Returned mail: see transcript for details  
Body:  
      The original message was received at ...  
      ----- The following addresses had permanent fatal errors -----  
      <recipient@yourcustomer.com>  
      ----- Transcript of session follows -----  
      Deferred: Connection timed out with yourcustomer.com.  
      Message could not be delivered for 4 hours  
      Message will be deleted from queue  
      [...]  

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

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

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

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

Subject: 
      Return receipt
Body:
      The original message was received at ...
      ----- The following addresses had successful delivery notifications -----
      <recipient@yourcustomer.com>  (successfully delivered to mailbox)
      ----- Transcript of session follows -----
      <recipient@yourcustomer.com>... Successfully delivered
      [...]

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

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

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

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

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

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

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