Email Spam Tester

Homeব্লগOutlook-এ আমার ইমেল স্প্যামে যাচ্ছে কেন? (সমাধানসহ)

Outlook-এ আমার ইমেল স্প্যামে যাচ্ছে কেন? (সমাধানসহ)

Outlook.com, Microsoft 365 ও Outlook app আলাদাভাবে মেইল ফিল্টার করে। May 2025 থেকে Microsoft-এর শর্ত, 550 5.7.515-এর অর্থ ও সমাধান।

এই পৃষ্ঠায়Outlook.com এবং মে ২০২৫-এর নিয়ম
  1. Outlook.com এবং মে ২০২৫-এর নিয়ম
  2. বাউন্স কোডটি আপনাকে কী জানাচ্ছে
  3. তৃতীয় পক্ষের প্রেরক এবং SPF-এর প্রয়োজনীয়তা
  4. Microsoft 365 অন্য কারও নীতি অনুযায়ী ফিল্টার হয়
  5. হেডারে সিদ্ধান্ত পড়া
  6. SNDS ও JMRP, এখন Postmaster সাইটে
  7. অপর প্রান্তের ব্যক্তি কী পরিবর্তন করতে পারেন
  8. আসল ইমেল পাঠানোর আগে পরীক্ষা

"Outlook" আসলে তিনটি আলাদা ফিল্টার, আর কোনটি আপনার ইমেলকে Junk-এ পাঠিয়েছে, তার ওপর সমাধান নির্ভর করে। একটি হলো Outlook.com, Microsoft-এর সাধারণ ব্যবহারকারীদের ইমেল পরিষেবা, যা hotmail.com, live.com ও msn.com ঠিকানাও পরিচালনা করে। আরেকটি হলো Microsoft 365, কোম্পানিগুলোর অর্থের বিনিময়ে নেওয়া ব্যবসায়িক মেইলবক্স, যেখানে প্রাপকের কোম্পানির একজন অ্যাডমিন স্প্যাম নীতি নির্ধারণ করেন। তৃতীয়টি হলো কারও কম্পিউটারে থাকা Outlook অ্যাপ, যা সার্ভারের সিদ্ধান্তের পাশাপাশি নিজস্ব Junk ফিল্টার চালাতে পারে। Microsoft 2025 সালে প্রেরকদের জন্য যে নিয়ম ঘোষণা করেছে, তা শুধু প্রথমটির ক্ষেত্রে প্রযোজ্য।

তাই একটি DNS রেকর্ডও পরিবর্তন করার আগে আমি প্রাপকের ঠিকানা দেখি। hotmail.com বা outlook.com ঠিকানা হলে নিচের সাধারণ ব্যবহারকারীদের নিয়ম প্রযোজ্য। Microsoft-এ ইমেল পরিচালনা করা কোনো কোম্পানির ঠিকানা হলে, সেই কোম্পানির IT টিমের লেখা টেন্যান্ট নীতি প্রযোজ্য।

Outlook.com এবং মে ২০২৫-এর নিয়ম

২০২৫ সালের এপ্রিলে Microsoft তার গ্রাহক পরিষেবায় প্রতিদিন ৫,০০০টির বেশি ইমেল পাঠানো ডোমেইনের জন্য শর্তাবলি ঘোষণা করে, এবং Postmaster নীতিমালার পৃষ্ঠায় বলা হয়েছে যে এগুলো ৫ মে, ২০২৫ থেকে কার্যকর হয়েছে। এই পরিমাণের বেশি হলে:

  • পাঠানো ডোমেইনের জন্য SPF অবশ্যই পাস করতে হবে।
  • DKIM অবশ্যই পাস করতে হবে।
  • DMARC অন্তত "p=none" দিয়ে প্রকাশ করতে হবে এবং SPF বা DKIM-এর সঙ্গে অ্যালাইন করতে হবে, "সম্ভব হলে দুটির সঙ্গেই"। নীতিমালার পৃষ্ঠায় আরও বলা হয়েছে, p=reject ব্যবহার করার পরামর্শ দেওয়া হয়।

বাউন্স-সংক্রান্ত সহায়তা নিবন্ধে বিষয়টি কিছুটা ভিন্নভাবে বলা হয়েছে। সেখানে Microsoft-এর গ্রাহক পরিষেবাগুলোতে পাঠানো ৫,০০০ বা তার বেশি বার্তা গণনা করা হয়, যদি সেগুলোর From ঠিকানায় একই ডোমেইন থাকে। সেখানে বলা হয়েছে, SPF ও DKIM উভয় পরীক্ষাই পাস করতে হবে। কোনো ডোমেইন এই সীমায় পৌঁছালে Microsoft আশা করে যে "ডোমেইনের প্রেরকদের সব বার্তা" নিয়মগুলো মেনে চলবে, শুধু যে নিউজলেটারটি সংখ্যাকে সীমার ওপরে নিয়ে গেছে সেটি নয়। তাদের DMARC উদাহরণটি একটি রেকর্ড যতটা ছোট হতে পারে, প্রায় ততটাই ছোট:

TXT·_dmarc
Hostname:   _dmarc
TXT value:  v=DMARC1; p=none

আমি এতে একটি রিপোর্টিং ঠিকানা যোগ করতাম, rua=mailto:dmarc@example.com অথবা এমন কোনো ঠিকানা যেখানে আপনি সত্যিই ইমেল পড়েন। Outlook.com সমন্বিত রিপোর্ট পাঠায়, Microsoft-এর FAQ অনুযায়ী এটি RUA পাঠায় এবং RUF পাঠানোর কোনো পরিকল্পনা নেই। আর DMARC পরীক্ষক দেখাবে, আপনার দেওয়া ঠিকানাটি সেগুলো গ্রহণ করতে পারে কি না।

Google ২০২৪ সালের ফেব্রুয়ারিতে Gmail-এর জন্য একই দৈনিক ৫,০০০ ইমেলের সীমা নির্ধারণ করে এবং ২০২৫ সালের নভেম্বরে প্রত্যাখ্যানসহ নিয়ম কার্যকর করার মাত্রা বাড়ানো শুরু করে। Yahoo কোনো সীমা উল্লেখ না করেই একই ধরনের নিয়মের তালিকা কার্যকর করে।

ঘোষণাটি তখনও নতুন থাকা অবস্থায় নিয়মটি কীভাবে কার্যকর করা হবে, তা বদলে যায়। মূল পোস্টে বলা হয়েছিল, নিয়ম না মানা ইমেল প্রথমে Junk-এ যাবে এবং পরে প্রত্যাখ্যাত হতে পারে। ২৯ এপ্রিলের একটি আপডেটে বলা হয়েছে, Microsoft পরিবর্তে প্রত্যাখ্যান করার সিদ্ধান্ত নিয়েছে। তবে একই পোস্টের নিচের দিকে এখনও প্রথমে Junk-এ পাঠানোর পুরোনো অনুচ্ছেদটি রয়েছে। বর্তমানে সতর্কতার সঙ্গে পড়লে বোঝা যায়, ৫ মে, ২০২৫ থেকে নিয়ম না মানা ইমেল Junk-এ যায় এবং Outlook.com এখন এই বার্তা দিয়ে সেটি প্রত্যাখ্যানও করে:

550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.

Microsoft-এর সহায়তা নিবন্ধে উদ্ধৃত Outlook.com বাউন্স বার্তা

প্রত্যাখ্যান শুরু হওয়ার কোনো প্রকাশিত তারিখ আমি খুঁজে পাইনি। সহায়তা নিবন্ধটি শুধু বর্তমান কাল ব্যবহার করে বিষয়টি বর্ণনা করেছে।

বাউন্স কোডটি আপনাকে কী জানাচ্ছে

Outlook.com থেকে আসা বাউন্স, Junk ফোল্ডারে নীরবে পড়ে থাকা বার্তার চেয়ে বেশি উপযোগী, কারণ এতে একটি কারণ উল্লেখ থাকে। Microsoft-এর সমস্যা সমাধানের পৃষ্ঠায় কোডগুলোর একটি টেবিল আছে। সাধারণ প্রেরকদের ক্ষেত্রে সাধারণত এই কোডগুলো দেখা যায়:

কোডMicrosoft-এর মতে এর অর্থ
550 5.7.515ডোমেইনটি দিনে 5,000টির বেশি ইমেল পাঠায় এবং SPF, DKIM ও DMARC দিয়ে প্রমাণীকৃত নয়
550 SC-001নীতিমালাজনিত প্রত্যাখ্যান, "content with spam-like characteristics or IP/domain reputation"
550 SC-004IP থেকে পাঠানো মেইল নিয়ে অভিযোগের পর সেটির ওপর আরোপিত ব্লক
421 RP-001সংযোগকারী IP-এর ওপর রেট সীমা, এটিও সুনামের কারণে

Microsoft-এর নিজস্ব কোড ছাড়া সাধারণ 550 5.7.1 আরেক ধরনের প্রত্যাখ্যান। এটি বোঝার জন্য আলাদা একটি পৃষ্ঠা আছে।

তৃতীয় পক্ষের প্রেরক এবং SPF-এর প্রয়োজনীয়তা

অনেক ডোমেইন একই সময়ে একাধিক পরিষেবার মাধ্যমে ইমেল পাঠায়: নিউজলেটার প্ল্যাটফর্ম, CRM, হেল্প ডেস্ক, বিলিং। এগুলোর প্রতিটি From লাইনে আপনার ডোমেইন ব্যবহার করে ইমেল পাঠায় এবং প্রতিটিকেই আপনার রেকর্ডে অন্তর্ভুক্ত করতে হবে। কোনো প্রদানকারী আপনার হয়ে ইমেল পাঠালেও নিয়মগুলো প্রযোজ্য কি না, এই প্রশ্নের উত্তরে Microsoft-এর FAQ বলে, "হ্যাঁ। আপনি ইমেল পাঠানোর কাজ আউটসোর্স করলেও অথেন্টিকেশন আপনার ডোমেইনের সঙ্গে সম্পর্কিত।" সাপোর্ট নিবন্ধটিতে কী যাচাই করতে হবে তা স্পষ্টভাবে বলা হয়েছে: DKIM আপনার ডোমেইন দিয়ে সাইন করে কি না এবং আপনার SPF রেকর্ডে "পরিষেবাটির প্রয়োজনীয় IP ঠিকানা বা include মানগুলো অন্তর্ভুক্ত আছে কি না"।

এখানেই SPF ও DKIM উভয়টি বাধ্যতামূলক করার বিষয়টি বিভ্রান্তিকর হয়ে ওঠে। অনেক প্ল্যাটফর্ম বাউন্স ঠিকানার জন্য তাদের নিজস্ব ডোমেইন ব্যবহার করে এবং SPF আসলে সেই Return-Path-ই পরীক্ষা করে। তখন প্ল্যাটফর্মের জন্য SPF পাস করে, যা "অবশ্যই পাস করতে হবে" শর্তটি পূরণ করে, আর DMARC alignment আসতে হয় আপনার ডোমেইন দিয়ে করা DKIM signing থেকে। প্ল্যাটফর্মটি যদি এর বদলে নিজস্ব ডোমেইন দিয়ে সাইন করে, তাহলে দুটি পরীক্ষাই পাস করে কিন্তু কোনো alignment থাকে না, আর এর ফলে যে DMARC fail হয়, 5.7.515 ঠিক সেই বিষয়েই। সাপোর্ট নিবন্ধটি Return-Path ডোমেইন From ডোমেইনের সঙ্গে aligned কি না, সেটিও পরীক্ষা করতে বলে।দুটি পাস, শূন্য alignment: 5.7.515-এর পুরো ঘটনা

SPF-এ যোগ করা প্রতিটি পরিষেবার জন্য DNS lookup-ও খরচ হয়। Microsoft-এর FAQ-তে এটি এভাবে বলা হয়েছে: "আপনি ১০টি DNS lookup অতিক্রম করলে আপনার SPF পরীক্ষা ব্যর্থ হতে পারে।" SPF checker আপনার হয়ে সেগুলো গোনে এবং সংখ্যা বেশি হলে এভাবে আবার দশের নিচে নামাতে পারেন। প্রতিটি প্ল্যাটফর্মের selector-এর জন্য DKIM checker একই ধরনের মিল যাচাই করে।

Microsoft 365 অন্য কারও নীতি অনুযায়ী ফিল্টার হয়

Microsoft 365 সংস্থায় অ্যান্টি-স্প্যাম নীতি থাকে, যা অ্যাডমিনরা কনফিগার করেন। ডিফল্টভাবে স্প্যাম, অত্যন্ত নিশ্চিত স্প্যাম এবং বাল্ক মেইল Junk Email ফোল্ডারে যায়, আর ফিশিং কোয়ারেন্টাইনে যায় এবং অত্যন্ত নিশ্চিত ফিশিং সব সময় কোয়ারেন্টাইনে রাখা হয়। প্রেরকের দিক থেকে কোয়ারেন্টাইনই সবচেয়ে ক্ষতিকর ফল, কারণ প্রাপক খুঁজতে না গেলে কোনো ফোল্ডারেই বার্তাটি দেখতে পান না। ডিফল্ট নীতিতে এটি সেখানে ১৫ দিন থাকে, আর Standard ও Strict প্রিসেটে ৩০ দিন।

বাল্ক মেইলের জন্য আলাদা একটি পরিমাপ রয়েছে, বাল্ক কমপ্লেইন্ট লেভেল। BCL ১ থেকে ৩ মানে এমন বাল্ক প্রেরক যার বিরুদ্ধে অভিযোগ কম, আর ৮ বা ৯ মানে এমন প্রেরক যার বিরুদ্ধে অভিযোগ বেশি। ডিফল্ট নীতি BCL ৭ থেকে বাল্ক মেইল Junk-এ পাঠায়, Standard প্রিসেট ৬ থেকে এবং Strict ৫ থেকে। আর জুলাই ২০২৬ থেকে একটি নতুন স্তর রয়েছে: প্রচারমূলক ধরনের বাল্ক মেইল তার BCL যা-ই হোক, Promotions ট্যাগ পায়। কোনো অ্যাডমিন "Bulk moves enabled" চালু করে থাকলে, সেটি Promotions ফোল্ডারে যায়। এটি স্প্যাম নয়, আবার Inbox-ও নয়। ফিচারটি এখনো পর্যায়ক্রমে চালু হচ্ছে।

Microsoft-এর এই দুটি ব্যবস্থা একে অপরের থেকে বিচ্ছিন্ন নয়। Microsoft বলছে, Microsoft 365-এর স্প্যাম ফিল্টারিং "আমাদের ভোক্তা প্ল্যাটফর্ম Outlook.com-এর পরিচিত স্প্যাম ও ফিশিং হুমকি এবং ব্যবহারকারীর প্রতিক্রিয়া থেকে শেখে"। তাই hotmail.com পাঠকেরা যা রিপোর্ট করেন, তা ব্যবসায়িক ইনবক্সে ব্যবহৃত ফিল্টারেও প্রভাব ফেলে।

অ্যাডমিনরা কোনো প্রেরককে অনুমোদিত তালিকাতেও রাখতে পারেন। এতে ম্যালওয়্যার ও অত্যন্ত নিশ্চিত ফিশিং ছাড়া অধিকাংশ সুরক্ষা এড়িয়ে যাওয়া যায়। কোনো অংশীদার প্রতিষ্ঠান যদি আপনার ইনভয়েস বারবার Junk-এ পায়, তাহলে তাদের IT টিমই প্রকৃত সিদ্ধান্তটি দেখতে পারে।

হেডারে সিদ্ধান্ত পড়া

Microsoft 365 মেইলবক্স যেভাবে বার্তাটি পেয়েছে, সেই অবস্থায় বার্তাটি হাতে পেলে অ্যান্টি-স্প্যাম হেডার সরাসরি সিদ্ধান্তটি জানায়। X-Forefront-Antispam-Report-এ কয়েকটি গুরুত্বপূর্ণ ফিল্ড থাকে:

  • SFV:SPM মানে স্প্যাম ফিল্টারিং বার্তাটিকে স্প্যাম হিসেবে চিহ্নিত করেছে, SFV:NSPM মানে স্প্যাম নয়, আর SFV:SFE মানে প্রেরক ব্যবহারকারীর Safe Senders তালিকায় থাকায় ফিল্টারিং এড়িয়ে যাওয়া হয়েছে।
  • CAT প্রয়োগ করা নীতির বিভাগ জানায়: SPM, HSPM (উচ্চ-নিশ্চয়তার স্প্যাম), BULK, PHSH, SPOOF।
  • SCL একটি সংখ্যা, -1 অথবা 0 থেকে 9। পুরোনো নির্দেশিকাগুলো এটিকেই সিদ্ধান্ত হিসেবে ধরে। Microsoft-এর বর্তমান SCL পৃষ্ঠা অনুযায়ী, মানটি "স্প্যাম ফিল্টারিং কোনো বার্তাকে স্প্যাম বা উচ্চ-নিশ্চয়তার স্প্যাম হিসেবে শনাক্ত করবে কি না, তা নির্ধারণ করে না", তাই আগে CAT দেখুন।

হেডারে compauth-ও থাকে, এটি SPF, DKIM, DMARC এবং বার্তার অন্যান্য অংশের ভিত্তিতে তৈরি Microsoft-এর সমন্বিত সিদ্ধান্ত। 001 কারণ কোডের অর্থ অন্তর্নিহিত প্রমাণীকরণ ব্যর্থ হয়েছে। সাধারণত এমনটি ঘটে যখন প্রেরক ডোমেইনে কোনো প্রমাণীকরণ রেকর্ড প্রকাশ করা হয়নি বা শুধু দুর্বল নীতি ছিল।

SNDS ও JMRP, এখন Postmaster সাইটে

Smart Network Data Services, অর্থাৎ SNDS, এখন নতুন Postmaster সাইটে রয়েছে এবং sendersupport.olc.protection.outlook.com-এর পুরোনো সাইটটির জায়গা নিয়েছে। এটি প্রতিটি IP ঠিকানা অনুযায়ী রিপোর্ট দেয়। তাই কিছু দেখার আগে আপনাকে প্রমাণ করতে হবে যে IP রেঞ্জটির মালিক আপনি। ডেটায় ইমেলের পরিমাণ, অভিযোগের হার এবং আপনার ট্রাফিকের কতটা ফিল্টার স্প্যাম হিসেবে শনাক্ত করেছে তা বোঝাতে একটি রং থাকে: ১০%-এর নিচে সবুজ, ১০% থেকে ৯০%-এর মধ্যে হলুদ, ৯০%-এর ওপরে লাল। অনুমোদন বা স্থানান্তরের ১০ মাস পর এখন অ্যাক্সেসের মেয়াদ শেষ হয় এবং সেটি নবায়ন করতে হয়।

ছোট প্রেরকের ক্ষেত্রে SNDS কোনো তথ্যই না-ও দেখাতে পারে, কারণ কোনো নির্দিষ্ট দিনে ১০০টির কম বার্তা পাঠানো IP এটি বাদ দিতে পারে। আর আপনি যদি কোনো প্ল্যাটফর্মের শেয়ার করা IP দিয়ে পাঠান, তাহলে ওই ঠিকানাগুলোর মালিক আপনি নন এবং সেগুলো নিবন্ধন করতে পারবেন না।

JMRP, অর্থাৎ Junk Mail Reporting Program, হলো ফিডব্যাক লুপ। SNDS-এর মাধ্যমে নিবন্ধন করুন। এরপর Outlook.com ব্যবহারকারীরা জাঙ্ক হিসেবে চিহ্নিত করা বার্তাগুলোর নির্বাচিত হেডার Microsoft আপনাকে পাঠাবে, যা সাধারণত ৭২ ঘণ্টার মধ্যে শুরু হয়। নতুন IP যোগ করার সঙ্গে সঙ্গে সেগুলোও এতে যোগ করুন।

Microsoft জাঙ্ক অভিযোগের হারকে প্রেরকের সুনামের ক্ষেত্রে "প্রধান কারণগুলোর একটি" বলে, আর SNDS FAQ-তে ০.৩%-এর কম অভিযোগের হারকে "লক্ষ্য হিসেবে ভালো একটি মাত্রা" বলা হয়েছে। নতুন IP-এর জন্য সময় লাগে। Microsoft বলছে, নতুন একটি IP "ইমেলের পরিমাণ ও তালিকার নির্ভুলতার ওপর নির্ভর করে কয়েক সপ্তাহ বা তারও কম সময়ের মধ্যে" পুরোপুরি প্রস্তুত হয়ে যাবে বলে আশা করা যায়। আর না, টাকা দিয়ে ঢোকার মতো কোনো তালিকা নেই। সমস্যা সমাধানের পৃষ্ঠায় প্রশ্ন করা হয়েছে, Outlook.com কি এমন কোনো অনুমোদিত তালিকা চালায়, যাতে একজন প্রেরক অন্তর্ভুক্ত হতে পারেন? উত্তর হলো "না।"

অপর প্রান্তের ব্যক্তি কী পরিবর্তন করতে পারেন

এর কিছু অংশ প্রাপকের নিয়ন্ত্রণে থাকে, তাই পাঠককে সাহায্য করতে বলা যুক্তিসঙ্গত। Outlook.com-এ (Settings, তারপর Mail, তারপর Junk email) একজন ব্যবহারকারী কোনো বার্তাকে Not junk হিসেবে চিহ্নিত করতে পারেন অথবা প্রেরককে Safe senders and domains-এ যোগ করতে পারেন। এই তালিকায় সর্বোচ্চ 10,000টি এন্ট্রি রাখা যায়, এবং Microsoft জানায়, এতে থাকা প্রেরকদের লিংক ও ছবি সাধারণত ডিফল্টভাবে সক্রিয় থাকে। কঠোর নিয়ম ব্যবহার করতে চাইলে ব্যবহারকারী "exclusive" মোডও চালু করতে পারেন, যা শুধু Contacts ও Safe Senders থেকে আসা ইমেল গ্রহণ করে।

Junk বোতামটি উল্টোভাবে কাজ করে। একই প্রেরকের ভবিষ্যৎ ইমেল ব্লক করা উচিত কি না, তা নির্ধারণে Microsoft এসব রিপোর্ট ব্যবহার করে। আলাদাভাবে, প্রেরকদের জন্য তাদের সুপারিশে একটি "স্পষ্টভাবে দৃশ্যমান" আনসাবস্ক্রাইব লিংক রাখতে বলা হয়েছে। Microsoft-এর লেখায় Gmail ও Yahoo-এর আবশ্যক এক-ক্লিক List-Unsubscribe হেডারের উল্লেখ নেই, তবে একই ক্যাম্পেইন যেহেতু তিনটিতেই যায়, তাই আমি সব ক্ষেত্রেই এগুলো যোগ করতাম (হেডার দুটি)।

ডেস্কটপ অ্যাপের নিজস্ব Junk Email Filter রয়েছে। ডিফল্টভাবে এটি "No Automatic Filtering"-এ সেট করা থাকে। এর ওপরে Low, High এবং "Safe Lists Only" অপশন রয়েছে। শেষেরটি ব্যবহারকারীর নিরাপদ তালিকার বাইরে থেকে আসা সবকিছুকে জাঙ্ক হিসেবে বিবেচনা করে। নিরাপদ ও ব্লক করা প্রেরকের তালিকাগুলো সার্ভারের সঙ্গে সিঙ্ক হয় এবং সেখানেও ব্যবহৃত হয়।

এরপর আছে Focused Inbox, যা ইনবক্সকে Focused ও Other-এ ভাগ করে এবং Microsoft-এর ভাষায়, "স্বয়ংক্রিয়ভাবে তৈরি বা বাল্ক ইমেলের মতো বিরক্তিকর উৎস ফিল্টার করে বাদ দেয়"। Other হলো ইনবক্সের একটি ট্যাব, এবং আমার ব্যাখ্যা অনুযায়ী সেখানে থাকা কোনো নিউজলেটার ইতিমধ্যেই স্প্যাম ফিল্টারিং পেরিয়ে এসেছে।

আসল ইমেল পাঠানোর আগে পরীক্ষা

Microsoft-এর নিজস্ব সমস্যা সমাধান পৃষ্ঠায় বলা হয়েছে, তারা "সরাসরি যোগাযোগ পাঠানোর আগে ইমেল পরীক্ষা করার জোরালো পরামর্শ দেয়"। Email Spam Tester এই ধাপটিই সম্পন্ন করে। আপনি যে সার্ভার বা প্ল্যাটফর্ম সত্যিই ব্যবহার করবেন, সেটি থেকে পৃষ্ঠাটির তৈরি করা ঠিকানায় আসল বার্তাটি পাঠান। প্রতিবেদনে ৪২টি পরীক্ষার ফল দেখানো হয়: অ্যালাইনমেন্টসহ SPF, DKIM ও DMARC, রিভার্স DNS, ২১টি ব্লকলিস্টে প্রেরণকারী IP (এগুলো কেন গুরুত্বপূর্ণ), আনসাবস্ক্রাইব হেডার এবং কনটেন্ট। ব্যর্থ পরীক্ষার সঙ্গে সমাধানের পরিকল্পনা ও কপি করার জন্য DNS রেকর্ড দেওয়া হয়। প্রতিটি সমাধানে কত পয়েন্ট পাওয়া যাবে, তা স্কোরিং টেবিল থেকে নির্ধারিত হয়।

ইনবক্স প্লেসমেন্ট টেস্ট যোগ করলে একই বার্তা Gmail, Outlook, Yahoo ও অন্যান্য প্রদানকারীর ইনবক্সেও যায়। প্রতিবেদনটি সংশ্লিষ্ট মেইলবক্স থেকেই তথ্য নিয়ে দেখায়, প্রতিটিতে বার্তাটি কোথায় পৌঁছেছে। প্রদানকারী এভাবে বাছাই করলে Focused বা Other-ও দেখানো হয়। এটি বিনামূল্যে, সাইন আপের প্রয়োজন নেই। ডকুমেন্টেশনে প্রতিটি পরীক্ষা এবং তাতে কত পয়েন্ট কাটা যায় তা ব্যাখ্যা করা হয়েছে।

আপনার পরবর্তী পদক্ষেপ যদি সাপোর্ট টিকিট খোলা হয়, মনে রাখবেন Microsoft-এর ডেলিভারেবিলিটি ফর্মে শুধু @outlook.com, @hotmail.com, @live.com ও @msn.com ঠিকানা-সংক্রান্ত কেস গ্রহণ করা হয়। নীতিমালার পৃষ্ঠায় সতর্ক করা হয়েছে, আপনি নিয়ম মেনে না চললে "আমাদের সাপোর্ট টিমের পক্ষে আপনাকে সহায়তা করা সম্ভব নাও হতে পারে।"

ব্লগ থেকে আরও লেখা

আগে আসল ইমেলটি একটি টেস্ট ঠিকানায় পাঠান

SPF, DKIM, DMARC, ব্লকলিস্ট, আনসাবস্ক্রাইব হেডার ও কনটেন্টের ওপর ৪২টি পরীক্ষা, সঙ্গে Gmail, Outlook, Yahoo ও অন্যান্য প্রদানকারীতে এটি কোন ফোল্ডারে পৌঁছায়। বিনামূল্যে, সাইনআপ ছাড়াই।

একটি টেস্ট ঠিকানা নিন