Defaults.Exposed › প্রতিবেদন
আমার SPF কেন ব্যর্থ হচ্ছে? UK এবং EU প্রেরকদের জন্য SaaS ১০-লুকআপ সমস্যা (২০২৬)
প্রকাশিত 2026-07-09
2026-06-29 পর্যন্ত পরিসংখ্যান · পদ্ধতি v7। 261 মিলিয়ন গ্রেড করা ডোমেইন জুড়ে সমষ্টিগত সেন্সাস ডেটা। দেখুন আমরা কীভাবে গ্রেড করি।
যখন UK বা EU-তে SaaS টুল ব্যবহারকারী একটি ব্যবসার SPF ব্যর্থ হয়, সবচেয়ে সম্ভাব্য কারণ হলো একটি একক RFC নিয়ম যা আপনাকে কখনো ভাবতে হয়নি: ১০টি DNS লুকআপের পরে, SPF “ফেল” ফেরত দেয় না — এটি PermError ফেরত দেয়, যার মানে রেকর্ডটি এমনভাবে ব্যবহার করা হয় যেন এটি বিদ্যমান নেই। কমপক্ষে 797,263 ডোমেইন ইতিমধ্যে সেই সীমা অতিক্রম করেছে। আরও 2,119,539 ঠিক ৯–১০ লুকআপে বসে আছে — একটি নতুন টুল যোগ করলেই একই ক্লিফের মুখে পড়বে।
SaaS টুল যোগ করলে SPF কেন ভাঙে?
SPF কাজ করে আপনার ডোমেইনের পক্ষে মেইল পাঠাতে অনুমোদিত মেইল সার্ভারগুলো তালিকাভুক্ত করে। আধুনিক ব্যবসাগুলো নিজস্ব মেইল সার্ভার চালায় না — তারা অভ্যন্তরীণ ইমেইলের জন্য Google Workspace, প্রচারাভিযানের জন্য Mailchimp, বিক্রয় ক্রমের জন্য HubSpot, CRM আউটরিচের জন্য Pipedrive ব্যবহার করে। প্রতিটি প্ল্যাটফর্ম আপনাকে আপনার DNS-এ পেস্ট করার জন্য একটি include: লাইন দেয়।
সমস্যা: প্রতিটি include: নিজেই একটি DNS লুকআপ। এবং সেই include-এর ভেতরের প্রতিটি রেকর্ড পুনরাবৃত্তিমূলকভাবে আরও লুকআপ ট্রিগার করতে পারে। RFC 7208 §4.6.4 দশটির একটি কঠোর সীমা নির্ধারণ করে। দশের পরে, প্রাপ্তি মেইল সার্ভার মূল্যায়ন বন্ধ করে এবং PermError ফেরত দেয় — এবং একটি PermError একটি নরম ব্যর্থতা নয় যা স্প্যামে শেষ হয়। এর মানে আপনার SPF রেকর্ডটি অনুপস্থিত হিসেবে বিবেচনা করা হয়। SPF পা-এ ইমেইল প্রমাণীকরণ ব্যর্থ হয়।
আপনি আপনার DNS প্যানেলে এটি দেখবেন না। কাউন্টার শুধুমাত্র লাইভ মূল্যায়নের সময় চালু হয়। আপনার দৃশ্যমান রেকর্ডে তিনটি include: লাইন থাকতে পারে এবং তবুও বারোটি লুকআপ গভীরে থাকতে পারে, কারণ প্রতিটি বিক্রেতার SPF রেকর্ড তার নিজস্ব সাব-include টানে।
কত ডোমেইন ইতিমধ্যে সীমা ছাড়িয়ে গেছে?
কমপক্ষে 797,263। এটি সেই গণনা যা আমরা প্রতিটি SPF include: লক্ষ্য ১০০ বা তার বেশি বার রেফারেন্স করা সমাধান করার পরে — 10,842টি পৃথক লক্ষ্য 95.2% সমস্ত include রেফারেন্স কভার করে — এবং প্রতিটি ডোমেইনের সম্পূর্ণ চেইনের মূল্য নির্ধারণ করে। পৃষ্ঠ গণনা (আপনি একটি রেকর্ডে শুধুমাত্র দৃশ্যমান লাইন গণনা করে যা পাবেন) প্রায় 7,958 খুঁজে পায়। চেইন-মূল্যনির্ধারণকৃত পরিসংখ্যান 100 গুণ বড়, কারণ প্রায় সমস্ত ক্ষতি include লক্ষ্যগুলোর ভেতরে অদৃশ্য।
একটি ইউরোপীয় ব্যবসাকে সবচেয়ে বেশি প্রভাবিত করার পরিস্থিতি:
| পরিস্থিতি | কী ঘটে |
|---|---|
| Google Workspace + Mailchimp + HubSpot + আরও একটি | সম্ভবত ১০ লুকআপে বা তার উপরে |
| IONOS হোস্টিং + যেকোনো তিনটি SaaS টুল | উচ্চ ঝুঁকি: IONOS-এর নিজস্ব SPF লক্ষ্য একাধিক হপ যোগ করে |
| OVH হোস্টিং + দুটি লেনদেনমূলক টুল + একটি CRM | ঝুঁকি মূল্যায়নের সময় OVH SPF গভীরতার উপর নির্ভর করে |
| Microsoft 365 একা | কম ঝুঁকি: Microsoft-এর SPF কম্প্যাক্ট এবং ভালো-রক্ষণাবেক্ষণ |
ইউরোপীয় হোস্টিং প্রদানকারী এবং দুর্বল SPF ডিফল্ট
আপনি যে হোস্টিং প্রদানকারী দিয়ে শুরু করেছেন তা গুরুত্বপূর্ণ — কারণ কিছু SPF ডিফল্ট সেট করে যা একটি একক SaaS টুল সংযোগ করার আগেই আপনার দশটি লুকআপের বেশ কয়েকটি খরচ করে।
আমাদের সেন্সাসে ইউরোপীয় ডোমেইন দ্বারা ব্যবহৃত বৃহত্তম হোস্টিং প্রদানকারীদের মধ্যে:
| প্রদানকারী | এটি ব্যবহার করা ডোমেইন | SPF কঠোর (-all) | DMARC প্রয়োগকারী |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS আলাদাভাবে দাঁড়িয়ে আছে: 1.0% IONOS-হোস্টেড ডোমেইনে প্রয়োগকারী DMARC আছে, যার মানে অপ্রতিরোধ্য সংখ্যাগরিষ্ঠের কার্যত কোনো অর্থপূর্ণ প্রেরক প্রমাণীকরণ নেই। OVH ডোমেইনগুলো SPF কঠোর সেটিংয়ে (43.7%) ভালো করে কিন্তু DMARC প্রয়োগে 2.2%-এ পড়ে — SPF একা, DMARC ছাড়া এটিকে From: হেডারের সাথে বেঁধে দিতে, শুধুমাত্র খামটি রক্ষা করে, প্রাপক যা দেখেন তা নয়।
Microsoft 365 একটি ভালো উপায়ে আলাদা: 85.0% Microsoft-হোস্টেড ডোমেইন কঠোর SPF ব্যবহার করে, মূলত কারণ Microsoft-এর মেইল-ফ্লো উইজার্ড ডিফল্টে -all সেট করে। Google Workspace ডিফল্টে ~all (softfail) সেট করে, 92% এর ডোমেইনকে কঠোর সুরক্ষা ছাড়া রাখে।
৬০ সেকেন্ডে আপনার SPF ব্যর্থতা কীভাবে নির্ণয় করবেন
দ্রুততম চেক হলো একটি বিনামূল্যে টুল যা সম্পূর্ণ লুকআপ চেইন মূল্যায়ন করে — শুধু দৃশ্যমান রেকর্ড নয়। কমান্ড লাইনে nslookup -type=TXT yourdomain.com চালান এবং আপনি দেখা প্রতিটি include: গণনা করুন। তারপর সেই রেকর্ডগুলোর প্রতিটি দেখুন এবং তাদেরটি গণনা করুন। আপনি include-এর আগে আঙুল শেষ করে ফেললে, আপনি বিপদ অঞ্চলে আছেন।
আরও নির্ভরযোগ্য পদ্ধতি: এখানে আপনার ডোমেইন পরীক্ষা করুন — স্ক্যানার সম্পূর্ণ সমাধান চেইন মূল্যায়ন করে, PermError ফ্ল্যাগ করে, এবং আপনাকে দেখায় কোন মেকানিজমগুলো আপনার লুকআপ বাজেট ব্যয় করছে।
তিনটি ডায়াগনস্টিক ফলাফল:
- PermError — আপনি ইতিমধ্যে দশের উপরে আছেন। আপনি পাঠানো প্রতিটি ইমেইল রিসিভারে SPF চেক ব্যর্থ করে।
- ৯–১০ লুকআপে — আপনি ক্লিফে আছেন। পরবর্তী SaaS ইন্টিগ্রেশন আপনাকে টেলিয়ে দেবে।
- Softfail (~all) hardfail-এর পরিবর্তে (-all) — আপনি সীমার নিচে আছেন কিন্তু রেকর্ডটি বাস্তব সুরক্ষা প্রদানের জন্য খুব অনুমতিমূলকভাবে সেট করা আছে।
-allবনাম~all-এর সম্পূর্ণ চিত্রের জন্য SPF ভুল কনফিগারেশন রিপোর্ট দেখুন।
একাধিক SaaS টুল ব্যবহার করলে SPF কীভাবে ঠিক করবেন
স্থায়িত্বের ক্রম অনুসারে তিনটি পদ্ধতি আছে:
১. অডিট করুন এবং ছাঁটাই করুন। আপনার বর্তমান রেকর্ডে প্রতিটি include: তালিকা করে শুরু করুন। আপনি আর ব্যবহার করছেন না এমন কোনো প্ল্যাটফর্ম সরিয়ে ফেলুন — পুরনো ESP, আগের চুক্তির CRM টুল, আপনি পরীক্ষা করেছিলেন কিন্তু ত্যাগ করেছেন এমন প্ল্যাটফর্ম। এটি বিনামূল্যে এবং প্রায়শই বেশ কিছু লুকআপ পুনরুদ্ধার করে। প্রতিটি সরানো include: ১–৩ সাব-লুকআপ দূর করতে পারে।
২. আপনার SPF রেকর্ড ফ্ল্যাটেন করুন। SPF ফ্ল্যাটেনিং সমস্ত include: লক্ষ্যগুলোকে তাদের অন্তর্নিহিত IP রেঞ্জে সমাধান করে এবং সেগুলো সরাসরি আপনার রেকর্ডে ip4: এবং ip6: মেকানিজম হিসেবে লেখে। IP মেকানিজম লুকআপ ট্রিগার করে না, তাই একটি ফ্ল্যাটেন করা রেকর্ড ডজন ডজন পাঠানোর উৎস তালিকা করতে পারে এবং তবুও শূন্য লুকআপে থাকতে পারে। নেতিবাচক দিক: একটি বিক্রেতা তাদের পাঠানোর IP আপডেট করলে এবং আপনি পুনরায় ফ্ল্যাটেন না করলে, আপনি তাদের মেইল প্রত্যাখ্যান করা শুরু করবেন। বেশিরভাগ ব্যবসা একটি পেইড SPF ফ্ল্যাটেনিং সার্ভিস ব্যবহার করে (PowerDMARC, EasyDMARC, Dmarcian, এবং অন্যরা এটি অফার করে) বা একটি মনিটরিং ওয়ার্কফ্লো তৈরি করে।
৩. SPF ম্যাক্রো ব্যবহার করুন। RFC 7208 ম্যাক্রো আপনাকে include-এর একটি চেইনের পরিবর্তে প্রতি-চেকে একটি একক DNS লুকআপ করে এবং গতিশীলভাবে উত্তর দেয় এমন রেকর্ড তৈরি করতে দেয়। ম্যাক্রোগুলোর DNS হোস্টিং সমর্থন এবং কিছু বাস্তবায়ন প্রচেষ্টা প্রয়োজন, কিন্তু তারা অনেক SaaS প্রেরক সহ সংস্থার জন্য আর্কিটেকচারালি পরিষ্কার সমাধান।
SPF ঠিক করার পরে, এটিকে DMARC প্রয়োগের সাথে যুক্ত করুন — DMARC ছাড়া SPF শুধুমাত্র খামের প্রেরককে প্রমাণীকরণ করে, হেডার From: ঠিকানা নয় যা প্রাপকরা দেখেন।
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
কেন আমার SPF রেকর্ড আমার DNS টুলে পাস করে কিন্তু ইমেইল হেডারে এখনও ব্যর্থ হয়?
বেশিরভাগ DNS লুকআপ টুল শুধুমাত্র আপনার নিজের রেকর্ডে দৃশ্যমান মেকানিজম গণনা করে, সেই মেকানিজমগুলো যে সাব-লুকআপ ট্রিগার করে তা নয়। আপনার কাছে দুটি include: লাইন থাকতে পারে এবং তবুও সীমার উপরে থাকতে পারে যদি প্রতিটি বিক্রেতার রেকর্ডে আরও বেশ কিছু থাকে। শুধুমাত্র একটি চেইন-মূল্যনির্ধারণ টুল (বা একটি প্রাপ্তি মেইল সার্ভার) সম্পূর্ণ গভীরতা গণনা করে। বাস্তব চেইন গণনা দেখতে আপনার ডোমেইন পরীক্ষা করুন।
SPF ব্যর্থ হলে কি আমার ইমেইল স্প্যামে যায়?
PermError (অনেক বেশি লুকআপ) মানে SPF প্রমাণীকরণের পা একটি অ-ফলাফল ফেরত দেয় — কার্যত অনুপস্থিত। DMARC উভয় SPF এবং DKIM মূল্যায়ন করে; যদি DKIM পাস করে, SPF PermError সত্ত্বেও DMARC এখনও পাস করতে পারে। যদি কোনোটিই পাস না করে, DMARC ব্যর্থ হয়, এবং ফলাফল আপনার DMARC নীতির উপর নির্ভর করে। p=none-এ, ইমেইল এখনও ডেলিভার হয় কিন্তু ব্যর্থতা লগ করা হয়। p=quarantine বা p=reject-এ, ইমেইল ফিল্টার বা বাউন্স হয়। SPF ঠিক করুন যাতে আপনি শুধুমাত্র DKIM-এর উপর নির্ভর না করেন।
একটি সাধারণ SaaS স্ট্যাক কত লুকআপ ব্যবহার করে? আমাদের সেন্সাসে p99 SPF রেকর্ড ইতিমধ্যে 9 লুকআপে — সীমার ঠিক সময়ে — কিছু যোগ করার আগে। একটি Google Workspace রেকর্ড ৩–৪ লুকআপ যোগ করে; Mailchimp ১–২; HubSpot তাদের বর্তমান কনফিগারেশনের উপর নির্ভর করে ১–৩। তিনটি মূলধারার টুল এছাড়াও আপনার হোস্টিং প্রদানকারীর ডিফল্ট প্রায়শই দশের উপরে টিপ দেওয়ার জন্য যথেষ্ট।
SPF ফ্ল্যাটেনিং কি নিরাপদ?
হ্যাঁ, তবে আপনি এটি বর্তমান রাখলে। ফ্ল্যাটেনিং include: চেইনগুলোকে স্ট্যাটিক IP রেঞ্জে রূপান্তরিত করে — যদি একটি বিক্রেতা তাদের পাঠানোর IP ঘোরায় এবং আপনি পুনরায় ফ্ল্যাটেন না করেন, আপনি তাদের মেইল প্রত্যাখ্যান করা শুরু করবেন। বেশিরভাগ সংস্থা একটি পরিচালিত ফ্ল্যাটেনিং সার্ভিস ব্যবহার করে যা IP পরিবর্তনগুলো মনিটর করে ম্যানুয়ালি বজায় রাখার পরিবর্তে।
আমার SPF বছরের পর বছর ধরে এমন ছিল — এটি হঠাৎ কেন ব্যর্থ হচ্ছে? কারণ আপনার বিক্রেতারা তাদের SPF রেকর্ড আপডেট করেছে, আপনারটি নয়। প্রতিবার একটি SaaS প্ল্যাটফর্ম একটি নতুন পাঠানোর IP রেঞ্জ যোগ করে বা অন্য include নেস্ট করে, আপনার চেইন খরচ আপনার পক্ষে কোনো পরিবর্তন ছাড়াই বৃদ্ধি পায়। ১০-লুকআপ সীমা বার্তা প্রাপ্তিতে লাইভ মূল্যায়ন করা হয়, তাই মঙ্গলবার সকালে একটি বিক্রেতা পরিবর্তন মঙ্গলবার বিকেলে আপনার SPF ভাঙতে পারে।
SPF ঠিক করলে কি ইমেইল ডেলিভারযোগ্যতা উন্নত হয়? এটি প্রমাণীকরণ ব্যর্থতার একটি উৎস সরিয়ে দেয়, যা ধারাবাহিক ডেলিভারির পূর্বশর্ত — বিশেষ করে যেহেতু Google এবং Yahoo এখন বাল্ক প্রেরকদের জন্য DMARC সংযোজন প্রয়োগ করে। SPF একাই সম্পূর্ণ চিত্র নয়: সম্পূর্ণ ইমেইল প্রমাণীকরণের জন্য এটিকে DKIM এবং DMARC-এর সাথে যুক্ত করুন।
আপনার SPF বিনামূল্যে পরীক্ষা করুন
আপনি নিশ্চিত না হলে যে আপনার SPF রেকর্ড লুকআপ সীমার উপরে আছে কিনা — বা আপনার ডোমেইন রক্ষা করার জন্য খুব দুর্বলভাবে সেট করা আছে কিনা — একটি বিনামূল্যে চেক চালান। এটি সম্পূর্ণ সমাধান চেইন মূল্যায়ন করে এবং আপনাকে দেখায় বাজেটটি ঠিক কোথায় ব্যয় হচ্ছে।
আপনার ডোমেইন পরীক্ষা করুন → · SPF ঠিক করুন → · SPF PermError রিপোর্ট → · SPF ভুল কনফিগারেশন রিপোর্ট → · SPF গ্রহণ পরিপক্কতা মডেল → · DMARC ঠিক করুন → · শুধুমাত্র সমষ্টিগত ডেটা। ডেটা EU-তে সংরক্ষিত এবং প্রক্রিয়াজাত।