Global SPF Validation Checker
Sender Policy Framework (SPF) হলো একটি ক্রিটিক্যাল ইমেইল অথেন্টিকেশন প্রোটোকল যা অথরাইজড সেন্ডিং IP অ্যাড্রেসের একটি ক্রিপ্টোগ্রাফিক হোয়াইটলিস্ট পাবলিশ করে ডোমেইন স্পুফিং (spoofing) প্রতিরোধ করে। আধুনিক ডেলিভারেবিলিটির (deliverability) জন্য SPF প্রোটোকলটি নিজেই অপরিহার্য হলেও, ডেডিকেটেড SPF DNS রেকর্ড টাইপের (Type 99) একটি অবিশ্বাস্যরকম অগোছালো ইতিহাস রয়েছে এবং এটি আনুষ্ঠানিকভাবে অবসোলেট (obsolete) বা অপ্রচলিত হয়ে গেছে।
Record Type 99 এর উত্থান ও পতন
যখন SPF প্রোটোকলটি মূলত কনসেপচুয়ালাইজ করা হয়েছিল (RFC 4408), তখন IETF একটি স্পেসিফিক DNS রিসোর্স রেকর্ড (Type 99) ইঞ্জিনিয়ার করেছিল যা স্ট্যান্ডার্ড TXT ডেটা থেকে SPF পে-লোডগুলোকে আইসোলেট (isolate) করার জন্য সুস্পষ্টভাবে ডিজাইন করা হয়েছিল। থিওরি ছিল যে, একটি ডেডিকেটেড রেকর্ড টাইপ মেইনটেইন করলে রিজলভার পার্সিংয়ের গতি বাড়বে। তবে, রোলআউটটি ছিল একটি বিশাল ব্যর্থতা। লিগ্যাসি DNS সার্ভার, ফায়ারওয়াল এবং হার্ডওয়্যার লোড ব্যালেন্সারগুলো নতুন Type 99 সিনট্যাক্স চিনতে পারেনি এবং প্রায়শই প্যাকেট ড্রপ করে দিত, যার ফলে ব্যাপক মাত্রায় ইমেইল আউটএজ (outages) দেখা দেয়। এই হার্ডওয়্যার ইনকম্প্যাটিবিলিটির (incompatibility) কথা স্বীকার করে, IETF RFC 7208 পাবলিশ করে, যা আনুষ্ঠানিকভাবে Type 99 রেকর্ডটিকে অবমূল্যায়ন (deprecated) করে। আজ, সমস্ত SPF কনফিগারেশন স্ট্যান্ডার্ড TXT রেকর্ড হিসেবে পাবলিশ করা বাধ্যতামূলক। কোনো অ্যাডমিনিস্ট্রেটর যদি লিগ্যাসি Type 99 SPF রেকর্ড ডিপ্লয় করা চালিয়ে যান, তবে Microsoft Exchange এবং Google Workspace-এর মতো আধুনিক প্ল্যাটফর্মগুলো এটিকে সম্পূর্ণ ইগনোর করবে, যার ফলে তাৎক্ষণিক DMARC ফেইলর ঘটবে।
মেকানিক্যাল 10-Lookup Limit
SPF ম্যানেজ করা ডেভেলপারদের জন্য সবচেয়ে বড় টেকনিক্যাল ফেইলর পয়েন্ট হলো কঠোর 10-লুকআপ থ্রেশহোল্ড (threshold)। যেহেতু একটি SPF রেকর্ড অ্যাডমিনিস্ট্রেটরদের include: ডিরেক্টিভ ব্যবহার করে অন্যান্য ডোমেইন পলিসি নেস্ট (nest) করার অনুমতি দেয় (যেমন, include:_spf.salesforce.com), তাই একটি রিসিভিং মেইল সার্ভারকে অবশ্যই সেই থার্ড-পার্টি প্রোভাইডার থেকে IP আনার জন্য একটি রিকার্সিভ DNS কোয়েরি পারফর্ম করতে হবে। অসীম রাউটিং লুপ এবং টার্গেটেড DDoS অ্যামপ্লিফিকেশন (amplification) অ্যাটাক থেকে MTA-গুলোকে রক্ষা করতে, প্রোটোকলটি 10টি রিকার্সিভ DNS লুকআপে এক্সিকিউশনের ওপর হার্ড-ক্যাপ আরোপ করে। কোনো কোম্পানি যদি খুব বেশি SaaS প্রোভাইডারকে একসাথে চেইন করে এবং 11টি লুকআপে হিট করে, তবে এক্সিকিউশন থেমে যায়, এবং একটি SPF "PermError" রিটার্ন করে। এর ফলে তাৎক্ষণিকভাবে লেজিটিমেট (legitimate) আউটবাউণ্ড ইমেইলগুলো হার্ড-বাউন্স (hard-bounce) করে বা কোয়ারেন্টাইনে চলে যায়।
Flattening এবং Diagnostics
লুকআপ লিমিটেশন বাইপাস করতে, নেটওয়ার্ক ইঞ্জিনিয়াররা "SPF Flattening" টুল ব্যবহার করেন। এই স্ক্রিপ্টগুলো প্রতি ঘণ্টায় রান করে, API এর মাধ্যমে সমস্ত include: ডিরেক্টিভগুলো এক্সপ্যান্ড (expand) করে, হোস্টনেমগুলো বাদ দেয় এবং র (raw) IPv4/IPv6 ব্লকগুলোকে একটি বিশাল, ফ্ল্যাট TXT রেকর্ডে কম্পাইল করে। একটি গ্লোবাল ডায়াগনস্টিক চেকার ব্যবহার করা নিশ্চিত করে যে আপনার সিনট্যাক্স ভ্যালিড, আপনার নেস্টেড ইনক্লুডগুলো (nested includes) সাইলেন্টলি DNS থ্রেশহোল্ড অতিক্রম করেনি, এবং স্পুফ করা পে-লোড রিজেক্ট করার জন্য আপনার পলিসি স্পষ্টভাবে একটি রেস্ট্রিক্টিভ -all (fail) বা ~all (softfail) ফ্ল্যাগ দিয়ে শেষ হয়েছে।