SPF, DKIM और DMARC: कोल्ड ईमेल भेजने से पहले जो टेक्निकल सेटअप जरूरी है
जो टीमें कोल्ड ईमेल से नए क्लाइंट खोजती हैं, वे अक्सर subject line और copy पर हफ्तों लगाती हैं, लेकिन SPF, DKIM, DMARC जैसे तीन DNS रिकॉर्ड को नज़रअंदाज़ कर देती हैं — और यही सबसे पहला फिल्टर होता है जिसे मेल पास ही नहीं कर पाता। यह लेख इन तीनों प्रोटोकॉल को बिना जार्गन के समझाता है, ताकि आप खुद अपना सेटअप चेक कर सकें, न कि सिर्फ किसी एजेंसी की बात पर भरोसा करें।
- SPF बताता है कौन से सर्वर आपके domain से मेल भेज सकते हैं; DKIM साबित करता है कि मेल रास्ते में बदला नहीं गया; DMARC तय करता है कि दोनों fail हों तो क्या हो।
- तीनों मिलकर filter को 'धोखा' नहीं देते — ये सिर्फ यह साबित करते हैं कि आप वही domain हैं जो होने का दावा कर रहे हैं।
- एक domain पर multiple SPF records या पुराना DKIM selector, दोनों ही cold email को सीधे spam में भेज सकते हैं।
- DMARC को none से शुरू करके धीरे-धीरे reject तक ले जाना चाहिए, वरना legitimate मेल भी bounce हो सकता है।
- B2B कोल्ड आउटरीच के लिए अलग sending subdomain इस्तेमाल करना main corporate domain की reputation सुरक्षित रखता है।
कोल्ड ईमेल स्पैम में क्यों जाता है — असली वजह content नहीं है
B2B कोल्ड आउटरीच targeted होता है — रोज़ थोड़ी संख्या में, specific कंपनी के specific व्यक्ति को, पर्सनलाइज़्ड मैसेज। फिर भी अगर भेजने वाले domain के पास authentication signal नहीं है, तो Gmail, Outlook या Yahoo जैसी mailbox providers उसे संदिग्ध मानती हैं — चाहे content कितना भी अच्छा क्यों न हो।
हर incoming मेल के लिए receiving server तीन सवाल पूछता है: क्या भेजने वाला सर्वर इस domain के लिए authorized है (SPF), क्या मेल का content भेजे जाने के बाद बदला तो नहीं गया (DKIM), और अगर दोनों में से कोई fail हो जाए तो क्या किया जाए (DMARC)। spf dkim dmarc explained करने का मतलब यही है — ये तीनों domain की पहचान प्रमाणित करते हैं, filter को bypass नहीं करते।
LDM जैसी anti-spam approach में लक्ष्य 'फिल्टर को चकमा देना' कभी नहीं होता। लक्ष्य यह है कि आप असली, वैध business sender के रूप में दिखें — और यही वह जगह है जहां spf dkim dmarc का सही सेटअप शुरुआती बिंदु बनता है, न कि पूरी रणनीति।
SPF: तय करना कि कौन-से सर्वर आपकी तरफ से मेल भेज सकते हैं
SPF (Sender Policy Framework) एक DNS TXT रिकॉर्ड है जो बताता है कि किस-किस मेल सर्वर को आपके domain के नाम पर मेल भेजने की अनुमति है। उदाहरण के लिए: v=spf1 include:_spf.google.com include:sendgrid.net ~all — यह रिकॉर्ड कहता है कि Google Workspace और SendGrid को भेजने की अनुमति है, बाकी सबको 'soft fail' माना जाए।
अगर SPF record मौजूद ही नहीं है, या गलत है, तो receiving server को कोई भरोसेमंद तरीका नहीं मिलता यह जांचने का कि मेल सच में आपके domain से आया या किसी और सर्वर से spoof किया गया। नए domain पर cold email शुरू करने से पहले यह सबसे पहला चरण होना चाहिए।
- अपने domain से मेल भेजने वाले सभी sources की लिस्ट बनाएं — Google Workspace, CRM (जैसे HubSpot), ESP, LDM जैसा outreach tool
- इन सबको एक ही SPF record में include करें — एक domain पर दो SPF records invalid माने जाते हैं और authentication पूरी तरह fail हो सकता है
- 10 DNS lookups की सीमा याद रखें — बहुत सारे includes चेन में जोड़ने पर SPF खुद ही break हो जाता है
- शुरुआत ~all (soft fail) से करें; कुछ हफ्तों तक स्थिर monitoring के बाद -all (hard fail) पर जाएं
- DNS propagate होने में 24–48 घंटे लग सकते हैं, इसलिए पहले से समय रखें
DKIM: डिजिटल हस्ताक्षर जो मेल को बीच में बदलने से पकड़ता है
DKIM (DomainKeys Identified Mail) मेल हेडर पर एक cryptographic signature जोड़ता है, जो private key से बनती है। इसकी matching public key DNS में एक TXT record (selector._domainkey.yourdomain.com) पर रखी जाती है। receiving server इस signature को verify करता है — अगर मेल भेजने के बाद रास्ते में कहीं बदल दिया गया हो, तो signature fail हो जाती है।
SPF सिर्फ 'सर्वर' को check करता है, DKIM 'content की integrity' को। इसीलिए दोनों का साथ होना जरूरी है — कोई एक अकेला काफी नहीं है, यही spf dkim dmarc meaning समझने की असली कुंजी है।
- अपने sending platform (Google Workspace admin console, ESP, या LDM) से DKIM key generate करें
- 1024-bit की जगह 2048-bit key चुनें — ज्यादा सुरक्षित और अब लगभग हर provider इसे सपोर्ट करता है
- हर sending tool का अलग selector हो सकता है (जैसे google._domainkey, sendgrid._domainkey) — हर एक को अलग से DNS में जोड़ें और verify करें
- अगर एक ही domain से Google Workspace और कोई cold email tool, दोनों भेज रहे हैं, तो दोनों के DKIM records अलग-अलग होने चाहिए
DMARC: SPF और DKIM को जोड़कर पॉलिसी और reporting तय करना
DMARC (Domain-based Message Authentication, Reporting and Conformance) SPF और DKIM के नतीजों को जोड़कर एक policy लागू करता है — बताता है कि अगर दोनों में से कोई fail हो जाए तो receiving server क्या करे: none (सिर्फ record करें, कुछ न करें), quarantine (spam folder में भेजें), या reject (मेल पूरी तरह ठुकरा दें)। साथ ही यह aggregate reports (rua tag) भी भेजता है, जिनसे पता चलता है कि कौन-कौन आपके domain के नाम पर मेल भेज रहा है — असली sending tools और potential spoofers दोनों।
रोलआउट क्रम अहम है: शुरुआत हमेशा p=none से करें और 2–4 हफ्ते reports पढ़ें ताकि सभी legitimate sources पहचान लिए जाएं। फिर p=quarantine, और आखिर में p=reject — तभी जब पूरा भरोसा हो कि हर वैध sending source SPF और DKIM दोनों में align हो रहा है। सीधे reject पर जाने से खुद अपनी ही टीम की मेल bounce होने लगती है।
आंकड़े indicative हैं, targeted B2B कैंपेन के practice अनुभव पर आधारित — मेलबॉक्स प्रोवाइडर और domain history के अनुसार बदलते हैं।
B2B टीमें जो आम गलतियां करती हैं
ज्यादातर deliverability समस्याएं गलत content से नहीं, बल्कि इन बुनियादी गलतियों से आती हैं — जिन्हें एक बार सही करना काफी होता है।
- एक domain पर दो अलग SPF records बना देना (सही तरीका है: सभी sources को एक ही record में include करना)
- जो subdomain cold outreach के लिए इस्तेमाल हो रहा है, उस पर अलग से SPF/DKIM सेट करना भूल जाना — सिर्फ main domain पर सेटअप काफी नहीं
- DMARC को महीनों तक p=none पर छोड़ देना और reports कभी न पढ़ना, जिससे spoofing का पता ही नहीं चलता
- नए domain पर बिना warm-up के सीधे बड़ी संख्या में मेल भेजना, भले ही SPF/DKIM/DMARC तीनों सही हों
- DKIM key/selector को कभी rotate न करना जब कोई पुराना sending tool बंद हो चुका हो — orphaned records भरोसा घटाते हैं
- personal Gmail या Outlook अकाउंट से 'official-looking' cold email भेजना, जहां domain-level authentication की कोई गुंजाइश ही नहीं होती
Checklist: LDM पर domain सेटअप कैसे होता है
LDM पर हर नए sending domain को onboard करने से पहले SPF, DKIM, DMARC तीनों verify किए जाते हैं — बिना इसके कैंपेन शुरू नहीं होता। कोल्ड आउटरीच के लिए main corporate domain (जैसे company.in) की जगह एक अलग sending subdomain (जैसे outreach.company.in) इस्तेमाल किया जाता है, ताकि अगर कभी कोई sending issue हो भी, तो main domain की reputation और उस पर आने वाली internal मेल सुरक्षित रहे।
भारत में Digital Personal Data Protection Act, 2023 (DPDP Act) के तहत किसी कंपनी के प्रतिनिधि का business email address भी personal data की श्रेणी में आता है। इसलिए legitimate business purpose, स्पष्ट unsubscribe/opt-out विकल्प और proportionate भेजने की मात्रा — ये सिर्फ deliverability के लिए नहीं, compliance के नज़रिए से भी जरूरी हैं।
- sending subdomain के लिए अलग SPF, DKIM, DMARC record — main domain से independent
- DMARC शुरुआत p=none से, फिर 3–4 हफ्तों में quarantine, फिर reject
- नए domain का warm-up: कम volume से शुरू, धीरे-धीरे बढ़ाना, हर हफ्ते reply और bounce rate चेक करना
- हर sending tool का DKIM selector अलग से track करना, purana tool हटते ही record clean करना
- DMARC aggregate reports को महीने में कम से कम एक बार review करना
आंकड़े indicative हैं, targeted B2B कैंपेन के practice अनुभव पर आधारित — actual timeline domain की उम्र और sending history पर निर्भर करता है।
अक्सर पूछे जाने वाले सवाल
SPF, DKIM, DMARC में क्या अंतर है?
SPF बताता है कौन-से सर्वर आपके domain से मेल भेज सकते हैं। DKIM साबित करता है कि मेल का content रास्ते में बदला नहीं गया। DMARC इन दोनों के नतीजों को जोड़कर तय करता है कि fail होने पर मेल के साथ क्या हो — और spoofing पर reports भेजता है।
अगर मैं ये तीनों सेट नहीं करूं तो क्या होगा?
मेल inbox की जगह स्पैम फोल्डर में जा सकता है, कई बार deliver ही नहीं होता, और बार-बार होने पर पूरे domain की reputation गिर जाती है — जिसका असर सिर्फ कोल्ड outreach ही नहीं, आपकी सामान्य business मेल पर भी पड़ता है।
क्या DMARC को सीधे reject पर सेट करना चाहिए?
नहीं। p=none से शुरू करके कुछ हफ्ते reports पढ़ें, यह पक्का करें कि सभी legitimate sending tools SPF और DKIM में align हैं, फिर quarantine और आखिर में reject पर जाएं। सीधे reject करने से legitimate मेल भी bounce हो सकती है।
क्या cold email के लिए अलग subdomain इस्तेमाल करना जरूरी है?
अनिवार्य नहीं, लेकिन अत्यधिक अनुशंसित है। इससे अगर sending domain की reputation पर कभी असर पड़े, तो आपकी internal और client-facing मेल जो main domain से जाती है, प्रभावित नहीं होती।
सेटअप सही करने के बाद कितना समय लगेगा असर दिखने में?
DNS propagate होने में 24–48 घंटे लगते हैं, लेकिन inbox placement में सुधार धीरे-धीरे दिखता है — नए domain के लिए warm-up के साथ आमतौर पर 4–6 हफ्तों में स्थिर सुधार दिखता है।
क्या DPDP Act का इससे कोई संबंध है?
सीधे तौर पर technical authentication को DPDP Act रेगुलेट नहीं करता, लेकिन जिन व्यक्तियों को आप मेल भेज रहे हैं उनका email address personal data है — इसलिए legitimate purpose, opt-out और proportionate volume जैसी practices, अच्छे domain authentication के साथ मिलकर ही एक भरोसेमंद, कानूनी रूप से टिकाऊ outreach बनाती हैं।
क्या आप इसे अपने आउटरीच में लागू करना चाहते हैं?
काम शुरू करने से पहले हम बताएंगे कि यह आपके सेगमेंट और प्रोडक्ट पर कैसे काम करेगा।
बात करें