2026 সালে নিজের email host করা কি এখনও সার্থক?

সংক্ষিপ্ত উত্তর

2026 সালেও self-hosting email করা সার্থক, তবে কাজটি দুটি ভাগে ভাগ করতে হবে। নিজের VPS-এ নিজের email গ্রহণ করা কম ঝুঁকিপূর্ণ এবং এটি কাজ করে, কারণ আপনি গ্রহণকারী এবং কাউকে আপনাকে বিশ্বাস করতে হয় না। বড় mailbox provider-গুলো গ্রহণ করবে এমন email পাঠানো ভিন্ন কাজ। এটি এমন একটি IP address-এর reputation-এর ওপর নির্ভর করে, যা আপনি তৈরি করেন না; উত্তরাধিকারসূত্রে পান।

অভিজ্ঞ operator-রা বাস্তবে hybrid setup ব্যবহার করেন। তাদের নিজস্ব server-এ mailbox এবং archive থাকে। Outbound mail port 587-এ authenticated relay-এর মাধ্যমে পাঠানো হয়। দুই দিকেই full self-hosting এখনও কয়েকটি নির্দিষ্ট ক্ষেত্রে বেশি উপযোগী। এই পোস্টের শেষের দিকে সেই ক্ষেত্রগুলো আলোচনা করা হয়েছে।

নিজে email hosting-এর কঠিন দিক হলো deliverability

Mail server install করতে একটি weekend-এর কাজ লাগে। একটি আধুনিক stack একই compose file থেকে mail পাঠানোর জন্য SMTP (simple mail transfer protocol), mail পড়ার জন্য IMAP (internet message access protocol), spam filtering এবং webmail interface দেয়। VPS-এ Mailcow mail server install বিষয়গুলো বিস্তারিতভাবে দেখায়। Install প্রক্রিয়ার কোনো অংশই মূল কঠিন বিষয় নয়।

সমস্যা শুরু হয় যখন আপনার server এমন একটি company-চালিত machine-এর সঙ্গে connection খোলে, যে company আপনার সম্পর্কে আগে কখনও শোনেনি, এবং সেটিকে কারও inbox-এ একটি message রাখতে বলে। Receiver-এর সম্মতি দেওয়ার কোনো কারণ নেই। এটি বিভিন্ন signal দেখে সিদ্ধান্ত নেয়: connection করা IP address-এর reputation, আপনার domain-এর reputation, message authenticated কি না, এবং এর users আগে আপনার mail-এ কীভাবে প্রতিক্রিয়া জানিয়েছে। নতুন sender-এর কোনো history থাকে না। History না থাকাকে neutral হিসেবে গণনা করা হয় না। এটিকে risk হিসেবে গণনা করা হয়। তাই প্রথম message-গুলো spam folder-এ যায়, অথবা কোনো pattern তৈরি না হওয়া পর্যন্ত deferred থাকে।

আপনি refusal দেখতে পাবেন। Gmail এই ধরনের একটি permanent 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 ভিন্ন একটি rejection পাঠায়, যার শেষে একটি পরিবর্তনশীল 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).

অন্য কিছু দেখার আগে প্রথম digit পড়ুন। 4 দিয়ে শুরু হওয়া code temporary। তাই আপনার server message সংরক্ষণ করে এবং আবার চেষ্টা করে। 5 দিয়ে শুরু হওয়া code permanent। তাই message সঙ্গে সঙ্গে sender-এর কাছে bounce back করে। যে 4xx deferral কখনও clear হয় না, সেটি rate limit বা reputation limit হতে পারে এবং নিজে থেকেই resolve হতে পারে। 5xx হলো একটি সিদ্ধান্ত, এবং এটি resolve হবে না।

নতুন সার্ভারের mail কেন spam folder-এ যায়?

কারণ IP address-টি নতুন নয়। আপনি fresh address পান না। Provider-এর pool থেকে পুনর্ব্যবহৃত একটি address পান, এবং সেটির পূর্ববর্তী history-ও সঙ্গে আসে। আগের tenant spam পাঠিয়ে থাকলে, আপনি দ্বিতীয় mail পাঠানোর আগেই আপনার প্রথম mail প্রত্যাখ্যাত হতে পারে।

সার্ভার তৈরি করার আগে address-টি পরীক্ষা করুন। Public blocklist-গুলো DNS-এর মাধ্যমে ফল দেয়। এ ক্ষেত্রে address-এর চারটি octet উল্টো ক্রমে দিতে হয়:

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

কোনো ফলাফল না থাকলে address-টি তালিকাভুক্ত নয়। 127.0.0.0/8-এর মধ্যে কোনো ফলাফল থাকলে address-টি তালিকাভুক্ত, এবং শেষ octet-টি কোন list match করেছে তা জানায়। এই পরীক্ষায় একটি সমস্যা আছে: বড় public resolver-এর মাধ্যমে আসা query Spamhaus প্রত্যাখ্যান করে। তাই 8.8.8.8-এর মাধ্যমে করা একই lookup, প্রকৃত status যা-ই হোক, 127.255.255.254 ফেরত দেয়। এই code-এর অর্থ query প্রত্যাখ্যাত হয়েছে; address তালিকাভুক্ত নয়। নিজের server-এর resolver ব্যবহার করে query চালান, অথবা web lookup ব্যবহার করুন।

Clean result প্রয়োজনীয়, কিন্তু এটিই যথেষ্ট নয়। Listed নয়—এর অর্থ শুধু সম্প্রতি কেউ address-টির বিরুদ্ধে অভিযোগ করেনি। এতে কোনো ইতিবাচক reputation তৈরি হয় না। Mail inbox-এ পৌঁছানোর জন্য positive reputation প্রয়োজন। কয়েক সপ্তাহ ধরে অল্প পরিমাণে প্রাপকের প্রত্যাশিত mail পাঠিয়ে এই reputation অর্জন করতে হয়।

আপনার প্রতিবেশী address-গুলোর অবস্থাও গুরুত্বপূর্ণ। কারণ কিছু receiver একটি address নয়, পুরো network block-এর reputation মূল্যায়ন করে। একই /24 range-এর অন্য কোনো customer spam পাঠানো শুরু করলে, সেই সম্পর্কের কারণে আপনার mail delivery ধীর হতে পারে। এই block-level মূল্যায়নের কারণেই account holder কখনো না-পাঠানো traffic-এর জন্য abuse complaint VPS inbox-এ আসে: complaint-টি address range অনুসরণ করে।

শুরু করার আগে যা নিশ্চিত করবেন: port 25 এবং PTR record

Outbound TCP port 25 Internet-এ সবচেয়ে বেশি অপব্যবহৃত port। তাই অনেক hosting provider নতুন account-এ এটি ডিফল্টভাবে বন্ধ রাখে। কেউ অনুরোধ করলে এটি খুলে দেয়। কেউ account-এর বয়স ও payment history তৈরি হলে এটি খুলে দেয়। কেউ কখনোই এটি খোলে না। Provider-ভেদে policy আলাদা এবং সময়ের সঙ্গে তা পরিবর্তিত হয়। তাই এই post, পুরোনো forum thread বা কোনো provider-এর marketing page-কে বর্তমান তথ্য ধরে নেবেন না। টাকা দেওয়ার আগে জিজ্ঞাসা করুন এবং লিখিত উত্তর নিন।

Server থেকেই path পরীক্ষা করুন:

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

Path খোলা থাকলে এক সেকেন্ডের মধ্যে succeeded! দেখা যাবে। Path block করা থাকলে কোনো block-এর নাম উল্লেখ না করে কিছুক্ষণ অপেক্ষার পর timeout হবে। কারণ নীরবে বাদ দেওয়া packet দেখতে সাধারণ network সমস্যার মতোই লাগে।

দ্বিতীয় প্রয়োজন হলো PTR record, যাকে reverse DNS-ও বলা হয়। Receiver যে IP address থেকে connection পেয়েছে, সেটি নিয়ে PTR record lookup করে একটি name বের করে। এরপর সেই name lookup করে আবার একটি address বের করে। দুটি address এক হলে তাকে forward-confirmed reverse DNS বলা হয়। এটি একটি সহজ যাচাই যে connecting host সত্যিই তার দাবিকৃত মালিকের সঙ্গে যুক্ত।

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

প্রথমটির ফলাফল আপনার mail hostname হতে হবে। দ্বিতীয়টির ফলাফল হিসেবে শুরুতে ব্যবহৃত একই address ফিরে আসতে হবে। শুধু কোনো IP address-এর owner তার PTR record publish করতে পারে। তাই আপনার host এটি আপনার হয়ে set করে দেবে, অথবা control panel-এ সেট করার ব্যবস্থা দেবে। PTR record না থাকা, অথবা 203-0-113-5.static.example-isp.net-এর মতো generic record থাকা, একটি শক্তিশালী negative signal। কারণ প্রকৃত mail server-এর প্রায় সবসময়ই matching name থাকে, আর bulk spam source-এর ক্ষেত্রে তা প্রায়ই থাকে না।

আপনার host যদি IPv6-ও দেয় এবং আপনার server সেটি অগ্রাধিকার দেয়, তাহলে উপরের সব নিয়ম IPv6 address-এর ক্ষেত্রেও প্রযোজ্য। Gmail এই বিষয়ে আরও কঠোর। PTR record ছাড়া address থেকে IPv6 ব্যবহার করে mail পাঠালে এমন rejection আসতে পারে যে PTR record ও authentication সম্পর্কিত IPv6 sending guideline বার্তাটি পূরণ হয়নি। আপনি IPv6 PTR record set করতে না পারলে শুধু IPv4 ব্যবহার করে mail পাঠান। Postfix-এ IPv4 অগ্রাধিকার দিতে smtp_address_preference = ipv4 ব্যবহার করুন, অথবা IPv6 সম্পূর্ণ বন্ধ করতে inet_protocols = ipv4 ব্যবহার করুন।

যেকোনো host-কে করা তিনটি প্রশ্ন

1. নতুন account-এ outbound TCP port 25 খোলা থাকে কি? না থাকলে এটি খোলার নির্দিষ্ট process এবং timeline কী?
2. আমার IPv4 address এবং IPv6 address-এর PTR record কি আমি set করতে পারব? পারলে কোথা থেকে সেট করতে হবে?
3. আগের কোনো customer-এর কারণে আমার address blocklist-এ থাকলে আপনারা কি আমাকে অন্য address-এ স্থানান্তর করবেন?

কেনার আগে তিনটি প্রশ্নই করুন, পরে নয়। কোনো host প্রথম দুটি প্রশ্নের স্পষ্ট উত্তর দেয় এবং তৃতীয়টির উত্তর না দেয়, তবুও সেটি ব্যবহারযোগ্য হতে পারে। কারণ প্রথম দিনেই address পরীক্ষা করে প্রয়োজনে cancel করতে পারবেন। কোনো host যদি এই প্রশ্নগুলোর কোনো একটিরও লিখিত উত্তর দিতে না চায়, তাহলে সেখানে mail চালানো কেমন হবে সে সম্পর্কে তারা ইতিমধ্যেই আপনাকে জানিয়ে দিয়েছে।

SPF, DKIM এবং DMARC আসলে কী প্রমাণ করে

তিনটি DNS record প্রমাণ করে যে আপনার domain থেকে আসার দাবি করা mail সত্যিই আপনার domain থেকেই পাঠানো হয়েছে। প্রতিটি record একটি আলাদা প্রশ্নের উত্তর দেয়। তৃতীয়টি বুঝতে হলে প্রথম দুটি আগে বুঝতে হবে।

SPF (sender policy framework) হলো একটি TXT record, যেখানে আপনার domain-এর হয়ে কোন server mail পাঠাতে পারে তা উল্লেখ থাকে। Receiver এটি envelope sender-এর সঙ্গে মিলিয়ে দেখে। এটি SMTP MAIL FROM command-এ দেওয়া address। এটি আপনার reader যে From: header দেখেন, সেটি নয়।

DKIM (domainkeys identified mail) message header-এ একটি cryptographic signature যোগ করে। এই signature body এবং নির্বাচিত header-এর তালিকাকে অন্তর্ভুক্ত করে। এর সঙ্গে মেলা public key আপনার নির্ধারিত selector-এর অধীনে DNS-এ থাকে। এরপর যে কেউ যাচাই করতে পারে যে message-টি আপনার private key-এর অধিকারী পক্ষ থেকে এসেছে এবং পথে পরিবর্তিত হয়নি।

DMARC (domain-based message authentication, reporting and conformance) অন্য দুইটির ফল visible From: header-এর domain-এর সঙ্গে মিলিয়ে দেখে। এই মিল ব্যর্থ হলে receiver-কে কী করতে হবে, DMARC তা জানায়।

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। SPF pass করলেই DMARC pass হয় না। SPF অথবা DKIM pass করতে হবে, এবং যে domain pass করেছে সেটি From: header-এর domain-এর সঙ্গে একই হতে হবে। Relayed mail নীরবে এখানেই ব্যর্থ হয়। কোনো relay envelope sender নিজের domain-এ পরিবর্তন করলেও SPF pass হয়। কিন্তু pass করা domain তখন relay-এর domain। তাই alignment হয় না। আপনার নিজের DKIM signature উপস্থিত এবং valid না থাকলে DMARC fail করে। আপনার domain-এর অধীনে প্রকাশিত key দিয়ে sign করলে সমস্যাটি থাকে না।

Alignment forwarding-এর বিষয়টিও ব্যাখ্যা করে। কোনো mailing list বা পুরোনো university address আপনার message অন্যত্র forward করলে forwarding server connecting IP address হয়ে যায়। সেটি আপনার SPF record-এ থাকে না। তাই final destination-এ SPF fail করে। Signed header-গুলো পরিবর্তিত না হলে DKIM forwarding-এর পরও কার্যকর থাকে। কাজ করতে হবে DKIM-কেই।

প্রথমে একটি rua= reporting address-সহ p=none publish করুন। এরপর কোনো policy কঠোর করার আগে দুই সপ্তাহ aggregate report পড়ুন। আপনার নামে পাঠানো কিন্তু আপনার না-পাঠানো mail কেবল এই report-এই দেখা যাবে। আপনি যে forwarder-এর কথা ভুলে গেছেন, সেটি খুঁজে বের করার একমাত্র উপায়ও এটি। সরাসরি p=reject-এ গেলে এই ধাপ বাদ পড়ে এবং কোন কারণে সমস্যা হয়েছে তার কোনো record ছাড়াই বৈধ mail ভেঙে যায়।

এরপর পুরো chain end to end পরীক্ষা করুন। বড় কোনো 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 চলার সময় তা দেখায়। Receiver server message গ্রহণ করলে delivery-এর জন্য Postfix-এর নিজস্ব log line status=sent (250 2.0.0 OK ...) দিয়ে শেষ হয়। অন্য কিছু হলে refusal text হুবহু log-এ লেখা হয়। সেই string-ই search করুন। Delivered message-এর raw source-এ একটি Authentication-Results: header থাকে। এতে প্রতিটি check-এর নাম, pass বা fail ফলাফল এবং যে domain authentication করেছে তা উল্লেখ থাকে। তিনটিকেই pass বলতে হবে। Domain-টিও আপনার হতে হবে।

কীভাবে reputation সমস্যা শনাক্ত করবেন?

Feedback loop হলো এমন একটি ব্যবস্থা, যেখানে কোনো mailbox provider-এর ব্যবহারকারী Report spam বোতামে ক্লিক করলে provider আপনাকে সেই message-এর একটি copy পাঠায়। এমন ব্যবস্থা না থাকলে সমস্যার প্রথম লক্ষণ হলো delivery ইতিমধ্যে ব্যর্থ হওয়া, যা জানতে কয়েক সপ্তাহ দেরি হয়ে যায়।

এই programme-গুলোর নিয়ম আলাদা, এবং সবগুলো একটি address-সহ একক VPS-এর জন্য উপযুক্ত নয়। August 2026 অনুযায়ী, Microsoft প্রতি-address data ও complaint service চালায়, যার জন্য address owner register করতে পারেন। Yahoo DKIM signing domain-ভিত্তিক complaint feedback loop দেয়। Google পৃথক complaint-এর বদলে aggregate reputation data প্রকাশ করে। এই data একটি dashboard-এ দেখা যায়, তবে Google-এর ব্যবহারকারীদের কাছে প্রতিদিন অর্থপূর্ণ পরিমাণে message পাঠানো শুরু না করা পর্যন্ত dashboard খালি থাকে। কোনো programme-এর ওপর নির্ভর করার আগে তার বর্তমান terms পড়ুন। এগুলোর নিয়ম পরিবর্তিত হয়, এবং কোনো programme-ই আপনাকে access দেওয়ার বাধ্যবাধকতা রাখে না।

February 2024 থেকে কার্যকর Google-এর প্রকাশিত bulk sender requirement-গুলো বর্তমানে বড় receiver কী প্রত্যাশা করে, তার সবচেয়ে স্পষ্ট public statement। প্রতিদিন personal Gmail account-এ 5,000-এর বেশি message পাঠানো sender-কে SPF ও DKIM দিয়ে authentication করতে হবে, একটি DMARC policy publish করতে হবে, bulk mail-এ one-click unsubscribe দিতে হবে এবং spam complaint rate 0.3 percent-এর নিচে রাখতে হবে। ছোট server থেকে পাঠানো personal mail এই threshold-এর অনেক নিচে থাকে। তবে সব volume-এই একই signal বিশ্লেষণ করা হয়। Feedback loop ছাড়া যে signal দেখা যায় না, সেটি হলো complaint rate।

যে বিভাজনটি কার্যকর: receive নিজে host করা, outbound relay-এর মাধ্যমে পাঠানো

Receive করা অংশটির অসুবিধা প্রায় নেই। আপনার কাছে পাঠানো mail গ্রহণ করার জন্য কাউকে আপনাকে বিশ্বাস করতে হয় না। আপনার MX record, অর্থাৎ আপনার domain-এর mail exchanger নির্ধারণকারী DNS record, আপনার server-কে নির্দেশ করে। Sender আপনার server-এ connect করে। এরপরের প্রতিটি সিদ্ধান্ত আপনার: কী সংরক্ষণ করবেন, কতদিন রাখবেন, কীভাবে index করবেন এবং কারা তা search করতে পারবে। Storage সস্তা। আপনার মালিকানাধীন archive অন্য কোথাও নেওয়া কোনো automated policy decision-এর কারণে বন্ধ হয়ে যেতে পারে না। কাজ আছে, তবে তা সীমিত: spam filter updated রাখতে হবে, TLS (transport layer security) certificate renewal চালু রাখতে হবে, backup রাখতে হবে এবং disk পূর্ণ হওয়া ঠেকাতে হবে।

Outbound mail-এর ক্ষেত্রে কঠিন সমস্যাটি এড়াতে অর্থ ব্যয় করেন। আপনার server এমনভাবে configure করুন, যাতে প্রতিটি outgoing message port 25-এ সরাসরি Internet-এর সঙ্গে কথা না বলে 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

Editor ব্যবহার করে credentials /etc/postfix/sasl_passwd-এ লিখুন, যাতে password কখনো shell history-তে না থাকে। এটি একটি line। বাম পাশের 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

এরপর কোনো message পাঠালে log-এ relay=smtp.relay.example[...]:587 এবং status=sent দেখা যাবে। কোনো log line-এ SASL authentication failed থাকলে বুঝতে হবে credentials গ্রহণ করা হয়নি। এর সাধারণ কারণ হলো sasl_passwd-এ hostname-টি relayhost-এর hostname থেকে ভিন্নভাবে লেখা হয়েছে, কারণ lookup-এ exact string match ব্যবহৃত হয়।

এই বিভাজন কার্যকর, কারণ relay-এর মালিকানাধীন address-গুলোর পেছনে বহু বছরের গ্রহণযোগ্য mail history থাকে এবং সেই reputation বজায় রাখাই তাদের মূল business। আপনি domain, mailbox, archive এবং relay পরিবর্তন করে বেরিয়ে যাওয়ার সক্ষমতা নিজের কাছে রাখেন, কারণ relay পরিবর্তনের জন্য একটি configuration line এবং একটি DNS record বদলানোই যথেষ্ট। আপনি যে বিষয়টি ত্যাগ করেন, তা হলো relay operator-এর বিরুদ্ধে outbound mail-এর confidentiality। এটাই এই ব্যবস্থার প্রকৃত খরচ। আগে থেকে এই সিদ্ধান্ত নেওয়া ভালো, পরে তা অনিচ্ছায় আবিষ্কার করার চেয়ে।

প্রথম দিনেই আরেকটি separation করা উচিত। সব bulk mail নিজস্ব DKIM key-সহ আলাদা subdomain থেকে পাঠান: newsletter-এর জন্য news.example.com এবং personal mail-এর জন্য mail.example.com। Reputation sending domain-এর সঙ্গে যুক্ত থাকে। তাই নিজে host করা Listmonk newsletter-এর complaint rate আপনার personal mail-এর reputation নষ্ট করতে পারবে না।

কখন সম্পূর্ণ self-hosting এখনও সঠিক সিদ্ধান্ত?

Volume। মাসে কয়েকশো message হলে প্রতি-message relay pricing সুবিধাজনক থাকে, কিন্তু কয়েক million message হলে আর তা সুবিধাজনক থাকে না। ওই পরিমাণে dedicated address এবং সেগুলো কার্যকর করার জন্য প্রয়োজনীয় warmup schedule বহন করার সামর্থ্য থাকে।

Jurisdiction। কোনো regulation বা contract যদি বলে mail কোনো third party-এর disk-এ রাখা যাবে না, তাহলে delivery quality সিদ্ধান্তের মূল বিষয় নয়। relay আপনার জন্য একেবারেই উপলভ্য নয়।

যে control কিনে পাওয়া যায় না। plan tier-এর বদলে আপনার policy অনুযায়ী retention rule, প্রতিটি service-এর জন্য আলাদা address যাতে কে address ফাঁস করেছে তা শনাক্ত করতে পারেন, আপনার নিজের code চালিয়ে filtering, এবং কোনো appeal ছাড়াই এমন system-এর সিদ্ধান্তে account suspension না হওয়া।

যে mail কখনো আপনার network ছেড়ে যায় না। Alert এবং অন্যান্য machine-to-machine mail-এর ক্ষেত্রে deliverability সমস্যা থাকে না, কারণ উভয় প্রান্তই আপনার নিয়ন্ত্রণে। একটি local SMTP server থেকে আপনার নিজের mailbox-এ delivery করাই সম্পূর্ণ সমাধান। MCP (model context protocol)-এর মাধ্যমে একটি assistant-কে তার নিজস্ব self-hosted mailbox দেওয়া-র পেছনেও একই pattern কাজ করে।

আপনি যদি সরাসরি outbound mail পাঠান, address-টি warm up করুন। প্রতিদিন কম volume দিয়ে শুরু করুন এবং এমন ব্যক্তিদের mail পাঠান যারা আপনার mail প্রত্যাশা করেন। কয়েক সপ্তাহ ধরে volume ধীরে ধীরে বাড়ান। cold address থেকে কখনো burst পাঠাবেন না। সময়ের সঙ্গে কম complaint-সহ accepted mail থেকেই reputation তৈরি হয়। তাই history নেই এমন address থেকে হঠাৎ spike হলে সেটি breached server-এর মতোই দেখায় এবং সেভাবেই বিবেচিত হয়।

মেইল সার্ভার চালানোর প্রথম বছরে খরচ কত?

প্রথম সপ্তাহে নির্মাণের কাজ হয়: package, DNS record, TLS certificate, প্রথম test message, এবং p=none-এ DMARC।

দ্বিতীয় থেকে ষষ্ঠ সপ্তাহের সময়টাই এমন অংশ, যার জন্য কেউ পরিকল্পনা করে না। আপনি DMARC aggregate report পড়েন, এমন একটি alignment সমস্যা খুঁজে পান যার অস্তিত্ব আপনি জানতেন না, SPF নষ্ট করে এমন forwarder শনাক্ত করেন, তারপর policy p=quarantine-এ এবং পরে p=reject-এ পরিবর্তন করেন। এই সময়েই বোঝা যায় self-hosting আপনার নিয়মিত কাজ হবে, নাকি এটি আপনার কাছে বিরক্তিকর হয়ে উঠবে।

এরপর কাজের পরিমাণ মাসে মোটামুটি এক ঘণ্টায় স্থির হয়: package update, ধরে না নিয়ে যাচাই করা certificate renewal, backup থেকে restore test, disk ব্যবহারের বৃদ্ধি দেখা, এবং একটি blocklist lookup।

তবে এমন একটি সপ্তাহও আসে, যার সময় আগে থেকে নির্ধারণ করা যায় না। আপনি যা করেননি, এমন কোনো কারণে একটি address blocklist-এ যুক্ত হয়। কোনো বড় receiver একটি rule পরিবর্তন করে, এবং আপনার mail আবার spam folder-এ যেতে শুরু করে। Queue-তে থাকা mail হারিয়ে যায়নি: Postfix default হিসেবে একটি deferred message পাঁচ দিন পর্যন্ত retry করে, যা maximal_queue_lifetime = 5d নির্ধারণ করে। তাই কয়েক ঘণ্টার outage হলে শুধু delivery latency বাড়ে, আর কিছু নয়। এক সপ্তাহের outage হলে mail হারাতে হয়।

Backup MX record দেখতে যতটা কার্যকর মনে হয়, বাস্তবে এটি তার চেয়ে দুর্বল সমাধান। Sending server-গুলো নিজেরাই কয়েক দিন retry করে, তাই শুধু mail queue করে এমন secondary server খুব কম অতিরিক্ত সুবিধা দেয়। আরও খারাপ হলো, আপনার domain-এর কোন address বিদ্যমান তা না জেনে কোনো secondary server mail গ্রহণ করলে এটি অস্তিত্বহীন address-এর mail-ও নেবে। এরপর সেই mail জাল sender-দের কাছে bounce করবে, ফলে আপনার backup backscatter-এর উৎসে পরিণত হবে। Monitoring এবং বাস্তবে পরীক্ষা করা restore-এর পেছনে সময় দিন।

পুরো বিষয়টি মূল্যায়ন করতে box-এর অন্য যেকোনো কিছুর ক্ষেত্রেও যে প্রশ্নটি করতেন, সেটিই করুন: এটি নিজের কাছে রাখলে কি এমন কিছু পাবেন, যা কিনতে পারবেন না? Mailbox এবং archive-এর ক্ষেত্রে উত্তর সাধারণত হ্যাঁ। অপরিচিত recipient-দের কাছে outbound delivery-এর ক্ষেত্রে উত্তর সাধারণত না। 2026 সালে self-hosting করার মতো বিষয়গুলোর তালিকা বাছাই করার ক্ষেত্রেও একই পরীক্ষা প্রযোজ্য।

FAQ

VPS provider outbound port 25 ব্লক করলে কি আমি নিজে email host করতে পারি?

হ্যাঁ, mail গ্রহণের জন্য এবং relay-এর মাধ্যমে mail পাঠানোর জন্য। Inbound mail আপনার server-এর port 25-এ আসে, তাই outbound block এতে প্রভাব ফেলে না। এরপর outbound mail port 587-এ authenticated relay-এর মাধ্যমে পাঠানো হয়, যে port provider-রা সাধারণত ব্লক করে না। port 25 বন্ধ থাকলে আপনি যা করতে পারবেন না, তা হলো অন্য mail server-এ সরাসরি mail পৌঁছে দেওয়া; কারণ server-to-server delivery সংজ্ঞা অনুযায়ী port 25-এ হয়। nc -vz gmail-smtp-in.l.google.com 25 দিয়ে পরীক্ষা করুন। Connection স্থবির হয়ে পরে timeout হলে port-টি ব্লক করা আছে।

SPF, DKIM এবং DMARC তিনটিই pass করলেও আমার mail spam-এ যায় কেন?

Authentication প্রমাণ করে কে message পাঠিয়েছে। এটি প্রমাণ করে না যে message-টি প্রাপকের কাছে কাঙ্ক্ষিত। তিনটিই pass করলে আপনি unidentified sender থেকে identified sender-এ পরিণত হন। এরপর receiver আপনার IP address এবং domain reputation মূল্যায়ন করে, যা নতুন sender-এর এখনও তৈরি হয়নি। কয়েক সপ্তাহ ধরে মানুষ প্রত্যাশা করে এমন mail অল্প পরিমাণে পাঠিয়ে reputation তৈরি করুন। এরপর নিশ্চিত করুন যে দুই দিকেই PTR record আপনার mail hostname-এর সঙ্গে মেলে। এছাড়া content নিজে থেকে কোনো penalty তৈরি করছে কি না দেখুন, যেমন link shortener বা অপরিচিত tracking domain ব্যবহার।

নিজে host করা mail server-এর জন্য কি dedicated IP address দরকার?

সরাসরি outbound delivery-এর জন্য হ্যাঁ। Mail server-এর এমন একটি address দরকার, যার PTR record আপনি নিয়ন্ত্রণ করেন এবং যার reputation শুধু আপনার জন্য ব্যবহৃত হয়। এই অর্থে VPS address ইতিমধ্যেই dedicated। তবে একই network block-এ থাকা addressটির history বা প্রতিবেশী address-গুলো আপনি নিয়ন্ত্রণ করেন না। আপনি যদি outbound mail relay করেন, তাহলে reputation relay-এর address-গুলোর ওপর থাকে। আপনার address-এর শুধু inbound connection গ্রহণ করতে হয়।

আমার প্রধান address self-hosted server-এ সরিয়ে নেওয়া কি নিরাপদ?

একবারে cut-over না করে ধাপে ধাপে সরান। বর্তমান mailbox চালু রাখুন, আপনার server-কে দ্বিতীয় destination হিসেবে যোগ করুন, এবং কয়েক সপ্তাহ সেখানে একটি copy forward করুন। এই সময় DMARC report পড়ুন এবং দুই দিকেই mail flow সঠিক আছে কি না নিশ্চিত করুন। এক সপ্তাহ ধরে test mail সঠিকভাবে পৌঁছানোর পরেই MX record পরিবর্তন করুন। মানুষ যে ব্যর্থতার জন্য পরে অনুতপ্ত হয়, তা হলো এমন cut-over যাতে inbound mail হারিয়ে যায়। Inbound mail-ই সেই অংশ, যা পুনর্গঠন করা যায় না।

আমার mail-এর ওপর নিয়ন্ত্রণ বজায় রাখতে সবচেয়ে ছোট setup কী?

Mailboxes এবং archive-এর জন্য আপনার নিজের server ব্যবহার করুন, আর outbound mail port 587-এ authenticated relay-এর মাধ্যমে পাঠান। Data এবং domain আপনার নিয়ন্ত্রণে থাকবে, আর reputation-এর সমস্যা পুরোপুরি এড়ানো যাবে। পরে সিদ্ধান্ত পরিবর্তন করলেও খরচ কম থাকবে। কারণ relay পরিবর্তন করতে একটি configuration line এবং একটি SPF entry বদলানোই যথেষ্ট। পরে এটি প্রতিস্থাপন করতে একটি বিকেল সময় লাগবে।