क्या 2026 में अपना ईमेल खुद होस्ट करना सही है?

संक्षिप्त उत्तर

2026 में भी अपना ईमेल खुद होस्ट करना सार्थक है, बशर्ते आप इस कार्य को दो भागों में विभाजित कर लें। अपने VPS पर ईमेल प्राप्त करना कम जोखिम वाला है और यह प्रभावी ढंग से काम करता है, क्योंकि आप प्राप्तकर्ता हैं और किसी को भी आप पर भरोसा करने की आवश्यकता नहीं है। ईमेल भेजना, जिसे बड़े मेलबॉक्स प्रदाता स्वीकार करें, एक अलग कार्य है और यह उस IP address reputation पर निर्भर करता है जिसे आप विरासत में प्राप्त करते हैं, न कि जिसे आप खुद बनाते हैं।

अनुभवी ऑपरेटर्स जो सेटअप वास्तव में चलाते हैं, वह एक हाइब्रिड मॉडल है। उनका अपना सर्वर मेलबॉक्स और आर्काइव को सुरक्षित रखता है, और आउटबाउंड मेल port 587 पर एक authenticated relay के माध्यम से बाहर जाता है। पूर्ण self-hosting, यानी दोनों दिशाओं में स्वयं प्रबंधन, अभी भी कुछ विशिष्ट मामलों में बेहतर है, और वे इस पोस्ट के अंत में दिए गए हैं।

ईमेल को self-host करने का कठिन हिस्सा उसकी deliverability है

एक mail server को install करना एक सप्ताहांत का काम है। एक आधुनिक stack आपको mail भेजने के लिए SMTP (simple mail transfer protocol), उसे पढ़ने के लिए IMAP (internet message access protocol), spam filtering और एक webmail interface, सब एक ही compose file से देता है, और VPS पर Mailcow mail server install करना इस विषय को कवर करता है। install करने में कुछ भी कठिन नहीं है।

कठिनाई तब शुरू होती है जब आपका सर्वर किसी ऐसी कंपनी द्वारा संचालित मशीन से connection खोलता है जिसने कभी आपके बारे में नहीं सुना है, और उससे किसी के inbox में संदेश डालने के लिए कहता है। उस receiver के पास हाँ कहने का कोई कारण नहीं है। वह कुछ संकेतों के आधार पर निर्णय लेता है: connecting IP address की reputation, आपके domain की reputation, क्या संदेश authenticated है, और उसके अपने users ने पहले आपके mail पर कैसी प्रतिक्रिया दी है। एक नए sender का कोई इतिहास नहीं होता है, और इतिहास का न होना neutral नहीं माना जाता है। इसे जोखिम माना जाता है। इसलिए पहले संदेश spam folder में चले जाते हैं, या जब तक कोई pattern नहीं बनता तब तक उन्हें रोक दिया जाता है।

आप इनकार देखेंगे। Gmail इस प्रकार का स्थायी rejection भेजता है:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft एक अलग संदेश भेजता है, जो एक block-list code पर समाप्त होता है जो बदलता रहता है:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

किसी भी अन्य चीज़ से पहले पहला अंक पढ़ें। 4 से शुरू होने वाला code अस्थायी होता है, इसलिए आपका सर्वर संदेश को रखता है और पुनः प्रयास करता है। 5 से शुरू होने वाला code स्थायी होता है, इसलिए संदेश तुरंत sender के पास वापस चला जाता है। एक 4xx deferral जो कभी ठीक नहीं होता, वह rate limit या reputation limit है, और यह अपने आप ठीक हो सकता है। एक 5xx एक निर्णय है, और यह नहीं बदलेगा।

नए सर्वर की ईमेल स्पैम में क्यों जाती है?

इसका कारण यह है कि IP address नया नहीं होता है। आपको कोई नया address नहीं मिलता है। आपको अपने provider के pool से एक recycled address मिलता है, और उसका पिछला इतिहास भी उसके साथ आता है। यदि पिछले उपयोगकर्ता ने स्पैम भेजा था, तो आपका पहला संदेश ही दूसरी बार भेजने से पहले reject हो सकता है।

उस पर कुछ भी बनाने से पहले address की जाँच करें। सार्वजनिक blocklists DNS के माध्यम से उत्तर देती हैं, जिसमें address के चार octets को उल्टा कर दिया जाता है:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

खाली उत्तर का अर्थ है कि address listed नहीं है। 127.0.0.0/8 के भीतर कोई उत्तर मिलने का अर्थ है कि वह listed है, और अंतिम octet यह बताता है कि कौन सी सूची मेल खाती है। इस परीक्षण में एक समस्या यह है: Spamhaus उन queries को अस्वीकार कर देता है जो बड़े सार्वजनिक resolvers के माध्यम से आती हैं, इसलिए 8.8.8.8 के माध्यम से की गई वही lookup 127.255.255.254 लौटाती है, चाहे वास्तविक स्थिति कुछ भी हो। उस code का अर्थ है कि query को reject कर दिया गया है, न कि यह कि address listed है। इसे अपने सर्वर के resolver के माध्यम से चलाएं, या इसके बजाय web lookup का उपयोग करें।

एक clean result आवश्यक है लेकिन पर्याप्त नहीं है। 'Not listed' का केवल इतना अर्थ है कि हाल ही में उस address के बारे में किसी ने शिकायत नहीं की है। इसकी कोई सकारात्मक प्रतिष्ठा (positive reputation) नहीं होती है, और सकारात्मक प्रतिष्ठा ही वह चीज है जो वास्तव में ईमेल को इनबॉक्स तक पहुँचाती है। यह हफ्तों तक छोटी मात्रा में वांछित ईमेल भेजकर अर्जित की जाती है।

आपके पड़ोसी भी मायने रखते हैं, क्योंकि कुछ प्राप्तकर्ता एक ही address के बजाय पूरे network block में प्रतिष्ठा को मापते हैं। जब उसी /24 range में कोई अन्य ग्राहक स्पैम भेजना शुरू करता है, तो आपकी ईमेल association के कारण धीमी हो सकती है। वह block-level दृष्टिकोण ही कारण है कि abuse complaints एक VPS इनबॉक्स में आती हैं उस ट्रैफ़िक के लिए जिसे account holder ने कभी नहीं भेजा: शिकायत address range का पीछा करती है।

शुरू करने से पहले क्या पुष्टि करें: port 25 और PTR record

Outbound TCP port 25 इंटरनेट पर सबसे अधिक दुरुपयोग किया जाने वाला port है, इसलिए कई hosting providers इसे नए accounts पर डिफ़ॉल्ट रूप से बंद रखते हैं। कुछ इसे अनुरोध करने पर खोल देते हैं। कुछ इसे तब खोलते हैं जब account पुराना हो जाता है और भुगतान का इतिहास बन जाता है। कुछ इसे कभी नहीं खोलते। providers की नीतियां अलग-अलग होती हैं और वे समय के साथ बदलती रहती हैं, इसलिए इस पोस्ट, किसी पुराने forum thread, या किसी provider के मार्केटिंग पेज को वर्तमान तथ्य न मानें। भुगतान करने से पहले पूछें, और लिखित में उत्तर प्राप्त करें।

सर्वर से ही path का परीक्षण करें:

nc -vz gmail-smtp-in.l.google.com 25

एक खुला path एक सेकंड के भीतर succeeded! प्रिंट करता है। एक blocked path hang हो जाता है और फिर बिना किसी संदेश के time out हो जाता है, क्योंकि चुपचाप drop किया गया packet बिल्कुल एक सामान्य नेटवर्क समस्या जैसा दिखता है।

दूसरी आवश्यकता एक PTR record है, जिसे reverse DNS भी कहा जाता है। प्राप्तकर्ता उस IP address को लेते हैं जो उनसे जुड़ा है, एक नाम प्राप्त करने के लिए उसके PTR record को देखते हैं, और फिर वापस एक address प्राप्त करने के लिए उस नाम को देखते हैं। जब दोनों सहमत होते हैं तो इसे forward-confirmed reverse DNS कहा जाता है, और यह एक सस्ता चेक है कि connecting host उसी का है जिसका वह दावा करता है।

dig -x 203.0.113.5 +short
dig +short mail.example.com

पहले वाले को आपके mail hostname को वापस करना चाहिए। दूसरे वाले को उसी address को वापस करना चाहिए जिससे आपने शुरुआत की थी। केवल एक IP address का स्वामी ही अपना PTR record प्रकाशित कर सकता है, इसलिए यह कुछ ऐसा है जिसे आपका host आपके लिए सेट करता है, या control panel में दिखाता है। एक गायब PTR record, या 203-0-113-5.static.example-isp.net जैसा सामान्य record, एक मजबूत नकारात्मक संकेत है, क्योंकि वास्तविक mail servers के पास लगभग हमेशा एक मेल खाने वाला नाम होता है और bulk spam sources के पास अक्सर नहीं होता है।

यदि आपका host IPv6 भी असाइन करता है और आपका सर्वर इसे प्राथमिकता देता है, तो ऊपर दी गई हर बात IPv6 address पर भी लागू होती है, और Gmail वहाँ अधिक सख्त है। बिना PTR record वाले address से IPv6 पर भेजने पर एक rejection मिलता है जिसमें कहा जाता है कि संदेश PTR records और प्रमाणीकरण के संबंध में IPv6 भेजने के दिशानिर्देशों को पूरा नहीं करता है। यदि आप IPv6 PTR record सेट नहीं कर सकते हैं, तो केवल IPv4 पर भेजें। Postfix में IPv4 को प्राथमिकता देने के लिए smtp_address_preference = ipv4 है, या IPv6 को पूरी तरह से बंद करने के लिए inet_protocols = ipv4 है।

किसी भी host से पूछने के लिए तीन प्रश्न

1. क्या नए account पर outbound TCP port 25 खुला है, और यदि नहीं है, तो इसे खोलने की सटीक प्रक्रिया और समय-सीमा क्या है?
2. क्या मैं अपने IPv4 address और अपने IPv6 address के लिए PTR record सेट कर सकता हूँ, और मैं इसे कहाँ करूँ?
3. यदि मेरा address किसी पिछले ग्राहक के कारण blocklist में पाया जाता है, तो क्या आप मुझे किसी दूसरे address पर स्थानांतरित करेंगे?

खरीदने से पहले तीनों पूछें, बाद में नहीं। एक host जो पहले दो का स्पष्ट उत्तर देता है और तीसरे के लिए मना करता है, वह अभी भी काम करने योग्य है, क्योंकि आप पहले दिन address की जाँच कर सकते हैं और रद्द कर सकते हैं। एक host जो उनमें से किसी का भी लिखित में उत्तर नहीं देगा, उसने पहले ही बता दिया है कि वहाँ mail चलाना कैसा महसूस होगा।

SPF, DKIM और DMARC वास्तव में क्या प्रमाणित करते हैं

तीन DNS records यह प्रमाणित करते हैं कि आपके domain से आने वाला mail वास्तव में वहीं से आया है। प्रत्येक record एक अलग प्रश्न का उत्तर देता है, और तीसरा तभी काम करता है जब आप पहले दो को समझ लेते हैं।

SPF (sender policy framework) एक TXT record है जो उन servers की सूची रखता है जो आपके domain के लिए mail भेज सकते हैं। प्राप्तकर्ता इसे envelope sender के साथ जाँचता है, जो SMTP MAIL FROM command में दिया गया पता होता है, न कि वह From: header जिसे आपका पाठक देखता है।

DKIM (domainkeys identified mail) message headers में एक cryptographic signature जोड़ता है, जो body और headers की चुनी हुई सूची को कवर करता है। संबंधित public key आपके द्वारा चुने गए selector के अंतर्गत DNS में रहती है। कोई भी व्यक्ति यह सत्यापित कर सकता है कि message आपके private key के धारक द्वारा भेजा गया था और रास्ते में उसमें कोई बदलाव नहीं किया गया।

DMARC (domain-based message authentication, reporting and conformance) अन्य दो को दृश्य From: header में मौजूद domain से जोड़ता है, और प्राप्तकर्ताओं को बताता है कि जब यह जुड़ाव विफल हो जाए तो क्या करना है।

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

यहाँ सबसे महत्वपूर्ण शब्द alignment है। DMARC केवल इसलिए pass नहीं होता क्योंकि SPF pass हो गया। यह तब pass होता है जब SPF या DKIM pass हो जाए और वह domain, जो pass हुआ है, वही हो जो From: header में लिखा है। यहीं पर relayed mail चुपचाप विफल हो जाता है: एक relay जो envelope sender को अपने domain में बदल देता है, वह SPF pass तो कर देता है, लेकिन चूँकि pass होने वाला domain relay का होता है, इसलिए वह aligned नहीं होता। ऐसे में DMARC विफल हो जाता है, जब तक कि आपका अपना DKIM signature मौजूद और मान्य न हो। अपने domain के अंतर्गत प्रकाशित key के साथ sign करें और समस्या दूर हो जाएगी।

Alignment forwarding को भी समझाता है। जब कोई mailing list या पुराना university address आपके message को आगे forward करता है, तो forwarding server ही connecting IP address बन जाता है, जो आपके SPF record में नहीं होता, इसलिए अंतिम destination पर SPF विफल हो जाता है। DKIM forwarding के दौरान तब तक सुरक्षित रहता है जब तक कि जिन headers को उसने sign किया है, उनमें कोई बदलाव न हो। DKIM ही वह तकनीक है जिसे काम करना ही चाहिए।

सबसे पहले rua= reporting address के साथ p=none प्रकाशित करें, और किसी भी नियम को सख्त करने से पहले दो सप्ताह तक aggregate reports पढ़ें। वे reports ही एकमात्र स्थान हैं जहाँ आप अपने नाम से भेजा गया वह mail देख पाएंगे जिसे आपने नहीं भेजा है, और यही उस forwarder को खोजने का एकमात्र तरीका है जिसे आप भूल गए थे। सीधे p=reject पर जाने से वह चरण छूट जाता है और वैध mail बिना किसी रिकॉर्ड के विफल हो जाता है।

इसके बाद पूरी chain को end-to-end test करें। किसी बड़े provider के पास मौजूद अपने account पर एक message भेजें, और उसका raw source खोलें:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks SMTP conversation को वैसे ही print करता है जैसे वह घटित होती है। Delivery के लिए Postfix की अपनी log line status=sent (250 2.0.0 OK ...) पर समाप्त होती है जब प्राप्त करने वाला server message स्वीकार कर लेता है। इसके अलावा कुछ भी होने पर वह refusal text को verbatim log करता है, और वही string है जिसे आपको खोजना चाहिए। वितरित message में, raw source में एक Authentication-Results: header होता है जो प्रत्येक check को pass या fail और उस domain के नाम के साथ दर्शाता है जिसे उसने प्रमाणित किया है। तीनों का pass होना अनिवार्य है, और domain आपका ही होना चाहिए।

रेप्यूटेशन (reputation) संबंधी समस्या का पता कैसे लगाएं?

फीडबैक लूप एक ऐसी व्यवस्था है जिसमें जब भी कोई उपयोगकर्ता 'report spam' बटन दबाता है, तो मेलबॉक्स प्रदाता आपको उस संदेश की एक प्रति भेजता है। इसके बिना, समस्या का पहला संकेत डिलीवरी का विफल होना है, जो कि हफ्तों की देरी से पता चलता है।

ये प्रोग्राम अलग-अलग होते हैं और सभी एक ही IP पते वाले VPS के लिए उपयुक्त नहीं होते। अगस्त 2026 तक, Microsoft प्रति-पता (per-address) डेटा और शिकायत सेवा चलाता है जिसके लिए पता स्वामी पंजीकरण कर सकता है, Yahoo DKIM साइनिंग डोमेन पर आधारित शिकायत फीडबैक लूप प्रदान करता है, और Google व्यक्तिगत शिकायतों के बजाय कुल रेप्यूटेशन डेटा प्रकाशित करता है। यह डेटा एक डैशबोर्ड में होता है जो तब तक खाली रहता है जब तक आप उनके उपयोगकर्ताओं को प्रतिदिन पर्याप्त मात्रा में ईमेल नहीं भेजते। किसी भी प्रोग्राम पर निर्भर होने से पहले उनकी वर्तमान शर्तों को पढ़ें, क्योंकि ये प्रोग्राम बदलते रहते हैं और इनमें से कोई भी आपको एक्सेस देने के लिए बाध्य नहीं है।

फरवरी 2024 से लागू Google की बल्क सेंडर आवश्यकताएं, यह स्पष्ट रूप से बताती हैं कि एक बड़ा रिसीवर अब क्या अपेक्षा करता है। जो सेंडर व्यक्तिगत Gmail खातों पर प्रतिदिन 5,000 से अधिक संदेश भेजता है, उसे SPF और DKIM के साथ ऑथेंटिकेट करना होगा, DMARC पॉलिसी प्रकाशित करनी होगी, बल्क मेल पर वन-क्लिक अनसब्सक्राइब की सुविधा देनी होगी, और स्पैम शिकायत दर को 0.3 प्रतिशत से नीचे रखना होगा। एक छोटे सर्वर से भेजे गए व्यक्तिगत मेल इस सीमा से काफी नीचे होते हैं, लेकिन समान संकेतों को हर वॉल्यूम पर पढ़ा जाता है, और शिकायत दर वह संकेत है जिसे आप फीडबैक लूप के बिना नहीं देख सकते।

सफल विभाजन: self-host पर प्राप्त करना, relay के माध्यम से भेजना

ईमेल प्राप्त करना वह हिस्सा है जिसमें लगभग कोई जोखिम नहीं है। आपको भेजे गए मेल को स्वीकार करने के लिए किसी को भी आप पर भरोसा करने की आवश्यकता नहीं है। आपका MX record, जो आपके domain के लिए mail exchanger को नामित करने वाला DNS record है, आपके सर्वर की ओर इशारा करता है। भेजने वाले आपसे जुड़ते हैं, और उसके बाद का हर निर्णय आपका होता है: क्या रखना है, कब तक रखना है, इसे कैसे index करना है, और इसे खोजने की अनुमति किसे है। Storage सस्ता है, और आपके स्वामित्व वाले archive को कहीं और किसी स्वचालित नीतिगत निर्णय द्वारा बंद नहीं किया जा सकता है। यह काम वास्तविक है और सीमित है: spam filter को अपडेट रखें, TLS (transport layer security) certificates को renew करते रहें, backups रखें, और disk को भरने से बचाएं।

Outbound वह जगह है जहाँ आप कठिन समस्या से बचने के लिए भुगतान करते हैं। अपने सर्वर को इस तरह configure करें कि वह हर outgoing message को port 25 पर दुनिया से बात करने के बजाय port 587 पर एक authenticated relay को सौंप दे। Postfix के main.cf में:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Credentials को एक editor के साथ /etc/postfix/sasl_passwd में लिखें, ताकि password कभी भी आपके shell history में न आए। यह एक लाइन है, और बाईं ओर का host बिल्कुल वैसा ही लिखा जाना चाहिए जैसा वह relayhost में दिखाई देता है:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

उस reload के बाद भेजा गया एक message relay=smtp.relay.example[...]:587 और status=sent को log करता है। SASL authentication failed पढ़ने वाली एक log line का मतलब है कि credentials स्वीकार नहीं किए गए थे, और इसका सामान्य कारण sasl_passwd में host का नाम relayhost से अलग तरीके से लिखा होना है, क्योंकि lookup एक सटीक string match है।

यह विभाजन इसलिए काम करता है क्योंकि relay उन addresses का स्वामी है जिनके पीछे वर्षों का स्वीकृत मेल है, और उस reputation को बनाए रखना ही उनका पूरा व्यवसाय है। आप domain, mailboxes, archive और छोड़ने की क्षमता को अपने पास रखते हैं, क्योंकि relay बदलना configuration की एक लाइन और एक DNS record का काम है। आप जो छोड़ते हैं वह relay operator के खिलाफ outbound mail की गोपनीयता है। यह इस व्यवस्था की ईमानदार कीमत है, और इसे खोजे जाने के बजाय पहले से तय कर लेना बेहतर है।

पहले दिन एक और अलगाव करना उचित है। कोई भी bulk मेल अपने स्वयं के subdomain से अपने स्वयं के DKIM key के साथ जाना चाहिए: newsletter के लिए news.example.com और व्यक्तिगत मेल के लिए mail.example.com। Reputation भेजने वाले domain से जुड़ी होती है, इसलिए self-hosted Listmonk newsletter पर शिकायत दर आपके व्यक्तिगत मेल को नीचे नहीं खींच सकती है।

पूर्ण self-hosting कब सही विकल्प होता है?

Volume. प्रति-संदेश relay pricing तब तक ठीक रहती है जब तक आप महीने में सैकड़ों संदेश भेजते हैं, लेकिन लाखों संदेशों पर यह महंगी हो जाती है। उस स्तर पर आप dedicated addresses और उन्हें काम करने योग्य बनाने वाले warmup schedule का खर्च उठा सकते हैं।

Jurisdiction. जब कोई नियम या अनुबंध यह कहता है कि ईमेल किसी तीसरे पक्ष की डिस्क पर नहीं रहना चाहिए, तो delivery quality निर्णायक कारक नहीं होती। उस स्थिति में relay का उपयोग आपके लिए संभव नहीं है।

ऐसा नियंत्रण जिसे आप खरीद नहीं सकते। ऐसे retention rules जो आपके प्लान टियर के बजाय आपकी नीति से मेल खाते हों, प्रत्येक service के लिए एक अलग address ताकि आप देख सकें कि डेटा कहाँ से लीक हुआ है, ऐसी filtering जो आपका अपना कोड चलाती हो, और बिना किसी अपील के किसी सिस्टम द्वारा account suspension का न होना।

ऐसा मेल जो कभी आपके नेटवर्क से बाहर नहीं जाता। Alerts और अन्य machine-to-machine मेल में deliverability की कोई समस्या नहीं होती, क्योंकि दोनों छोर आपके अपने होते हैं। एक local SMTP server जो आपके अपने mailboxes में मेल पहुँचाता है, वही इसका पूरा समाधान है, और यही वह पैटर्न है जो MCP (model context protocol) के माध्यम से एक assistant को उसका अपना self-hosted mailbox देने के पीछे काम करता है।

यदि आप outbound मेल सीधे भेजते हैं, तो address को warm up करें। उन लोगों को कम दैनिक volume के साथ शुरुआत करें जो आपसे मेल की अपेक्षा रखते हैं, कई हफ्तों में इसे धीरे-धीरे बढ़ाएं, और कभी भी cold address से अचानक बहुत सारे मेल न भेजें। Reputation समय के साथ स्वीकार किए गए मेल और कम शिकायतों से बनती है, इसलिए बिना किसी इतिहास वाले address से अचानक आया spike बिल्कुल एक compromised server जैसा दिखता है और उसके साथ वैसा ही व्यवहार किया जाता है।

मेल सर्वर चलाने का पहले साल का खर्च क्या है?

पहला सप्ताह सेटअप का होता है: पैकेज, DNS रिकॉर्ड, TLS सर्टिफिकेट, पहले टेस्ट मैसेज, और p=none पर DMARC।

दूसरे से छठे सप्ताह तक का समय वह है जिसकी कोई योजना नहीं बनाता। आप DMARC एग्रीगेट रिपोर्ट्स पढ़ते हैं, उस अलाइनमेंट समस्या का पता लगाते हैं जिसके बारे में आपको जानकारी नहीं थी, उस फॉरवर्डर को खोजते हैं जो SPF को तोड़ता है, और फिर पॉलिसी को p=quarantine और बाद में p=reject पर ले जाते हैं। यह अवधि तय करती है कि सेल्फ-होस्टिंग आपके लिए एक सामान्य दिनचर्या बन जाएगी या ऐसी चीज जिससे आप परेशान रहेंगे।

इसके बाद, यह लगभग एक घंटे प्रति माह पर स्थिर हो जाता है: पैकेज अपडेट, सर्टिफिकेट रिन्यूअल जिसे आप मान लेने के बजाय सत्यापित करते हैं, बैकअप से रिस्टोर टेस्ट, डिस्क ग्रोथ पर एक नजर, और एक ब्लॉकलिस्ट लुकअप।

फिर वह सप्ताह आता है जिसे आप शेड्यूल नहीं कर सकते। कोई एड्रेस किसी ऐसी चीज के लिए लिस्ट हो जाता है जो आपने नहीं की है। कोई बड़ा रिसीवर नियम बदल देता है और आपका मेल फिर से स्पैम में जाने लगता है। कतार में लगा मेल खोया हुआ मेल नहीं है: Postfix डिफ़ॉल्ट रूप से पांच दिनों तक deferred मैसेज को फिर से भेजने का प्रयास करता है, जिसे maximal_queue_lifetime = 5d द्वारा सेट किया जाता है, इसलिए घंटों में मापी गई आउटेज से केवल लेटेंसी बढ़ती है और कुछ नहीं। एक सप्ताह तक चलने वाली आउटेज से आपका मेल खो सकता है।

एक बैकअप MX रिकॉर्ड इसके लिए उतना प्रभावी समाधान नहीं है जितना दिखता है। भेजने वाले सर्वर पहले से ही अपने आप दिनों तक पुनः प्रयास करते हैं, इसलिए एक सेकेंडरी सर्वर जो केवल कतार में रखता है, वह बहुत कम लाभ देता है। इससे भी बुरा यह है कि एक सेकेंडरी सर्वर जो यह जाने बिना कि कौन से एड्रेस मौजूद हैं, आपके डोमेन के लिए मेल स्वीकार करता है, वह उन एड्रेस के लिए भी मेल ले लेगा जो मौजूद नहीं हैं, और फिर उन्हें फर्जी भेजने वालों को बाउंस कर देगा, जिससे आपका बैकअप 'बैकस्कैटर' (backscatter) का स्रोत बन जाएगा। अपना प्रयास मॉनिटरिंग और एक ऐसे रिस्टोर पर खर्च करें जिसे आपने वास्तव में टेस्ट किया हो।

पूरी स्थिति को उसी प्रश्न के साथ परखें जो आप सर्वर पर मौजूद किसी भी अन्य चीज के लिए लागू करते हैं: क्या इसे खुद चलाने से आपको कुछ ऐसा मिलता है जिसे आप खरीद नहीं सकते? मेलबॉक्स और आर्काइव के लिए, उत्तर आमतौर पर हाँ होता है। अजनबियों को आउटबाउंड डिलीवरी के लिए, उत्तर आमतौर पर नहीं होता है। यही वह परीक्षण है जो बाकी 2026 में सेल्फ-होस्ट करने योग्य चीजों की सूची को अलग करता है।

FAQ

क्या मैं अपना ईमेल self-host कर सकता हूँ यदि मेरा VPS प्रदाता outbound port 25 को ब्लॉक करता है?

हाँ, ईमेल प्राप्त करने के लिए और relay के माध्यम से भेजने के लिए। इनबाउंड मेल आपके सर्वर पर port 25 पर आता है, और outbound ब्लॉक इसे प्रभावित नहीं करता है। आउटबाउंड मेल फिर port 587 पर एक authenticated relay के माध्यम से जाता है, जिसे प्रदाता ब्लॉक नहीं करते हैं। port 25 बंद होने पर आप जो नहीं कर सकते, वह है अन्य मेल सर्वरों को सीधे डिलीवरी करना, क्योंकि सर्वर-टू-सर्वर डिलीवरी परिभाषा के अनुसार port 25 पर ही होती है। इसे nc -vz gmail-smtp-in.l.google.com 25 के साथ टेस्ट करें। यदि यह hang हो जाता है और फिर timeout हो जाता है, तो इसका मतलब है कि port ब्लॉक है।

SPF, DKIM और DMARC पास होने के बावजूद मेरा मेल spam में क्यों जाता है?

Authentication यह साबित करता है कि संदेश किसने भेजा है। यह साबित नहीं करता कि संदेश वांछित है। तीनों को पास करने से आप 'अज्ञात' (unidentified) से 'पहचाने गए' (identified) की श्रेणी में आ जाते हैं, और उसके बाद प्राप्तकर्ता आपके IP address और domain reputation को स्कोर करता है, जो एक नए sender के पास अभी नहीं होती। इसे हफ्तों तक लोगों द्वारा अपेक्षित मेल की छोटी मात्रा भेजकर बनाएं। फिर पुष्टि करें कि PTR record दोनों दिशाओं में आपके mail hostname से मेल खाता है, और जांचें कि सामग्री स्वयं कोई दंड (penalties) तो नहीं जोड़ रही है, जैसे कि link shorteners या कोई अपरिचित tracking domain।

क्या मुझे self-hosted मेल सर्वर के लिए dedicated IP address की आवश्यकता है?

सीधी आउटबाउंड डिलीवरी के लिए, हाँ। एक मेल सर्वर को ऐसे address की आवश्यकता होती है जिसका PTR record आप नियंत्रित करते हैं और जिसकी reputation केवल आपकी है, और एक VPS address उस अर्थ में पहले से ही dedicated होता है। आप जो नियंत्रित नहीं करते हैं, वह है इसका इतिहास या उसी network block में इसके पड़ोसी। यदि आप इसके बजाय आउटबाउंड मेल को relay करते हैं, तो relay के addresses reputation वहन करते हैं, और आपके address को केवल इनबाउंड कनेक्शन स्वीकार करने होते हैं।

क्या अपने मुख्य address को self-hosted सर्वर पर ले जाना सुरक्षित है?

इसे एक बार में बदलने के बजाय चरणों में ले जाएं। मौजूदा mailbox को live रखें, अपने सर्वर को दूसरे destination के रूप में जोड़ें, और कुछ हफ्तों तक इसकी एक copy forward करें। इस दौरान DMARC reports पढ़ें और पुष्टि करें कि मेल दोनों दिशाओं में सही ढंग से आ-जा रहा है। MX record को केवल तभी बदलें जब एक सप्ताह तक test mail सही ढंग से प्राप्त हो जाए। जिस विफलता पर लोग पछताते हैं, वह है एक ऐसा cut-over जो इनबाउंड मेल को खो देता है, और इनबाउंड वह हिस्सा है जिसे दोबारा प्राप्त नहीं किया जा सकता।

मेरे मेल पर नियंत्रण रखने के लिए सबसे छोटा सेटअप क्या है?

mailboxes और archive के लिए आपका अपना सर्वर, जिसमें आउटबाउंड मेल को port 587 पर एक authenticated relay को सौंप दिया जाता है। आप डेटा और domain के मालिक हैं, और आप reputation की समस्या को पूरी तरह से छोड़ देते हैं। अपना मन बदलने की लागत कम रहती है, क्योंकि relay केवल एक configuration line और एक SPF entry है, इसलिए इसे बाद में बदलना केवल एक दोपहर का काम है।