DKIM, SPF और DMARC
ईमेल ऑथेंटिकेशन वह तरीका है जिससे प्राप्त करने वाले मेल सर्वर तय करते हैं कि कोई संदेश सच में आपके डोमेन से आया है या नहीं। भेजने वाले डोमेन के लिए आप जो भी DNS रिकॉर्ड प्रकाशित करते हैं, वह एक खास बात साबित करता है। DKIM साबित करता है कि संदेश पर आपने हस्ताक्षर किया है। return-path साबित करता है कि बाउंस आपके डोमेन से संरेखित पते के ज़रिए वापस आते हैं। DMARC प्राप्तकर्ताओं को बताता है कि ये जाँचें विफल होने पर क्या करना है। यह पेज हर उस रिकॉर्ड का वर्णन करता है जिसे प्रकाशित करने के लिए हम आपसे कहते हैं, और यह भी कि वह क्या साबित करता है। अगर आपने अभी तक भेजने वाला डोमेन नहीं जोड़ा है, तो भेजने वाले डोमेन से शुरू करें।
DNS रिकॉर्ड
प्रकाशित किए जाने वाले रिकॉर्ड देखने के लिए Email > Domains खोलें, फिर अपना डोमेन चुनें। API यही रिकॉर्ड dns_records में लौटाता है।
भेजना तीन रिकॉर्ड पर निर्भर है: DKIM, return-path CNAME और DMARC। वैकल्पिक tracking CNAME केवल ब्रांडेड open/click ट्रैकिंग को नियंत्रित करता है और इसका भेजने पर कोई असर नहीं होता।
DKIM (TXT)
DKIM आपके स्वामित्व और हस्ताक्षर का प्रमाण है। हम आपके संगठन के लिए एक हस्ताक्षर कुंजी बनाते हैं और आपके भेजे हर संदेश पर उससे हस्ताक्षर करते हैं। इसका सार्वजनिक हिस्सा एक TXT रिकॉर्ड के रूप में ऐसे selector के तहत प्रकाशित होता है जो केवल आपके संगठन का है। प्राप्तकर्ता उस selector से सार्वजनिक कुंजी लेकर हस्ताक्षर की जाँच करते हैं। इससे साबित होता है कि संदेश उसी ने भेजा है जिसका आपके डोमेन के DNS पर नियंत्रण है। हर संगठन को अपना अलग selector और कुंजी मिलती है, इसलिए आपका DKIM प्रमाण केवल आपका होता है, भले ही कोई दूसरा ग्राहक उसी डोमेन से भेजे।
| प्रकार | होस्ट | मान |
|---|---|---|
| TXT | <selector>._domainkey.example.com | v=DKIM1; k=rsa; p=<public-key> |
सेलेक्टर और सार्वजनिक कुंजी आपके लिए बनाई जाती हैं। इन्हें हाथ से बनाने के बजाय डैशबोर्ड या API से सटीक होस्ट और मान कॉपी करें। हम आपके DNS प्रदाता का पता लगाते हैं और मान को उसी प्रारूप में देते हैं जिसकी वह प्रदाता अपेक्षा करता है, इसलिए इसे जैसा दिखाया गया है वैसा ही पेस्ट करें। अगर आपका प्रदाता लंबे TXT मान को एक स्ट्रिंग के रूप में स्वीकार नहीं करता, तो DNS रिकॉर्ड स्प्लिटर उसे उन उद्धृत हिस्सों में बाँट देता है जो प्रदाता को चाहिए।
रिटर्न-पाथ (CNAME)
रिटर्न-पाथ रिकॉर्ड आपका envelope-from (बाउंस) डोमेन तय करता है। आपके संदेशों के बाउंस और डिलीवरी फ़ीडबैक इसी होस्टनेम पर भेजे जाते हैं, और इसे हमारी ओर पॉइंट करने से हम इन्हें आपके लिए प्रोसेस कर पाते हैं। यह रिकॉर्ड SPF अलाइनमेंट भी देता है। प्राप्तकर्ता SPF की जाँच envelope-from डोमेन के आधार पर करते हैं। चूँकि यह होस्टनेम हमारे बाउंस इंफ्रास्ट्रक्चर पर रिज़ॉल्व होता है, इसलिए आपके apex पर कोई रिकॉर्ड न होने पर भी SPF पास होता है और आपके डोमेन के साथ अलाइन होता है (SPF कहाँ है? देखें)।
| प्रकार | होस्ट | मान |
|---|---|---|
| CNAME | send.example.com | <region>.bounce.bird.com |
होस्ट डिफ़ॉल्ट रूप से आपके भेजने वाले डोमेन के अंतर्गत send. होता है, लेकिन आप कोई दूसरा होस्टनेम चुन सकते हैं। वैल्यू इस पर निर्भर करती है कि आपका वर्कस्पेस किस क्षेत्र से भेजता है; इसे डैशबोर्ड से कॉपी करें। इस रिकॉर्ड को कस्टमाइज़ करने और बदलने की जानकारी बाउंस डोमेन गाइड में है।
DMARC (TXT)
DMARC आपकी नीति प्रकाशित करता है: यह प्राप्तकर्ताओं को बताता है कि DKIM या SPF अलाइनमेंट में विफल मेल के साथ क्या करना है (केवल निगरानी के लिए p=none, लागू करने के लिए p=quarantine या p=reject), और समेकित रिपोर्ट कहाँ भेजनी हैं (rua)। डोमेन से भेजना शुरू होने से पहले हम DMARC रिकॉर्ड का मौजूद होना ज़रूरी मानते हैं, और आपके DNS को सीधे रिज़ॉल्व करके इसका सत्यापन करते हैं। डोमेन पर मौजूद रिकॉर्ड और पैरेंट डोमेन से विरासत में मिला रिकॉर्ड, दोनों मान्य हैं।
| प्रकार | होस्ट | वैल्यू |
|---|---|---|
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc-agg@dmarc.bird.com; |
नमूना वैल्यू हमारी सिफ़ारिश है: p=none शुरुआत के लिए एक सुरक्षित नीति है, और rua पता समेकित रिपोर्ट हम तक पहुँचाता है। आप अपनी नीति और रिपोर्टिंग पता इस्तेमाल कर सकते हैं, क्योंकि गेट के लिए केवल एक मान्य DMARC रिकॉर्ड का मौजूद होना ज़रूरी है; DMARC नीति जनरेटर इसे लिखने में मदद कर सकता है। अगर आपके पास पहले से DMARC रिकॉर्ड है, या पैरेंट डोमेन पर कोई रिकॉर्ड है, तो उसे बदलने की ज़रूरत नहीं है। अगर आप rua रिपोर्ट अपने मेलबॉक्स पर भेजते हैं, तो DMARC रिपोर्ट विश्लेषक कच्चे XML को पढ़ने योग्य रूप में बदल देता है।
ट्रैकिंग (CNAME, वैकल्पिक)
ट्रैकिंग रिकॉर्ड आपको ओपन और क्लिक ट्रैकिंग के लिए एक ब्रांडेड होस्टनेम देता है। क्लिक ट्रैकिंग चालू होने पर आपके संदेशों के लिंक किसी सामान्य साझा डोमेन के बजाय इसी होस्टनेम पर बदल दिए जाते हैं। इससे प्राप्तकर्ताओं को लिंक बेहतर दिखते हैं और लिंक की प्रतिष्ठा आपके ब्रांड से जुड़ी रहती है। यह सेटिंग आपके वर्कस्पेस के डोमेन कॉन्फ़िगरेशन का हिस्सा है।
| प्रकार | होस्ट | मान |
|---|---|---|
| CNAME | links.example.com | <region>.links.bird.com |
यह रिकॉर्ड भेजने की शर्तों का हिस्सा नहीं है: जिस डोमेन के DKIM, return-path और DMARC सत्यापित हैं, वह ट्रैकिंग रिकॉर्ड न होने पर भी भेज सकता है। यह केवल तय करता है कि ब्रांडेड ओपन/क्लिक ट्रैकिंग उपलब्ध है या नहीं। इसे कस्टमाइज़ करने और ट्रैकिंग चालू करने वाली सेटिंग्स के बारे में ट्रैकिंग डोमेन गाइड में बताया गया है।
SPF कहाँ है?
आपको अपने डोमेन के एपेक्स (example.com) पर SPF रिकॉर्ड प्रकाशित करने की ज़रूरत नहीं है, और डैशबोर्ड भी इसे नहीं माँगता। SPF की जाँच दिखाई देने वाले From पते के बजाय envelope-from डोमेन पर होती है। आपका envelope-from, return-path होस्टनेम (send.example.com) है। सत्यापित return-path CNAME इसे हमारे बाउंस इंफ्रास्ट्रक्चर की ओर इंगित करता है, जिस पर SPF प्राधिकरण पहले से सेट है। इसलिए SPF पास होता है, और यह आपके डोमेन से संरेखित होता है क्योंकि return-path उसी का सबडोमेन है।
अपने एपेक्स पर include: प्रविष्टि जोड़ने से हमारे ज़रिए भेजे गए मेल को प्राधिकरण नहीं मिलता। SPF जाँच में DNS क्वेरी करने वाले टर्म की संख्या 10 तक सीमित होती है, इसलिए अनावश्यक लुकअप न जोड़ें। अगर अन्य प्रेषकों के लिए आपके एपेक्स पर पहले से SPF रिकॉर्ड है, तो उसे न बदलें।
इन रिकॉर्ड का सत्यापन कैसे होता है
डोमेन रजिस्टर करने के बाद हम आपका DNS अपने आप जाँचते हैं, हर डोमेन को रोज़ दोबारा जाँचते हैं, और हर रिकॉर्ड की स्थिति डोमेन रिसोर्स और डैशबोर्ड पर दिखाते हैं। पूरी प्रक्रिया सेंडिंग डोमेन § सत्यापन जीवनचक्र में दी गई है। इसमें स्थितियाँ, माँग पर दोबारा जाँच, और वे छूट नियम शामिल हैं जो DNS की किसी अस्थायी गड़बड़ी को भेजने में बाधा नहीं बनने देते।
अगले कदम
- डोमेन जोड़ने से लेकर उन्हें प्रबंधित करने तक की पूरी प्रक्रिया: सेंडिंग डोमेन
- आपके DNS प्रदाता के लिए चरण-दर-चरण निर्देश, उदाहरण के लिए Cloudflare; अन्य रजिस्ट्रार की गाइड इसी नॉलेज-बेस सेक्शन में हैं
- सत्यापन एंडपॉइंट और रिकॉर्ड पेलोड: डोमेन API संदर्भ
संबंधित संसाधन
इस विषय के लिए दस्तावेज़, गाइड और उदाहरणों के साथ आगे बढ़ें।