SPF, DKIM এবং DMARC পাস করলেও কেন আপনার ইমেল spam-এ যায়

Authentication পাস করা হলো শুরুর রেখা, শেষ রেখা নয়

দায়িত্বশীল কাজটি করা — SPF, DKIM এবং DMARC ঠিকভাবে কনফিগার করা — তবু ইমেল spam-এ যেতে দেখা হতাশাজনক।

বিভ্রান্তিটি সাধারণত authentication-কে deliverability-র নিশ্চয়তা হিসেবে ধরার কারণে হয়। এটি তা নয়। SPF, DKIM এবং DMARC একটি তুলনামূলক সংকীর্ণ প্রশ্নের উত্তর দেয়: এই server কি এই domain-এর হয়ে পাঠানোর অনুমতি পেয়েছে, এবং দৃশ্যমান sender কি authenticated identity-র সঙ্গে align করছে?

এটি গুরুত্বপূর্ণ। Authentication ছাড়া আধুনিক mailbox providers আপনার ওপর আস্থা না রাখাই স্বাভাবিক। কিন্তু আপনি একবার এই checks পাস করলেও, Gmail, Outlook, Yahoo এবং corporate filters-কে এখনও সিদ্ধান্ত নিতে হয় message-টি চাওয়া হয়েছে কি না, নিরাপদ কি না এবং প্রাসঙ্গিক কি না। সেই সিদ্ধান্ত sender reputation, recipient behavior, content, infrastructure, complaints, list quality এবং sending patterns-এর ওপর নির্ভর করে।

Records আসলে কী করে সে বিষয়ে যদি পুনরালোচনা দরকার হয়, আমাদের developer-friendly guide MX, SPF, DKIM এবং DMARC দিয়ে শুরু করুন। এই article ধরে নিচ্ছে ওই records পাস করছে এবং পরের স্তরে মনোযোগ দিচ্ছে: তবু mail কেন filter হয়।

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

SPF পরীক্ষা করে sending mail server-টি return-path-এর domain দ্বারা অনুমোদিত কি না। DKIM পরীক্ষা করে message-টি কোনো domain দ্বারা cryptographically signed হয়েছে কি না এবং message-এর signed অংশগুলো বদলানো হয়নি কি না। DMARC পরীক্ষা করে SPF বা DKIM এমনভাবে পাস করছে কি না যা দৃশ্যমান From domain-এর সঙ্গে align করে।

এই সমন্বয় spoofing ঠেকাতে সাহায্য করে। এটি বলে না:

• sender-এর reputation ভালো;
• recipients message-টি চেয়েছিলেন;
• content দরকারি;
• links নিরাপদ;
• sending volume স্বাভাবিক;
• domain-এর history পরিষ্কার;
• message-টি কোনো low-quality campaign-এর অংশ নয়।

Authentication-কে passport-এর মতো ভাবুন। এটি identity যাচাই করে। Border control এখনও জিজ্ঞেস করতে পারে আপনি কোথায় যাচ্ছেন, কী বহন করছেন এবং আগে কোনো ঝামেলা করেছেন কি না।

সবচেয়ে বড় কারণ: reputation

Mailbox providers ক্রমাগত senders-কে score করে। স্বাভাবিক কারণেই তারা পুরো scoring model প্রকাশ করে না, কিন্তু বড় signals-গুলো ভালোভাবেই জানা।

Domain reputation এবং IP reputation—দুটিই গুরুত্বপূর্ণ। নিখুঁত DKIM থাকা নতুন domain-ও risky মনে হতে পারে। একটি পুরোনো domain, যা বহু বছর শুধু invoices পাঠানোর পর হঠাৎ 80,000 promotional emails পাঠাতে শুরু করে, সেটিও risky দেখাবে। Abusive neighbors থাকা shared sending IP ক্ষতি করতে পারে, যদিও major email service providers এটি manage করতে কঠোর পরিশ্রম করে।

Reputation প্রভাবিত হয়:

• spam complaints;
• hard bounces;
• পুরোনো বা abandoned addresses-এ পাঠানো;
• হঠাৎ volume spikes;
• কম opens বা ignored messages;
• না পড়েই মুছে ফেলা messages;
• suspicious বা newly registered domains-এ links;
• অতীতের phishing বা malware incidents;
• inconsistent sending identity।

অস্বস্তিকর সত্যটি হলো: reputation ধীরে ধীরে অর্জিত হয় এবং দ্রুত হারায়। Authentication আপনাকে trust-এর যোগ্য রাখে। এটি নিজে trust তৈরি করে না।

আপনার list-ই সমস্যা হতে পারে

অনেক spam-folder সমস্যা আসলে list-quality সমস্যা, যা DNS সমস্যা বলে মনে হয়।

যদি কোনো list scraped, purchased, পুরোনো CRM থেকে inherited, event scans থেকে assembled, বা অস্পষ্ট consent-এর মাধ্যমে তৈরি হয়, সেটি সাধারণত খারাপ perform করবে। প্রথম campaign স্পষ্ট complaints trigger না করলেও, mailbox providers pattern দেখতে পারে: অনেক recipients engage করেন না, কেউ কেউ spam হিসেবে mark করেন, এবং কিছু addresses bounce করে।

ভালো lists-এর উৎস সাধারণত খুব সাধারণ। মানুষ ইচ্ছাকৃতভাবে sign up করেছেন। তারা জানতেন কীসের জন্য sign up করছেন। প্রথম email এত দ্রুত এসেছে যে তারা কাজটি মনে রাখতে পেরেছেন। Unsubscribing সহজ।

এই list warning signs-গুলোর দিকে নজর দিন:

• high bounce rate, বিশেষ করে প্রথম send-এ;
• info@, sales@ এবং admin@-এর মতো অনেক role accounts;
• বহু বছর আগে collected addresses, কিন্তু খুব কম contacted;
• এমন countries বা industries-এর subscribers যাদের আপনি serve করেন না;
• অস্বাভাবিকভাবে কম click বা reply rates;
• provider thresholds-এর ওপরে spam complaints।

B2B teams-এর জন্য contact forms-ও email flows বিষাক্ত করতে পারে। আপনার forms যদি automated abuse অনুমতি দেয়, আপনার domain junk notifications, fake leads বা backscatter পাঠানো শুরু করতে পারে। আমরা why your contact form is your biggest spam liability-এ সেই ঝুঁকি আলোচনা করেছি। Form spam শুধু বিরক্তিকর নয়; এটি reputation issue হয়ে উঠতে পারে।

DMARC পাস করলেও alignment দুর্বল হতে পারে

একটি message “pass DMARC” করতে পারে, তবু operationally অগোছালো হতে পারে।

উদাহরণস্বরূপ, আপনার দৃশ্যমান From address হতে পারে [email protected], DKIM pass করতে পারে mailer.example.net-এর জন্য, এবং SPF pass করতে পারে আপনার email provider দ্বারা controlled কোনো bounce domain-এর জন্য। Alignment settings এবং provider configuration-এর ওপর নির্ভর করে এটি technically acceptable হতে পারে। কিন্তু একটি clean setup সাধারণত আপনার domain বা স্পষ্টভাবে related subdomain দিয়ে sign করে।

Check করুন:

• DKIM d= domain: এটি কি আপনার From domain-এর সঙ্গে match বা align করে?
• return-path domain: এটি কি আপনার, নাকি আপনার provider-এর?
• DMARC policy: আপনি কি বহু বছর পরও p=none-এ আছেন?
• subdomain policy: ভুলে যাওয়া subdomains কি unprotected?
• forwarding behavior: forwarded messages কি SPF ভেঙে দিচ্ছে কিন্তু DKIM দিয়ে টিকে থাকছে?

প্রতিটি sender-এর জন্য strict alignment বাধ্যতামূলক নয়, কিন্তু identity coherent হওয়া উচিত। মানুষ এবং filters—দুজনেই যদি unrelated domains-এর জট দেখে, trust ক্ষতিগ্রস্ত হয়।

Content এখনও গুরুত্বপূর্ণ, তবে পুরোনোভাবে নয়

এক সময় deliverability advice “free”, “guarantee” বা “act now”-এর মতো words নিয়ে অতিরিক্ত ব্যস্ত ছিল। এখন সে advice খুবই সরলীকৃত। Modern filters message context, sender history, link reputation, HTML structure, user behavior এবং আরও অনেক signals দেখে।

তবু content আপনাকে ক্ষতি করতে পারে।

সাধারণ সমস্যাগুলোর মধ্যে আছে:

• link shorteners, যা destination অস্পষ্ট করে;
• mismatched link domains;
• খুব কম real text-সহ image-only emails;
• প্রতিটি link-এ heavy tracking wrappers;
• broken HTML বা malformed MIME parts;
• এমন attachments যা recipients আশা করেননি;
• deceptive subject lines;
• অতিরিক্ত personalization, যা machine-generated মনে হয়;
• legal footer text যা sending organization-এর সঙ্গে মেলে না।

একটি ভালো test: সব images blocked হলে এবং tracking parameters সরিয়ে দিলে email-টি কি এখনও অর্থবহ থাকবে? না হলে message-টি fragile।

Message-এর actual source-ও inspect করুন। Email headers HTTP headers-এর মতো নয়, কিন্তু অভ্যাসটি একই: অনুমান বন্ধ করুন এবং raw conversation দেখুন। debugging redirects and HTTP headers-এর জন্য আমাদের ছোট toolkit web-এর জন্য লেখা, তবু একই discipline email-এও প্রযোজ্য: কী পাঠানো হয়েছে, কী signed হয়েছে এবং links কোথায় resolve করে তা verify করুন।

Sending patterns সন্দেহজনক দেখাতে পারে

Mailbox providers সময়ের সঙ্গে behavior-কে গুরুত্ব দেয়। একটি ছোট company মাসে 500 emails পাঠায়, তারপর হঠাৎ এক বিকেলে 50,000 পাঠালে attention আকর্ষণ করবে, প্রতিটি message authenticated হলেও।

এ কারণেই warming গুরুত্বপূর্ণ। Warming কোনো magic নয়। এর অর্থ শুধু volume ধীরে ধীরে বাড়ানো, এবং প্রথমে তাদের কাছে পাঠানো যারা engage করার সম্ভাবনা সবচেয়ে বেশি। যদি সেই recipients open, click, reply করেন বা অন্যভাবে mail-টিকে wanted হিসেবে treat করেন, আপনার reputation নিরাপদে বাড়ার বেশি সুযোগ পায়।

Bad sending patterns-এর মধ্যে আছে:

• বড় volume spikes;
• অনিয়মিত “blast and disappear” schedules;
• সবচেয়ে কম engaged recipients-দের প্রথমে পাঠানো;
• careful sunset policy ছাড়া old lists reactivating করা;
• পরিকল্পনা ছাড়া একই domain-এ transactional এবং marketing mail মেশানো;
• একই সময়ে email service providers এবং volume পরিবর্তন করা।

অনেক teams-এর জন্য fix হলো segmentation। Important mail একটি stable domain বা subdomain থেকে পাঠান। Marketing experiments আলাদা রাখুন। কোনো risky campaign-কে password resets, invoices বা account alerts ক্ষতি করতে দেবেন না।

Unsubscribe handling এখন deliverability feature

Mailbox providers ক্রমশ bulk senders-এর কাছ থেকে unsubscribing সহজ করার প্রত্যাশা করে। এর অর্থ visible unsubscribe links এবং অনেক bulk senders-এর জন্য one-click unsubscribe headers।

Unsubscribe link লুকানো self-defeating। মানুষ unsubscribe করতে না পারলে message-টিকে spam হিসেবে mark করবে। Spam complaint একটি unsubscribe-এর তুলনায় অনেক শক্তিশালী negative signal।

নিশ্চিত করুন:

• unsubscribe link login ছাড়াই কাজ করে;
• requests দ্রুত honored হয়;
• bulk mail-এর জন্য List-Unsubscribe header উপস্থিত থাকে;
• preference centers সহজ, maze নয়;
• unsubscribed users CRM syncs দ্বারা আবার re-added হয় না।

এটি এমন একটি ক্ষেত্র যেখানে legal compliance এবং deliverability একই দিকে নির্দেশ করে: recipient-এর choice-কে respect করুন।

আপনার infrastructure noisy হতে পারে

ভালো DNS থাকলেও infrastructure mistakes trust দুর্বল করতে পারে।

Sending IPs-এর reverse DNS check করুন। HELO/EHLO names যেন sensible হয়। Compromised web servers থেকে পাঠানো এড়িয়ে চলুন। আপনার domain বা IP reputable blocklists-এ আছে কি না monitor করুন। TLS সচল রাখুন। Risk profiles আলাদা হলে mail streams আলাদা করুন।

Third-party senders নিয়েও সতর্ক থাকুন। আপনার SPF record-এ allowed প্রতিটি platform, আপনার publish করা প্রতিটি DKIM selector এবং আপনার domain হিসেবে send করতে পারে এমন প্রতিটি integration আপনার email reputation surface-এর অংশ হয়ে যায়। পুরোনো tools, forgotten CRMs এবং abandoned marketing platforms সরিয়ে ফেলতে হবে।

একটি practical quarterly review:

1. আপনার domain-এর হয়ে email পাঠানোর অনুমতিপ্রাপ্ত প্রতিটি service list করুন।
2. প্রতিটি service internally কে owns করে তা confirm করুন।
3. unused SPF includes এবং DKIM keys remove করুন।
4. unknown senders-এর জন্য DMARC aggregate reports review করুন।
5. mail stream অনুযায়ী complaint, bounce এবং unsubscribe rates check করুন।

এটি glamorous কাজ নয়। তবে এখানেই অনেক deliverability problems পাওয়া যায়।

অযথা হাতড়ে না বেড়িয়ে কীভাবে সমস্যা diagnose করবেন

একসঙ্গে দশটি জিনিস পরিবর্তন করবেন না। তাহলে কখনও জানতে পারবেন না কোনটি সাহায্য করেছে।

Spam-এ যাওয়া সাম্প্রতিক একটি message দিয়ে শুরু করুন এবং এই sequence অনুসরণ করুন:

1. Authentication confirm করুন। Received headers-এ SPF, DKIM এবং DMARC results check করুন।
2. Alignment check করুন। কোন domains pass করেছে এবং সেগুলো visible From domain-এর সঙ্গে align করে কি না verify করুন।
3. Mail stream identify করুন। এটি কি transactional, lifecycle, sales, newsletter নাকি cold outreach?
4. Audience quality review করুন। এটি কি opted-in, recently engaged recipients-দের কাছে পাঠানো হয়েছে?
5. Links inspect করুন। Link domains কি reputable, consistent এবং expected?
6. Engagement দেখুন। Recipients কি opening, clicking, replying করছেন, নাকি ignoring?
7. Complaints এবং bounces check করুন। এগুলো প্রায়ই open rates-এর চেয়ে বেশি revealing।
8. Providers compare করুন। Issue কি মূলত Gmail, Outlook, corporate filters, নাকি everywhere?
9. একটি variable change করুন। Segment করুন, volume কমান, list clean করুন বা content adjust করুন — তারপর measure করুন।

আপনি meaningful volume পাঠালে, যেখানে available, mailbox providers-এর offered reporting tools ব্যবহার করুন। তারা প্রতিটি detail reveal করবে না, কিন্তু আপনার domain reputation, IP reputation, authentication বা complaint-rate problem আছে কি না দেখাতে পারে।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: SPF পাস করলেও, ভুল কনফিগারেশন এবং লুকআপ সীমা ডেলিভারেবিলিটিকে ক্ষতিগ্রস্ত করতে পারে—SPF Tester দিয়ে আপনার রেকর্ডটি আরেকবার পরীক্ষা করুন।

<!-- tool-cta:end -->

একটি sober deliverability checklist

আপনার email authenticate করলেও spam-এ গেলে, প্রথমে এই fixes-গুলোর দিকে মনোযোগ দিন:

• শুধু clear consent বা strong existing relationship থাকা মানুষদের কাছে পাঠান;
• hard bounces সঙ্গে সঙ্গে remove করুন;
• chronically inactive recipients suppress করুন;
• complaining-এর চেয়ে unsubscribing সহজ করুন;
• From names এবং domains consistent রাখুন;
• sudden volume increases এড়িয়ে চলুন;
• appropriate হলে transactional এবং promotional mail আলাদা করুন;
• DNS থেকে unused third-party senders remove করুন;
• aligned DKIM domain দিয়ে mail sign করুন;
• DMARC reports এবং complaint data monitor করুন।

Pattern সহজ: identifiable হন, expected হন, wanted হন এবং consistent থাকুন।

SPF, DKIM এবং DMARC প্রয়োজনীয়, কারণ এগুলো প্রমাণ করে আপনার mail সহজে forged নয়। কিন্তু inbox placement একটি reputation decision। Mailbox providers শুধু “এটি কি সত্যিই আপনার কাছ থেকে?” জিজ্ঞেস করছে না। তারা জিজ্ঞেস করছে “আমাদের users কি আপনার কাছ থেকে mail পেতে চান বলে মনে হচ্ছে?”

দ্বিতীয় প্রশ্নটির উত্তর দেওয়া কঠিন, এবং fake করা আরও কঠিন। Authenticated mail inbox-এ পৌঁছাবে কি না সেটিই শেষ পর্যন্ত নির্ধারণ করে।