- आपकी मेल प्रमाणीकृत नहीं है। प्राप्त करने वाला सर्वर यह पुष्टि नहीं कर सकता कि संदेश वास्तव में आपके डोमेन से आया है। आमतौर पर कोई रिकॉर्ड गायब होता है, किसी नए टूल (CRM, इनवॉइसिंग, न्यूज़लेटर, वेबसाइट फॉर्म, हेल्प डेस्क, यहाँ तक कि एक स्कैनर) को कभी उसमें जोड़ा नहीं गया होता, या SPF रिकॉर्ड अपनी सीमा से अधिक बढ़ गया होता है और चुपचाप सब कुछ काम करना बंद कर देता है।
- यह संदेश स्पैम जैसा दिखता है। लिंक शॉर्टनर, कई छवियाँ और कुछ शब्द, बड़े अक्षर, छह लोगो वाला हस्ताक्षर, अनचाहे अटैचमेंट, या विज्ञापन की तरह लिखा गया विषय। फ़िल्टर इनमें से प्रत्येक को स्कोर करते हैं।
- आपके डोमेन की प्रतिष्ठा को धक्का लगा। एक मेलबॉक्स समझौता हो गया और पूरे सप्ताहांत स्पैम भेजा गया, किसी ने Outlook से 400-प्रापक का अपडेट सभी को Bcc में भेज दिया, या आपकी मेल एक साझा सर्वर के माध्यम से एक बुरे पड़ोसी के साथ जाती है।
- प्रापक का पक्ष। एक नियम, एक भरा हुआ मेलबॉक्स, एक व्यक्तिगत पते पर फॉरवर्ड, या एक फ़िल्टर जिसने एक बार आपके पते को जंक के रूप में सीख लिया। लोगों की सोच से कम आम, और इसे केवल प्राप्तकर्ता ही ठीक कर सकता है।
आपकी कंपनी का ईमेल स्पैम में क्यों जाता है, और इसे हमेशा के लिए कैसे ठीक करें
चार कारण जिनकी वजह से व्यावसायिक ईमेल जंक फ़ोल्डर में चली जाती है, SPF, DKIM और DMARC वास्तव में क्या करते हैं, Gmail और Outlook अब हर प्रेषक से क्या चाहते हैं, और एक जाँच जिसे आप 20 मिनट में चला सकते हैं।
8 मिनट में पढ़ेंअपडेट किया गया
संक्षिप्त जवाब
दस में से नौ बार कारण प्रमाणीकरण (authentication) होता है: आपका डोमेन दुनिया को यह नहीं बता रहा है कि कौन सी सेवाएं आपके रूप में मेल भेज सकती हैं, या उन रिकॉर्ड को अपडेट किए बिना कोई नया टूल जोड़ दिया गया है। अब Gmail और Outlook हर प्रेषक से SPF, DKIM और एक DMARC रिकॉर्ड की उम्मीद करते हैं, और जब कुछ विफल हो जाता है तो वे चुपचाप मेल को स्पैम में भेज देते हैं। रिकॉर्ड को ठीक करें, आपके डोमेन से मेल भेजने वाले हर टूल में DKIM चालू करें, DMARC को मॉनिटरिंग पर शुरू करें, और अधिकांश डिलीवरी समस्याएं एक या दो दिन के भीतर गायब हो जाती हैं।
संभाव्यता के क्रम में चार कारण
SPF, DKIM और DMARC वास्तव में क्या करते हैं
ये तीनों आपके डोमेन के DNS में छोटे टेक्स्ट रिकॉर्ड हैं। आपकी कंपनी में कोई भी उन्हें नहीं देखता, लेकिन हर मेल सर्वर जिसे आप लिखते हैं, वे उन्हें जांचता है।
| रिकॉर्ड | सरल शब्दों में | इसके बिना क्या गलत होता है |
|---|---|---|
| SPF | आपके डोमेन के रूप में ईमेल भेजने की अनुमति प्राप्त सेवाओं की एक सूची, उदाहरण के लिए Microsoft 365 और आपका इनवॉइसिंग टूल। | सूची में शामिल नहीं होने वाली सेवा से भेजा गया मेल विफल हो जाता है। दस से अधिक लुकअप वाली सूची हर चीज़ के लिए विफल हो जाती है। |
| DKIM | प्रत्येक संदेश में जोड़ा गया एक डिजिटल हस्ताक्षर, जो यह साबित करता है कि यह आपके डोमेन से आया है और रास्ते में इसमें कोई बदलाव नहीं किया गया है। | संदेश बिना हस्ताक्षर के आते हैं और किसी जालसाजी से अलग नहीं दिखते। |
| DMARC | प्राप्तकर्ताओं के लिए आपका निर्देश: जब कोई संदेश आप होने का दावा करता है और उपरोक्त जांचों में विफल हो जाता है, तो क्या करें, और रिपोर्ट कहाँ भेजें। | प्राप्तकर्ता अनुमान लगाते हैं, और कोई भी आपके नाम से मेल भेज सकता है, यह आपको पता भी नहीं चलेगा। |
एक विवरण मायने रखता है: संरेखण। 'From' पते में जो डोमेन लोगों को दिखाई देता है, उसका मिलान उसी डोमेन से होना चाहिए जिसने SPF या DKIM पास किया हो। एक न्यूज़लेटर टूल जो आपके डोमेन के रूप में भेजता है लेकिन अपने स्वयं के डोमेन से हस्ताक्षर करता है, वह अपने लिए DKIM पास कर लेता है और फिर भी आपके लिए DMARC में विफल रहता है।
Gmail, Outlook और Yahoo अब क्या चाहते हैं
2024 से बड़े मेलबॉक्स प्रदाता अनुमान लगाने के बजाय नियम प्रकाशित करते हैं, और 2025 के अंत में गूगल ने अधिक अस्वीकृतियों के साथ प्रवर्तन को तेज कर दिया। उनकी प्रकाशित आवश्यकताएँ, अक्टूबर 2026 तक:
| आवश्यकता | Gmail (प्रत्येक प्रेषक) | Outlook.com और Yahoo |
|---|---|---|
| SPF और DKIM | दोनों सेट अप | दिन में लगभग 5,000 संदेश या उससे अधिक भेजने वाले किसी भी व्यक्ति के लिए दोनों सेटअप; अन्य सभी से दृढ़ता से अपेक्षित |
| DMARC रिकॉर्ड | प्रकाशित, कम से कम p=none | प्रकाशित, कम से कम p=none, SPF या DKIM के साथ संरेखित |
| डोमेन के अनुरूप | हाँ, SPF या DKIM के साथ | हाँ |
| रिवर्स DNS और TLS | आवश्यक | उम्मीद की गई |
| स्पैम शिकायत दर | 0.3 प्रतिशत से कम, 0.1 का लक्ष्य रखें | निम्न रखा गया; माइक्रोसॉफ्ट प्रतिष्ठा पर बारीकी से नजर रखता है |
| एक-क्लिक सदस्यता रद्द करें | बल्क प्रेषकों से मार्केटिंग मेल | बल्क प्रेषकों से मार्केटिंग मेल |
ये नियम औपचारिक रूप से व्यक्तिगत Gmail, Outlook.com और Yahoo पतों पर भेजे गए मेल को कवर करते हैं। व्यावहारिक रूप से Microsoft 365 और Google Workspace व्यावसायिक मेलबॉक्स पर भी वही जाँच लागू करते हैं, इसलिए आपका ग्राहक कोई भी हो, समाधान एक ही है।
20 मिनट की जाँच
- आपके डोमेन से भेजी जाने वाली सभी चीज़ों की सूची बनाएं। Microsoft 365 या Google Workspace, CRM, इनवॉइसिंग और पेरोल टूल्स, न्यूज़लेटर प्लेटफ़ॉर्म, वेबसाइट का संपर्क फ़ॉर्म, हेल्प डेस्क, कैलेंडर और बुकिंग टूल्स, और वह एक प्रिंटर जो ईमेल पर स्कैन करता है। अधिकांश डोमेन में पाँच से आठ होते हैं।
- अपना SPF रिकॉर्ड पढ़ें। इसमें ठीक एक ही होना चाहिए। इसमें सूची की हर सेवा शामिल होनी चाहिए, यह दस DNS लुकअप से कम रहना चाहिए, और -all या ~all पर समाप्त होना चाहिए। दूसरा SPF रिकॉर्ड, या ग्यारहवां लुकअप, सब कुछ विफल कर देता है।
- DKIM को हर जगह चालू करें। Microsoft 365 में यह डिफेंडर पोर्टल में ईमेल प्रमाणीकरण सेटिंग्स के अंतर्गत होता है; Google Workspace में ऐप्स, Google Workspace, Gmail, ईमेल प्रमाणीकृत करें के अंतर्गत। हर तीसरे पक्ष के टूल की अपनी DKIM सेटिंग होती है जो आपको जोड़ने के लिए दो या तीन DNS रिकॉर्ड देती है।
- DMARC को मॉनिटरिंग स्तर पर प्रकाशित करें। p=none वाले रिकॉर्ड और रिपोर्टिंग पते से अभी कुछ नहीं बदलता, लेकिन कुछ ही दिनों में रिपोर्ट दिखाएंगी कि हर सेवा आपके रूप में संदेश भेज रही है, उन सेवाओं सहित जिन्हें आप भूल गए थे और कोई भी जो आपका नक़ल कर रहा है।
- एक परीक्षण भेजें और परिणाम पढ़ें। किसी व्यक्तिगत Gmail खाते में ईमेल करें, संदेश खोलें, 'मूल दिखाएँ' (Show original) चुनें, और SPF: PASS, DKIM: PASS और DMARC: PASS देखें। Outlook.com संदेश हेडर में भी यही दिखाता है। एक FAIL आपको ठीक बताता है कि कौन से रिकॉर्ड को ठीक करना है।
- DMARC को चरणों में कड़ा करें। दो से चार सप्ताह की साफ रिपोर्टों के बाद, p=quarantine पर जाएँ, फिर p=reject पर। reject पर, कोई भी आपके नाम से मेल नहीं भेज सकता और प्राप्तकर्ता आपकी मेल पर अधिक भरोसा करते हैं।
समस्याएँ जो प्रमाणीकरण जैसी दिखती हैं लेकिन नहीं हैं
- एक समझौता किया गया मेलबॉक्स। यदि डिलीवरी रातों-रात रुक गई है, तो किसी भी अन्य चीज़ से पहले प्रभावित खातों के साइन-इन लॉग और इनबॉक्स नियमों की जाँच करें। हमलावर एक ऐसा नियम जोड़ते हैं जो जवाबों को छिपा देता है और असली खाते से स्पैम भेजता है।
- सामान्य मेलबॉक्स से थोक मेल। Outlook और Gmail बातचीत के लिए बनाए गए हैं, अभियान के लिए नहीं। सैकड़ों संपर्कों को अपडेट करना एक उचित उपकरण का काम है, जिसे news.yourcompany.com जैसे सबडोमेन से भेजा जाना चाहिए ताकि वहाँ का एक बुरा दिन आपके मुख्य डोमेन को प्रभावित न करे।
- भारी हस्ताक्षर और लिंक संक्षिपक। कम छवियाँ, कोई संक्षिप्त लिंक नहीं, और ऐसा टेक्स्ट जो किसी व्यक्ति द्वारा लिखा गया प्रतीत हो।
- एक बिल्कुल नया डोमेन। बिना इतिहास वाले डोमेन को पहले कुछ हफ्तों के लिए संदेह की दृष्टि से देखा जाता है। कम मात्रा और वास्तविक बातचीत से शुरुआत करें।
- खरीदी गई या स्क्रैप की गई सूचियाँ। 0.3 प्रतिशत से अधिक शिकायत दरें आपको एक बार में एक सप्ताह के लिए प्रदाताओं की अच्छी नजर से हटा देती हैं, और कोई रिकॉर्ड इसे ठीक नहीं करता।
इसे क्रम में रखें
- हर नए टूल को, जो ईमेल भेजता है, उसे सेटअप के दिन ही SPF और DKIM पर जोड़ें।
- DMARC रिपोर्टों को मासिक रूप से पढ़ें, या किसी से उन्हें आपके लिए पढ़वाएं
- मार्केटिंग और लेन-देन संबंधी मेल को उनके स्वयं के सबडोमेन पर रखें
- Google Postmaster Tools और Microsoft के सेंडर टूल्स में शिकायत दर देखें
- समीक्षा करें कि कौन इनबॉक्स नियम और फॉरवर्ड बना सकता है, क्योंकि ये वे पहली चीजें हैं जिन्हें एक हमलावर बदलता है
अक्सर पूछे जाने वाले सवाल
लोग हमसे क्या पूछते हैं
संस्थापक और वित्त प्रमुख हमसे सबसे ज़्यादा जो पूछते हैं, उनके संक्षिप्त जवाब।
हमसे कुछ और पूछेंआमतौर पर चार में से एक कारण होता है: कोई नया टूल आपके डोमेन से भेजना शुरू कर देता है लेकिन उसे SPF में जोड़ा नहीं गया होता, SPF रिकॉर्ड ने दस-लुकअप सीमा पार कर ली होती, कोई मेलबॉक्स समझौता हो गया होता, या किसी प्रदाता ने प्रवर्तन को कड़ा कर दिया होता, जैसा कि Google ने 2025 के अंत में किया था। ऊपर दिया गया 20-मिनट का चेक यह पता लगाता है कि कौन सा कारण है।
हाँ। गूगल अब Gmail पतों पर लिखने वाले हर प्रेषक से एक DMARC रिकॉर्ड की उम्मीद करता है, और Outlook.com बड़ी कंपनियों से इसकी उम्मीद करता है। p=none वाला रिकॉर्ड कुछ भी नहीं बदलता और इसमें कोई लागत नहीं आती, और यह यह देखने का एकमात्र तरीका है कि आपके रूप में कौन संदेश भेज रहा है।
p=none पर नहीं। समस्याएँ केवल तभी उत्पन्न होती हैं जब आप हर वैध सेवा के पास होने से पहले क्वारंटाइन या अस्वीकार पर कूद जाते हैं, यही कारण है कि हम पहले कुछ हफ्तों के लिए रिपोर्ट पढ़ते हैं।
हाँ। रिकॉर्ड आपके डोमेन के DNS में रहते हैं और उन सभी प्लेटफ़ॉर्म और टूल पर लागू होते हैं जो आपका मेल भेजते हैं। केवल वह जगह जहाँ आप DKIM चालू करते हैं, अलग होती है।
क्योंकि Microsoft 365 आपके SPF और DKIM में है और CRM नहीं है, या CRM आपके बजाय अपने डोमेन से साइन करता है। प्रत्येक टूल में एक DKIM सेटिंग होती है जो इसे ठीक करती है।
अधिकांश डोमेन के लिए रिकॉर्ड एक दिन में ठीक किए जा सकते हैं। रिपोर्ट पढ़ने में कुछ सप्ताह लगते हैं, और सुरक्षित रूप से रिजेक्ट करने के लिए DMARC को लागू करने में कुछ सप्ताह लगते हैं, और खराब हुई प्रतिष्ठा को साफ-सुथरी भेजने की प्रक्रिया से कुछ हफ्तों में ठीक किया जा सकता है।
SF3 Technologies कैसे मदद करता है
हम हर सेवा को आपके डोमेन से भेजते हुए ढूंढते हैं, SPF को ठीक करते हैं, DKIM को Microsoft 365 और हर टूल में चालू करते हैं, DMARC प्रकाशित करते हैं और रिपोर्ट पढ़ते हुए इसे अस्वीकार करने तक ले जाते हैं, ताकि आपका ईमेल पहुंचे और कोई भी आपके नाम से संदेश न भेज सके। रिकॉर्ड आपके DNS और आपके टेनेंट में रहते हैं, आपके नियंत्रण में।
प्रेषक आवश्यकताएँ अक्टूबर 2026 में Google और Microsoft द्वारा प्रकाशित अनुसार हैं और समय के साथ बदलती रहती हैं। किसी सीमा पर भरोसा करने से पहले प्रत्येक प्रदाता के वर्तमान प्रेषक दिशानिर्देशों की जाँच करें।