'SPF রেকর্ড পাওয়া যায়নি' — কিন্তু আপনার একটি আছে? ৫টি আসল কারণ (২০২৬)

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

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

চেকার “SPF রেকর্ড পাওয়া যায়নি” বললে কিন্তু আপনি নিশ্চিত একটি প্রকাশ করেছেন, রেকর্ড সাধারণত অনুপস্থিত নয় অদৃশ্য: Defaults.Exposed জনগণনা অনুযায়ী 261 মিলিয়ন ডোমেইন জুড়ে, 1,013,416 ডোমেইন — SPF চেষ্টাকারীদের প্রায় এক in 138 — দুই বা তার বেশি SPF রেকর্ড প্রকাশ করে, একটি PermError (RFC 7208 §3.2) যা অনেক চেকার not-found হিসেবে রিপোর্ট করে।

পাঁচটি আসল কারণ আছে, সব এক বসায় ঠিক করা যায়: ভুল হোস্ট, নকল রেকর্ড, ভুল DNS type বা বিকৃত quoting, inconsistent nameserver, বা length/CNAME collision। নিচে: প্রতিটির জন্য ৬০-সেকেন্ডের পরীক্ষা, চেক করার ক্রমে, তারপর সমাধানের ধাপ।

আপনি কি নিশ্চিত রেকর্ড আসলে আছে?

অপ্রীতিকর সম্ভাবনা দিয়ে শুরু করুন, কারণ এটি এখন পর্যন্ত সবচেয়ে সাধারণ: Defaults.Exposed জনগণনায় গ্রেড করা 261,086,232 ডোমেইনের মধ্যে, 121,145,609 — 46.4% — মোটেই কোনো SPF রেকর্ড নেই। প্রচুর “কিন্তু আমি এটি সেটআপ করেছি” ক্ষেত্র একটি staging zone বা পুরানো DNS প্রদানকারীতে যোগ করা রেকর্ড হিসেবে প্রমাণিত হয় যা আর authoritative নয়। আপনার nameserver-গুলি আসলে যেখানে point করে (প্রায়ই আপনার registrar নয়) সেই DNS প্রদানকারীতে v=spf1 দিয়ে শুরু হওয়া একটি TXT রেকর্ড চেক করুন। সত্যিই সেখানে না থাকলে, detective কাজ এড়িয়ে সরাসরি আপনার SPF রেকর্ড ঠিক করুন-এ যান।

কীভাবে সঠিকভাবে SPF রেকর্ড চেক করবেন?

ওয়েব চেকাররা তাদের নিজস্ব caching resolver-এর মাধ্যমে DNS query করে। সত্য দেখতে, আপনার ডোমেইনের authoritative nameserver সরাসরি জিজ্ঞাসা করুন:

# authoritative nameserver খুঁজুন
dig NS yourdomain.com +short

# TXT রেকর্ডের জন্য সরাসরি একটিকে জিজ্ঞাসা করুন
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Windows-এ: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com।

ব্যাখ্যার দুটি নিয়ম। প্রথম, v=spf1 দিয়ে শুরু হওয়া লাইন গণনা করুন — বিষয়বস্তুর মতোই সংখ্যা গুরুত্বপূর্ণ। দ্বিতীয়, আপনি সঠিক নাম query করেছেন কিনা পরীক্ষা করুন: রিসিভাররা Return-Path (RFC5321.MailFrom, “envelope from”) ডোমেইনের বিপরীতে SPF মূল্যায়ন করে, প্রাপক যে From ঠিকানা দেখেন তার নয়। আপনার newsletter টুল যদি bounce.yourdomain.com-এর মাধ্যমে মেইল bounce করে, apex-এ একটি নিখুঁত রেকর্ড সেই রেকর্ড নয় যা রিসিভাররা lookup করে।

পাঁচটি আসল কারণ কী?

#	কারণ	৬০-সেকেন্ডের পরীক্ষা	সমাধান
১	ভুল হোস্টে রেকর্ড (subdomain বনাম apex)	আপনার Return-Path-এর সঠিক ডোমেইন `dig TXT` করুন	আসলে যে নাম পাঠায় সেখানে প্রকাশ করুন
২	দুই বা তার বেশি `v=spf1` রেকর্ড = PermError	`dig TXT` ২+ `v=spf1` লাইন ফেরত দেয়	ঠিক একটি রেকর্ডে merge করুন
৩	record type 99 হিসেবে প্রকাশিত, বা বিকৃত quoting	রেকর্ড type এবং stray quote চিহ্ন পরীক্ষা করুন	একটি পরিষ্কার TXT রেকর্ড হিসেবে পুনরায় প্রকাশ করুন
৪	Stale cache / inconsistent nameserver	প্রতিটি NS সরাসরি query করুন; উত্তর তুলনা করুন	পিছিয়ে পড়া nameserver ঠিক করুন, পুরানো TTL শেষ হতে দিন
৫	>255-character splitting বা CNAME collision	ভাঙা string chunk বা একই নামে CNAME খুঁজুন	প্রদানকারীকে সঠিকভাবে string split করতে দিন; CNAME’d নাম থেকে রেকর্ড সরান

2026-06-29 তারিখের তথ্য।

১. রেকর্ড কি ভুল হোস্টে?

ক্লাসিক: mail.yourdomain.com-এ SPF যোগ করা যখন মেইল দাবি করে yourdomain.com থেকে আসছে, বা উল্টো। SPF নিচে উত্তরাধিকারসূত্রে পায় না — apex-এ একটি রেকর্ড subdomain সম্পর্কে কিছু বলে না, এবং উল্টোটাও। আপনার Return-Path-এ ঠিক সেই নামে প্রকাশ করুন। একটি ভেন্ডর যা তার নিজের bounce subdomain থেকে পাঠায় সেই subdomain-এ একটি রেকর্ড দরকার — সাধারণত ভেন্ডর সরবরাহিত একটি CNAME বা TXT (GoDaddy SPF setup গাইড দেখায় এই ক্ষেত্রগুলি কোথায় থাকে)।

২. আপনার কি দুটি SPF রেকর্ড আছে?

মূল কারণ, এবং ইমেইল authentication-এ সবচেয়ে বিভ্রান্তিকর error বার্তা। RFC 7208 §3.2 স্পষ্ট: একটি ডোমেইনে ঠিক একটি SPF রেকর্ড থাকতে হবে। দুই বা তার বেশি একটি PermError — রিসিভাররা আপনার SPF শূন্য হিসেবে বিবেচনা করে। কিছু চেকার সেই অবস্থা সঠিকভাবে রিপোর্ট করে (“multiple records found”); অন্যরা net effect রিপোর্ট করে: কোনো বৈধ SPF রেকর্ড পাওয়া যায়নি। আপনি আপনার প্যানেলে একটি রেকর্ড দেখেন এবং সিদ্ধান্ত নেন চেকার ভাঙা। তা নয় — আপনার একটি বেশি রেকর্ড আছে।

জনগণনা 1,013,416 ডোমেইন দুই বা তার বেশি SPF রেকর্ড বহন করে খুঁজে পেয়েছে — SPF চেষ্টাকারী ডোমেইনের প্রায় এক in 138 — প্রতিটি SPF কার্যকরভাবে বন্ধ করা সহ। এটি সাধারণত একটি প্রদানকারী পরিবর্তনের সময় ঘটে: নতুন প্রদানকারীর wizard পুরানোটি সম্পাদনা করার পরিবর্তে একটি নতুন রেকর্ড যোগ করে। সমাধান হল merge, কখনো দ্বিতীয় রেকর্ড নয়: সবকিছু একটি v=spf1 … ~all লাইনে combine করুন এবং বাকি মুছুন। আমাদের ডেটা রিপোর্ট two SPF records equals none দেখায় কীভাবে এক মিলিয়ন ডোমেইন এখানে পৌঁছল; যদি এটি migration-এর পরে শুরু হয়ে থাকে, দেখুন SPF প্রদানকারী পরিবর্তনের পরে কাজ করা বন্ধ করেছে। Merging-এর সময়, প্রতিটি include: অন্ধভাবে concatenate করবেন না — প্রতিটি DNS lookup SPF-এর ১০-এর কঠিন সীমার বিপরীতে খরচ করে, not-found কে PermError: too many DNS lookups-এর জন্য ট্রেড করে।

৩. আপনি কি ভুল রেকর্ড type প্রকাশ করেছেন — বা UI কি এটি বিকৃত করেছে?

প্রাথমিক SPF-এর নিজস্ব DNS রেকর্ড type (type 99, আক্ষরিক অর্থে “SPF” নামে) ছিল। এটি deprecated ছিল: RFC 7208 TXT প্রয়োজন, এবং রিসিভাররা type 99 query করে না। কিছু DNS প্যানেল এখনও রেকর্ড-type dropdown-এ “SPF” অফার করে; এটি বেছে নিলে আপনার রেকর্ড বাস্তব, সুগঠিত এবং অদৃশ্য। Type কলাম চেক করুন এবং TXT হিসেবে পুনরায় প্রকাশ করুন।

সূক্ষ্ম ভাইটি হল quoting। একটি মান quotes-এ wrapped করে এমন একটি ক্ষেত্রে paste করা যা নিজে quotes যোগ করে ""v=spf1 …"" তৈরি করে — যা আর v=spf1 দিয়ে শুরু নয়, তাই একটি verifier-এর কাছে এটি বিদ্যমান নয়। আপনার dig output সত্য দেখায়; DNS প্যানেল প্রায়ই এটি cosmetically লুকায়।

৪. এটি কি সত্যিই “এখনও propagating”?

“প্রচারের জন্য ২৪–৪৮ ঘন্টা দিন” হল DNS-এ সবচেয়ে বেশি prescribed পরামর্শ। Propagation হল শুধু cache expire হওয়া: রেকর্ডের TTL শেষ হলে (সাধারণত ১ ঘন্টা, কদাচিৎ ২৪ ঘন্টার বেশি), প্রতিটি resolver নতুন উত্তর দেখতে পারে। ২৪ ঘন্টা পরেও not-found? Propagation কারণ নয়।

দুটি আসল দোষী: negative caching — একটি resolver যা আপনি রেকর্ড যোগ করার আগে আপনাকে lookup করেছিল “কোনো রেকর্ড নেই” উত্তর negative TTL শেষ না হওয়া পর্যন্ত cache করে — এবং migration-এর পরে inconsistent nameserver, যেখানে ডোমেইন এখনও পুরানো প্রদানকারীর nameserver-গুলি নতুনগুলির পাশে তালিকাভুক্ত করে এবং বিশ্বের অর্ধেক একটি zone পড়ে যা আপনি আর সম্পাদনা করেন না। প্রতিটি তালিকাভুক্ত nameserver সরাসরি query করুন; উত্তর আলাদা হলে, আপনি এটি খুঁজে পেয়েছেন। registrar-এর NS delegation ঠিক করুন যাতে শুধুমাত্র আপনি আসলে যে প্রদানকারী সম্পাদনা করেন তা authoritative হয়।

৫. রেকর্ড কি খুব দীর্ঘ, বা CNAME দ্বারা blocked?

একটি TXT রেকর্ডে একটি string সর্বোচ্চ ২৫৫ অক্ষরে পৌঁছায়। দীর্ঘ SPF রেকর্ড আইনি কিন্তু একটি রেকর্ডের মধ্যে একাধিক quoted string-এ বিভক্ত করতে হবে — এবং DNS প্রদানকারী interface নিয়মিতভাবে split করে, মান truncate করে বা mechanism মাঝখানে ভেঙে দেয় যাতে এটি আর parse না করে। আপনার রেকর্ড দীর্ঘ হলে, হঠাৎ শেষ হওয়া মানের জন্য dig output চেক করুন।

আলাদাভাবে, DNS একটি TXT রেকর্ড এমন একটি নামে নিষিদ্ধ করে যেখানে ইতিমধ্যে একটি CNAME আছে। যদি mail.yourdomain.com আপনার প্রদানকারীতে একটি CNAME হয়, আপনি সেখানে SPF রাখতে পারবেন না — কিছু প্যানেল এটি গ্রহণ করে এবং তারপর শুধু CNAME serve করে। রেকর্ড যেখানে CNAME point করে সেখানে রাখুন (যদি আপনি এটি নিয়ন্ত্রণ করেন), বা restructure করুন যাতে sending নাম CNAME’d না হয়। পরিষ্কার TXT handling সহ প্রদানকারীরা উভয়ই সহজ করে — দেখুন Cloudflare SPF setup গাইড।

ধাপে ধাপে কীভাবে ঠিক করবেন?

defaults.exposed এ বিনামূল্যে স্ক্যান চালান — এটি আপনার live DNS পড়ে এবং কিছু স্পর্শ করার আগে আপনি পাঁচটি অবস্থার কোনটিতে আছেন তা বলে।
নিশ্চিত করুন কোন nameserver গুলি authoritative (dig NS) এবং তারা সব একমত।
সঠিক Return-Path ডোমেইনে authoritative nameserver-এ TXT query করুন।
v=spf1 লাইন গণনা করুন: শূন্য → একটি প্রকাশ করুন; দুই বা তার বেশি → একটিতে merge করুন।
নিশ্চিত করুন type TXT, মান ঠিক v=spf1 দিয়ে শুরু, এবং কোনো stray quote বা truncation ঢুকেনি।
এক TTL অপেক্ষা করুন, তারপর পুনরায় স্ক্যান করুন নিশ্চিত করতে এটি সর্বত্র পরিষ্কারভাবে resolve হয়।

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

আমি আমার DNS প্যানেলে রেকর্ড দেখতে পাচ্ছি তখন চেকার কেন “not found” বলে? সাধারণত কারণ ২ বা ৪: একটি দ্বিতীয় v=spf1 রেকর্ড উভয়কে শূন্য করে — একটি PermError যা কিছু টুল not-found হিসেবে রিপোর্ট করে, 2026-06-29 পর্যন্ত 1,013,416 ডোমেইন যে অবস্থায় আছে — বা আপনার প্যানেল সেই DNS নয় যা আসলে authoritative।

আমার সমাধান দেখতে চেকারদের কত সময় লাগবে? এক TTL — সাধারণত এক ঘন্টা, সর্বোচ্চ ২৪। এর পরে, “propagation” ব্যাখ্যা নয়; nameserver consistency দিয়ে শুরু করে পাঁচটি কারণ পুনরায় চেক করুন।

আমার DNS প্যানেল অফার করা “SPF” রেকর্ড type ব্যবহার করা উচিত? না। Type 99 deprecated; RFC 7208 শুধুমাত্র TXT প্রয়োজন। একটি type-99 রেকর্ড আধুনিক রিসিভারের কাছে অদৃশ্য।

রেকর্ড এখন পাওয়া যাচ্ছে — কেন আমার মেইল এখনও SPF ব্যর্থ করে? কারণ SPF Return-Path ডোমেইনের বিপরীতে চেক হয়, From হেডার নয়, এবং রেকর্ড অবশ্যই আপনার জন্য পাঠানো সার্ভারগুলি তালিকাভুক্ত করতে হবে। Found হল ধাপ এক; আপনার SPF রেকর্ড ঠিক করুন গাইড passing কভার করে।

SPF রেকর্ড না থাকা কি সত্যিই এত সাধারণ? হ্যাঁ — 121,145,609 ডোমেইন, Defaults.Exposed জনগণনায় গ্রেড করা 261,086,232-এর 46.4% (2026-06-29 পর্যন্ত), মোটেই কোনো SPF প্রকাশ করে না। Not-found হল ইন্টারনেটের ডিফল্ট অবস্থা।

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

রেকর্ড পরিষ্কারভাবে resolve হলে, স্ক্যান পুনরায় চালান এবং গ্রেডকৃত রিপোর্টটি ব্যবসার মালিক বা ক্লায়েন্টের কাছে ফরওয়ার্ড করুন যার ডোমেইন এটি। এটি সহজ ইংরেজিতে দেখায় কী ভাঙা ছিল, আপনি কী ঠিক করেছেন, এবং ডোমেইন এখন কোথায় দাঁড়িয়ে — ঠিক সেই প্রমাণ যা cyber-insurance নবায়ন এবং সরবরাহকারী নিরাপত্তা প্রশ্নপত্রে চাওয়া হবে। রিপোর্ট হল কাজের রসিদ।

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

দেখুন আপনার ডোমেইন পাঁচটি not-found অবস্থার কোনটিতে আছে — ব্যক্তিগতভাবে এবং মালিক-শুধুমাত্র।

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