Email Spam Tester

বিনামূল্যের টুল

ইমেল হেডার বিশ্লেষক

আপনার পাওয়া কোনো বার্তার হেডার পেস্ট করুন। বার্তাটি কোন পথে গেছে, প্রতিটি ধাপে কতক্ষণ আটকে ছিল এবং গ্রহণকারী সার্ভার SPF, DKIM ও DMARC সম্পর্কে কী সিদ্ধান্ত নিয়েছে তা দেখুন।

হেডার কোথায় পাবেন: Gmail ⋮ → আসলটি দেখুন · Outlook ⋯ → দেখুন → বার্তার বিবরণ দেখুন · Apple Mail দেখুন → বার্তা → সব হেডারএকটি নমুনা ব্যবহার করুন

হেডারে IP ঠিকানা ও ইমেল ঠিকানা থাকে। ফলাফল তৈরির জন্য এগুলো মেমরিতে পড়া হয় এবং সংরক্ষণ, ক্যাশ বা লগ করা হয় না।

নিচ থেকে ওপরে ইমেলের পথ পড়ুন

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

কয়েক সেকেন্ডের ব্যবধান স্বাভাবিক। কয়েক মিনিটের ব্যবধান সাধারণত বোঝায় যে বার্তাটি কোনো কিউতে অপেক্ষা করেছে। এর কারণ হতে পারে কোনো গ্রহীতা গ্রেলিস্টিংয়ের জন্য আবার চেষ্টা করতে বলেছে, কোনো রিলে ব্যস্ত ছিল অথবা প্রেরকের নিজস্ব আউটবাউন্ড ফিল্টার বার্তাটি আটকে রেখেছিল। ঘড়ির সময় উল্টো দিকে যাচ্ছে? সার্ভারগুলোর একটিতে ভুল সময় সেট করা আছে।

কোন Authentication-Results বিশ্বাস করবেন

Authentication-Results (RFC 8601) লাইনে গ্রহণকারী সার্ভার তার SPF, DKIM, DMARC এবং কখনো কখনো ARC ফলাফল লেখে। একটি বার্তায় এ ধরনের একাধিক লাইন থাকতে পারে, তবে যে সার্ভার বার্তাটি আপনার কাছে পৌঁছে দিয়েছে, শুধু তার যোগ করা লাইনটিই প্রযোজ্য। এর নিচের সব লাইন আপনার প্রদানকারী বার্তাটি পাওয়ার আগে এমন সব সার্ভার লিখেছে, যেগুলোকে বিশ্বাস করার কোনো কারণ আপনার নেই। প্রেরকও সেখানে ইচ্ছামতো যেকোনো কিছু লিখতে পারে।

বিশ্লেষক সবচেয়ে উপরের ফলাফলটিকে চূড়ান্ত সিদ্ধান্ত হিসেবে ধরে এবং বাকি ফলাফলগুলো আলাদাভাবে দেখায়। এর পাশে অ্যালাইনমেন্ট নির্ধারণকারী তিনটি ডোমেইন দেখা যায়: From ডোমেইন, DKIM d= ডোমেইন এবং যে Return-Path ডোমেইনের বিপরীতে SPF পরীক্ষা করা হয়েছে। From ডোমেইনের সঙ্গে মিলে যাওয়া কোনো ডোমেইনের জন্য SPF বা DKIM পাস করলেই কেবল DMARC পাস করে। এগুলো তুলনা করলেই প্রায়ই ব্যর্থতার কারণ বোঝা যায়।

ইমেল হেডার কোথায় পাবেন

Gmail-এ মেসেজটি খুলুন, Reply-এর পাশের তিনটি ডটে ক্লিক করে Show original বেছে নিন। ওয়েবে Outlook-এ মেসেজটি খুলুন, More actions, তারপর View এবং View message details বেছে নিন। Outlook ডেস্কটপ অ্যাপে File, তারপর Properties-এ যান এবং Internet headers নামের বক্সটি দেখুন। Apple Mail-এ View, Message, All Headers বেছে নিন। প্রথম ফাঁকা লাইন পর্যন্ত সবকিছু কপি করুন, কারণ সেখান থেকেই বডি শুরু হয়। আপনি পুরো মেসেজ পেস্ট করলে বিশ্লেষণের আগে বডি বাদ দেওয়া হবে।

হেডারে IP ঠিকানা ও ইমেল ঠিকানা থাকে। ফলাফল তৈরির জন্য এগুলো মেমরিতে পড়া হয় এবং সংরক্ষণ, ক্যাশ বা লগ করা হয় না।

পরিবর্তে একটি আসল ইমেল পরীক্ষা করুন

এই টুলগুলোর প্রতিটি আপনার সেটআপের একটি অংশ পরীক্ষা করে। পূর্ণাঙ্গ পরীক্ষাটি ইমেলটিই বিশ্লেষণ করে: একটি অস্থায়ী ঠিকানায় একটি বার্তা পাঠান এবং গ্রহণকারী সার্ভার যেভাবে SPF, DKIM ও DMARC মূল্যায়ন করেছে, সেই ফলাফলসহ ব্ল্যাকলিস্ট, কনটেন্ট, উভয় স্প্যাম স্কোর ও সমাধানের পরিকল্পনা পান। Gmail, Outlook, Yahoo ও অন্যান্য প্রদানকারীতে এটি কোন ফোল্ডারে পৌঁছায়, তা দেখতে ইনবক্স প্লেসমেন্ট যোগ করুন।

আপনার ইমেল পরীক্ষা করুননমুনা রিপোর্ট দেখুন

প্রশ্ন

ইমেল হেডার কীভাবে পড়বেন?

সবচেয়ে নিচের Received লাইন থেকে শুরু করে ওপরের দিকে যান। সার্ভারগুলো যে ক্রমে মেসেজটি প্রক্রিয়া করেছে, এটি সেই ক্রম। এরপর আপনার নিজস্ব প্রদানকারীর যোগ করা সবচেয়ে উপরের Authentication-Results লাইনে SPF, DKIM ও DMARC ফলাফল দেখুন।

DKIM পাস করলেও DMARC কেন ব্যর্থ হয়?

DMARC-এর জন্য এমন একটি পাস করা DKIM স্বাক্ষর প্রয়োজন, যার d= ডোমেইন From ডোমেইনের সঙ্গে মেলে, অথবা এমন একটি Return-Path ডোমেইনের জন্য SPF পরীক্ষা পাস করতে হয়, যা From ডোমেইনের সঙ্গে মেলে। আপনার পাঠানোর প্ল্যাটফর্মের নিজস্ব ডোমেইনের স্বাক্ষর DKIM পাস করতে পারে, কিন্তু তবুও DMARC-এর জন্য কোনো কাজে আসে না। বিশ্লেষক তিনটি ডোমেইন পাশাপাশি দেখায়, তাই অমিলটি স্পষ্টভাবে দেখা যায়।

সম্পূর্ণ নির্দেশিকা: DMARC fail

দুটি হপের মধ্যে দীর্ঘ বিলম্বের অর্থ কী?

যে সার্ভারে বিলম্ব শুরু হয়েছে, মেসেজটি সেখানে অপেক্ষা করেছে। সাধারণ কারণগুলোর মধ্যে আছে greylisting, যেখানে প্রাপক প্রেরককে পরে আবার চেষ্টা করতে বলে, পূর্ণ outbound queue, অথবা মেসেজ পরবর্তী সার্ভারে পাঠানোর আগে স্ক্যান করা কোনো ফিল্টার। কয়েক মিনিটের একটি মাত্র বিলম্ব সাধারণত ডেলিভারেবিলিটি সমস্যা নয়। এটি শুধু ব্যাখ্যা করে কেন মেসেজটি দেরিতে পৌঁছেছে।

ইমেল হেডার কি জাল করা যায়?

প্রেরকের লেখা যেকোনো কিছু জাল করা যায়। আপনার প্রদানকারীর নিজস্ব Received লাইনের নিচের লাইনগুলো এবং পুরোনো Authentication-Results লাইন বানানো হতে পারে। আপনার প্রদানকারী ওপরে যা যোগ করেছে, তা জাল করা যায় না এবং আপনার প্রদানকারী প্রেরকের public key দিয়ে DKIM স্বাক্ষর পরীক্ষা করতে পারে। বিশ্লেষক নিজে স্বাক্ষর যাচাই করে না। এটি সবচেয়ে উপরের লাইন থেকে আপনার প্রদানকারীর সিদ্ধান্ত পড়ে।

হেডারে ARC কী?

ARC (RFC 8617) কোনো forwarding service, যেমন mailing list বা forwarding address-কে মেসেজ পরিবর্তনের আগে দেখা authentication ফলাফল রেকর্ড করতে দেয়। forwarding-এর কারণে SPF বা DKIM নষ্ট হলে চূড়ান্ত প্রাপক সেই রেকর্ড বিশ্বাস করবে কি না, তা সিদ্ধান্ত নিতে পারে।

পাঠানোর আগেই কি মেসেজ পরীক্ষা করতে পারি?

হ্যাঁ। কোনো মেসেজ কোথাও পৌঁছানোর পরেই শুধু হেডার তৈরি হয়। কোনো campaign বা transactional email কারও কাছে পৌঁছানোর আগে পরীক্ষা করতে হোম পেজের একটি টেস্ট ঠিকানায় সেটি পাঠান। একটি রিপোর্টেই আপনি এসব ফলাফলের সঙ্গে ব্ল্যাকলিস্ট, কনটেন্ট, লিংক এবং bulk-sender নিয়মের ফলাফল পাবেন।

Common errors

অন্যান্য ফ্রি টুল