EQVPS

একটি VPS-এ একটি মেইল সার্ভার চালানো: আসলে যা আপনাকে spam-এর বাইরে রাখে

Jul 1, 2026 · 4 min read · EQVPS Team

আপনার মেইল সার্ভার কাজ করে। Postfix শুরু হয়, log পরিষ্কার দেখায়, আপনি আপনার Gmail-এ একটি test বার্তা পাঠান — আর এটি spam-এ পড়ে। বা এটি কেবল উধাও হয়। আপনার config-এ কিছু ভাঙা নেই। সফটওয়্যার আপনি যা বলেছেন ঠিক তাই করেছে।

সমস্যা হলো অপর প্রান্তের সার্ভার এখনও আপনার IP-কে বিশ্বাস করে না, আর ইমেল ছোট trust-চেকের একটি পুরো stack লুকায় যা একজন অচেনার inbox আপনাকে ঢুকতে দেওয়ার আগে সবগুলোকে মিলতে হয়। সেগুলো ঠিক করুন আর delivery বেশিরভাগ নিজে সামলায়। একটি মিস করুন আর আপনি একটি spam folder-এ চিৎকার করছেন।

তিনটি জিনিস বেশিরভাগ ওজন বহন করে: reverse DNS, sender authentication, ও আপনার হোস্ট এমনকি আপনাকে পোর্ট 25-এ কথা বলতে দেয় কি না। এদের কোনোটাই কঠিন নয়। এরা কেবল ভুলে যাওয়া সহজ, আর প্রতিটি একটি নীরব veto।

যেটা সবাই ভুলে যায়: reverse DNS

Forward DNS সেই অংশ যা আপনি জানেন — একটি নাম একটি IP-তে তাক করে। Reverse DNS আয়না: একটি IP একটি নামে ফিরে তাক করে। সেই record-কে একটি PTR বলে, আর এটি আপনার ডোমেইনের zone-এ নয়, যে IP নিয়ন্ত্রণ করে তার কাছে থাকে।

এই যে কেন এটি গুরুত্বপূর্ণ। আপনার সার্ভার Gmail-এর SMTP-তে একটি সংযোগ খুললে, গ্রহণকারী পক্ষ প্রথম যা করে তার একটি হলো আপনার IP-তে একটি reverse lookup — এটি কে? এটি নিজে চালান:

dig -x 203.0.113.19 +short

তা static.203-0-113-19.rev.example-isp.net-র মতো কিছু নিয়ে ফিরলে, বা খালি ফিরলে, আপনি ইতিমধ্যেই পয়েন্ট হারিয়েছেন। সেই generic নাম বলে "কোনো এলোমেলো VPS," আর আরও খারাপ, এটি আপনার সার্ভার HELO greeting-এ যে hostname হিসেবে নিজেকে পরিচয় দেয় তার সাথে মেলে না। গ্রহণকারী সার্ভার সেই অমিল কঠোরভাবে flag করে। কেউ সরাসরি প্রত্যাখ্যান করে।

তারা যা দেখতে চায় তা হলো একটি PTR যা আপনার মেইল hostname-এর সাথে মেলে। আপনার সার্ভার HELO mail.example.com বললে, এর IP-তে reverse lookup mail.example.com ফেরত দেওয়া উচিত। Forward ও reverse একমত, গল্প সামঞ্জস্যপূর্ণ, আর আপনাকে একটি hijack-করা বক্সের বদলে একটি আসল মেইল সার্ভার মনে হয়।

একটি PTR সেট করা ঐতিহ্যগতভাবে মানে IP block-এর মালিকের সাথে একটি support ticket খোলা ও অপেক্ষা করা। EQVPS dedicated-IP প্ল্যানে এটি আপনার dashboard-এ একটি ক্ষেত্র — hostname টাইপ করুন, এটি প্রোভাইডারের API-র মাধ্যমে সরাসরি registry-তে লেখে, আর এটি সেকেন্ডে live। এটি self-serve করার পুরো বিন্দু সেটাই: reverse DNS সেই ধাপ যা মানুষ এড়িয়ে যায় কারণ এটি আগে বিরক্তিকর ছিল।

Authentication: SPF, DKIM, DMARC

এই তিনটি DNS record গ্রহণকারী সার্ভারকে বলে যে আপনার ডোমেইন থেকে আসা দাবি করা মেইল সত্যিই তাই। এড়িয়ে যান আর আপনি একজন unverified অচেনা।

আপনি তিনটিই চান। SPF ও DKIM প্রমাণ করে মেইল বৈধভাবে আপনার; DMARC সেই প্রমাণকে একটি policy-তে পরিণত করে। এটি হয়তো বিশ মিনিটের DNS-সম্পাদনা, আর এটি "verified sender" ও "কে?"-র মধ্যে পার্থক্য।

পোর্ট 25, আর কেন এটি বন্ধ

এই যে যেটা মানুষকে অবাক করে। Outbound পোর্ট 25 — যে পোর্ট মেইল সার্ভার একে অপরের সাথে কথা বলতে ব্যবহার করে — মূলত প্রতিটি VPS হোস্টে ডিফল্টে block। আমরাও।

সেটি ইচ্ছাকৃত। পোর্ট 25 ক্লাসিক spam কামান, তাই এটি আপনি চাওয়া ও আপনি আসলে কী পাঠাচ্ছেন বলা পর্যন্ত বন্ধ থাকে। আমরা যে কেউ একটি সার্ভার চালু করলে খোলা রাখার বদলে প্রতি অনুরোধে এটি খুলি।

আর এখানে স্পষ্টভাবে বলার একটি সৎ সতর্কতা: একটি খোলা পোর্ট 25-এর সাথে দায়িত্ব আসে। spam পাম্প করা একটি compromised script বা একটি ভুল-কনফিগার-করা relay, আর আপনার IP-র reputation গেল — কখনও সপ্তাহের জন্য। একটি shared subnet-এ সেই জঞ্জাল আপনার প্রতিবেশীদের ওপর ছিটকে পড়ে, ঠিক এজন্যই হোস্ট এ নিয়ে সতর্ক। আপনি আমাদের 25 খুলতে বললে, আপনার সার্ভার পরিষ্কার রাখুন, কারণ আপনি যে reputation রক্ষা করছেন তা আংশিকভাবে আমাদেরও।

কেন dedicated IP ঐচ্ছিক নয়

এর সবই একটি প্রয়োজনে ফিরে আসে: IP আপনার হতে হবে। একটি NAT সেটআপ বা একটি shared ঠিকানায় আপনি নিজের PTR সেট করতে পারবেন না, কারণ ঠিকানা একচেটিয়াভাবে আপনার তাক করার নয়। shared IP ইতিমধ্যেই যে reputation বহন করে তা-ও আপনি উত্তরাধিকারসূত্রে পান — আর শেষ ভাড়াটে এটি দিয়ে কী করেছে তার কোনো ধারণা আপনার নেই।

একটি dedicated IP আপনাকে নিয়ন্ত্রণ করা একটি PTR, আপনার গড়া একটি reputation, ও একটি পরিচ্ছন্ন শুরুর বিন্দু দেয়। outbound মেইলের জন্য সেটি একটি nice-to-have নয়; এটি মেঝে।

সৎ শেষ কথা

2026-এ ইমেল সেলফ-হোস্ট করা আসল, চলমান কাজ। এটি set-and-forget নয় — আপনি blocklist দেখবেন, DKIM key ঘোরাবেন, ও মাঝেমধ্যে বের করবেন কেন একটি নির্দিষ্ট প্রোভাইডার আপনাকে greylist করা শুরু করল। এটি একটি low-stakes side project হলে, সৎভাবে, একটি বিদ্যমান মেইল প্রোভাইডারের মাধ্যমে forward করা আপনার মাথাব্যথা বাঁচাবে।

কিন্তু আপনি আসল নিয়ন্ত্রণ চাইলে — আপনার ডেটা, আপনার ডোমেইন, header পড়া আর কেউ নেই — এটি একটি ছোট VPS-এ খুবই করার মতো। উপরের trust-plumbing প্রায় 90% যুদ্ধ, আর এর কিছুই বিদেশি-বিচিত্র নয়। একটি dedicated IP নিন, PTR-কে আপনার hostname-এর সাথে মেলাতে সেট করুন, SPF/DKIM/DMARC প্রকাশ করুন, আমাদের পোর্ট 25 খুলতে বলুন, তারপর mail-tester.com-র মতো একটি টুলের মাধ্যমে একটি test পাঠান ও এটি যা flag করে তা ঠিক করুন। এটি করুন আর আপনি আর একটি spam folder-এ চিৎকার করছেন না — আপনি এমন একটি মেইল সার্ভার যা মানুষের inbox আসলে বিশ্বাস করে।

FAQ

একটি মেইল সার্ভার চালাতে কি একটি dedicated IP দরকার?

কার্যত হ্যাঁ। Deliverability আপনার মেইল hostname-এর সাথে মেলে এমন একটি reverse DNS (PTR) record-এর ওপর নির্ভর করে, আর আপনি শুধু একচেটিয়াভাবে আপনার একটি IP-তে একটি PTR সেট করতে পারেন। একটি shared বা NAT ঠিকানায় আপনি PTR নিয়ন্ত্রণ করেন না, তাই গ্রহণকারী সার্ভার একটি generic বা অমিল hostname দেখে ও আপনাকে সন্দেহজনক গণ্য করে। একটি dedicated IP outbound মেইলের baseline।

একটি PTR record কী আর ইমেলের এটি কেন দরকার?

একটি PTR record হলো reverse DNS — এটি আপনার IP-কে একটি hostname-এ ফিরিয়ে ম্যাপ করে, একটি সাধারণ A record-এর বিপরীত। আপনার সার্ভার Gmail বা Outlook-এ সংযুক্ত হলে, গ্রহণকারী পক্ষ দেখে কে আপনার IP-র মালিক। PTR অনুপস্থিত বা generic হলে (static.203-0-113-19.rev.example-isp.net-র মতো), তা আপনার বিপক্ষে একটি তাৎক্ষণিক strike। মেইল সার্ভার আশা করে PTR আপনার সার্ভার HELO-তে যে নাম ঘোষণা করে তার সাথে মেলে।

বেশিরভাগ VPS হোস্টে outbound পোর্ট 25 ডিফল্টে block কেন?

পোর্ট 25 একক সবচেয়ে বড় spam vector, তাই হোস্ট আপনি চাওয়া ও কী পাঠাচ্ছেন ব্যাখ্যা না-করা পর্যন্ত এটি বন্ধ রাখে। এটি একটি bug নয় — এটি অপব্যবহার-প্রতিরোধ। spam ছোড়া একটি compromised script একটি IP-র reputation পোড়াতে পারে, আর একটি shared subnet-এ সেই ক্ষতি অন্য গ্রাহকদের ওপর ছিটকে পড়ে। সম্মানজনক হোস্ট, EQVPS সহ, ডিফল্টে নয়, প্রতি অনুরোধে এটি খোলে।

একটি NAT বা shared IP-তে কি একটি মেইল সার্ভার চালাতে পারি?

আপনি port forwarding-এর মাধ্যমে মেইল গ্রহণ করতে পারেন, কিন্তু নির্ভরযোগ্যভাবে পাঠানো ভিন্ন গল্প। নিজের IP ছাড়া আপনি একটি মেলানো PTR সেট করতে পারবেন না, আর shared ঠিকানার ইতিমধ্যেই যে reputation আছে তা উত্তরাধিকারসূত্রে পান — ভালো বা খারাপ। যা delivered হওয়া দরকার তার জন্য, একটি পরিচ্ছন্ন history ও আপনি নিয়ন্ত্রণ করেন এমন একটি PTR সহ একটি dedicated IP ব্যবহার করুন।

2026-এ ইমেল সেলফ-হোস্ট করা কি আসলে সার্থক?

কেন-র ওপর নির্ভর করে। আপনি কোনো তৃতীয় পক্ষ loop-এ ছাড়া আপনার ডেটা ও ডোমেইনের নিয়ন্ত্রণ চাইলে, এটি একটি ছোট VPS-এ খুবই করার মতো। কিন্তু deliverability একটি চলমান কাজ — আপনি blocklist দেখেন, DKIM key ঘোরান, ও IP পরিষ্কার রাখেন। একটি low-stakes side project-এর জন্য, একটি বিদ্যমান প্রোভাইডারের মাধ্যমে forward করা কম যন্ত্রণা। সুবিধার চেয়ে নিয়ন্ত্রণ বেশি গুরুত্বপূর্ণ হলে সেলফ-হোস্ট করুন।

← Back to blogSee plans & pricing →

মন্তব্য

এখনো কোনো মন্তব্য নেই। প্রথম হোন।

একটি মন্তব্য দিন

মন্তব্য প্রকাশের আগে মডারেট করা হয়।