Google Workspace के लिए SPF रिकॉर्ड क्या है?

Google, Workspace के लिए include:_spf.google.com बताता है। इसे प्रकाशित करने से पहले Google के अपने सहायता पेज पर वर्तमान मान की पुष्टि कर लें।

Microsoft 365 के लिए SPF रिकॉर्ड क्या है?

Microsoft, Exchange Online के लिए include:spf.protection.outlook.com बताता है। वर्तमान मान की पुष्टि Microsoft के दस्तावेज़ों में कर लें।

क्या मैं Google Workspace और सेंडिंग सेवा को एक ही SPF रिकॉर्ड में जोड़ सकता हूँ?

हाँ। दोनों include मेकेनिज़्म को उसी एक रिकॉर्ड में रखें, और अंत में अपना all मेकेनिज़्म लगाएँ।

मैं अपने SPF लुकअप की गिनती कैसे जाँचूँ?

ऐसा SPF चेकर इस्तेमाल करें जो include का पीछा करके लुकअप गिनता हो। कुल संख्या दस या उससे कम रखें।

SPF रिकॉर्ड उदाहरण: Google Workspace, Microsoft 365

एक नज़र में। Google: include:_spf.google.com · Microsoft 365: include:spf.protection.outlook.com · हमेशा: प्रति डोमेन एक ही v=spf1 रिकॉर्ड · पुष्टि करें: वर्तमान मानों के लिए प्रोवाइडर के दस्तावेज़ देखें

संक्षेप में

एक रिकॉर्ड, कई सेंडर। अगर आपके स्टाफ़ का मेल एक प्रोवाइडर पर चलता है और एप्लिकेशन का मेल किसी सेंडिंग सेवा से जाता है, तो दोनों को एक ही SPF रिकॉर्ड में अधिकृत करना होगा।
केवल Google Workspace। Google, Workspace के लिए include:_spf.google.com बताता है।
केवल Microsoft 365। Microsoft, Exchange Online के लिए include:spf.protection.outlook.com बताता है।
Google Workspace के साथ सेंडिंग सेवा। सेंडिंग सेवा का include, Google के include के बगल में जोड़ें।
Microsoft 365 के साथ सेंडिंग सेवा। यही तरीका यहाँ भी लागू होता है।
अपना सर्वर IP एड्रेस से जोड़ना। अगर आप कोई ऐसा सर्वर चलाते हैं जो मेल भेजता है, जैसे वेब एप्लिकेशन या पुराना मेल सर्वर, तो उसका पता ip4 से लिखें।

एक रिकॉर्ड, कई सेंडर

अगर आपके स्टाफ़ का मेल एक प्रोवाइडर पर चलता है और एप्लिकेशन का मेल किसी सेंडिंग सेवा से जाता है, तो दोनों को एक ही SPF रिकॉर्ड में अधिकृत करना होगा। हर एक एक include जोड़ता है, और आप शुरुआत में एक ही v=spf1 तथा अंत में एक ही all रखते हैं।

नीचे के उदाहरण Google और Microsoft द्वारा प्रकाशित include मानों का उपयोग करते हैं। प्रोवाइडर कभी-कभी इन्हें बदल देते हैं, इसलिए प्रकाशित करने से पहले उनके वर्तमान दस्तावेज़ों से मिलान कर लें।

केवल Google Workspace

Google, Workspace के लिए include:_spf.google.com बताता है। जो डोमेन केवल Google के ज़रिए मेल भेजता है, वह यही रिकॉर्ड प्रकाशित करेगा।

v=spf1 include:_spf.google.com ~all

अगर आप अपने डोमेन के साथ Gmail इस्तेमाल करते हैं, तो शुरुआत के लिए भी यही सही है।

केवल Microsoft 365

Microsoft, Exchange Online के लिए include:spf.protection.outlook.com बताता है। जो डोमेन केवल Microsoft 365 से मेल भेजता है, वह इसे प्रकाशित करेगा।

v=spf1 include:spf.protection.outlook.com ~all

अगर माइग्रेशन के दौरान आप दोनों प्रोवाइडर इस्तेमाल कर रहे हैं, तो आगे दिखाए अनुसार उन्हें मिलाएँ, और बदलाव पूरा होने पर पुराने को हटा दें।

Google Workspace के साथ सेंडिंग सेवा

सेंडिंग सेवा का include, Google के include के बगल में जोड़ें। रिकॉर्ड एक ही रखें, और दोनों include अंत से पहले रखें।

v=spf1 include:_spf.google.com include:YOUR_SPF_HOST ~all

YOUR_SPF_HOST की जगह अपने MigoSMTP डैशबोर्ड का मान लगाएँ, या जो भी सेवा आप इस्तेमाल करते हैं उसका मान।

Microsoft 365 के साथ सेंडिंग सेवा

यही तरीका यहाँ भी लागू होता है। दो include, एक रिकॉर्ड।

v=spf1 include:spf.protection.outlook.com include:YOUR_SPF_HOST ~all

सेंडिंग सेवा को DKIM से भी ऑथेंटिकेट करें, ताकि जब SPF अलाइन न हो तब DMARC, DKIM सिग्नेचर पर पास हो सके।

अपना सर्वर IP एड्रेस से जोड़ना

अगर आप कोई ऐसा सर्वर चलाते हैं जो मेल भेजता है, जैसे वेब एप्लिकेशन या पुराना मेल सर्वर, तो उसका पता ip4 से लिखें। आप CIDR रूप में रेंज भी जोड़ सकते हैं।

v=spf1 include:_spf.google.com ip4:203.0.113.10 include:YOUR_SPF_HOST ~all

केवल वही पते डालें जिन पर आपका नियंत्रण है, और सर्वर बंद होने पर उन्हें हटा दें।

अन्य मेलबॉक्स प्रोवाइडर

Zoho जैसे अन्य प्रोवाइडर अपने include मान खुद प्रकाशित करते हैं, और कुछ के अलग डेटा सेंटरों के लिए अलग मान होते हैं। मान हमेशा अपने क्षेत्र के लिए प्रोवाइडर के अपने सहायता पेज से कॉपी करें, किसी ब्लॉग पोस्ट से नहीं।

पैटर्न नहीं बदलता: एक रिकॉर्ड, हर सेंडर के लिए एक include, एक समापन।

अपनी लुकअप गिनती जाँचें

हर include एक लुकअप गिना जाता है, और किसी प्रोवाइडर के include में आगे और include हो सकते हैं। Google और Microsoft के रिकॉर्ड हर एक अंदर से कई लुकअप इस्तेमाल करते हैं, इसलिए उन्हें कुछ सेवाओं के साथ मिलाने पर दस की सीमा आपकी अपेक्षा से जल्दी आ सकती है।

हमारा मुफ़्त चेकर और ज़्यादातर SPF टेस्टिंग टूल लुकअप आपके लिए गिन देते हैं। अगर आप सीमा के करीब हैं, तो जो सेंडर अब इस्तेमाल में नहीं हैं उन्हें हटा दें, और अलग-अलग तरह के मेल को अलग सबडोमेन से भेजने पर विचार करें, जिनमें से हर एक का अपना रिकॉर्ड हो।

सबडोमेन से भेजना

कई टीमें मार्केटिंग या ट्रांज़ैक्शनल मेल mail.yourdomain.com जैसे सबडोमेन से भेजती हैं। सबडोमेन का अपना SPF रिकॉर्ड होता है, जो रूट से अलग रहता है, इससे हर रिकॉर्ड छोटा रहता है और रूट साफ़-सुथरा रहता है।

याद रखें कि DMARC सबडोमेन पर भी लागू होता है, इसलिए सबडोमेन के मेल का अलाइनमेंट जाँचें।

कमांड लाइन से रिकॉर्ड देखें

आप किसी भी डोमेन का SPF रिकॉर्ड DNS क्वेरी से पढ़ सकते हैं। Linux और macOS पर dig और Windows पर nslookup इस्तेमाल करें। दोनों रूट के TXT रिकॉर्ड दिखाते हैं, और SPF वाला v=spf1 से शुरू होता है।

dig +short TXT yourdomain.com

अगर आपको v=spf1 से शुरू होने वाले दो रिकॉर्ड दिखें, तो उन्हें मर्ज करें। अगर एक भी न दिखे, तो एक प्रकाशित करें। हर बदलाव के बाद क्वेरी दोबारा चलाएँ, क्योंकि आपका DNS पैनल ऐसा मान दिखा सकता है जो अभी फैला नहीं है।

लुकअप गिनती का एक उदाहरण

मान लीजिए किसी रिकॉर्ड में include:_spf.google.com, include:YOUR_SPF_HOST और ip4:203.0.113.10 हैं। ip4 की कोई लागत नहीं है। हर include एक लुकअप का खर्च है, साथ में वे लुकअप भी जो उस प्रोवाइडर के अपने रिकॉर्ड के भीतर हैं। जिस प्रोवाइडर के रिकॉर्ड में तीन और include हैं, उसकी कुल लागत इसलिए चार है।

हर include की कुल संख्या जोड़ें। अगर योग दस या उससे कम आए तो ठीक है। अगर दस से ऊपर जाए, तो SPF सबके लिए विफल हो जाता है, इसलिए प्रकाशित करने से पहले सेंडर घटाएँ या कुछ मेल को सबडोमेन पर ले जाएँ।

बिना अंतराल के प्रोवाइडर बदलना

जब आप एक सेंडिंग सेवा से दूसरी पर जाएँ, तो नया include जोड़ते समय पुराना include रिकॉर्ड में बनाए रखें, नई सेवा से थोड़ा हिस्सा भेजें, और पुराना include तभी हटाएँ जब पुरानी सेवा कुछ न भेज रही हो।

उसे बहुत जल्दी हटाने का अर्थ है कि पुरानी सेवा से जा रहा कोई भी संदेश SPF में विफल हो जाएगा। हमारी माइग्रेशन गाइड DNS, कुंजियों और टेम्पलेट के लिए यही ओवरलैप वाला तरीका बताती हैं।

जब SPF काफ़ी नहीं होता

SPF केवल एन्वेलप सेंडर को जाँचता है और फ़ॉरवर्डिंग पर टूट जाता है, इसलिए प्राप्तकर्ता DKIM और DMARC भी देखते हैं। जो रिकॉर्ड SPF पास करता है पर जिसमें न DKIM सिग्नेचर है और न DMARC रिकॉर्ड, वह केवल आंशिक रूप से ऑथेंटिकेटेड है।

तीनों सेट अप करें। हमारी DMARC गाइड बताती है कि रिकॉर्ड को सुरक्षित ढंग से कैसे प्रकाशित करें और रिपोर्ट कैसे पढ़ें।

Google Workspace, Microsoft 365 और आपकी सेंडिंग सेवा के लिए SPF रिकॉर्ड उदाहरण