Self-hosted apps से email कैसे भेजें: आसान तरीका

Self-hosted apps को mail भेजने के लिए क्या चाहिए

Self-hosted apps से mail भेजने के लिए आपको mail server की आवश्यकता नहीं है। आपको एक relay की आवश्यकता है: एक authenticated SMTP account, जिसे host पर एक बार configure किया जाता है, और box पर मौजूद हर app अपना outgoing mail उसी को सौंपता है। Mailbox चलाना एक कठिन समस्या है, और यह एक अलग समस्या है।

Mail प्राप्त करने का अर्थ है port 25 पर पूरी internet से connections स्वीकार करना, spam filter करना, mailbox को store और backup करना, और जब तक server मौजूद है तब तक IP reputation की रक्षा करना। वह काम वास्तव में कठिन हो गया है। Mail भेजने का अर्थ है password reset, signup confirmation, "backup failed" alert, और forum reply notification। ये छोटे, कम volume वाले होते हैं और एक बार में एक भेजे जाते हैं। एक relay इन्हें संभाल लेता है, और इसे set up करने में एक दोपहर का समय लगता है।

तय करें कि आप वास्तव में इन दोनों में से किस समस्या को हल करने का प्रयास कर रहे हैं। क्या अपना खुद का mailbox चलाना अभी भी सार्थक है एक वास्तविक प्रश्न है जिसका एक वास्तविक उत्तर है, और अधिकांश लोगों के लिए उत्तर 'नहीं' है। यदि आपका उत्तर 'हाँ' है, तो VPS पर एक पूर्ण Mailcow mail server ही सही रास्ता है। दूसरा हिस्सा, यानी mail भेजना, वह है जिसकी लगभग सभी को आवश्यकता होती है और जिसकी योजना लगभग कोई नहीं बनाता।

सबसे पहले दो शब्द। SMTP (simple mail transfer protocol) वह protocol है जिसका उपयोग इसका हर हिस्सा करता है। एक relay, जिसे smarthost भी कहा जाता है, एक ऐसा server है जो आपके authenticated mail को स्वीकार करता है और उसे अपने स्वयं के addresses और अपनी स्वयं की reputation का उपयोग करके आगे पहुँचाता है।

आपका VPS पोर्ट 25 पर मेल डिलीवर क्यों नहीं कर सकता

लगभग हर VPS प्रदाता डिफ़ॉल्ट रूप से आउटबाउंड TCP पोर्ट 25 को ब्लॉक करता है। पोर्ट 25 वह पोर्ट है जिसका उपयोग मेल सर्वर एक-दूसरे तक पहुँचने के लिए करते हैं, इसलिए यदि आउटबाउंड 25 खुला हो और VPS हैक हो जाए, तो वह सीधे हर प्राप्तकर्ता मेल सर्वर पर स्पैम भेज सकता है। प्रदाता इन पैकेटों को अस्वीकार करने के बजाय ड्रॉप कर देते हैं, यही कारण है कि इसका लक्षण एक ऐसा कनेक्शन है जो हैंग हो जाता है और फिर टाइम आउट हो जाता है, न कि कोई त्रुटि।

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

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

यदि पहली कमांड पूरे पाँच सेकंड तक रुकी रहती है जबकि दूसरी तुरंत उत्तर देती है, तो ब्लॉक की पुष्टि हो जाती है। कुछ प्रदाता खाता समीक्षा के बाद इसे हटा देते हैं। अधिकांश ऐसा नहीं करते हैं।

ब्लॉक रिले का उपयोग करने का मुख्य कारण नहीं है। पोर्ट 25 खुला होने पर भी, एक नए VPS पते से सीधे भेजा गया मेल स्पैम में चला जाता है या उसे सीधे अस्वीकार कर दिया जाता है, क्योंकि उस पते का कोई भेजने का इतिहास नहीं होता है और वह ऐसी रेंज में होता है जिसे प्राप्तकर्ता होस्टिंग स्पेस मानते हैं। Google के प्रेषक मार्गदर्शन के लिए भेजने वाले IP के लिए वैध फॉरवर्ड और रिवर्स DNS की आवश्यकता होती है, और कई VPS पतों में एक सामान्य PTR (पॉइंटर) रिकॉर्ड होता है जिसे आप बदल नहीं सकते। एक रिले आपको ऐसे पते देता है जिनका पहले से ही एक इतिहास होता है।

सबमिशन पोर्ट बाहर निकलने का रास्ता हैं। पोर्ट 587 STARTTLS को ले जाता है, जहाँ सत्र सादे टेक्स्ट में शुरू होता है और अपग्रेड किया जाता है। पोर्ट 465 इम्प्लिसिट TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) को ले जाता है, जहाँ सत्र पहले बाइट से ही एन्क्रिप्टेड होता है। दोनों प्रमाणित क्लाइंट्स के लिए हैं, दोनों VPS नेटवर्क पर खुले हैं, और आपका रिले कम से कम एक का समर्थन करता है।

एक relay और एक sending subdomain चुनें

कई transactional mail providers उपलब्ध हैं और वे सभी एक ही कार्य करते हैं। उनका मूल्यांकन इन चार बिंदुओं के आधार पर करें:

• SMTP AUTH के साथ एक submission port, जैसे 587 या 465
• केवल उनके domain के बजाय, आपके अपने domain और selector के साथ DKIM signing
• bounce और complaint डेटा जिसे आप dashboard या webhook के माध्यम से पढ़ सकें
• एक ऐसा tier जो आपके volume के अनुकूल हो। अगस्त 2026 तक, कई providers अभी भी प्रति माह कुछ हजार संदेश मुफ्त में भेजने की सुविधा देते हैं। ये शर्तें अक्सर बदलती रहती हैं, इसलिए किसी blog post के बजाय उनके वर्तमान pricing page को देखें।

App mail को एक subdomain से भेजें। example.com के बजाय notify.example.com जैसा कुछ उपयोग करें। प्राप्तकर्ता domain के आधार पर reputation तय करते हैं, इसलिए आपके apps से भेजा गया कोई खराब mail उस domain को प्रभावित नहीं करेगा जहाँ से आपके invoices और टीम के mail आते हैं। सीमाओं के प्रति ईमानदार रहें: कुछ प्राप्तकर्ता subdomain के signals को मुख्य organisational domain तक जोड़ देते हैं, इसलिए subdomain नुकसान को पूरी तरह रोकने के बजाय उसे केवल कम करता है।

हर self-hosted ऐप के लिए relay को एक बार कॉन्फ़िगर करें

आकर्षक तरीका यह है कि प्रत्येक ऐप के सेटिंग पेज पर जाएं और SMTP होस्ट, यूजरनेम और पासवर्ड पेस्ट कर दें। Nextcloud, फोरम, Grafana, Vaultwarden और uptime मॉनिटर, इन सभी में यह फॉर्म होता है। ऐसा करने पर क्रेडेंशियल छह अलग-अलग जगहों पर, छह अलग-अलग फॉर्मेट में आ जाते हैं, जिनमें से कई ऐसे डेटाबेस में होते हैं जिन्हें आप कॉन्फ़िगरेशन के बजाय डेटा के रूप में बैकअप लेते हैं। जब आप पासवर्ड बदलते हैं, तो आपको उनमें से पांच को अपडेट करना होगा। छठा काम करना बंद कर देता है, और वह भी चुपचाप, क्योंकि अधिकांश ऐप्स SMTP त्रुटि को सर्वर साइड पर लॉग करते हैं और यूजर को अभी भी सफलता का पेज दिखाते हैं।

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

msmtp एक sendmail-संगत क्लाइंट है जिसमें कोई daemon नहीं होता। यह कनेक्ट होता है, भेजता है, और बंद हो जाता है। इसमें queuing नहीं होती, इसलिए यदि relay तक नहीं पहुँचा जा सकता है तो संदेश खो जाता है और कॉलिंग ऐप को non-zero एग्जिट स्टेटस मिलता है।

सैटेलाइट के रूप में कॉन्फ़िगर किया गया Postfix एक पूर्ण mail transfer agent है जिसमें एक वास्तविक queue होती है। यह संदेश को तुरंत स्वीकार करता है, विफलता पर दिनों तक पुनः प्रयास करता है, और relay क्रेडेंशियल को केवल root द्वारा एक्सेस की जा सकने वाली फाइल में रखता है। इसका उपयोग तब करें जब relay आउटेज के दौरान अलर्ट खोना मायने रखता है, या जब कई ऐप्स अलग-अलग सिस्टम यूजर्स के रूप में चलते हैं।

msmtp, छोटा विकल्प

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta, /usr/sbin/sendmail सिमलिंक को इंस्टॉल करता है, इसलिए जो कुछ भी sendmail को कॉल करता है, वह यह जाने बिना कि यह मौजूद है, msmtp तक पहुँच जाता है।

/etc/msmtprc लिखें:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on हमेशा एक From हेडर सेट करता है और किसी भी मौजूदा हेडर को ओवरराइड करता है, इसलिए यह ऐप द्वारा उत्पन्न किसी भी चीज़ को from के पते से बदल देता है। इसके बिना, एक cron जॉब root@your-hostname के रूप में भेजता है, और relay इसे अस्वीकार कर देता है क्योंकि यह वह पता नहीं है जिसे आपने सत्यापित किया है। syslog on लॉग को syslog के माध्यम से भेजता है, इसलिए आप इसे journalctl -t msmtp के साथ पढ़ते हैं। एक साझा logfile पथ विकल्प है, और इसे भेजने वाले प्रत्येक यूजर के लिए राइट परमिशन की आवश्यकता होती है, जो मल्टी-यूजर बॉक्स पर एक समस्या है।

परमिशन खुद सेट करें। msmtp प्रति-यूजर कॉन्फ़िगरेशन (~/.msmtprc) पर परमिशन लागू करता है, जहाँ यह contains secrets and therefore must have no more than user read/write permissions के साथ चलने से इनकार कर देता है। यह /etc/msmtprc पर कुछ भी लागू नहीं करता है, क्योंकि यदि वह फाइल पढ़ने योग्य है तो यह बस उसे लोड कर लेता है।

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v पूरी SMTP बातचीत को प्रिंट करता है, इसलिए आप relay से प्रत्येक उत्तर देखते हैं। एक सफल सेंड संदेश को स्वीकार करने वाले 250 उत्तर के साथ समाप्त होता है। एक authentication failed लाइन का मतलब है कि यूजरनेम या पासवर्ड गलत है, या relay अकाउंट पासवर्ड के स्थान पर API की की अपेक्षा करता है।

अब समस्या यह है, और यही कारण है कि बहुत से लोग Postfix पर चले जाते हैं। मोड 600 और ओनर root के साथ, केवल root ही भेज सकता है। www-data के रूप में चलने वाला ऐप फाइल को नहीं पढ़ सकता, msmtp इसे छोड़ देता है, और ऐप डिफ़ॉल्ट अकाउंट न मिलने की त्रुटि के साथ विफल हो जाता है। इसका समाधान एक ग्रुप है:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

साफ शब्दों में इसका मतलब यह है: mail ग्रुप का प्रत्येक सदस्य relay पासवर्ड पढ़ सकता है और उस बॉक्स से आपके डोमेन के रूप में मेल भेज सकता है। एक VPS पर जिसे आप अकेले मैनेज करते हैं, यह स्वीकार्य है। जहाँ आपके द्वारा न लिखे गए कई ऐप्स अलग-अलग यूजर्स के रूप में चलते हैं, वहाँ यह स्वीकार्य नहीं है, और Postfix बेहतर उत्तर है क्योंकि वे ऐप्स कभी क्रेडेंशियल नहीं देखते हैं।

सैटेलाइट के रूप में Postfix

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules वैकल्पिक नहीं है। इसके बिना Postfix warning: SASL authentication failure: No worthy mechs found लॉग करता है, क्योंकि PLAIN और LOGIN मैकेनिज्म लाइब्रेरी /usr/lib/sasl2 के तहत इंस्टॉल नहीं होती हैं।

बाकी को postconf -e के साथ सेट करें, जो /etc/postfix/main.cf को इन-प्लेस एडिट करता है:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

relay होस्टनाम के चारों ओर वर्गाकार कोष्ठक Postfix को उस नाम के लिए MX रिकॉर्ड खोजने से रोकते हैं और इसे सीधे नाम से कनेक्ट करते हैं। कुछ relay होस्टनाम MX रिकॉर्ड प्रकाशित करते हैं जो कहीं और इंगित करते हैं, और कोष्ठक के बिना आपका मेल उन्हें गलत सर्वर पर ले जाता है।

smtp_tls_security_level = encrypt TLS को अनिवार्य बनाता है, इसलिए संदेश कभी भी cleartext में नहीं भेजा जाता है। यह सर्टिफिकेट को सत्यापित नहीं करता है। Postfix का अपना डॉक्यूमेंटेशन इस बारे में स्पष्ट है: उस स्तर पर, डिलीवरी तब भी जारी रहती है जब सर्वर सर्टिफिकेट अविश्वसनीय हो या गलत नाम हो। यदि आप चाहते हैं कि सर्टिफिकेट की जाँच हो, तो verify या secure का उपयोग करें और smtp_tls_CAfile को सेट रखें।

क्रेडेंशियल एक root-ओनली फाइल में जाता है:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

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

ऐप्स अभी भी अपने मेल को root@hostname के रूप में संबोधित करते हैं। सेंडर को फिर से लिखें:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

एक regexp: टेबल सीधे पढ़ी जाती है, इसलिए इसे postmap की आवश्यकता नहीं है। अब प्रत्येक संदेश एक ही लिफाफा सेंडर और एक ही From हेडर के साथ निकलता है, जो relay चाहता है। इसकी कीमत यह है कि सभी उत्तर एक ही जगह आते हैं, इसलिए प्रत्येक ऐप के अंदर एक Reply-To हेडर सेट करें जहाँ उत्तर किसी व्यक्ति तक पहुँचने चाहिए।

एक टेस्ट भेजें और लॉग पढ़ें:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

एक डिलीवर किया गया संदेश status=sent लॉग करता है, जिसके बाद कोष्ठक में relay का अपना उत्तर होता है। कुछ और होने पर कारण का नाम आता है। status=deferred के साथ Connection timed out का मतलब है कि कुछ अभी भी पोर्ट 25 पर पॉइंट कर रहा है। Host or domain name not found. Name service error for name=smtp.relay.example type=A का मतलब है कि relay होस्टनाम गलत है या बॉक्स पर DNS टूटा हुआ है। mailq सूचीबद्ध करता है कि क्या अटका हुआ है और sudo postqueue -f इसे अभी पुनः प्रयास करता है।

Docker containers से host relay तक पहुँचना

एक container host के sendmail को call नहीं कर सकता, क्योंकि binary image में नहीं होती और queue साझा नहीं होती है। containers को इसके बजाय एक network target दें। Postfix को Docker bridge address पर listen करने के लिए सेट किया जा सकता है।

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

इस command को copy करने के बजाय उस पहली command से अपना bridge address पढ़ें, क्योंकि एक Compose project अपने अलग subnet पर अपना network बनाता है और docker network inspect <name> उसे print करता है। यहाँ restart का उपयोग करें, न कि reload का: Postfix के documentation के अनुसार inet_interfaces बदलने के बाद आपको service को stop और start करना होगा, केवल reload करने से बदलाव लागू नहीं होंगे। इसके बाद प्रत्येक app को SMTP host 172.17.0.1, port 25, बिना authentication और बिना TLS के उपयोग करना होगा, क्योंकि यह traffic कभी भी host से बाहर नहीं जाता है। यदि आपकी services Compose network पर स्थित हैं, तो VPS पर Docker Compose चलाना यह बताता है कि वह subnet कहाँ से आता है।

यह वह चरण है जो आपको नुकसान पहुँचा सकता है। सार्वजनिक address पर एक विस्तृत mynetworks के साथ listen करने वाला Postfix एक open relay होता है: अनजान लोग आपके relay account के माध्यम से mail भेजते हैं, provider उसे suspend कर देता है, और आपके domain की reputation महीनों तक खराब रहती है। हर बदलाव के बाद दोनों पक्षों की जाँच करें।

ss -tlnp | grep ':25'

output में केवल loopback address और bridge address ही दिखना चाहिए। किसी अन्य machine से, nc -vz your.server.ip 25 विफल (fail) होना चाहिए।

भेजने वाले डोमेन के लिए SPF, DKIM और DMARC

पहली बार ईमेल भेजने से पहले तीनों रिकॉर्ड पब्लिश करें। ये मुफ्त हैं, DNS आधारित हैं, और प्राप्तकर्ता सबसे पहले इन्हीं की जाँच करते हैं।

SPF (sender policy framework) यह सूची बनाता है कि कौन आपके डोमेन को envelope sender में उपयोग कर सकता है। इसे भेजने वाले सबडोमेन पर पब्लिश करें:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

अपने relay के सेटअप पेज से include: मान कॉपी करें, क्योंकि यदि कोई include resolve नहीं होता है, तो यह pass के बजाय permanent error देता है। SPF मूल्यांकन दस DNS-querying मैकेनिज्म के बाद रुक जाता है और permerror देता है, जिसे प्राप्तकर्ता failure मानते हैं, इसलिए includes की संख्या कम रखें। प्रति नाम केवल एक v=spf1 रिकॉर्ड पब्लिश करें: दो रिकॉर्ड होना भी एक permerror है।

DKIM (domainkeys identified mail) प्रत्येक संदेश को एक private key से साइन करता है जो relay के पास होती है, और प्राप्तकर्ता DNS से मेल खाने वाली public key प्राप्त करते हैं। आपका relay आपको पब्लिश करने के लिए एक selector और एक TXT रिकॉर्ड या CNAME देता है:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM, SPF से अधिक महत्वपूर्ण है, क्योंकि DKIM फॉरवर्डिंग के दौरान भी सुरक्षित रहता है। जब कोई मेलिंग लिस्ट या .forward नियम आपके संदेश को आगे भेजता है, तो वह फॉरवर्डर के IP एड्रेस से आता है, जिससे SPF फेल हो जाता है जबकि signature अभी भी verify हो जाता है।

DMARC (domain-based message authentication, reporting and conformance) प्राप्तकर्ताओं को बताता है कि जब कोई भी चेक मेल न खाए तो क्या करना है, और उनसे रिपोर्ट वापस भेजने के लिए कहता है। इसे संगठनात्मक डोमेन पर पब्लिश करें:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

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

जाँचें कि दुनिया क्या देख रही है, न कि आपका DNS पैनल क्या दिखा रहा है:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

खाली आउटपुट का मतलब है कि रिकॉर्ड propagate नहीं हुआ है या नाम गलत है। पांच मिनट पहले ठीक किया गया रिकॉर्ड अपने पिछले TTL (time to live) की अवधि तक कैश में गलत रह सकता है, इसलिए किसी भी निष्कर्ष पर पहुँचने से पहले TTL की जाँच करें।

From और Return-Path को align रखें

हर message में दो sender addresses होते हैं और उनकी जाँच अलग-अलग तरीके से की जाती है। Envelope sender को SMTP MAIL FROM command में दिया जाता है और यह deliver किए गए message में Return-Path के रूप में दिखाई देता है। Header From वह address है जिसे पाठक देखता है।

SPF, envelope sender के domain की जाँच connecting IP address के आधार पर करता है। DKIM उस domain की रिपोर्ट करता है जिसने sign किया है, जिसे d= कहा जाता है। DMARC केवल तभी pass होता है जब उन दो domains में से कम से कम एक, header From में मौजूद domain के साथ align हो। Relaxed alignment (adkim=r, aspf=r, जो कि default है) के साथ, एक subdomain मान्य होता है, इसलिए notify.example.com पर मौजूद envelope sender, example.com पर मौजूद header From के साथ align हो जाता है। Strict alignment के साथ ऐसा नहीं होता है।

व्यावहारिक नियम संक्षिप्त है: header From और envelope sender को एक ही domain पर रखें, और यह समस्या कभी उत्पन्न ही नहीं होगी। msmtp में set_from_header on और Postfix में sender_canonical_maps बिल्कुल यही काम करते हैं।

Deliver किए गए message में verdict पढ़ें। Gmail में, "Show original" वह header दिखाता है जिसे receiver ने लिखा है:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

वहाँ तीनों जाँचें pass हो जाती हैं। यदि कुछ और दिखाई दे, तो वह उस जाँच का नाम बताता है जो fail हुई है और आमतौर पर उसका कारण भी, जो इस विषय पर आपको मिलने वाली सबसे तेज़ debugging जानकारी होगी।

बाउंस और शिकायतें, वॉल्यूम आने से पहले

बाउंस का अर्थ है कि रिसीवर आपके संदेश को स्वीकार करने से मना कर रहा है। हार्ड बाउंस स्थायी होता है, और Gmail इसे 550 5.1.1 The email account that you tried to reach does not exist के रूप में दर्शाता है। सॉफ्ट बाउंस अस्थायी होता है, जो फुल मेलबॉक्स या ग्रेलिस्टिंग के लिए 4xx कोड होता है, और रिले इसे अपने आप पुनः प्रयास (retry) करता है।

रिले आपके हार्ड बाउंस रेट को मापते हैं और उन अकाउंट्स को सस्पेंड कर देते हैं जो ऐसे ईमेल पतों पर मेल भेजते रहते हैं जो मौजूद ही नहीं हैं, क्योंकि यह पैटर्न खरीदी गई लिस्ट जैसा दिखता है। शिकायतें (complaints) अधिक महत्वपूर्ण होती हैं। शिकायत का अर्थ है कि किसी व्यक्ति ने स्पैम बटन दबाया है, और Google की सेंडर गाइडेंस (अगस्त 2026 में जाँची गई) सेंडर्स को Postmaster Tools में रिपोर्ट किए गए 0.30% स्पैम रेट से नीचे रहने के लिए कहती है, और 0.10% से नीचे रहने की सलाह देती है।

वॉल्यूम आने से पहले ये चार चीजें तैयार रखें:

• एक वेबहुक, या रिले की सप्रेशन लिस्ट की साप्ताहिक जांच, ताकि आप बाउंस को देख सकें
• एक From एड्रेस जो एक वास्तविक मेलबॉक्स हो जिसे कोई पढ़ता हो, और जहाँ रिप्लाई आने चाहिए वहाँ Reply-To सेट हो
• किसी भी एड्रेस को कहीं भी जोड़ने से पहले पुष्टि (confirmation), ताकि आप कभी भी ऐसे एड्रेस पर मेल न भेजें जिसे उसके मालिक ने दर्ज न किया हो
• मेल ट्रिगर करने वाले किसी भी फॉर्म पर रेट लिमिट

ये अंतिम दो बिंदु वे हैं जहाँ self-hosted apps सबसे पहले विफल होते हैं। एक असुरक्षित साइनअप फॉर्म किसी को भी किसी अजनबी का एड्रेस टाइप करने देता है, आपका सर्वर कन्फर्मेशन भेजता है, और वह अजनबी इसे स्पैम के रूप में मार्क कर देता है। अपने साइनअप फॉर्म पर सब्सक्रिप्शन बॉम्बिंग रोकना एक डिलीवरेबिलिटी का काम है, उतना ही जितना कि यह दुरुपयोग (abuse) को रोकने का है।

बल्क मेल को इस रास्ते से दूर रखें। न्यूज़लेटर्स को लिस्ट मैनेजमेंट और अनसब्सक्राइब हेडर की आवश्यकता होती है जो ट्रांजेक्शनल मेल में कभी नहीं होते, इसलिए उन्हें एक self-hosted Listmonk instance के माध्यम से चलाएं, जो अपने स्वयं के सबडोमेन और अपनी प्रतिष्ठा (reputation) पर हो। एक self-hosted forum से आने वाली नोटिफिकेशन मेल इन दोनों के बीच में आती है, जो आकार में ट्रांजेक्शनल है और वॉल्यूम में बल्क, और आमतौर पर यही वह पहली चीज है जो आपको दिखाती है कि आपका सेटअप टिकेगा या नहीं।

संदर्भ के लिए, Gmail के बल्क सेंडर नियम Gmail एड्रेस पर प्रतिदिन 5,000 से अधिक संदेश भेजने पर लागू होते हैं और मार्केटिंग मेल पर SPF, DKIM, DMARC और वन-क्लिक अनसब्सक्राइब की आवश्यकता होती है। अधिकांश self-hosted apps कभी उस सीमा तक नहीं पहुँचते। प्रमाणीकरण (authentication) वाला हिस्सा अब हर सेंडर से अपेक्षित है, चाहे वॉल्यूम कुछ भी हो।

भरोसा करने से पहले परीक्षण करें

swaks इसके लिए उपयुक्त टूल है। यह SMTP का उपयोग करता है और पूरी बातचीत को प्रिंट करता है, जिससे आप देख सकते हैं कि कौन सा चरण विफल हुआ।

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

यह सीधे relay के विरुद्ध credentials का परीक्षण करता है। उस पथ का परीक्षण करने के लिए जिसका उपयोग आपके apps वास्तव में करते हैं, इसे host relay की ओर निर्देशित करें:

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

फिर सर्वर से, वास्तविक ईमेल के साथ, end-to-end परिणाम की जाँच करें। इनमें से किसी भी बात को केवल config files से सिद्ध नहीं किया जा सकता है, इसलिए स्वयं चलाकर देखें:

• mail-tester.com जैसी scoring service पर भेजें, जो आपके SPF, DKIM, DMARC और message content को पढ़ती है और आपको score के पीछे के कारण बताती है
• उन दो providers में से प्रत्येक पर एक mailbox पर भेजें जहाँ आपके users वास्तव में हैं, और raw message में Authentication-Results को पढ़ें
• जब alignment का परिणाम स्पष्ट न हो, तो learndmarc.com के माध्यम से एक message को प्रोसेस करें
• app से ही send ट्रिगर करें, न कि केवल command line से, क्योंकि app ही वह है जो From header सेट करता है

अंत में एक ईमानदार चेतावनी। तीनों records के सही होने के बावजूद एक बिल्कुल नया domain कभी-कभी spam में चला जाता है, क्योंकि इसका कोई इतिहास नहीं होता और receivers उन domains के प्रति सतर्क रहते हैं जो पिछले सप्ताह ही दिखाई दिए हैं। छोटे स्तर से शुरुआत करें और वही mail भेजें जिसकी लोग अपेक्षा करते हैं। reputation वहीं से बनती है, और कोई भी configuration इस चरण को नहीं बदल सकता।

FAQ

मेरे VPS पर आउटबाउंड पोर्ट 25 ब्लॉक क्यों है?

लगभग हर प्रदाता डिफ़ॉल्ट रूप से आउटबाउंड TCP पोर्ट 25 को ब्लॉक करता है, क्योंकि इस पोर्ट के खुले होने पर एक breached सर्वर सीधे मेल सर्वर पर स्पैम भेज सकता है। पैकेट को रिफ्यूज करने के बजाय ड्रॉप कर दिया जाता है, इसलिए इसका लक्षण यह है कि कनेक्शन हैंग हो जाता है और फिर टाइम आउट हो जाता है, न कि कोई एरर मैसेज मिलता है। nc -vz -w 5 gmail-smtp-in.l.google.com 25 को nc -vz -w 5 smtp.relay.example 587 के साथ चलाकर इसकी पुष्टि करें: पहला कमांड हैंग हो जाएगा, जबकि दूसरा तुरंत उत्तर देगा। इसका समाधान ब्लॉक हटवाने का अनुरोध करना नहीं है। सबमिशन पोर्ट 587 या 465 पर एक रिले के माध्यम से मेल भेजें, जो खुले रहते हैं और ऑथेंटिकेटेड क्लाइंट्स के लिए ही बने हैं।

क्या मुझे केवल कुछ ऐप नोटिफिकेशन भेजने के लिए भी SPF, DKIM और DMARC की आवश्यकता है?

हाँ, और वॉल्यूम से इसमें कोई बदलाव नहीं आता। रिसीवर एक पासवर्ड रीसेट के लिए भी वही जांच लागू करते हैं जो पचास हजार संदेशों के अभियान के लिए करते हैं। SPF और DKIM के बिना आपका मेल ऑथेंटिकेटेड नहीं होता है, और Google के वर्तमान सेंडर गाइडेंस के अनुसार हर सेंडर के लिए इनमें से कम से कम एक का होना अनिवार्य है। DMARC के बिना आपको कोई रिपोर्ट नहीं मिलती, इसलिए समस्या का पहला संकेत तब मिलता है जब कोई यूजर कहता है कि उसे रीसेट लिंक कभी नहीं मिला। ये तीनों DNS रिकॉर्ड हैं, इनकी कोई लागत नहीं है, और इन्हें पब्लिश करने में लगभग दस मिनट लगते हैं।

क्या मुझे रिले क्लाइंट के रूप में msmtp का उपयोग करना चाहिए या Postfix का?

जब सर्वर का एडमिनिस्ट्रेशन एक व्यक्ति करता हो और रिले आउटेज के दौरान संदेश खो जाना स्वीकार्य हो, तब msmtp का उपयोग करें। यह बिना किसी डेमन के एक सिंगल कॉन्फ़िगरेशन फ़ाइल है, और चूंकि इसमें कोई क्यू (queue) नहीं होती, इसलिए रिले तक पहुँच न होने पर संदेश खो जाता है। जब आप ऐसी क्यू चाहते हैं जो दिनों तक रिट्राई करे, या जब कई ऐप्स अलग-अलग सिस्टम यूजर्स के रूप में चल रहे हों, तो Postfix को सैटेलाइट के रूप में उपयोग करें। Postfix रिले पासवर्ड को केवल-root वाली फ़ाइल में रखता है जिसे ऐप्स कभी नहीं पढ़ते, जबकि msmtp के लिए इसकी कॉन्फ़िगरेशन फ़ाइल को हर उस यूजर द्वारा पढ़ा जाना आवश्यक है जो मेल भेजता है।

मेरे ऐप का मेल इसलिए क्यों रिजेक्ट हो जाता है क्योंकि वह root से आता है?

क्रॉन जॉब्स और कई ऐप्स लोकल यूजर और होस्टनेम से सेंडर एड्रेस बनाते हैं, जिससे root@srv1.localdomain जैसा एड्रेस बनता है। यह वह एड्रेस नहीं है जिसे आपने रिले पर वेरीफाई किया है, इसलिए रिले सेंडर एड्रेस का नाम लेते हुए 553 या 554 रिप्लाई के साथ संदेश को रिजेक्ट कर देता है। इसे हर ऐप में ठीक करने के बजाय होस्ट लेवल पर ठीक करें: /etc/msmtprc में from एड्रेस के साथ set_from_header on का उपयोग करें, या Postfix में sender_canonical_classes = envelope_sender, header_sender के साथ sender_canonical_maps का उपयोग करें। यदि रिप्लाई किसी व्यक्ति तक पहुँचने की आवश्यकता हो, तो प्रत्येक ऐप के अंदर Reply-To सेट करें।

क्या ऐप मेल के लिए एक अलग सबडोमेन वास्तव में मेरे मुख्य डोमेन की सुरक्षा करता है?

आंशिक रूप से, और यह अभी भी करने योग्य है। रिसीवर प्रति डोमेन प्रतिष्ठा ट्रैक करते हैं, इसलिए notify.example.com के खिलाफ शिकायतें काफी हद तक notify.example.com तक ही सीमित रहती हैं जबकि आपका मुख्य डोमेन मेल डिलीवर करना जारी रखता है। इसकी सीमा वास्तविक है: कुछ रिसीवर सबडोमेन सिग्नल्स को संगठनात्मक डोमेन तक जोड़ देते हैं, और संगठनात्मक स्तर पर पब्लिश की गई DMARC पॉलिसी सबडोमेन पर भी लागू होती है जब तक कि आप अलग से sp= सेट न करें। सबडोमेन को गारंटी के बजाय डैमेज लिमिटेशन के रूप में देखें।