আপনি যদি “Sender ID” search করে এখানে এসে থাকেন, প্রথমে একটা ছোট correction: Sender ID মানে SPF নয়। এটা ছিল 2000-এর দশকের মাঝামাঝি সময়ের একটা আলাদা, Microsoft-backed authentication scheme, যেটা Purported Responsible Address (PRA) check নামের একটা জিনিসের ওপর তৈরি হয়েছিল। এটা কখনো আসল adoption পায়নি, আর IETF অনেক আগেই এটাকে “Historic” status-এ সরিয়ে দিয়েছে — কার্যত এটা মৃত। আজ আপনার domain-কে আসলে যেটা protect করে সেটা একদম আলাদা, তিন-অংশের একটা system: SPF, DKIM আর DMARC, আর ওপরে reward হিসেবে BIMI। এই guide-এ এই চারটাই ঠিকভাবে ব্যাখ্যা করা হলো, কারণ 2026 সালে এসে এগুলো আর optional extra নয় — Gmail, Yahoo আর Microsoft এখন non-compliant mail সরাসরি reject করে।
কেন Email Authentication আর Optional থাকল না
Gmail আর Yahoo 2024-এর February থেকে bulk senders-দের জন্য SPF, DKIM আর DMARC enforce করা শুরু করে, আর 2025-এর শেষ নাগাদ সেই enforcement আরও কড়া হয়ে যায়: non-compliant message inbox-এ পৌঁছানোর আগেই permanent 5xx rejection পায়, শুধু spam-folder-এ soft-fail হয় না। Microsoft-ও Outlook.com, Hotmail আর Live.com-এর জন্য 2025 জুড়ে সমতুল্য requirement চালু করেছে। আপনার domain যদি প্রতিদিন personal Gmail বা Yahoo account-এ 5,000+ message পাঠায়, তাহলে এখন ন্যূনতম চাহিদা হলো: valid SPF, valid DKIM, একটা published DMARC policy, bulk mail-এ one-click unsubscribe (RFC 8058), আর 0.3%-এর কম spam-complaint rate।
এই volume threshold-এর নিচে থাকলেও, unauthenticated mail ক্রমশ default হিসেবে spam-এ চলে যাচ্ছে — sender-এর size যাই হোক না কেন, inbox provider-রা authentication status-কে একটা core trust signal হিসেবে ব্যবহার করে।
SPF — Sender Policy Framework
SPF (RFC 7208) একটা প্রশ্নের উত্তর দেয়: “এই server-টা কি এই domain-এর হয়ে mail পাঠানোর অনুমতি পেয়েছে?” আপনি একটা DNS TXT record publish করেন, যেখানে আপনার domain-এর হয়ে mail পাঠানোর জন্য authorized সব IP address আর third-party service (আপনার email host, আপনার CRM, আপনার marketing platform) তালিকাবদ্ধ থাকে। Receiving server connecting IP-টাকে সেই তালিকার সাথে মিলিয়ে দেখে।
বেশিরভাগ domain যেটা ভুল করে: SPF প্রতি check-এ সর্বোচ্চ 10টা DNS lookup-এর অনুমতি দেয়। যথেষ্ট পরিমাণ include: statement জমা করলে — আপনার email platform, আপনার helpdesk, আপনার marketing tool, আপনার invoicing system — আপনি নিঃশব্দে সেই limit পেরিয়ে যান, আর তখন legitimate mail সমেত সবার জন্য SPF fail করে। যখনই নতুন কোনো sending tool যোগ করেন, তখনই আপনার SPF record audit করুন, শুধু কিছু ভেঙে গেলে নয়।
DKIM — DomainKeys Identified Mail
DKIM (RFC 6376) একটা আলাদা প্রশ্নের উত্তর দেয়: “এই message-টা কি transit-এ পরিবর্তিত হয়েছে, আর এটা কি সত্যিই যেখান থেকে দাবি করছে সেখান থেকে এসেছে?” আপনার mail server প্রতিটা outgoing message একটা private key দিয়ে sign করে; public key একটা “selector”-এর অধীনে একটা DNS TXT record-এ থাকে। Receiving server সেই public key-এর বিপরীতে signature verify করে — মাঝপথে message-এ কোনো টেম্পারিং হলে, বা signature না মিললে, DKIM fail করে।
SPF-এর থেকে আলাদা, DKIM message-এর সাথেই থেকে যায়, তাই সাধারণ forwarding-এও এটা ভালোভাবে টিকে থাকে। সবচেয়ে সাধারণ failure mode: team-রা তাদের main mail server-এর জন্য DKIM set up করে, আর তাদের হয়ে mail পাঠানো বাকি সব platform ভুলে যায় — প্রতিটা sending source-এ আলাদাভাবে, নিজের selector সহ, DKIM configure করতে হয়।
DMARC — যে Policy Layer সব একসাথে বেঁধে রাখে
শুধু SPF আর DKIM দিয়ে, একজন মানুষ আসলে যে address দেখেন, তার spoofing আটকানো যায় না। DMARC (RFC 7489) সেই ফাঁকটা বন্ধ করে: এটা দাবি করে যে SPF বা DKIM-এর মধ্যে অন্তত একটা (আদর্শভাবে দুটোই) pass করবে এবং “aligned” হবে — মানে সেগুলো visible From: address-এ যে domain দেখা যায় ঠিক সেটাকেই authenticate করছে, recipient কখনো না-দেখা কোনো technical envelope address নয়। DMARC receiving server-কে এটাও বলে দেয় যে fail করা mail নিয়ে কী করতে হবে: p=none (শুধু monitor), p=quarantine (spam-এ পাঠানো), বা p=reject (সরাসরি block) — সাথে aggregate report কোথায় পাঠাতে হবে (rua=), যাতে enforce করার আগে দেখতে পান কী fail করছে।
2026-এর জন্য industry-র অস্বস্তিকর সংখ্যাটা হলো: global DMARC adoption 50%-এর ওপরে উঠে গেছে, কিন্তু সেই domain-গুলোর বেশিরভাগই এখনও p=none-এ বসে আছে — তারা শুধু দেখছে, protect করছে না। যে DMARC record কখনো monitoring পেরিয়ে graduate করে না, সেটা আসলে কোনো spoofing-ই আটকাতে পারে না।
BIMI — বাকিটা ঠিকভাবে করার পুরস্কার
BIMI (Brand Indicators for Message Identification) হলো সেই জিনিস যেটা inbox-এ আপনার email-এর পাশে আপনার verified logo বসায় — কিন্তু এটা বাকি তিনটার ওপর শর্তসাপেক্ষ: mailbox provider আপনার logo আদৌ দেখানোর আগে আপনার লাগবে quarantine বা reject-এ enforced DMARC, আর SPF ও DKIM দুটোই ঠিকভাবে aligned। Vendor data-তে BIMI logo থেকে reported open-rate lift প্রায় 39% পর্যন্ত উঠতে দেখা গেছে — এটা guaranteed নয়, কিন্তু DMARC rollout-টা p=none-এ অনির্দিষ্টকাল ফেলে না রেখে শেষ করার একটা আসল incentive।
সাধারণ ভুল যেগুলো নিঃশব্দে Authentication ভেঙে দেয়
- 10-lookup limit পেরিয়ে যাওয়া SPF — সাধারণত জমে থাকা third-party
include:entry-র কারণে, যেগুলো কেউ audit করে না। - Secondary sender-এ DKIM না থাকা — marketing platform বা support desk আপনার domain হয়ে mail পাঠাচ্ছে, কিন্তু নিজের DKIM selector ছাড়াই।
- DMARC alignment mismatch — SPF/DKIM technically pass করে, কিন্তু visible From: address-এর থেকে আলাদা একটা domain-এর বিপরীতে, তাই DMARC তবু fail করে।
- কখনো
p=noneনা ছাড়া — report set up হয়, কিন্তু তারপর কেউ সেগুলো review করে না বা enforcement-এ যায় না। - Subdomain ভুলে যাওয়া — নিজের কোনো policy না থাকা একটা spoofed
mail.yourdomain.comবাnews.yourdomain.comএকটা খোলা দরজা, যেটা বন্ধ করার জন্যই DMARC-এর subdomain policy (sp=) তৈরি হয়েছে।
এটা ঠিকভাবে Set Up করা
- আপনার domain হয়ে mail পাঠায় এমন প্রতিটা service-এর inventory করুন — mail server, CRM, marketing tool, invoicing, helpdesk।
- এগুলো সব কভার করে একটা SPF record publish করুন, 10 lookup-এর নিচে থেকে।
- শুধু primary mail server নয়, প্রতিটা sending source-এ নিজের selector সহ DKIM configure করুন।
rua=reporting চালু করেp=none-এ একটা DMARC record publish করুন — আর সত্যিই সেই report পড়ুন।- report-এ যা fail হচ্ছে দেখাচ্ছে সেটা ঠিক করুন, তারপর
p=quarantine-এ graduate করুন, আর শেষেp=reject-এ। - একবার DMARC enforce হয়ে গেলে, inbox-এ brand recognition আপনার কাছে গুরুত্বপূর্ণ হলে BIMI-এর জন্য apply করুন।
XgenPlus কীভাবে সাহায্য করে
XgenPlus SPF, DKIM আর DMARC support-কে core administration হিসেবেই দেয়, কোনো bolt-on হিসেবে নয় — domain setup, selector management আর policy enforcement সেই একই admin console থেকে হ্যান্ডল করা হয় যেটা user আর mailbox management-এর জন্য ব্যবহৃত হয়, 25+ বছরের email infrastructure আর 50M+ mailbox জুড়ে। যেসব organization-এর transport-level authentication-এর থেকে এক ধাপ আরও এগোনো দরকার, তাদের জন্য XgenPlus S/MIME-এর জন্য একটা in-house PKI/Certificate Authority-ও চালায় — message-level signing আর encryption, যেখানে trust chain-এর নিয়ন্ত্রণ আপনার হাতে, বিদেশের কোনো third party-র হাতে নয়।
প্রায়ই জিজ্ঞাসিত প্রশ্ন
“Sender ID” কি SPF-এর মতোই একই জিনিস?
না। Sender ID ছিল 2000-এর দশকের মাঝামাঝি সময়ের একটা আলাদা, Microsoft-backed authentication proposal, যেটা Purported Responsible Address (PRA) check ব্যবহার করত। এটা কখনো আসল adoption পায়নি, আর IETF তখন থেকে এটাকে Historic হিসেবে classify করেছে। Modern email authentication SPF, DKIM আর DMARC-এর ওপর চলে।
আমার কি SPF, DKIM আর DMARC তিনটাই দরকার, নাকি একটাই যথেষ্ট?
তিনটাই দরকার, কারণ এগুলো আলাদা আলাদা প্রশ্নের উত্তর দেয়। SPF check করে sending server authorized কিনা; DKIM check করে message পরিবর্তিত হয়েছে কিনা আর cryptographically origin verify করে; DMARC check করে SPF/DKIM visible From: address-এর সাথে align করছে কিনা, আর সেগুলো না করলে কী হবে সেটা define করে। এগুলোর যেকোনো একটা একা থাকলে বাকিগুলো যে ফাঁক বন্ধ করে সেটা খোলা থেকে যায়।
SPF set up থাকা সত্ত্বেও Gmail কেন বারবার আমার mail reject করছে?
সবচেয়ে সাধারণ কারণগুলো হলো: SPF 10-DNS-lookup limit পেরিয়ে যাওয়া (তাই নিঃশব্দে fail হওয়া), যে specific platform সেই message পাঠিয়েছে তাতে DKIM না থাকা, বা authenticated domain আর visible From: address-এর মধ্যে DMARC alignment mismatch। 2024-2025 থেকে, Gmail আর Yahoo non-compliant bulk mail শুধু spam-folder-এ না পাঠিয়ে সরাসরি hard-reject-ও করে।
DMARC-এর “p=none” আসলে কীসের বিরুদ্ধে protect করে?
একা এটা কিছুই না — p=none শুধু monitor-only। এটা একটা প্রয়োজনীয় প্রথম ধাপ (যাতে enforce করার আগে দেখতে পান কী ভাঙতে পারে), কিন্তু অনির্দিষ্টকাল p=none-এ ফেলে রাখা একটা DMARC record আসলে কোনো spoofing-ই আটকাতে পারে না। Protection আসে p=quarantine বা p=reject-এ graduate করা থেকে।
BIMI (logo-in-inbox feature) পাওয়ার আগে আমার কী দরকার?
DMARC enforced at quarantine বা reject-এ (none নয়), আপনার domain-এর সাথে ঠিকভাবে aligned SPF আর DKIM দুটোই, আর সাথে একটা certificate — Gmail, Yahoo আর Apple Mail জুড়ে broad support-এর জন্য একটা Verified Mark Certificate (VMC, registered trademark দরকার), অথবা শুধু Gmail support-এর জন্য একটা Common Mark Certificate (CMC, কোনো trademark দরকার নেই)।
শেষ কথা
প্রায় দুই বছরের মধ্যেই Email authentication “থাকলে ভালো” থেকে “deliver হতে হলে বাধ্যতামূলক”-এ পরিণত হয়ে গেছে। আপনার domain যদি এখনও বছরের পর বছর আগে copy-paste করা যেকোনো SPF record-এ চলে, শুধু একটা sending source-এ DKIM থাকে, আর DMARC তৈরির দিন থেকেই p=none-এ বসে থাকে, তাহলে এটা ঠিক করে নেওয়াই ভালো — নাহলে কোনো provider-এর enforcement update আপনার mail বাউন্স করে দিয়ে সেটা নিজেই ঠিক করে দেবে।
- XgenPlus-এর email security & authentication controls দেখুন — SPF, DKIM, DMARC আর admin-level policy management।
- S/MIME দিয়ে আরও এগিয়ে যান — message-level signing আর encryption-এর জন্য in-house PKI/CA।
- আমাদের team-এর সাথে কথা বলুন আপনার বর্তমান SPF/DKIM/DMARC setup audit করার ব্যাপারে।
