यह उपकरण सर्वर पर निष्पादित होता है
यह कैसे काम करता है
ईमेल प्रोटोकॉल यह जाँच नहीं करता कि भेज कौन रहा है: कोई भी सर्वर प्रेषक में आपका डोमेन डाल सकता है। तीन DNS रिकॉर्ड यह दरवाज़ा बंद करते हैं। SPF बताता है कि कौन-से सर्वर डोमेन की ओर से भेज सकते हैं। DKIM हर संदेश को एक निजी कुंजी से हस्ताक्षरित करता है, जिसका सार्वजनिक हिस्सा DNS में प्रकाशित होता है। DMARC दोनों को जोड़ता है: यह माँगता है कि कम से कम एक पास हो और दिखाई देने वाले प्रेषक डोमेन से मेल खाए, प्राप्तकर्ता को बताता है कि विफल संदेशों का क्या करना है, और आपके नाम से भेजी गई हर चीज़ की रिपोर्ट माँगता है।
फ़रवरी 2024 से Gmail और Yahoo अपने उपयोगकर्ताओं को रोज़ 5000 से ज़्यादा संदेश भेजने वालों से SPF, DKIM और DMARC की माँग करते हैं, और इनमें से किसी एक की कमी का मतलब है अस्वीकृत ईमेल या स्पैम फ़ोल्डर। इसलिए तीनों को साथ जाँचना ठीक रहता है: DMARC के बिना एक बेदाग़ SPF ज़्यादा काम का नहीं, और गलत ढंग से प्रकाशित DKIM के साथ reject पर सेट DMARC आपकी अपनी मेल को ही रोक देता है।
जाँच हमारे सर्वर से सार्वजनिक DNS क्वेरी के ज़रिए होती है, ठीक वैसे ही जैसे कोई भी मेल सर्वर करता। SPF का पूरा मूल्यांकन होता है — DNS लुकअप गिनने के लिए हर include और redirect का पीछा किया जाता है, क्योंकि 10 की सीमा पार करने से पूरा रिकॉर्ड अमान्य हो जाता है। MX रिकॉर्ड और वैकल्पिक MTA-STS, TLS-RPT व BIMI रिकॉर्ड भी जाँचे जाते हैं।
उदाहरण
github.comSPF · 10 / 10प्रदाताओं के आठ include (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) और उनके अपने include मिलकर मूल्यांकन को ठीक 10 DNS लुकअप की सीमा तक ले जाते हैं। एक और प्रदाता जुड़ते ही पूरा SPF स्थायी त्रुटि देने लगेगा।example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sऐसे डोमेन के लिए सही सेटअप जो न ईमेल भेजता है न पाता है: शून्य MX, किसी को अधिकृत न करने वाला SPF और reject पर सेट DMARC। यह पार्क किए गए डोमेन की सुरक्षा करता है, जो नकल का आम निशाना होते हैं।v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %धीरे-धीरे लागू करना: विफल संदेशों में से केवल हर चौथा स्पैम में जाता है, और रिपोर्ट rua में दिए मेलबॉक्स पर आती हैं ताकि आप उन वैध प्रेषकों को पहचान सकें जो अभी प्रमाणित नहीं हैं।उपयोग के मामले
- यह पता लगाना कि डोमेन के ईमेल स्पैम में क्यों जाते हैं या Gmail, Outlook या Yahoo उन्हें क्यों अस्वीकार करते हैं।
- नया भेजने वाला प्रदाता, जैसे CRM या न्यूज़लेटर प्लेटफ़ॉर्म, जोड़ने से पहले यह जाँचना कि SPF 10 DNS लुकअप से ऊपर न जाए।
- सेटअप के बाद जाँचना कि किसी प्रदाता की DKIM कुंजी ठीक से प्रकाशित हुई है।
- वैध ईमेल रोके बिना DMARC को none से quarantine और फिर reject पर ले जाने की योजना बनाना।
- किसी ग्राहक या अधिग्रहित कंपनी के डोमेन का ऑडिट करना, उन पार्क किए गए डोमेन सहित जिन्हें ईमेल नहीं भेजना चाहिए।
- फ़िशिंग का विश्लेषण करते समय किसी संदिग्ध प्रेषक का सेटअप देखना।
अक्सर पूछे जाने वाले प्रश्न
मेरा डोमेन ईमेल पर हस्ताक्षर करता है, फिर भी DKIM नहीं मिला ऐसा क्यों दिखता है?
क्योंकि DKIM किसी डोमेन की कुंजियों की सूची बनाने नहीं देता: हर कुंजी <selector>._domainkey.<domain> पर होती है और उसे खोजने के लिए सेलेक्टर पता होना चाहिए। टूल सबसे आम सेलेक्टर आज़माता है, लेकिन कई प्रदाता अपने नाम या तारीख़ वाले नाम इस्तेमाल करते हैं। डोमेन से भेजा गया कोई ईमेल खोलें, DKIM-Signature हेडर ढूँढें और s= का मान कॉपी करें; उस सेलेक्टर से जाँच सटीक होती है।
अगर SPF 10 DNS लुकअप से ज़्यादा हो जाए तो क्या होता है?
RFC 7208 प्राप्तकर्ता को स्थायी त्रुटि (permerror) लौटाने के लिए बाध्य करता है, और DMARC के लिए इसका मतलब है कि SPF विफल हुआ। include, a, mx, ptr और exists मैकेनिज़्म तथा redirect मॉडिफ़ायर लुकअप ख़र्च करते हैं, हर include के अंदर वाले भी; ip4 और ip6 कोई लुकअप नहीं लेते। संख्या घटाने के लिए ऐसे प्रदाता हटाएँ जो अब इस्तेमाल नहीं होते, include की जगह ip4 रेंज डालें या अपने SPF वाले सबडोमेन से भेजें।
~all या -all?
DMARC सक्रिय होने पर फ़र्क कम है: प्राप्तकर्ता SPF क्वालिफ़ायर नहीं, DMARC नीति लागू करता है। ~all आम है क्योंकि कुछ प्राप्तकर्ता -all होने पर DKIM जाँचने से पहले ही अस्वीकार कर देते हैं, जिससे वह फ़ॉरवर्ड की गई मेल खो सकती है जिसे DKIM बचा लेता। DMARC के बिना, अनधिकृत मेल को अस्वीकार करवाने का एकमात्र तरीका -all है।
बिना ईमेल खोए DMARC को none से reject पर कैसे ले जाऊँ?
p=none और rua में एक पते के साथ शुरू करें और कुछ हफ़्तों तक समेकित रिपोर्ट पढ़ें: ये आपके डोमेन से भेजने वाले हर सर्वर को दिखाती हैं और बताती हैं कि वह SPF या DKIM में पास होता है या नहीं। छूटे हुए वैध प्रेषकों को प्रमाणित करें, कम pct के साथ quarantine पर जाएँ, pct धीरे-धीरे बढ़ाएँ और reject पर पहुँचें। सीधे reject पर जाने से अक्सर बिलिंग सिस्टम, CRM या ऐसे आंतरिक सिस्टम बाहर हो जाते हैं जिन्हें कोई याद नहीं रखता।
क्या 1024-बिट DKIM कुंजी काफ़ी है?
यह काम करती है, क्योंकि RFC 8301 प्राप्तकर्ताओं को 1024 से 4096 बिट तक की कुंजियाँ स्वीकार करने को कहता है, लेकिन वही मानक हस्ताक्षर करने वालों को कम से कम 2048 इस्तेमाल करने की सलाह देता है। 1024 से छोटी कुंजियाँ मान्य नहीं मानी जातीं। 2048 पर जाना आसान है: नई कुंजी दूसरे सेलेक्टर से प्रकाशित करें, हस्ताक्षर बदलें और फिर p खाली छोड़कर पुरानी रद्द कर दें।
MTA-STS, TLS-RPT और BIMI किस काम के हैं?
MTA-STS (RFC 8461) भेजने वाले सर्वरों से कहता है कि आपके MX पर डिलीवरी के समय TLS अनिवार्य करें, जिससे कनेक्शन को सादे टेक्स्ट पर गिराने वाले हमले रुकते हैं। TLS-RPT (RFC 8460) उन डिलीवरी के विफल होने पर आपको रिपोर्ट भेजता है। BIMI इसे सपोर्ट करने वाले क्लाइंट में प्रेषक के पास ब्रांड का लोगो दिखाता है, और केवल quarantine या reject वाले DMARC के साथ काम करता है। इनमें से कोई अनिवार्य नहीं, पर तीनों मदद करते हैं।