VPS पर Mailcow कैसे सेटअप करें: Gmail के लिए ईमेल गाइड

आप क्या बना रहे हैं

अपने स्वयं के सर्वर पर एक पूर्ण मेल सर्वर: भेजने और प्राप्त करने के लिए SMTP, आपके फोन और लैपटॉप को सिंक में रखने के लिए IMAP, एक वेबमेल क्लाइंट, और एक स्पैम फ़िल्टर जो दोनों दिशाओं में प्रत्येक संदेश को स्कोर करता है। mailcow-dockerized एक ही Docker Compose स्टैक में Postfix, Dovecot, Rspamd, SOGo वेबमेल, MariaDB, Redis और एक ACME क्लाइंट को बंडल करता है, इसलिए सॉफ्टवेयर का हिस्सा कठिन नहीं है। आप इसे आधे घंटे में चला लेंगे।

कठिन हिस्सा इसके आसपास की हर चीज है। ईमेल वह सेवा है जहाँ बाकी इंटरनेट सक्रिय रूप से एक बिल्कुल नए सर्वर पर अविश्वास करता है, और "यह काम करता है" और "Gmail चुपचाप हर संदेश को खा जाता है" के बीच का अंतर मुख्य रूप से चार DNS रिकॉर्ड और एक IP-reputation सेटिंग पर निर्भर करता है जिसे आप पूरी तरह से नियंत्रित नहीं कर सकते हैं। कुछ भी किराए पर लेने से पहले नीचे दी गई पूर्वापेक्षाएँ (prerequisites) पढ़ें। यदि उन्हें पढ़ने के बाद, आप यह तय करते हैं कि reputation बनाए रखने की मेहनत इसके लायक नहीं है, तो यह एक वैध निर्णय है, 2026 में वास्तव में क्या self-host करने योग्य है, इसका हमारा विवरण ईमेल को ठीक इन्हीं कारणों से "केवल तभी जब आप गंभीर हों" श्रेणी में रखता है।

पूर्वापेक्षाएँ ही प्रोजेक्ट हैं

यदि आप इनमें से एक भी चूक गए, तो आप ऐसे ईमेल भेजेंगे जो कभी नहीं पहुँचेंगे। यहाँ उन समस्याओं का क्रम दिया गया है जो अक्सर लोगों के काम को विफल कर देती हैं:

Outbound port 25 खुला होना चाहिए। आपका सर्वर TCP port 25 के माध्यम से Gmail और Microsoft को ईमेल डिलीवर करता है। स्पैम रोकने के लिए अधिकांश VPS और क्लाउड प्रदाता डिफ़ॉल्ट रूप से outbound 25 को ब्लॉक कर देते हैं। यह ब्लॉक चुपचाप होता है; बूट के समय कोई त्रुटि नहीं आती, सब कुछ ठीक दिखता है, और ईमेल कतार (queue) में deferred स्थिति में रहता है जब तक कि Postfix हार मानकर उसे bounce न कर दे (mailcow अधिकतम कतार जीवनकाल को पाँच दिनों पर सेट करता है)। कुछ भी इंस्टॉल करने से पहले इसका परीक्षण करें। यदि यह ब्लॉक है, तो एकमात्र समाधान अपने प्रदाता को सपोर्ट टिकट भेजकर इसे खोलने का अनुरोध करना है; कुछ प्रदाता पुराने खातों के लिए ऐसा करते हैं, कुछ कभी नहीं करेंगे।

उपयोगी प्रतिष्ठा (reputation) वाला एक साफ IP। पुनर्नवीनीकरण (recycled) किए गए VPS IP अक्सर पिछले उपयोगकर्ता द्वारा स्पैम भेजने के कारण पहले से ही ब्लॉकलिस्ट में होते हैं। प्रतिबद्ध होने से पहले Spamhaus lookup या mxtoolbox जैसी सेवा पर अपना IP चेक करें। यदि IP लिस्टेड है, तो ईमेल रिजेक्ट होंगे और आप कोडिंग के जरिए इसे ठीक नहीं कर पाएंगे।

DNS का नियंत्रण और एक सही PTR रिकॉर्ड। आपको अपने डोमेन के ज़ोन में रिकॉर्ड जोड़ने होंगे, और आपको अपने सर्वर के IP के लिए reverse DNS (PTR) की आवश्यकता होगी जो आपके मेल hostname की ओर इशारा करता हो। PTR लगभग कभी भी आपके DNS पैनल में सेट नहीं होता है; यह उस संस्था के पास होता है जो IP की मालिक है, इसलिए इसे आपके VPS प्रदाता के कंट्रोल पैनल में या टिकट के माध्यम से सेट किया जाता है।

6 GiB RAM और 2 vCPU न्यूनतम आवश्यकता है। mailcow की अपनी न्यूनतम आवश्यकता एक निजी इंस्टॉलेशन के लिए 6 GiB RAM और 1 GiB swap है, और जब कुछ उपयोगकर्ता इसका उपयोग करने लगें तो 8 GiB की सलाह दी जाती है। लगभग 2.5 GiB से नीचे, generate_config.sh ClamAV वायरस स्कैनर को अक्षम करने का विकल्प देता है ताकि kernel कंटेनरों को बंद (kill) न करे। mailcow के लिए प्रलेखित न्यूनतम डिस्क स्थान 20 GiB है, इससे पहले कि कोई मेल स्टोर किया जाए, इसलिए शुरुआत में इससे अधिक स्थान दें और मेलबॉक्स के बढ़ने के लिए जगह छोड़ें।

एक DNS नाम, न कि केवल एक IP। mail.example.com जैसा एक hostname चुनें। वह एकल नाम आपका MAILCOW_HOSTNAME, आपके TLS certificate का विषय, आपका PTR लक्ष्य और आपका SMTP banner बन जाता है। इसे हर जगह एक समान रखें।

चरण 1, साबित करें कि outbound port 25 खुला है

सबसे पहले यह करें। यदि यह विफल हो जाता है, तो बाकी सब कुछ व्यर्थ है। नए VPS से, एक वास्तविक mail server के साथ SMTP conversation शुरू करने का प्रयास करें:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25

एक सफल परिणाम तुरंत मिलता है:

Connection to gmail-smtp-in.l.google.com (142.250.x.x) 25 port [tcp/smtp] succeeded!

एक blocked port पूरे पांच सेकंड तक रुकता है, और फिर विफल हो जाता है:

nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

बिना किसी outbound firewall rules वाले एक नए VPS पर, वह timeout प्रदाता (provider) द्वारा लगाया गया block है। यह प्रदाता-स्तर का network filter है, न कि आपका firewall, इसलिए कोई भी स्थानीय बदलाव इसे ठीक नहीं करेगा। एक ticket खोलें: "कृपया मेरे VPS के लिए outbound TCP port 25 को <IP> पर सक्षम करें; मैं एक वैध mail server चला रहा हूँ।" जब तक यह "succeeded" न हो जाए, तब तक mailcow इंस्टॉल न करें। ध्यान दें कि inbound 25 (अन्य सर्वर जो आप तक पहुँच रहे हैं) एक अलग मार्ग है और आमतौर पर खुला रहता है, प्रदाता केवल outbound पक्ष को ही throttle करते हैं।

चरण 2, अभी DNS रिकॉर्ड सेट करें

DNS परिवर्तनों को propagate होने में समय लगता है, इसलिए इंस्टॉलेशन से पहले ही सब कुछ पब्लिश कर दें। मान लें कि आपका डोमेन example.com है, आपका मेल होस्ट mail.example.com है, और IP 10.0.0.10 है। अपने ज़ोन में, निम्नलिखित बनाएँ:

mail.example.com.        A      10.0.0.10
mail.example.com.        AAAA   2001:db8::10          ; only if you have IPv6
example.com.             MX  10 mail.example.com.
example.com.             TXT    "v=spf1 mx -all"
_dmarc.example.com.      TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

SPF रिकॉर्ड का अर्थ है "केवल मेरा MX इस डोमेन के लिए मेल भेज सकता है, बाकी को अस्वीकार करें"। DMARC को p=none पर शुरू करें ताकि आप अपने मेल को रिजेक्ट किए बिना रिपोर्ट्स की निगरानी कर सकें; एक बार अलाइनमेंट सिद्ध हो जाने पर इसे p=quarantine और फिर p=reject पर सख्त करें। दो रिकॉर्ड जानबूझकर अभी भी गायब हैं: DKIM, जिसे mailcow आपके लिए चरण 6 में जनरेट करेगा, और PTR, जिसे आप अभी अपने प्रोवाइडर के पैनल में सेट करते हैं।

10.0.0.10 के लिए PTR (रिवर्स DNS) को mail.example.com पर सेट करें, जो MAILCOW_HOSTNAME का सटीक मान है। यह वह एकमात्र रिकॉर्ड है जिसे अधिकांश लोग भूल जाते हैं, और बड़े प्रोवाइडर्स इसी के आधार पर मेल रिजेक्ट कर देते हैं। यदि आपके पैनल में rDNS फ़ील्ड नहीं है, तो एक टिकट रेज़ करें।

चरण 3, Docker इंस्टॉल करें

mailcow को Docker Engine 24.0 या उससे नया और Docker Compose 2.0 या उससे नया वर्ज़न चाहिए। Compose plugin (docker compose) सबसे सरल तरीका है, हालाँकि mailcow स्टैंडअलोन docker-compose बाइनरी को भी सपोर्ट करता है। Ubuntu के docker.io पैकेज के बजाय Docker की आधिकारिक सुविधा स्क्रिप्ट (convenience script) का उपयोग करें, क्योंकि उस पैकेज में कोई Compose plugin नहीं होता है:

curl -fsSL https://get.docker.com | sudo sh
sudo docker compose version

आपको एक Docker Compose version लाइन दिखनी चाहिए जो v2.x या v5.x रिपोर्ट करे। 2025 में रिलीज़ हुआ Compose v5, फंक्शन के तौर पर v2 के समान है, और दोनों में से कोई भी mailcow की आवश्यकताओं को पूरा करता है। यदि docker compose version आउटपुट में docker: 'compose' is not a docker command दिखाता है, तो Docker Engine इंस्टॉल है लेकिन Compose plugin नहीं है। Docker के रिपॉजिटरी से प्लगइन इंस्टॉल करें, ऊपर दी गई स्क्रिप्ट को फिर से चलाएँ, या हमारी Docker Compose बेसिक्स गाइड का पालन करें, जो Docker की अपनी apt रिपॉजिटरी से दोनों को सेटअप करती है।

चरण 4, mailcow को क्लोन करें और कॉन्फ़िगरेशन जनरेट करें

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
umask
sudo ./generate_config.sh

यह सुनिश्चित करना कि umask, 0022 प्रिंट करता है, mailcow के अपने इंस्टॉलेशन चरणों का पालन करता है, जो क्लोनिंग से पहले umask 0022 को सेट करते हैं। mailcow में कुछ भी इस मान का परीक्षण नहीं करता है, और एक नया Ubuntu 24.04 root शेल आपको पहले से ही 0022 देता है। स्क्रिप्ट फिर वह एकमात्र महत्वपूर्ण चीज़ पूछती है: fully qualified hostname। mail.example.com दर्ज करें, मान को आपके A record और PTR से बिल्कुल मेल खाना चाहिए। यह mailcow.conf लिखता है, जो एकमात्र environment file है जिसे पूरा स्टैक पढ़ता है। यदि आपको web ports (HTTP_PORT, HTTPS_PORT) बदलने हैं या छोटे बॉक्स पर ClamAV को अक्षम करना है, तो इसे खोलें:

MAILCOW_HOSTNAME=mail.example.com
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n          # set to y to drop the virus scanner on a <2.5 GiB box

SKIP_FTS=y कम RAM वाले बॉक्स पर दूसरा विकल्प है: full-text search mailcow के दस्तावेज़ों में बताया गया दूसरा मेमोरी खपत करने वाला फीचर है, और इसे छोड़ने पर आपको केवल webmail में body-text search की सुविधा नहीं मिलेगी।

HTTP_PORT=80 और HTTPS_PORT=443 को वैसे ही छोड़ दें जब तक कि होस्ट पर किसी अन्य चीज़ ने पहले से ही उनका उपयोग न किया हो, mailcow का इन-बिल्ट ACME client डिफ़ॉल्ट रूप से HTTP-01 challenge का उपयोग करता है, जिसके लिए सर्टिफिकेट प्राप्त करने के लिए इंटरनेट से port 80 तक पहुंच आवश्यक है। (mailcow 2026-03 और बाद के संस्करण ACME_DNS_CHALLENGE=y के साथ DNS-01 challenge का उपयोग कर सकते हैं, जिसके लिए port 80 की आवश्यकता नहीं होती है, लेकिन आपके DNS होस्ट तक API पहुंच की आवश्यकता होती है।) यही कारण है कि सरल लेआउट उसी बॉक्स पर एक अलग nginx-plus-Certbot सेटअप नहीं चलाता है; mailcow अपने TLS को आंतरिक रूप से जारी और नवीनीकृत करता है, और 80/443 पर कब्जा करने वाली दूसरी सेवा इसे बाधित करती है। mailcow विकल्प का दस्तावेजीकरण करता है: अपने web listeners को HTTP_BIND=127.0.0.1 HTTP_PORT=8080 HTTPS_BIND=127.0.0.1 HTTPS_PORT=8443 के साथ स्थानीय रूप से bind करें, 80 और 443 पर एक reverse proxy रखें, और यदि आप चाहते हैं कि एक स्थानीय Certbot सर्टिफिकेट का मालिक हो, तो mailcow को उनकी ओर इंगित करें और एक renewal hook जोड़ें। मेल सर्वर पर यह अधिक जटिल प्रक्रिया है, इसलिए यही ट्रेड-ऑफ किसी भी अन्य सेवा पर लागू होता है जिसे public web front end की आवश्यकता होती है: Jellyfin लाइब्रेरी को 90 के दशक के वीडियो स्टोर के रूप में बदलने वाला Halcyon जैसा बिल्ड, जो 443 पर अपने स्वयं के reverse proxy की अपेक्षा करता है, उसे एक अलग होस्ट पर होना चाहिए जब तक कि आप mailcow को उस प्रॉक्सी के पीछे न ले जाएं। अपवाद वह सेवा है जो कभी भी public web port नहीं मांगती है: एक self-hosted RustDesk relay केवल अपनी 21115 से 21119 रेंज पर सुनता है, इसलिए यदि आपके पास पर्याप्त बैंडविड्थ है तो यह बॉक्स साझा कर सकता है।

चरण 5, स्टैक शुरू करें और लॉग इन करें

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Pull करने पर लगभग दो दर्जन images डाउनलोड होती हैं; इसे कुछ मिनट का समय दें। जब docker compose ps हर container को running (या healthy) के रूप में दिखाए, तो ब्राउज़र में https://mail.example.com/admin खोलें। डिफ़ॉल्ट एडमिन लॉग इन username admin और password moohoo है। एडमिन UI में System → Configuration, और फिर Access → Administrators के अंतर्गत उस पासवर्ड को तुरंत बदलें। यदि ब्राउज़र NET::ERR_CERT_AUTHORITY_INVALID की चेतावनी देता है, तो इसका मतलब है कि ACME certificate अभी जारी नहीं हुआ है; इसे खराब मानने से पहले नीचे दी गई ACME विफलता (failure) देखें। पहले एक या दो मिनट के लिए self-signed placeholder का दिखना सामान्य है।

चरण 6, एक domain और mailbox जोड़ें, और DKIM प्रकाशित करें

Admin UI में, E-Mail → Configuration खोलें, और Domains टैब के अंतर्गत Add domain पर क्लिक करें और example.com दर्ज करें। फिर, Mailboxes के अंतर्गत, एक पासवर्ड के साथ you@example.com बनाने के लिए Add mailbox पर क्लिक करें। यह एक कार्यशील mailbox है जो पहले से ही IMAP के माध्यम से पहुँच योग्य है।

अब DKIM key की बारी है। System → Configuration पर जाएँ, फिर Options → ARC/DKIM keys चुनें; हो सकता है कि domain जोड़ते समय mailcow ने पहले ही एक key generate कर ली हो, और यदि नहीं, तो वहाँ एक key generate करें, domain चुनें, selector को dkim रखें, 2048-bit चुनें, और Add पर क्लिक करें। यह जो लंबा TXT मान दिखाता है उसे कॉपी करें और इसे इस प्रकार प्रकाशित करें:

dkim._domainkey.example.com.  TXT  "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqh...long-key...QAB"

mailcow के Domains पेज पर एक DNS बटन है जो उन सभी records को सूचीबद्ध करता है जिनकी उसे अपेक्षा है और जो वास्तव में प्रकाशित हैं उनके सामने हरा टिक या लाल क्रॉस दिखाता है। इसे अपनी चेकलिस्ट के रूप में उपयोग करें, deliverability का परीक्षण करने से पहले हर पंक्ति को हरा करें। प्रकाशित करने के बाद एक लाल DKIM पंक्ति का मतलब आमतौर पर यह होता है कि key को TXT chunks में गलत तरीके से विभाजित किया गया था; एक 2048-bit key एक एकल TXT string के लिए 255-अक्षर की सीमा से अधिक लंबी होती है, इसलिए इसे एक तार्किक मान के रूप में पेस्ट करें और अपने DNS host को इसे आपके लिए chunks में विभाजित करने दें।

चरण 7, deliverability का परीक्षण करें और 10/10 स्कोर प्राप्त करें

mail-tester.com पर जाएं, वहां दिखाए गए रैंडम पते को कॉपी करें, और अपने नए मेलबॉक्स से उस पर एक संदेश भेजें। इसके लिए https://mail.example.com/SOGo पर SOGo वेबमेल में लॉग इन करें और वहां से ईमेल भेजें। इसके बाद "Then check your score" पर क्लिक करें।

आपका लक्ष्य 10/10 स्कोर प्राप्त करना है। सामान्य कटौती और उनके कारण इस प्रकार हैं:

• SPF aligned नहीं है, आपका MX/SPF रिकॉर्ड गायब है या भेजने वाला IP इसमें शामिल नहीं है। अपने SPF TXT रिकॉर्ड की दोबारा जांच करें।
• DKIM signature सत्यापित नहीं हो रहा है, dkim._domainkey TXT रिकॉर्ड गायब है, अभी भी propagate हो रहा है, या गलत तरीके से कॉन्फ़िगर है। यह सबसे आम गलती है।
• PTR नहीं है / PTR मेल नहीं खाता, reverse DNS mail.example.com पर resolve नहीं हो रहा है। इसे अपने प्रदाता (provider) के पास ठीक करें।
• ब्लॉकलिस्ट में सूचीबद्ध है, यह आपके IP की पिछली प्रतिष्ठा के कारण है। delisting का अनुरोध करें या एक क्लीन IP की मांग करें।

जब तक स्कोर 10/10 न हो जाए, तब तक Gmail या Outlook पर वास्तविक मेल न भेजें। कम स्कोर और नया IP होने पर आपका डोमेन पहले ही दिन फ्लैग (flag) हो सकता है।

चरण 8, एक वास्तविक mail client को कनेक्ट करें

Thunderbird, Apple Mail, या अपने फोन को इन सेटिंग्स के साथ सर्वर पर पॉइंट करें। सभी के लिए सर्वर होस्ट mail.example.com है:

• IMAP: पोर्ट 993, SSL/TLS (या STARTTLS के साथ 143)
• SMTP submission: पोर्ट 465, SSL/TLS (या STARTTLS के साथ 587)
• Username: पूरा ईमेल पता, you@example.com
• Password: आपके द्वारा सेट किया गया मेलबॉक्स पासवर्ड

Client mail को कभी भी पोर्ट 25 पर न भेजें, वह पोर्ट केवल सर्वर-टू-सर्वर संचार के लिए है। mailcow वहां authenticated submission की सुविधा नहीं देता है, और उस पर पॉइंट किए गए किसी भी client को अस्वीकार कर दिया जाता है। यदि कोई client Relay access denied रिपोर्ट करता है, तो इसका मतलब है कि वह पोर्ट 25 पर या बिना authentication के भेजने का प्रयास कर रहा है; इसे अपने मेलबॉक्स क्रेडेंशियल्स के साथ 465 या 587 पर स्विच करें।

चरण 9, जो वास्तव में महत्वपूर्ण है उसका बैकअप लें

mailcow एक बैकअप स्क्रिप्ट के साथ आता है जो हर stateful volume का स्नैपशॉट लेती है। इसे किसी बाहरी डिस्क या माउंट की गई रिमोट लोकेशन पर चलाएं:

sudo MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
  ./helper-scripts/backup_and_restore.sh backup all

all छह चीजों को कैप्चर करता है, और इनमें से किसी को भी खोने का मतलब है डेटा का नुकसान: vmail (वास्तविक मेलबॉक्स), crypt (वे कुंजियाँ जो vmail को डिक्रिप्ट करती हैं, इनके बिना vmail बेकार है), mysql (MariaDB जो डोमेन, उपयोगकर्ता, उपनाम और सेटिंग्स को होल्ड करता है), redis (कतार और कैश स्थिति), rspamd (सीखा गया स्पैम/हैम), और postfix (मेल कतार)। यह एक हेल्पर कंटेनर के अंदर चलता है जो कंप्रेस्ड आर्काइव लिखता है, इसलिए स्टैक के लाइव रहने के दौरान भी बैकअप सुसंगत (consistent) रहते हैं। इसे एक nightly cron job के साथ स्वचालित करें, और पुराने सेट को हटाने के लिए --delete-days 14 जोड़ें। जो cron job काम करना बंद कर देती है वह चुपचाप विफल हो जाती है, इसलिए स्क्रिप्ट के exit status को कहीं ऐसी जगह भेजें जहाँ आप उसे वास्तव में देख सकें; एक self-hosted ntfy server उसी cron entry से एक-लाइन का curl लेता है और विफलता होने वाली रात ही आपके फोन पर सूचना भेज देता है। रिस्टोर करने के लिए उसी स्क्रिप्ट का restore के साथ उपयोग करें, जो स्नैपशॉट की सूची दिखाता है और आपको यह चुनने देता है कि क्या वापस लाना है। जिस बैकअप को आपने कभी रिस्टोर करके टेस्ट नहीं किया है, वह केवल एक उम्मीद है, बैकअप नहीं; एक बार किसी स्क्रैच VPS पर इसका ड्राई रन जरूर करें।

चरण 10, निर्धारित समय पर अपडेट करना

mailcow अपने स्वयं के script के माध्यम से अपडेट होता है, जो नया code pull करता है, mailcow.conf को migrate करता है, images को prefetch करता है और containers को इस क्रम में restart करता है:

cd /opt/mailcow-dockerized
sudo ./update.sh --check   # reports whether an update exists, changes nothing
sudo ./update.sh           # applies it

सबसे पहले backup लें (चरण 9), क्योंकि schema migration को वापस पलटना कठिन होता है। अपडेट अक्सर आते रहते हैं और इनमें internet-facing daemons के लिए security fixes शामिल होते हैं, इसलिए mail server को महीनों तक पुराना न रहने दें। यदि कोई अपडेट किसी container को unhealthy छोड़ देता है, तो sudo docker compose logs --tail=50 <service>-mailcow उस daemon का नाम बताता है जो वापस start होने में विफल रहा।

Hardening पर एक नोट

mailcow अपनी खुद की netfilter service (netfilter-mailcow) चलाता है जो mail और webmail ports पर हमला करने वाले IPs को ban कर देती है, इसलिए mail का पक्ष पहले से ही सुरक्षित है। यह host पर मौजूद SSH को कवर नहीं करता है, जो अभी भी exposed है और उस पर brute-force हमले होते रहते हैं। इस build को SSH auth log को monitor करने वाले Fail2ban और केवल key-based login के साथ उपयोग करें। mailcow admin UI को एक मजबूत password के पीछे रखें और आदर्श रूप से, इसे public internet से दूर या VPN के पीछे रखें।

विफलता के प्रकार (Failure modes) और सटीक स्ट्रिंग्स

मेल कतार (queue) में फँस जाते हैं और डिलीवर नहीं होते। sudo docker compose exec postfix-mailcow postqueue -p चलाएँ, या एडमिन UI की मेल कतार देखें; प्रविष्टियाँ Postfix द्वारा बाउंस किए जाने से पहले पाँच दिनों तक deferred स्थिति में रहती हैं, और यह त्रुटि दिखाती हैं:

status=deferred (connect to gmail-smtp-in.l.google.com[142.250.x.x]:25: Connection timed out)

यह लगभग हमेशा आपके प्रदाता (provider) द्वारा आउटबाउंड पोर्ट 25 को ब्लॉक किए जाने के कारण होता है (चरण 1)। आपके स्वयं के होस्ट फायरवॉल में आउटबाउंड नियम भी यही टाइमआउट उत्पन्न करता है, इसलिए पहले उसे जाँच लें; यदि होस्ट सही है, तो कोई भी कॉन्फ़िगरेशन इसे ठीक नहीं करेगा, सपोर्ट टिकट खोलें। यह DNS या TLS की समस्या नहीं है; इसका मुख्य संकेत पोर्ट 25 पर रिमोट MX के विरुद्ध timed out शब्द का आना है।

Gmail हर चीज़ को स्पैम के रूप में चिह्नित करता है, या उसे बाउंस कर देता है। Gmail में संदेश खोलें, "Show original" पर क्लिक करें, और ऑथेंटिकेशन परिणाम पढ़ें। dkim=fail या dkim=none का मतलब है कि आपका dkim._domainkey TXT रिकॉर्ड गायब है, गलत है, या अभी तक प्रोपेगेट नहीं हुआ है। ARC/DKIM पेज पर जो दिखाया गया है उसे ठीक वैसा ही पुनः प्रकाशित करें और TTL समाप्त होने तक प्रतीक्षा करें। spf=fail का मतलब है कि SPF/MX रिकॉर्ड आपके IP को कवर नहीं करते हैं। अलाइनमेंट सबसे महत्वपूर्ण है; एक भी विफल चेक स्पैम में जाने के लिए पर्याप्त है।

कनेक्ट करने पर बड़े प्रदाताओं द्वारा अस्वीकार कर दिया जाना। बाउंस संदेश या Postfix लॉग में Gmail का PTR रिजेक्शन दिखाई देता है:

550-5.7.25 [10.0.0.10] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match
550 5.7.25 the sending IP. As a policy, Gmail does not accept messages from IPs
550 5.7.25 with missing PTR records.

550 5.7.25 कोड का मतलब है कि रिवर्स DNS गायब है या मेल नहीं खाता है। प्रदाता के पास अपने IP के लिए PTR को mail.example.com पर सेट करें (चरण 2)। फॉरवर्ड (A) और रिवर्स (PTR) रिकॉर्ड एक समान होने चाहिए, और दोनों में वही होस्टनाम होना चाहिए जिसके साथ mailcow अन्य सर्वरों से संपर्क करता है।

ब्राउज़र एक सर्टिफिकेट चेतावनी दिखाता है जो कभी नहीं हटती। acme-mailcow कंटेनर वास्तविक सर्टिफिकेट प्राप्त करने में विफल रहा। इसका लॉग देखें:

sudo docker compose logs acme-mailcow | tail -n 40

Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. जैसी लाइन या चैलेंज विफलता का मतलब है कि पोर्ट 80 इंटरनेट से पहुँच योग्य नहीं है, या A रिकॉर्ड इस सर्वर की ओर इशारा नहीं कर रहा है। यदि आपने AAAA रिकॉर्ड प्रकाशित किया है, तो उसे भी जाँचें: mailcow पहले AAAA रिकॉर्ड के विरुद्ध सत्यापन करता है और यदि वह मौजूद हो तो A चेक को छोड़ देता है। इसलिए, गलत AAAA रिकॉर्ड या IPv6 पाथ जो पोर्ट 80 तक नहीं पहुँच सकता, सही A रिकॉर्ड होने पर भी सत्यापन को विफल कर देगा। पुष्टि करें कि mail.example.com इस बॉक्स पर रिज़ॉल्व होता है, किसी भी होस्ट फायरवॉल के माध्यम से 80 और 443 पोर्ट खोलें, और सुनिश्चित करें कि कोई अन्य सेवा इन पोर्ट्स का उपयोग नहीं कर रही है। कारण ठीक करने के बाद, एक घंटे के बैक-ऑफ का इंतज़ार करने के बजाय sudo docker compose restart acme-mailcow के साथ क्लाइंट को रीस्टार्ट करें।

FAQ

क्या खुद का ईमेल सर्वर होस्ट करना वास्तव में फायदेमंद है?

यदि आप डेटा का स्वामित्व, असीमित aliases और पूर्ण नियंत्रण चाहते हैं, तो हाँ, mailcow आपको एक VPS की कीमत पर एक प्रोफेशनल स्टैक प्रदान करता है। लेकिन ईमेल की deliverability एक निरंतर चलने वाला काम है: IP reputation, DNS alignment और blocklist की निगरानी कभी पूरी तरह समाप्त नहीं होती। किसी ऐसे mission-critical व्यावसायिक पते के लिए जहाँ किसी के spam folder में एक दिन भी ईमेल जाने से आपको नुकसान हो सकता है, एक managed provider का उपयोग करना ही व्यावहारिक निर्णय है। यदि आप सुविधा से अधिक नियंत्रण को महत्व देते हैं और वास्तव में उसका रखरखाव करेंगे, तभी self-hosting करें। यदि आप वास्तव में केवल अपना डेटा किसी और के सर्वर से हटाना चाहते हैं, न कि विशेष रूप से ईमेल, तो किसी ऐसी सेवा से शुरुआत करें जिसमें किसी और का हस्तक्षेप न हो: एक फोटो लाइब्रेरी में deliverability की कोई समस्या नहीं होती है, और हमारी PhotoPrism और Immich तुलना उसी प्रकार के VPS पर इसके लिए आवश्यक RAM और backup commands के बारे में जानकारी देती है।

मुझे कैसे पता चलेगा कि outbound port 25 ब्लॉक है?

सर्वर से nc -vz -w 5 gmail-smtp-in.l.google.com 25 चलाएँ। "succeeded!" का अर्थ है कि यह खुला है; पॉज़ के बाद timed out का अर्थ है कि पोर्ट ब्लॉक है, और यदि आपके पास कोई outbound firewall नियम नहीं है, तो यह आपके प्रदाता की ओर से है। यह सबसे आम कारण है कि एक self-hosted सर्वर ईमेल प्राप्त तो कर सकता है लेकिन भेज नहीं सकता, और प्रदाता द्वारा ब्लॉक किए जाने का एकमात्र समाधान प्रदाता से ही पोर्ट खुलवाना है, कोई भी local setting इसे नहीं बदल सकती।

मेरा ईमेल अभी भी Gmail के spam folder में क्यों जाता है?

इसका कारण लगभग हमेशा एक टूटी हुई authentication chain होती है। Gmail में "Show original" का उपयोग करें और spf=pass, dkim=pass, और dmarc=pass की जाँच करें। एक dkim=fail का अर्थ है कि dkim._domainkey TXT record गायब है या गलत है; PTR mismatch या बिना किसी sending history वाला नया IP भी नुकसान पहुँचाता है। पहले mail-tester.com पर 10/10 स्कोर प्राप्त करें, फिर IP को धीरे-धीरे warm up करें, पहले दिन ही भारी मात्रा में ईमेल भेजने के बजाय प्रतिदिन कुछ संदेशों से शुरुआत करें।

मुझे वास्तव में किसका बैकअप लेने की आवश्यकता है?

backup_and_restore.sh backup all चलाएँ और पूरे सेट को सर्वर से बाहर रखें। यह vmail (मेलबॉक्स), crypt (उन्हें डिक्रिप्ट करने वाली कुंजियाँ), MariaDB डेटाबेस (डोमेन, उपयोगकर्ता, aliases, सेटिंग्स), Redis, Rspamd का सीखा हुआ डेटा और Postfix queue को कैप्चर करता है। crypt वॉल्यूम वह है जिसे लोग अनदेखा कर देते हैं, इसके बिना vmail बैकअप केवल अपठनीय ciphertext है। कम से कम एक बार किसी अन्य सर्वर पर restore का परीक्षण अवश्य करें।

क्या मैं 2 GB VPS पर mailcow चला सकता हूँ?

आराम से नहीं। generate_config.sh लगभग 2.5 GiB से कम मेमोरी होने पर ClamAV को disable करने का विकल्प देता है, और ClamAV बंद होने पर भी Rspamd, Dovecot, MariaDB और बाकी स्टैक मेमोरी के लिए प्रतिस्पर्धा करते हैं, इसलिए किसी भी वास्तविक load के तहत आप swap और OOM kills का सामना करेंगे। एक स्थिर single-user इंस्टॉलेशन के लिए 6 GiB RAM और 1 GiB swap को न्यूनतम आधार मानें, और जैसे ही एक-दो से अधिक लोग इस पर निर्भर हों, इसे 8 GiB पर ले जाएँ।