इस पेज परOutlook.com और मई 2025 के नियम
"Outlook" तीन अलग-अलग फ़िल्टर हैं, और समाधान इस बात पर निर्भर करता है कि इनमें से किसने आपके ईमेल को Junk में भेजा। पहला Outlook.com है, जो Microsoft की उपभोक्ता मेल सेवा है और hotmail.com, live.com तथा msn.com पतों को भी संभालती है। दूसरा Microsoft 365 है, यानी वे व्यावसायिक मेलबॉक्स जिनके लिए कंपनियाँ भुगतान करती हैं और जहाँ प्राप्तकर्ता की कंपनी का एडमिन स्पैम नीति तय करता है। तीसरा किसी व्यक्ति के कंप्यूटर पर मौजूद Outlook ऐप है, जो सर्वर के निर्णय के बाद अपना अलग Junk फ़िल्टर चला सकता है। Microsoft ने 2025 में जिन प्रेषक नियमों की घोषणा की थी, वे इनमें से केवल पहले पर लागू होते हैं।
इसलिए किसी भी DNS रिकॉर्ड को बदलने से पहले मैं प्राप्तकर्ता का पता देखता हूँ। hotmail.com या outlook.com पता होने का अर्थ है कि नीचे दिए गए उपभोक्ता नियम लागू होंगे। Microsoft पर अपनी मेल चलाने वाली किसी कंपनी का पता होने पर उस कंपनी की IT टीम द्वारा लिखी गई टेनेंट नीति लागू होती है।
Outlook.com और मई 2025 के नियम
अप्रैल 2025 में Microsoft ने अपनी उपभोक्ता सेवा पर एक दिन में 5,000 से अधिक ईमेल भेजने वाले डोमेन के लिए ज़रूरी शर्तों की घोषणा की, और Postmaster नीतियों का पेज बताता है कि वे 5 मई 2025 से प्रभावी हुईं। इस सीमा से अधिक मात्रा पर:
- भेजने वाले डोमेन के लिए SPF पास होना चाहिए।
- DKIM पास होना चाहिए।
- DMARC को "कम से कम p=none" के साथ प्रकाशित करना और SPF या DKIM के साथ अलाइन करना आवश्यक है, "बेहतर होगा कि दोनों के साथ"। नीतियों का पेज यह भी कहता है कि
p=rejectकी सलाह दी जाती है।
बाउंस से संबंधित सहायता लेख इसे थोड़े अलग ढंग से बताता है। इसके अनुसार, Microsoft की उपभोक्ता सेवाओं पर भेजे गए ऐसे 5,000 या अधिक संदेश इस सीमा में गिने जाते हैं जिनके From पते में एक ही डोमेन इस्तेमाल हुआ हो। यह कहता है कि SPF और DKIM, दोनों जाँचों का पास होना ज़रूरी है। किसी डोमेन के इस सीमा तक पहुँचने के बाद Microsoft अपेक्षा करता है कि "डोमेन के प्रेषकों से आने वाले सभी संदेश" नियमों को पूरा करें, न कि केवल वह न्यूज़लेटर जिसके कारण संख्या इस सीमा से अधिक हुई। इसका DMARC उदाहरण किसी रिकॉर्ड का लगभग सबसे छोटा संभव रूप है:
Hostname: _dmarc
TXT value: v=DMARC1; p=noneमैं इसमें रिपोर्ट पाने का पता भी जोड़ूँगा, rua=mailto:dmarc@example.com या वह पता जहाँ आप वास्तव में ईमेल पढ़ते हैं। Outlook.com एग्रीगेट रिपोर्ट भेजता है (Microsoft के FAQ के अनुसार वह RUA भेजता है और RUF भेजने की उसकी कोई योजना नहीं है), और DMARC चेकर दिखाएगा कि आपका दिया हुआ पता उन्हें स्वीकार कर सकता है या नहीं।
Google ने फरवरी 2024 में Gmail के लिए भी प्रतिदिन 5,000 ईमेल की यही सीमा तय की थी और नवंबर 2025 में नियम लागू करने की सख्ती बढ़ानी शुरू की, जिसमें संदेश अस्वीकार करना भी शामिल था। Yahoo किसी सीमा का उल्लेख किए बिना ऐसी ही सूची लागू करता है।
घोषणा के नया रहते ही नियम लागू करने का तरीका बदल गया। मूल पोस्ट में कहा गया था कि नियमों का पालन न करने वाले ईमेल पहले Junk में जाएँगे और बाद में उन्हें अस्वीकार किया जा सकता है। 29 अप्रैल के अपडेट में कहा गया है कि Microsoft ने इसके बजाय उन्हें अस्वीकार करने का निर्णय लिया, फिर भी उसी पोस्ट में नीचे की ओर पहले Junk में भेजने वाला पुराना पैराग्राफ अब भी मौजूद है। आज सावधानी से इसे पढ़ने पर निष्कर्ष यह निकलता है कि 5 मई 2025 से नियमों का पालन न करने वाले ईमेल Junk में जाते हैं, और Outlook.com अब उन्हें इस संदेश के साथ अस्वीकार भी करता है:
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.
मुझे संदेश अस्वीकार करना शुरू करने की कोई प्रकाशित तारीख नहीं मिली। सहायता लेख इसे केवल वर्तमान काल में बताता है।
बाउंस कोड आपको क्या बता रहा है
Outlook.com से मिला बाउंस, Junk में चुपचाप पड़े संदेश से अधिक उपयोगी होता है, क्योंकि उसमें कारण बताया जाता है। Microsoft के समस्या निवारण पेज पर कोड की एक तालिका है, और सामान्य प्रेषकों को आम तौर पर ये कोड दिखाई देते हैं:
| कोड | Microsoft के अनुसार इसका अर्थ |
|---|---|
550 5.7.515 | डोमेन एक दिन में 5,000 से अधिक ईमेल भेजता है और SPF, DKIM तथा DMARC से प्रमाणित नहीं है |
550 SC-001 | नीति के कारण अस्वीकृति, "content with spam-like characteristics or IP/domain reputation" |
550 SC-004 | आपके IP से भेजे गए ईमेल की शिकायतों के बाद उस पर लगाया गया ब्लॉक |
421 RP-001 | कनेक्ट होने वाले IP पर दर सीमा, इसका कारण भी प्रतिष्ठा है |
Microsoft के अपने कोड के बिना सामान्य 550 5.7.1 एक अलग प्रकार की अस्वीकृति है, और इसे समझने के लिए अलग पेज उपलब्ध है।
तृतीय-पक्ष प्रेषक और SPF की आवश्यकता
कई डोमेन एक साथ कई सेवाओं के माध्यम से ईमेल भेजते हैं: न्यूज़लेटर प्लेटफ़ॉर्म, CRM, हेल्प डेस्क और बिलिंग। इनमें से हर सेवा From लाइन में आपके डोमेन का उपयोग करके ईमेल भेजती है, इसलिए हर सेवा आपके रिकॉर्ड में शामिल होनी चाहिए। यह पूछे जाने पर कि जब कोई सेवा प्रदाता आपकी ओर से ईमेल भेजता है, तब भी क्या नियम लागू होते हैं, Microsoft का FAQ जवाब देता है, "हाँ। भले ही आप ईमेल भेजने का काम किसी अन्य सेवा को दें, प्रमाणीकरण आपके डोमेन से जुड़ा होता है।" सहायता लेख बताता है कि क्या सत्यापित करना है: DKIM आपके डोमेन से हस्ताक्षर करे और आपके SPF रिकॉर्ड में "सेवा के लिए आवश्यक IP पता या include मान शामिल हों"।
यहीं पर SPF और DKIM दोनों को अनिवार्य करने की बात भ्रमित करने लगती है। कई प्लेटफ़ॉर्म बाउंस पता अपने डोमेन पर रखते हैं और SPF वास्तव में उसी Return-Path की जाँच करता है। इसके बाद प्लेटफ़ॉर्म के लिए SPF पास हो जाता है, जिससे "पास होना चाहिए" वाली शर्त पूरी हो जाती है, और DMARC अलाइनमेंट आपके डोमेन से किए गए DKIM हस्ताक्षर से आना चाहिए। अगर प्लेटफ़ॉर्म इसके बजाय अपने डोमेन से हस्ताक्षर करता है, तो दोनों जाँच पास होती हैं लेकिन अलाइनमेंट नहीं होता, और इसके बाद मिलने वाला DMARC fail ठीक वही समस्या है जिससे 5.7.515 संबंधित है। सहायता लेख यह जाँचने के लिए भी कहता है कि Return-Path डोमेन, From डोमेन के साथ अलाइन है या नहीं।दो जाँच पास, अलाइनमेंट शून्य: 5.7.515 की पूरी कहानी
SPF में जोड़ी गई हर सेवा DNS लुकअप की संख्या भी बढ़ाती है। Microsoft का FAQ इसे इस तरह बताता है: "अगर आप 10 DNS लुकअप से अधिक हो जाते हैं, तो आपकी SPF जाँच विफल हो सकती है।" SPF चेकर आपके लिए उनकी गिनती करता है, और अगर संख्या अधिक है, तो यहाँ बताया गया है कि इसे फिर से दस से कम कैसे करें। DKIM चेकर हर प्लेटफ़ॉर्म के selector के लिए मिलान की यही जाँच करता है।
Microsoft 365 पर किसी और की नीति के अनुसार फ़िल्टरिंग होती है
Microsoft 365 संगठन में एंटी-स्पैम नीतियाँ होती हैं, जिन्हें उसके एडमिन कॉन्फ़िगर करते हैं। डिफ़ॉल्ट रूप से स्पैम, उच्च-विश्वास वाला स्पैम और बल्क मेल Junk Email फ़ोल्डर में जाते हैं, जबकि फ़िशिंग मेल क्वारंटीन में जाता है और उच्च-विश्वास वाला फ़िशिंग मेल हमेशा क्वारंटीन किया जाता है। भेजने वाले के लिए क्वारंटीन सबसे अधिक नुकसानदायक परिणाम है, क्योंकि संदेश पाने वाले को वह किसी फ़ोल्डर में नहीं मिलता, जब तक कि वह उसे खुद खोजने न जाए। डिफ़ॉल्ट नीति उसे वहाँ 15 दिन रखती है, जबकि Standard और Strict प्रीसेट 30 दिन रखते हैं।
बल्क मेल के लिए अलग माप होता है, बल्क शिकायत स्तर। 1 से 3 का BCL कम शिकायतों वाले बल्क भेजने वाले को दर्शाता है, जबकि 8 या 9 अधिक शिकायतों वाले भेजने वाले को। डिफ़ॉल्ट नीति BCL 7 से बल्क मेल को Junk में भेजती है, Standard प्रीसेट BCL 6 से और Strict BCL 5 से। जुलाई 2026 से एक नई परत भी है: प्रचारात्मक प्रकृति वाले बल्क मेल को उसके BCL की परवाह किए बिना Promotions टैग मिलता है, और जहाँ एडमिन ने "Bulk moves enabled" चालू किया है, वहाँ वह Promotions फ़ोल्डर में पहुँचता है। यह स्पैम नहीं है, लेकिन Inbox भी नहीं है। यह सुविधा अभी भी धीरे-धीरे उपलब्ध कराई जा रही है।
Microsoft की दोनों प्रणालियाँ एक-दूसरे से पूरी तरह अलग नहीं हैं। Microsoft के अनुसार Microsoft 365 स्पैम फ़िल्टरिंग "ज्ञात स्पैम और फ़िशिंग खतरों तथा हमारे उपभोक्ता प्लेटफ़ॉर्म Outlook.com से मिलने वाले उपयोगकर्ता फ़ीडबैक से सीखती है", इसलिए hotmail.com के पाठकों की रिपोर्ट उस फ़िल्टर को प्रभावित करती है जिसका उपयोग व्यावसायिक इनबॉक्स करते हैं।
एडमिन किसी भेजने वाले को अनुमति सूची में भी डाल सकते हैं, जिससे मैलवेयर और उच्च-विश्वास वाली फ़िशिंग को छोड़कर अधिकांश सुरक्षा जाँचें बायपास हो जाती हैं। अगर किसी साझेदार कंपनी को आपके इनवॉइस लगातार Junk में मिल रहे हैं, तो उनकी IT टीम ही वास्तविक निर्णय देख सकती है।
हेडर में निर्णय पढ़ना
जब आप संदेश को उसी रूप में प्राप्त कर सकते हैं जैसा Microsoft 365 मेलबॉक्स ने उसे पाया था, तो एंटी-स्पैम हेडर निर्णय को सीधे बताते हैं। X-Forefront-Antispam-Report में कुछ उपयोगी फ़ील्ड होते हैं:
SFV:SPMका अर्थ है कि स्पैम फ़िल्टरिंग ने इसे स्पैम माना,SFV:NSPMका अर्थ है कि इसे स्पैम नहीं माना गया, औरSFV:SFEका अर्थ है कि फ़िल्टरिंग छोड़ दी गई क्योंकि प्रेषक उपयोगकर्ता की Safe Senders सूची में है।CATलागू की गई नीति की श्रेणी बताता है:SPM,HSPM(उच्च-विश्वसनीयता वाला स्पैम),BULK,PHSH,SPOOF।SCLएक संख्या है, -1 या 0 से 9 तक। पुराने गाइड इसे ही निर्णय मानते हैं। Microsoft का मौजूदा SCL पेज कहता है कि यह मान "यह निर्धारित नहीं करता कि स्पैम फ़िल्टरिंग किसी संदेश को स्पैम या उच्च-विश्वसनीयता वाला स्पैम मानती है या नहीं", इसलिए पहलेCATदेखें।
हेडर में compauth भी होता है, जो SPF, DKIM, DMARC और संदेश के अन्य हिस्सों के आधार पर बनाया गया Microsoft का संयुक्त निर्णय है। कारण कोड 001 का अर्थ है कि अप्रत्यक्ष प्रमाणीकरण विफल हुआ। आमतौर पर ऐसा तब होता है जब भेजने वाले डोमेन ने कोई प्रमाणीकरण रिकॉर्ड प्रकाशित नहीं किया हो या केवल कमज़ोर नीति लागू की हो।
SNDS और JMRP, अब Postmaster साइट पर
Smart Network Data Services, यानी SNDS, अब नई Postmaster साइट पर उपलब्ध है और इसने sendersupport.olc.protection.outlook.com पर मौजूद पुरानी साइट की जगह ले ली है। यह हर IP पते के लिए अलग रिपोर्ट देता है, इसलिए कोई भी जानकारी देखने से पहले आपको साबित करना होगा कि IP रेंज आपकी है। डेटा में ईमेल की मात्रा, शिकायत दर और एक रंग शामिल होता है, जो बताता है कि फ़िल्टर ने आपके कितने ट्रैफ़िक को स्पैम माना: 10% से कम के लिए हरा, 10% से 90% के बीच पीला और 90% से अधिक के लिए लाल। अब एक्सेस मंज़ूरी या माइग्रेशन के 10 महीने बाद समाप्त हो जाता है और इसे फिर से नवीनीकृत करना पड़ता है।
छोटे प्रेषक के लिए SNDS कोई डेटा नहीं भी दिखा सकता है, क्योंकि यह ऐसे IP को छोड़ सकता है जिसने किसी दिन 100 से कम संदेश भेजे हों। और यदि आप किसी प्लेटफ़ॉर्म के साझा IP से ईमेल भेजते हैं, तो वे पते आपके नहीं होते और आप उन्हें पंजीकृत नहीं कर सकते।
JMRP, यानी Junk Mail Reporting Program, फ़ीडबैक लूप है। SNDS के ज़रिए नामांकन करें। इसके बाद Microsoft आपको उन संदेशों के चुने हुए हेडर भेजता है जिन्हें Outlook.com उपयोगकर्ताओं ने जंक के रूप में चिह्नित किया है। यह आम तौर पर 72 घंटों के भीतर शुरू हो जाता है। नए IP जोड़ते समय उन्हें भी इसमें जोड़ें।
Microsoft जंक शिकायत दर को प्रेषक की प्रतिष्ठा तय करने वाले "प्रमुख कारकों में से एक" कहता है, और SNDS FAQ के अनुसार 0.3% से कम शिकायत दर "एक अच्छा लक्ष्य" है। नए IP को स्थापित होने में समय लगता है। Microsoft के अनुसार, कोई नया IP "ईमेल की मात्रा और सूची की सटीकता के आधार पर कुछ हफ़्तों के भीतर या उससे पहले" पूरी तरह सक्रिय हो सकता है। और नहीं, ऐसी कोई सूची नहीं है जिसमें जगह खरीदकर आप शामिल हो सकें। समस्या निवारण पेज यह सवाल पूछता है कि क्या Outlook.com ऐसी allow list चलाता है जिसमें कोई प्रेषक शामिल हो सकता है, और जवाब देता है, "नहीं।"
दूसरी ओर मौजूद व्यक्ति क्या बदल सकता है
इनमें से कुछ चीज़ें प्राप्तकर्ता के नियंत्रण में होती हैं, और पाठक से मदद माँगना उचित है। Outlook.com में (Settings, फिर Mail, फिर Junk email) उपयोगकर्ता किसी संदेश को Not junk के रूप में चिह्नित कर सकता है या प्रेषक को Safe senders and domains में जोड़ सकता है। इस सूची में अधिकतम 10,000 प्रविष्टियाँ हो सकती हैं, और Microsoft के अनुसार इसमें शामिल प्रेषकों के लिंक और चित्र आम तौर पर डिफ़ॉल्ट रूप से सक्षम होते हैं। सख्त सेटिंग चाहने वाला उपयोगकर्ता "exclusive" मोड भी चालू कर सकता है, जो केवल Contacts और Safe Senders से आए ईमेल स्वीकार करता है।
Junk बटन इसके उलट काम करता है। Microsoft इन रिपोर्टों का उपयोग यह तय करने के लिए करता है कि उसी प्रेषक से आने वाले भविष्य के ईमेल को ब्लॉक किया जाना चाहिए या नहीं। इसके अलावा, प्रेषकों के लिए उसकी सिफारिशों में ऐसा सदस्यता समाप्त करने का लिंक देने को कहा गया है जो "साफ़ दिखाई दे"। Microsoft के विवरण में उन वन-क्लिक List-Unsubscribe हेडर का उल्लेख नहीं है जिनकी Gmail और Yahoo को आवश्यकता होती है, लेकिन चूँकि एक ही कैंपेन तीनों पर भेजा जाता है, मैं उन्हें हर जगह जोड़ूँगा (दोनों हेडर)।
डेस्कटॉप ऐप का अपना Junk Email Filter है। डिफ़ॉल्ट रूप से यह "No Automatic Filtering" पर सेट होता है, जबकि इसके ऊपर Low, High और "Safe Lists Only" विकल्प होते हैं। अंतिम विकल्प उपयोगकर्ता की सुरक्षित सूचियों से बाहर के हर ईमेल को जंक मानता है। इसकी सुरक्षित और ब्लॉक की गई सूचियाँ सर्वर के साथ सिंक होती हैं और वहाँ भी उपयोग की जाती हैं।
इसके बाद Focused Inbox है, जो इनबॉक्स को Focused और Other में बाँटता है और Microsoft के शब्दों में, "अपने-आप जनरेट किए गए या बल्क ईमेल जैसे शोर पैदा करने वाले स्रोतों को फ़िल्टर कर देता है"। Other इनबॉक्स का एक टैब है, और मेरी समझ के अनुसार वहाँ मौजूद न्यूज़लेटर पहले ही स्पैम फ़िल्टरिंग से गुजर चुका होता है।
वास्तविक ईमेल भेजने से पहले परीक्षण
Microsoft का अपना समस्या निवारण पेज कहता है कि वह "वास्तविक संचार भेजने से पहले ईमेल परीक्षण करने की पुरज़ोर अनुशंसा करता है"। Email Spam Tester इसी चरण को पूरा करता है। आप पेज से जनरेट किए गए पते पर वास्तविक संदेश उसी सर्वर या प्लेटफ़ॉर्म से भेजते हैं जिसका आप सच में उपयोग करेंगे, और रिपोर्ट में 42 जाँचें दिखाई जाती हैं: अलाइनमेंट सहित SPF, DKIM और DMARC, रिवर्स DNS, 21 ब्लॉकलिस्ट में भेजने वाला IP (जानें कि ये क्यों महत्वपूर्ण हैं), अनसब्सक्राइब हेडर और सामग्री। असफल जाँचों के साथ सुधार योजना और कॉपी करने के लिए DNS रिकॉर्ड दिए जाते हैं। हर सुधार से मिलने वाले पॉइंट स्कोरिंग तालिका पर आधारित होते हैं।
इनबॉक्स प्लेसमेंट परीक्षण जोड़ने पर वही संदेश Gmail, Outlook, Yahoo और अन्य प्रदाताओं के इनबॉक्स में भी जाता है। रिपोर्ट हर प्रदाता के मेलबॉक्स से पढ़कर दिखाती है कि संदेश कहाँ पहुँचा। जहाँ प्रदाता इस तरह वर्गीकरण करता है, वहाँ Focused या Other भी शामिल होते हैं। यह मुफ़्त है और साइनअप की ज़रूरत नहीं है। दस्तावेज़ हर जाँच और उसके पॉइंट की लागत समझाते हैं।
अगर आपका अगला चरण सहायता टिकट खोलना है, तो ध्यान दें कि Microsoft का डिलिवरेबिलिटी फ़ॉर्म केवल @outlook.com, @hotmail.com, @live.com और @msn.com पतों से जुड़े मामलों को स्वीकार करता है। नीतियों वाला पेज चेतावनी देता है कि अगर आप अनुपालन नहीं करते हैं, तो "हो सकता है कि हमारी सहायता टीम आपकी मदद न कर सके।"