SPF, DKIM, DMARC — तीनों प्रोटोकॉल एक-दूसरे से कैसे अलग हैं

जब कोई B2B sender पहली बार किसी prospect को cold email भेजता है, तो receiving mail server (Gmail, Outlook, या कोई corporate server) यह चेक करता है कि यह mail असल में उसी domain से आया है जिसका दावा कर रहा है। यह चेक तीन अलग प्रोटोकॉल — SPF, DKIM और DMARC — के ज़रिए होता है, और अगर एक भी गलत configure हो तो mail inbox की जगह spam folder में जा सकती है। यह article spf dkim dmarc difference को practical तरीके से समझाता है, ताकि targeted outreach शुरू करने से पहले domain को सही से तैयार किया जा सके।

spf dkim dmarc full form और हर एक का असली काम

spf dkim dmarc full forms जानना पहला कदम है। SPF यानी Sender Policy Framework — यह domain के DNS में एक TXT record होता है जो बताता है कि कौन-से IP address या mail server उस domain की तरफ से mail भेजने के लिए authorized हैं। DKIM यानी DomainKeys Identified Mail — यह हर outgoing email पर एक private key से digital signature जोड़ता है, और receiving server public key से उसे verify करता है।

dmarc full form है Domain-based Message Authentication, Reporting and Conformance। यह SPF और DKIM के ऊपर बैठता है — यह खुद authentication नहीं करता, बल्कि यह तय करता है कि अगर SPF या DKIM में से कोई fail हो जाए तो receiving mailbox provider उस mail के साथ क्या करे: उसे पास होने दे, spam में डाले, या पूरी तरह reject कर दे।

तीनों domain के DNS में TXT records के रूप में मौजूद रहते हैं। Setup खुद ज़्यादा मुश्किल नहीं है, लेकिन जो कंपनी multiple sending tool (CRM, marketing platform, transactional mail service) एक साथ इस्तेमाल करती है, वहाँ record आपस में टकरा सकते हैं — और यही सबसे common गलती है।

SPF कैसे काम करता है और कहाँ फेल होता है

SPF record कुछ ऐसा दिखता है: `v=spf1 include:_spf.google.com include:sendgrid.net ~all`। जब कोई mail server ईमेल receive करता है, वह sending domain का SPF record देखता है और चेक करता है कि जिस IP से mail आई है वह list में है या नहीं। अगर नहीं, तो SPF fail हो जाता है।

सबसे बड़ी दिक्कत तब आती है जब एक ही domain पर दो अलग SPF records बन जाते हैं (जैसे एक CRM टूल ने खुद add किया, दूसरा marketing platform ने) — DNS standard के अनुसार एक domain पर सिर्फ एक SPF record valid माना जाता है, बाकी सब को mail server ignore या fail कर सकता है। दूसरी सीमा यह है कि SPF सिर्फ envelope sender (Return-Path) को चेक करता है, email के 'From' header को नहीं — इसलिए अकेले SPF spoofing को पूरी तरह रोक नहीं पाता।

• एक domain पर सिर्फ एक SPF record रखें — सभी sending sources को उसी record में `include` करें
• 10 DNS lookups की limit को पार न करें, वरना SPF permerror होकर पूरा fail हो जाता है
• cold outreach tool और transactional mail दोनों का IP/domain SPF में शामिल करें

DKIM कैसे content को tamper-proof बनाता है

DKIM का काम अलग है — यह IP या server को नहीं, बल्कि email के actual content (subject, body, कुछ headers) को verify करता है। Sending server private key से एक signature बनाता है और उसे email header में जोड़ देता है। Receiving server domain के DNS में मौजूद public key से उस signature को verify करता है।

अगर email transit में किसी तरह बदल दी जाए (उदाहरण के लिए कोई forwarding service सिर्फ एक लाइन जोड़ दे), तो signature mismatch हो जाता है और DKIM fail हो सकता है। इसलिए बड़े मेलिंग lists या forwarding-heavy setups में DKIM alignment पर विशेष ध्यान देना पड़ता है — खासकर जब outreach domain पर कई sending tools साथ काम कर रहे हों।

DMARC — policy और visibility दोनों एक साथ

DMARC record यह जांचता है कि email के visible 'From' domain के साथ SPF और DKIM 'aligned' हैं या नहीं — यानी क्या दोनों उसी domain से match करते हैं जो recipient को दिख रहा है। अगर दोनों में से कोई भी aligned नहीं है, तो DMARC policy लागू होती है: `p=none` (सिर्फ report भेजो, कुछ block मत करो), `p=quarantine` (spam folder में भेजो), या `p=reject` (mail को पूरी तरह discard करो)।

नए domain के लिए `p=none` से शुरुआत करना समझदारी है — इससे बिना किसी mail को block किए यह पता चलता है कि कौन-कौन से sources उस domain की तरफ से mail भेज रहे हैं (`rua` reports के ज़रिए)। SPF और DKIM दोनों stable हो जाने के बाद धीरे-धीरे `quarantine` और फिर `reject` की तरफ बढ़ना चाहिए।

तीनों साथ मिलकर deliverability पर असर कैसे डालते हैं

जब कोई नई domain cold outreach शुरू करती है और SPF, DKIM, DMARC — तीनों सही configure होते हैं, तो mailbox providers (Gmail, Outlook) उस domain को धीरे-धीरे 'trusted sender' के रूप में treat करना शुरू करते हैं, बशर्ते sending volume भी controlled हो। अकेले DMARC record होना काफी नहीं — अगर SPF या DKIM alignment fail हो रहा है तो policy चाहे जो भी हो, mail spam folder में जा सकती है।

targeted B2B cold email में daily volume वैसे भी कम रहता है (per-day प्रति domain कुछ दर्जन mail), इसलिए authentication setup की गलती जल्दी दिखती नहीं — लेकिन जब reply rate अचानक गिर जाए या open rate कम आए, तो सबसे पहले यही तीन records चेक करने चाहिए।

आम गलतियाँ और checklist

सबसे common गलतियों में shामिल है: main corporate domain से सीधे cold outreach भेजना (जिससे पूरे company की email reputation risk में आती है), DMARC को सीधे `p=reject` पर सेट कर देना बिना monitoring phase के, और नई domain पर बिना warm-up के अचानक हाई volume भेजना। यह सारी गलतियाँ authentication सही होने के बावजूद deliverability खराब कर सकती हैं।

LDM में हम हर नई sending domain के लिए इन तीनों records को campaign शुरू होने से पहले verify करते हैं — SPF में सभी sources शामिल हैं या नहीं, DKIM signature domain से align है या नहीं, और DMARC कम-से-कम `p=none` मोड में मौजूद है ताकि reporting शुरू से मिलती रहे। यही base setup targeted B2B cold email की inbox placement की नींव है।

• domain के DNS में सिर्फ एक SPF record है और सभी sending tools उसमें include हैं
• DKIM key generate करके sending platform में जोड़ी गई है और signature verify हो रहा है
• DMARC record मौजूद है, कम-से-कम `p=none` के साथ, और `rua` report address set है
• cold outreach के लिए अलग subdomain इस्तेमाल हो रहा है, main corporate domain सुरक्षित रखा गया है
• नई domain पर volume धीरे-धीरे बढ़ाया जा रहा है (warm-up), अचानक spike नहीं

अक्सर पूछे जाने वाले सवाल