Defaults.Exposed › সমাধান › Guides

SPF PermError: ইমেইল না ভেঙে 'অতিরিক্ত DNS Lookup' কীভাবে ঠিক করবেন (২০২৬)

প্রকাশিত 2026-07-08

2026-06-29 তারিখের তথ্য · পদ্ধতি v7। 261 মিলিয়ন গ্রেডকৃত ডোমেইন জুড়ে সমন্বিত জনগণনা তথ্য। দেখুন আমরা কীভাবে গ্রেড করি।

Defaults.Exposed জনগণনা অনুযায়ী 261,086,232 ডোমেইনের মধ্যে কমপক্ষে 797,263 ডোমেইন SPF-এর ১০-DNS-lookup সীমা ভাঙে — 139 মিলিয়ন SPF প্রকাশকের মধ্যে। দশ lookup-এর পরে রিসিভার থামে এবং PermError ফেরত দেয়: আপনার SPF শূন্য, এবং DMARC একটি PermError-কে ব্যর্থতা হিসেবে গণনা করে।

সমাধানের একটি কঠোর ক্রম আছে, এবং বেশিরভাগ গাইড এটি উল্টো পায়। আপনার আসল, resolved lookup গণনা করুন; মৃত এবং অব্যবহৃত include মুছুন — এটি একাই বেশিরভাগ রেকর্ড ঠিক করে; bulk sender গুলিকে তাদের নিজস্ব SPF বাজেট সহ subdomain-এ সরান; শুধুমাত্র শেষ উপায় হিসেবে flatten করুন, এবং শুধুমাত্র automated re-flattening সহ, কারণ static flattening পচে এবং নীরবে ডেলিভারি ভাঙে।

“SPF PermError: too many DNS lookups” মানে কী?

RFC 7208 §4.6.4 প্রতিটি SPF চেককে ১০ DNS lookup-এ সীমাবদ্ধ করে। দশের পরে, রিসিভার থামে এবং PermError ফেরত দেয় — সম্পূর্ণ রেকর্ড ভাঙা হিসেবে বিবেচিত হয়, শুধু বাজেটের অতিরিক্ত অংশ নয়। একই বিভাগে একটি কম-পরিচিত দ্বিতীয় সীমাবদ্ধতা যোগ করা হয়েছে: সর্বোচ্চ ২ “void lookup” (কোনো উত্তর বা NXDOMAIN ফেরত দেওয়া queries), তাই বাতিল সেবার জন্য কয়েকটি মৃত include: এন্ট্রি নিজেরাই আপনার SPF বাতিল করতে পারে।

পরিণতি “কোনো SPF নেই”-এর চেয়ে খারাপ: DMARC একটি PermError-কে SPF ব্যর্থতা হিসেবে গণনা করে, তাই একটি ডোমেইন যা তার নিজস্ব SPF ভাঙে প্রতিটি DMARC মূল্যায়নের SPF লেগে unauthenticated। DKIM সেটআপ না থাকলে বা ট্রান্জিটে ভাঙলে, সেই মেইল এখন সরাসরি DMARC ব্যর্থ করে।

একটি জনগণনা সংখ্যা দেখায় এই ব্যর্থতা মোড কতটা নিষ্ঠুর: 112,215 ডোমেইন একটি strict -all রেকর্ড প্রকাশ করে যা lookup overflow থেকে শূন্য — 54,655,923 ডোমেইনের মধ্যে যারা -all প্রকাশ করে। তাদের মালিকরা কঠিন অংশ করেছিল — strict শেষ বেছে নিয়েছিল — এবং একটি অতিরিক্ত include সম্পূর্ণ রেকর্ড বন্ধ করে দিয়েছে। তারা strict দেখায়; তারা ভাঙা। সম্পূর্ণ ডেটা চিত্রের জন্য, দেখুন SPF PermError রিপোর্ট।

আমি কিছু পরিবর্তন না করলে কেন আমার SPF ভাঙল?

কারণ বাজেট বেশিরভাগ অন্যদের রেকর্ড দ্বারা খরচ হয়। প্রতিটি include: পুনরাবৃত্তিভাবে মূল্যায়ন হয়, এবং এর ভেতরে প্রতিটি lookup mechanism আপনার দশের বিপরীতে গণনা হয়। আপনার DNS প্যানেলে একটি লাইন একবার resolve হলে চার বা পাঁচটি lookup খরচ করতে পারে। একটি প্রদানকারী আরও একটি include নেস্ট করে, এবং আপনার zone-এ একটিও পরিবর্তন ছাড়াই আপনার SPF মারা যায়।

বড় প্ল্যাটফর্মগুলি সমস্যা নয়: Google এবং Microsoft উভয়ই তাদের নিজস্ব SPF flatten করেছে — _spf.google.com এবং spf.protection.outlook.com শূন্য internal lookup খরচে সাধারণ IP তালিকায় প্রসারিত হয় (জুলাই ২০২৬ live DNS-এর বিপরীতে যাচাই করা)। বাস্তব জীবনের blowout আসে hosting-panel include chain থেকে যা কয়েক স্তর গভীরে নেস্ট করা, এবং সৎ SaaS স্ট্যাকিং থেকে — মেইলবক্স প্লাস newsletter প্লাস CRM প্লাস helpdesk, প্রতিটি “শুধু একটি include”। কেউ উদ্দেশ্যমূলকভাবে একাদশ lookup যোগ করে না; এটি যুক্তিসঙ্গত সিদ্ধান্তের সমষ্টি হিসেবে আসে। এ কারণেই সীমানা এত ভিড়াক্রান্ত: 2,119,539 ডোমেইন ঠিক ৯–১০ resolved lookup-এ বসে আছে — সমস্ত SPF প্রকাশকের প্রায় ১ in 66, আজ ঠিক আছে, যেদিন কেউ আরও একটি include পেস্ট করবে সেদিন শূন্য। 99th-percentile SPF রেকর্ড ইতিমধ্যে 9 lookup-এ resolve হয়। আপনার স্ট্যাক SaaS-ভারী হলে, SaaS টুলের জন্য SPF ব্যর্থতার গাইড ভেন্ডর-অনুযায়ী সংস্করণ কভার করে।

SPF রেকর্ডের কোন অংশ DNS lookup হিসেবে গণনা হয়?

দৃশ্যমান লাইন নয়, resolved মোট গণনা করুন। চারটি include চার বা চৌদ্দটি lookup হতে পারে।

ইমেইল না ভেঙে “too many DNS lookups” কীভাবে ঠিক করব?

1. DNS স্পর্শ করার আগে বিনামূল্যে স্ক্যান চালান। এটি আপনার সম্পূর্ণ include চেইন resolve করে এবং আপনার আসল lookup সংখ্যা দেখায়, তাই আপনি আসল সমস্যা ঠিক করেন — প্যানেলে যেমন দেখায় তা নয়। (যদি বলে আপনার SPF মোটেই নেই, সেটি ভিন্ন ব্যর্থতা — দেখুন “SPF রেকর্ড পাওয়া যায়নি”।)
2. প্রথমে মৃত এবং অব্যবহৃত include মুছুন। আপনি ২০২৩-এ ছেড়ে দেওয়া টুল, পুরানো হোস্টের include যা migration-এ টিকেছিল, নকল, যেকোনো ptr mechanism। মৃত include দ্বিগুণ বিষাক্ত: তারা lookup বাজেট পোড়ায় এবং সাধারণত void lookup-এর উৎস। বেশিরভাগ over-budget রেকর্ড এই ধাপেই ১০-এর নিচে ফিরে আসে। আপনার রেকর্ডে এখনও পূর্ববর্তী প্রদানকারীর mechanism থাকলে, migration cleanup গাইড অনুসরণ করুন।
3. প্রতিটি বাকি include কিছু করছে কিনা পরীক্ষা করুন। রিসিভাররা Return-Path (RFC5321.MailFrom) ডোমেইনের বিপরীতে SPF মূল্যায়ন করে, From হেডার নয় — এবং অনেক SaaS টুল Return-Path-এ তাদের নিজের bounce ডোমেইন রাখে, তাই আপনার রেকর্ডে তাদের include বাজেট ছাড়া কিছুই করে না। শুধুমাত্র সেই সেবাগুলির জন্য include রাখুন যা আপনার ডোমেইনকে Return-Path হিসেবে ব্যবহার করে; বাকিদের জন্য পরিবর্তে ভেন্ডরের custom-domain DKIM সক্ষম করুন।
4. bulk sender গুলিকে subdomain-এ সরান। news.yourdomain.com থেকে newsletter, mail.yourdomain.com থেকে transactional মেইল। প্রতিটি subdomain তার নিজস্ব SPF রেকর্ড পায় নতুন ১০-lookup বাজেট সহ, এবং একটি stream-এর সমস্যা অন্যগুলিতে bleeding বন্ধ করে।
5. তারপরেই flattening বিবেচনা করুন — এবং শুধুমাত্র automated flattening। নিচে দেখুন।
6. পুনরায় স্ক্যান করুন নিশ্চিত করতে আপনি ১০-এর অনেক নিচে আছেন — headroom লক্ষ্য করুন, ঠিক ১০ নয়, অথবা আপনি সীমানায় 2.1 মিলিয়ন ডোমেইনে আবার যোগ দিয়েছেন। তারপর fix SPF পেজে স্ক্যান যা পতাকা করে তার মধ্য দিয়ে কাজ করুন।

আমার কি SPF রেকর্ড flatten করা উচিত?

Flattening include-গুলিকে তাদের underlying ip4:/ip6: ব্লক দিয়ে প্রতিস্থাপন করে, যা শূন্য lookup খরচ করে। এটি কাজ করে — এবং হাতে করা হলে, এটি একটি delayed-action ডেলিভারি বিভ্রাট।

প্রদানকারীরা নিয়মিত sending IP rotate করে এবং কাউকে ঘোষণা করে না। একটি static IP তালিকা আপনি পেস্ট করার দিন সঠিক এবং মাসের মধ্যে চুপচাপ ভুল — এবং কারণ ব্যর্থতা অন্য মানুষেরা আপনার মেইল না পাওয়া হিসেবে দেখায়, আপনি দেরিতে জানেন। Pruning এবং subdomain আপনাকে সীমার নিচে নিয়ে গেলে, সেখানে থামুন; কখনো একটি স্থায়ী সমাধান হিসেবে তৃতীয় পক্ষের IP ব্লক হাতে কপি করবেন না।

সচরাচর জিজ্ঞাসিত প্রশ্ন

SPF PermError মানে কি আমার ইমেইল ডেলিভার হওয়া বন্ধ হয়? তাৎক্ষণিকভাবে নয় — এটিই এটিকে বিপজ্জনক করে। DMARC একটি PermError-কে SPF ব্যর্থতা হিসেবে গণনা করে, তাই ডেলিভারি সম্পূর্ণভাবে DKIM-এর উপর নির্ভর করে; DKIM অনুপস্থিত বা ট্রান্জিটে ভাঙলে, আপনি DMARC ব্যর্থ করছেন। আমাদের জনগণনায় 139 মিলিয়ন SPF প্রকাশকের মধ্যে (2026-06-29 তারিখ পর্যন্ত), কমপক্ষে 797,263 এই অবস্থায় আছে — বেশিরভাগ না জেনেই।

আমার রেকর্ডে মাত্র চারটি include আছে — কীভাবে ১০-এর বেশি lookup হতে পারে? Include পুনরাবৃত্তিভাবে গণনা হয়: প্রতিটি include-এর ভেতরে সবকিছু (এবং এর include-এর ভেতরে) আপনার বাজেটের বিপরীতে চার্জ হয়, তাই চারটি দৃশ্যমান লাইন চৌদ্দটি lookup-এ resolve হতে পারে। চোখ দিয়ে নয়, resolving টুল দিয়ে গণনা করুন — আমাদের PermError রিপোর্ট যেভাবে surface গণনার চেয়ে ~100× বেশি ভাঙা ডোমেইন খুঁজে পেয়েছিল।

আমি আমার রেকর্ড -all দিয়ে শেষ করি — নিশ্চয়ই আমি সুরক্ষিত? শুধুমাত্র যদি রেকর্ড মূল্যায়ন হয়। আমাদের জনগণনা (2026-06-29 তারিখ পর্যন্ত) 112,215 ডোমেইন খুঁজে পেয়েছে যাদের strict -all রেকর্ড lookup overflow থেকে শূন্য। একটি PermError রেকর্ডে strict qualifier কিছুই রক্ষা করে না।

সীমা কি include প্রতি ১০ lookup নাকি সম্পূর্ণ রেকর্ডের? সম্পূর্ণ মূল্যায়ন: RFC 7208 §4.6.4 সম্পূর্ণ চেককে ১০-এ সীমাবদ্ধ করে, প্লাস সর্বোচ্চ ২ void lookup। প্রতিটি subdomain-এর নিজস্ব রেকর্ড এবং বাজেট আছে — এজন্যই ধাপ ৪ কাজ করে।

ip4 এবং ip6 এন্ট্রি কি সীমার দিকে গণনা হয়? না — IP mechanism কিছুই খরচ করে না, এজন্যই flattening গণনা কমায়।

মালিককে রিপোর্ট পাঠান

আপনি যদি কোনো ক্লায়েন্ট বা নিয়োগকর্তার জন্য এটি ঠিক করছেন, প্রমাণ সহ কাজ শেষ করুন। আপনার পরিবর্তনের পরে বিনামূল্যে স্ক্যান পুনরায় চালান এবং গ্রেডকৃত রিপোর্টটি ব্যবসার মালিকের কাছে ফরওয়ার্ড করুন: সহজ ভাষা, তারিখযুক্ত, PermError চলে গেছে। এটিই সেই artifact যা তাদের cyber-insurance নবায়ন এবং পরবর্তী গ্রাহক নিরাপত্তা প্রশ্নপত্রের জন্য দরকার হবে — “আমি কিছু DNS রেকর্ড পরিবর্তন করেছি” এবং একটি নথিভুক্ত before-and-after-এর মধ্যে পার্থক্য।

বিনামূল্যে আপনার ডোমেইন পরীক্ষা করুন

আপনার আসল, resolved lookup সংখ্যা দেখুন — এবং SPF, DKIM এবং DMARC-এর সবকিছু — ব্যক্তিগতভাবে এবং মালিক-শুধুমাত্র।

আপনার ডোমেইন পরীক্ষা করুন → · SPF ঠিক করুন → · SaaS টুলের জন্য SPF ব্যর্থ হচ্ছে → · GoDaddy-তে SPF সেটআপ করুন → · আমরা কীভাবে গ্রেড করি → · শুধুমাত্র সমন্বিত তথ্য। EU-তে তথ্য সংরক্ষিত এবং প্রক্রিয়া করা হয়।