एक बेहतरीन अनसब्सक्राइब पेज से सदस्यता समाप्त करना आसान हो जाता है, लोगों को बांधे बिना प्राथमिकता या आवृत्ति के विकल्प मिलते हैं, और सदस्यता समाप्त करने की पुष्टि तुरंत हो जाती है। एक साफ-सुथरा अनसब्सक्राइब पेज...
चाबी छीन लेना
- SPF (आरएफसी 7208), DKIM (आरएफसी 6376), और DMARC (आरएफसी 7489) पूरक हैं DNSमानक-आधारित मानक — ये विनिमेय चेकलिस्ट आइटम नहीं हैं।
- Google के प्रेषक दिशानिर्देशों के अनुसार, बल्क प्रेषकों (5,000+ संदेश/दिन) को Gmail) स्थापित करना SPF और DKIM, प्रकाशित करना DMARC (कम से कम
p=none), और दृश्यमान From डोमेन को संरेखित करें SPF or DKIM. - DMARC जब गुजरता है भी SPF or DKIM प्रमाणित करता है और यह प्रेषक डोमेन के साथ संरेखित होता है — संरेखण विफलताओं के कारण ही "रिकॉर्ड मौजूद हैं" लेकिन मेल फिर भी विफल हो जाता है।
- रोल आउट DMARC सुरक्षित रूप से:
p=noneसमग्र रिपोर्टों के साथ → प्रेषकों को ठीक करें →p=quarantine→p=reject. - प्रमाणीकरण यह साबित करता है कि आपके डोमेन के रूप में किसे संदेश भेजने की अनुमति है। यह सूची की गुणवत्ता को साबित नहीं करता है - अमान्य और जोखिम भरे पते प्रमाणीकरण के पूरी तरह से सफल होने के बाद भी प्रतिष्ठा को नुकसान पहुंचा सकते हैं।
SPF, DKIM, तथा DMARC हर डिलीवरी संबंधी चर्चा में ये मानक सामने आते हैं—और इसका एक ठोस कारण है। ये सार्वजनिक मानक हैं जिनका उपयोग मेलबॉक्स प्रदाता यह तय करने के लिए करते हैं कि आपके डोमेन से आने वाला कोई संदेश अधिकृत, सही और नीति के अनुरूप है या नहीं। 2026 में ये गंभीर प्रेषकों, विशेष रूप से मेल भेजने वाली टीमों के लिए बुनियादी अपेक्षाओं का भी हिस्सा होंगे। Gmailयाहू और इसी तरह के अन्य उपभोक्ताओं के इनबॉक्स में बड़े पैमाने पर डेटा मौजूद होता है।
यह गाइड बताती है कि प्रत्येक रिकॉर्ड क्या कार्य करता है, तीनों आपस में कैसे जुड़े होते हैं, वैध ईमेल को बाधित किए बिना उन्हें कैसे प्रकाशित किया जाए, और प्रमाणीकरण अकेले सूची स्वच्छता का विकल्प क्यों नहीं है। प्राथमिक संदर्भों में शामिल हैं: आरएफसी 7208 (SPF), आरएफसी 6376 (DKIM), आरएफसी 7489 (DMARC), अवलोकन पर dmarc.org, तथा गूगल के ईमेल प्रेषक दिशानिर्देश.
ईमेल प्रमाणीकरण स्पूफिंग के जोखिम को कम करता है और इनबॉक्स में ईमेल भेजने में सहायता करता है। यह इस बात की पुष्टि नहीं करता कि प्राप्तकर्ता का पता मौजूद है या वह आपका ईमेल चाहता है। DNS टिकाऊ वितरण क्षमता के लिए निरंतर सूची स्वच्छता के साथ रिकॉर्ड।
2026 में ईमेल प्रमाणीकरण क्यों महत्वपूर्ण है?
प्रमाणीकरण के बिना, कोई भी आपके डोमेन को 'फ्रॉम' हेडर में डाल सकता है। फिर प्राप्तकर्ताओं को यह अनुमान लगाना पड़ता है कि कौन से संदेश आपके हैं और कौन से फ़िशिंग संदेश हैं। SPF, DKIM, तथा DMARC प्राप्तकर्ताओं को क्रिप्टोग्राफिक और DNSसमर्थित सिग्नल ताकि वे अनधिकृत मेल के साथ अधिक सख्ती से निपट सकें और जब कोई आपके ब्रांड की नकल करे तो आपको रिपोर्टिंग प्रदान कर सकें।
गूगल की प्रेषक दिशानिर्देश एक स्पष्ट रेखा खींचें:
- सभी प्रेषक व्यक्तिगत के लिए Gmail खाते: सेटअप करें SPF or DKIM (Google अभी भी दोनों की अनुशंसा करता है), साथ ही मान्य फॉरवर्ड/रिवर्स कमांड भी। DNSपोस्टमास्टर टूल्स में TLS, RFC 5322 फॉर्मेटिंग और 0.3% से कम स्पैम दर।
- थोक प्रेषक (प्रतिदिन 5,000 से अधिक संदेश) Gmail): स्थापित करना SPF और DKIM, प्रकाशित करना DMARC (नीति हो सकती है
p=none), और सुनिश्चित करें कि From डोमेन इसके साथ संरेखित हो SPF डोमेन या DKIM साइनिंग डोमेन। मार्केटिंग और सब्सक्राइब्ड मेल के लिए भी एक क्लिक में अनसब्सक्राइब करने की सुविधा होनी चाहिए।
अनधिकृत या गलत तरीके से भेजे गए ईमेल के फ़िल्टर होने या त्रुटियों के साथ अस्वीकार होने की संभावना अधिक होती है। Gmailहै 5.7.26इसलिए प्रमाणीकरण एक सुरक्षा नियंत्रण और वितरण योग्यता की आवश्यकता दोनों है, न कि कोई वैकल्पिक "अच्छी बात"।
फिर भी एक दूसरा सत्य शेष रह जाता है: परिपूर्ण SPF/DKIM/DMARC हार्ड बाउंस, स्पैम ट्रैप और पुराने पतों से भरी सूची को सहेजा नहीं जाएगा। प्रतिष्ठा के उस पहलू के लिए, देखें ईमेल डोमेन की प्रतिष्ठा की जांच कैसे करें और एक साफ-सुथरी ईमेल सूची क्यों महत्वपूर्ण है.
ईमेल प्रमाणीकरण कैसे काम करता है (शुरू से अंत तक)
उच्च स्तर पर देखा जाए तो मार्केटिंग प्लेटफॉर्म, ट्रांजैक्शनल मेल और ऑफिस सूट के लिए प्रवाह समान है:
- आप प्रकाशित करें DNS वे रिकॉर्ड जो अधिकृत प्रेषण अवसंरचना की घोषणा करते हैं (SPF), हस्ताक्षरों के लिए सार्वजनिक कुंजी (DKIM), और एक डोमेन नीति (DMARC).
- आपके मेल सर्वर (या ESP) ऐसे संदेश भेजें जिनकी जांच उन अभिलेखों के आधार पर की जा सके — SPF यह कनेक्टिंग आईपी का मूल्यांकन एनवेलप प्रेषक डोमेन के विरुद्ध करता है; DKIM एक क्रिप्टोग्राफिक हस्ताक्षर संलग्न करता है; DMARC परिणामों को दृश्यमान 'फ्रॉम' डोमेन से जोड़ता है।
- प्राप्तकर्ता सर्वर जाँचों को सत्यापित करते हैं, अपना लागू करें DMARC प्रमाणीकरण विफल होने पर नीति संरेखण, और आपके पते पर समग्र रिपोर्ट भेज सकती है
rua=टैग।
As dmarc.org पर जोर देती है, SPF और DKIM इससे एक कमी रह गई: प्राप्तकर्ताओं को अभी भी यह समझने में कठिनाई हो रही थी कि कौन सी विफलताएं स्पूफिंग के कारण थीं और कौन सी अपूर्ण प्रेषक सेटअप के कारण थीं। DMARC उस अंतर को पाटता है संरेखण (क्या प्रमाणित डोमेन प्राप्तकर्ता द्वारा देखे जाने वाले डोमेन से मेल खाता है?) और नीति (प्राप्तकर्ताओं को विफलताओं के मामले में क्या करना चाहिए?), साथ ही रिपोर्टिंग ताकि आप लागू करने से पहले वास्तविक मेल प्रवाह को ठीक कर सकें।
SPF (प्रेषक नीति ढांचा)
SPFमें परिभाषित किया गया है RFC 7208यह सुविधा किसी डोमेन को यह प्रकाशित करने की अनुमति देती है कि उस डोमेन के लिए कौन से मेल सर्वर मेल भेजने के लिए अधिकृत हैं। यह जाँच इन सर्वरों के विरुद्ध चलती है। SMTP लिफाफा भेजने वाला ( MAIL FROM / रिटर्न-पाथ डोमेन), दृश्यमान फ्रॉम हेडर के विरुद्ध नहीं। एक प्राप्तकर्ता सर्वर देखता है TXT उस डोमेन पर रिकॉर्ड दर्ज करता है, तंत्रों का मूल्यांकन करता है और परिणाम लौटाता है।
क्या एक SPF रिकॉर्ड ऐसा दिखता है
एक ठेठ TXT रिकॉर्ड कुछ इस तरह दिख सकता है:
v=spf1 include:_spf.google.com include:send.example-esp.com ip4:203.0.113.10 -all
मुख्य अंश:
v=spf1— आवश्यक संस्करण टैग (SPF संस्करण 1)।- इस प्रकार के तंत्र
ip4:/ip6:(स्पष्ट आईपी),a/mx(A/AAAA या MX रिकॉर्ड से होस्ट), औरinclude:(किसी अन्य डोमेन को प्रतिनिधि करें) SPF नीति — गूगल वर्कस्पेस के लिए सामान्य, Microsoft 365, तथा ESPएस). - एक अनुगामी
allविशेषण सहित तंत्र:-all(असफल),~all(सॉफ्टफेल),?all(तटस्थ), या+all(सब कुछ पास करें - इसे कभी भी प्रोडक्शन में इस्तेमाल न करें)।
RFC 7208 एक सख्त सीमा भी लागू करता है: मूल्यांकन इससे अधिक नहीं होना चाहिए 10 DNS लुकअप ऐसे तंत्रों के कारण include, a, mx, ptr, तथा existsबहुत अधिक नेस्टेड इन्क्लूड्स का उपयोग करना सबसे आम तरीकों में से एक है। SPF तीसरा जोड़ने के बाद "टूट जाता है" ESP.
SPF परिणाम प्राप्तकर्ताओं को परवाह होती है
- पास — कनेक्टिंग आईपी अधिकृत है।
- विफल — आईपी अधिकृत नहीं है (
-allशैली में भारी विफलता)। - सॉफ्टफेल — अधिकृत नहीं था, लेकिन डोमेन ने नरम व्यवहार का अनुरोध किया था (
~all). - तटस्थ / कोई नहीं — कोई ठोस दावा नहीं, या कोई उपयोगी SPF नीति।
- पर्मरएरर / टेम्परएरर — स्थायी सिंटैक्स/खोज संबंधी समस्याएं, या अस्थायी DNS मुद्दे।
स्थापित कैसे करें SPF
- उन सभी सिस्टमों की सूची बनाएं जो आपके डोमेन के रूप में ईमेल भेजते हैं: वर्कस्पेस मेल, मार्केटिंग ईमेल आदि। ESPसीआरएम, सपोर्ट डेस्क, बिलिंग, फॉर्म और कोई भी पुराने सर्वर।
- प्रत्येक विक्रेता से जानकारी एकत्र करें SPF उनके दस्तावेज़ों से (या आईपी रेंज) शामिल करें — खुद से शामिल करने की कोशिश न करें।
- प्रकाशित करना एक SPF TXT डोमेन शीर्ष पर रिकॉर्ड (एकाधिक) SPF TXT रिकॉर्ड अमान्य हैं और पर्मएरर का कारण बनते हैं)।
- 10 लुकअप की सीमा के भीतर रहें; यदि आप सीमा के करीब हैं तो उन्हें समतल करें या समेकित करें।
- अंत में इसे प्राथमिकता दें
-allएक बार सभी वैध प्रेषकों को कवर कर लेने के बाद; उपयोग करें~allकेवल तभी जब आप स्रोतों की खोज कर रहे हों। - टेस्ट मेल भेजें और पुष्टि करें SPF संदेश शीर्षलेखों में (
Authentication-Results) और आपके साथ ESPप्रमाणीकरण निदान।
याद रखें: SPF केवल इससे संतुष्टि नहीं मिलती DMARC. के लिए DMARC, SPF-प्रमाणित डोमेन भी होना चाहिए संरेखित करें दृश्यमान प्रेषक डोमेन के साथ - एक ऐसी चीज़ जो अक्सर तब विफल हो जाती है जब मेल अग्रेषित किया जाता है या जब रिटर्न-पाथ किसी विक्रेता सबडोमेन का उपयोग करता है जो संगठनात्मक रूप से संरेखित नहीं होता है।
DKIM (डोमेनकीज़ द्वारा पहचाने गए मेल)
DKIMमें परिभाषित किया गया है RFC 6376यह आउटबाउंड संदेशों पर एक क्रिप्टोग्राफिक हस्ताक्षर संलग्न करता है। प्रेषक प्रणाली चयनित हेडर और बॉडी सामग्री को एक निजी कुंजी से हस्ताक्षरित करती है। प्राप्तकर्ता मिलान करने वाली सार्वजनिक कुंजी प्राप्त करते हैं। DNS (कम से selector._domainkey.example.com) और यह सत्यापित करें कि हस्ताक्षरित सामग्री को परिवहन के दौरान बदला नहीं गया था और हस्ताक्षरकर्ता उस कुंजी को नियंत्रित करता है।
क्यों DKIM यह "अच्छी क्रिप्टो" से ज्यादा मायने रखता है।
- अखंडता — हस्ताक्षरित शीर्षक/मुख्य भाग के साथ छेड़छाड़ करने से हस्ताक्षर अमान्य हो जाते हैं।
- लचीलेपन को आगे बढ़ाना - कब SPF आगे बढ़ने के बाद विफल हो जाता है, एक वैध संरेखित DKIM हस्ताक्षर अभी भी संदेश को प्रमाणित कर सकता है DMARC.
- प्रदाता की अपेक्षाएँ — गूगल की अनुशंसा DKIM चाबियाँ 1024 बिट या उससे अधिक व्यक्तिगत को मेल के लिए Gmail खाते, और प्राथमिकताएँ 2048-बिट चाबियाँ जब DNS उनका समर्थन करता है।
स्थापित कैसे करें DKIM
- प्रत्येक प्रेषण प्लेटफ़ॉर्म में (Google वर्कस्पेस, Microsoft 365, ESP, इत्यादि), सक्षम करें DKIM अपने डोमेन के लिए एक कुंजी युग्म/चयनकर्ता उत्पन्न करें।
- प्रदान की गई जानकारी प्रकाशित करें TXT विक्रेता द्वारा निर्दिष्ट चयनकर्ता होस्टनाम पर (या CNAME) रिकॉर्ड।
- इनके साथ हस्ताक्षर करना बेहतर रहेगा तुंहारे डोमेन में DKIM
d=टैग — न केवल ESP's साझा डोमेन — इसलिए DMARC आपका प्रेषक पता (From address) के आधार पर संरेखण मान्य हो सकता है। - के लिए इंतजार DNS प्रसार के लिए, प्लेटफ़ॉर्म पर हस्ताक्षर सक्षम करें, फिर एक वास्तविक संदेश के साथ सत्यापित करें।
DKIM-SignatureऔरAuthentication-Resultsहेडर। - कुंजी रोटेशन की योजना बनाएं: एक नया सेलेक्टर प्रकाशित करें, ड्यूल-साइन का उपयोग करें या पुराने को हटा दें। DNS ट्रैफ़िक चलने के बाद कुंजी दबाएँ।
सामान्य DKIM विफलताओं में गलत चयनकर्ता शामिल है DNS, छोटा किया गया 2048-बिट TXT रिकॉर्ड्स, एक डोमेन पर हस्ताक्षर करना जबकि 'फ्रॉम' दूसरे डोमेन का उपयोग करता है, और मिडलबॉक्स द्वारा बॉडी में परिवर्तन जो हस्ताक्षर को अमान्य कर देते हैं।
DMARC (डोमेन-आधारित संदेश प्रमाणीकरण, रिपोर्टिंग और अनुरूपता)
DMARC, में निर्दिष्ट किया RFC 7489 और संक्षेप में बताया गया है dmarc.org, पर बनाता है SPF और DKIMयह उन दो सवालों के जवाब देता है जिनका जवाब प्राप्तकर्ता पहले विश्वसनीय रूप से नहीं दे पाते थे:
- कम से कम एक सफल प्रमाणीकरण करता है संरेखित करें क्या डोमेन दृश्यमान 'फ्रॉम' हेडर में है?
- यदि नहीं, तो प्राप्तकर्ता को क्या करना चाहिए — निगरानी करना, अलग रखना या अस्वीकार करना — और रिपोर्ट कहाँ भेजी जानी चाहिए?
DMARC कर देता है नहीं दोनों की आवश्यकता है SPF और DKIM पास होने के लिए। या तो संरेखित SPF or गठबंधन DKIM एक के लिए पर्याप्त है DMARC पास। आप अब भी दोनों को तैनात करना चाहते हैं, क्योंकि SPF अक्सर अग्रेषित मेल पर विफल हो जाता है जबकि DKIM यह प्रक्रिया जारी रह सकती है, और Google के बल्क-सेंडर नियमों में दोनों तंत्रों को स्थापित करने की अपेक्षा की जाती है, भले ही संरेखण एक तंत्र द्वारा संतुष्ट हो जाए।
संरेखण (वह हिस्सा जिसे ज्यादातर टीमें नजरअंदाज कर देती हैं)
प्रमाणीकरण सफल हो सकता है जबकि DMARC फिर भी विफल। उदाहरण: आपका ESP के साथ संकेत d=esp-mail.com और SPF पास के लिए bounces.esp-mail.comलेकिन 'फ्रॉम' हेडर दिखाता है [email protected]संगठनात्मक संरेखण के बिना yourbrand.com, DMARC यह विफल हो जाता है। इसे कस्टम फ्रॉम डोमेन, ब्रांडेड रिटर्न-पाथ/बाउंस डोमेन और कस्टम का उपयोग करके ठीक करें। DKIM अपने डोमेन पर हस्ताक्षर करना — इसमें अधिकांश प्रमुख विशेषताएं शामिल हैं ESPएस दस्तावेज़ के अंतर्गत “DMARC संरेखण” या “कस्टम डोमेन प्रमाणीकरण।”
संरेखण मोड:
- आराम (डिफ़ॉल्ट) — संगठनात्मक डोमेन मेल खा सकते हैं (उदाहरण के लिए,
news.example.comके साथ संरेखित कर सकते हैंexample.com). - कठोर (
adkim=s/aspf=s)— डोमेन का सटीक मिलान आवश्यक है।
ए की शारीरिक रचना DMARC रिकॉर्ड
प्रकाशित करें TXT रिकॉर्ड पर _dmarc.yourdomain.comउदाहरण निगरानी रिकॉर्ड:
v=DMARC1; p=कोई नहीं; rua=मेलटो:[ईमेल संरक्षित]; फ़ो=1
कोर टैग (टैग चार्ट भी देखें) dmarc.org):
v=DMARC1— आवश्यक संस्करण।p=— संगठनात्मक क्षेत्र के लिए नीति:none,quarantineया,reject.sp=— सबडोमेन के लिए वैकल्पिक नीति।rua=— एग्रीगेट रिपोर्ट मेलबॉक्स (यहां से शुरू करें; यह आपका डिस्कवरी टूल है)।ruf=— फोरेंसिक/विफलता रिपोर्ट (वैकल्पिक; प्राप्तकर्ता के अनुसार वितरण का तरीका भिन्न हो सकता है)।pct=— असफल ईमेल का वह प्रतिशत जिस पर यह नीति लागू होती है (लागू करने के दौरान उपयोगी)।adkim/aspf— संरेखण मोड।
सुरक्षित DMARC रोलआउट (dmarc.org द्वारा अनुशंसित)
- तैनाती SPF और DKIM प्रत्येक वैध स्ट्रीम के लिए और पुष्टि पहचानकर्ताओं को संरेखित किया जा सकता है।
- प्रकाशित करना
p=noneकाम करने के साथrua=कई हफ्तों तक रिपोर्टों का पता लगाना और उन्हें एकत्र करना। - अज्ञात या विफल स्रोतों को ठीक करें: गुमशुदा इन्क्लूड्स, अहस्ताक्षरित स्ट्रीम, गलत संरेखण ESP डोमेन।
- में ले जाएँ
p=quarantine(वैकल्पिक रूप सेpct=रैंप), फिरp=rejectजब रिपोर्टें साफ हों।
सीधे कूदते हुए p=reject रिपोर्ट विश्लेषण के बिना ही टीमें अपने स्वयं के चालान, पासवर्ड रीसेट या एजेंसी न्यूज़लेटर को गोपनीय रखती हैं।
कैसे SPF, DKIM, तथा DMARC एक साथ काम करो
स्टैक को परतों के रूप में सोचें:
- SPF एनवेलप डोमेन के लिए आईपी पते अधिकृत करता है।
- DKIM यह संदेश की सत्यता को सिद्ध करता है और हस्ताक्षर डोमेन को सामग्री से जोड़ता है।
- DMARC इसके लिए आवश्यक है कि उन सफलताओं में से कम से कम एक 'फ्रॉम' डोमेन के साथ संरेखित हो, फिर आपकी प्रकाशित नीति और रिपोर्टिंग लागू होती है।
थोक के लिए Gmail ट्रैफ़िक के लिए, Google के दिशानिर्देशों में पूर्ण स्टैक की अपेक्षा की जाती है: SPF + DKIM कॉन्फ़िगर किया गया, DMARC प्रकाशित (न्यूनतम) p=none), और फ्रॉम-डोमेन संरेखण के साथ SPF or DKIMप्रमाणीकरण अन्य आवश्यकताओं के साथ-साथ भी आवश्यक है। PTR/आगे DNSटीएलएस, कम स्पैम शिकायत दरें और सूची सहभागिता संकेत जैसी जानकारी गाइडों में शामिल है। स्पैम फ़िल्टर से कैसे बचें और ईमेल प्रेषक की प्रतिष्ठा.
सामान्य प्रमाणीकरण गलतियाँ
- विभिन्न SPF TXT अभिलेख — एक में विलय हो जाना
v=spf1स्ट्रिंग. - खोज सीमा पार हो गई - ढेर सारे
include:श्रृंखलाएं; एक ही डोमेन पर विक्रेताओं को समतल या कम करना। - भूले हुए प्रेषक — सीआरएम, बिलिंग, या "अस्थायी" उपकरण जो छूट गए हैं SPF/DKIM.
- DKIM पर ESP केवल डोमेन - SPF/DKIM विक्रेता के लिए पास, DMARC आपके ब्रांड के लिए विफलताएँ।
- DMARC रुआ निगरानी के बिना — अंधापन लागू करना।
- यह मानते हुए कि प्रमाणीकरण बाउंस को ठीक करता है प्रमाणीकरण आपके सीआरएम से अमान्य पतों को नहीं हटाता है।
प्रमाणीकरण सूची गुणवत्ता नहीं है
SPF, DKIM, तथा DMARC “क्या इस संदेश को हमारे डोमेन का उपयोग करने की अनुमति है?” का उत्तर वे नहीं देते, “क्या यह प्राप्तकर्ता का पता वास्तविक, सक्रिय और ईमेल भेजने के लिए सुरक्षित है?” हार्ड बाउंस, निष्क्रिय साइनअप, ऐसे खाते जिन्हें आप भेजना नहीं चाहते थे, और स्पैम-ट्रैप हिट, ये सभी सूची और अधिग्रहण संबंधी समस्याएं हैं। ये संकेत अभी भी नुकसान पहुंचाते हैं। प्रेषक की प्रतिष्ठा भले ही प्रत्येक हेडर पूरी तरह से प्रमाणित हो जाए।
व्यावहारिक संयोजन:
- रखना DNS आपके स्वामित्व वाली प्रत्येक स्ट्रीम के लिए प्रमाणीकरण स्वस्थ और संरेखित होना चाहिए।
- बड़े पैमाने पर शिपमेंट भेजने से पहले सूचियों को सत्यापित और साफ करें ताकि हार्ड बाउंस दरें कम रहें — देखें आदर्श ईमेल बाउंस दर दिशा निर्देश।
- उपयोग ईमेल सत्यापन इसे कैप्चर के समय और कैंपेन से पहले जोखिम कम करने के रूप में देखा जाता है - न कि परफेक्ट इनबॉक्स प्लेसमेंट के वादे के रूप में।
यदि आप पहले से ही सही तरीके से प्रमाणीकरण कर रहे हैं लेकिन फिर भी डिलीवरी में समस्या आ रही है, तो दोबारा लिखने से पहले लिस्ट हाइजीन और शिकायत/एंगेजमेंट मेट्रिक्स से शुरुआत करें। DNS पांचवीं बार।
निष्कर्ष
SPF प्रेषण अवसंरचना को अधिकृत करता है, DKIM सामग्री पर हस्ताक्षर, और DMARC यह नीति और रिपोर्टिंग के साथ उन परिणामों को 'प्रेषक' डोमेन से जोड़ता है। 2026 में, मेलबॉक्स प्रदाता आपसे यही भाषा बोलने की अपेक्षा करेंगे — खासकर तब जब आप Google के दिशानिर्देशों में बल्क-सेंडर सीमा को पार कर लेते हैं। सटीक रिकॉर्ड प्रकाशित करें, निगरानी रखें। DMARC रिपोर्ट तैयार करते समय, अलाइनमेंट सही होने के बाद ही कार्रवाई करें, और याद रखें कि प्रमाणीकरण और सूची की गुणवत्ता अलग-अलग काम हैं। दोनों को करें, इससे आप अपने ब्रांड को नकली उत्पादों से सुरक्षित रख पाएंगे और वैध कैंपेन को इनबॉक्स में बेहतर परिणाम मिलने का उचित मौका मिलेगा।
