Defaults.Exposed

Defaults.ExposedসমাধানGuides

আপনার SaaS টুলের জন্য SPF ব্যর্থ হচ্ছে? কেন হয় এবং সমাধানের ক্রম — ইউরোপ সংস্করণ (২০২৬)

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

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

একটি SaaS টুল “SPF ব্যর্থ করে” তখন আপনার রেকর্ড সাধারণত সমস্যা নয়: মেইল DMARC alignment ব্যর্থ করছে, অথবা আপনার include চেইন SPF-এর ১০-DNS-lookup সীমা অতিক্রম করেছে। 2,119,539 of 138,927,207 SPF-প্রকাশকারী ডোমেইন ৯–১০ lookup-এ বসে আছে — Defaults.Exposed জনগণনা অনুযায়ী 261,086,232 ডোমেইন জুড়ে এক SaaS include সীমানা থেকে দূরে।

নিচে: দুটি সমস্যার মধ্যে আপনার কোনটি আছে তা কীভাবে বলবেন, তারপর সমাধানের ক্রম — আগে স্ক্যান করুন, টুল আসলে কোন ডোমেইন থেকে পাঠায় তা খুঁজুন, ভেন্ডরকে custom-domain DKIM-এ স্যুইচ করুন, এবং শুধুমাত্র যেখানে সত্যিই সাহায্য করে সেখানে SPF include যোগ করুন — HubSpot, Salesforce, Mailchimp এবং SendGrid-এর বিশদ সহ।

কেন SaaS টুল থেকে মেইল SPF ব্যর্থ করে?

তিনটি প্যাটার্ন প্রায় প্রতিটি ক্ষেত্র কভার করে:

রিপোর্ট বা bounce কী বলেআসলে কী ভুলসমাধান
SPF পাস, DMARC এখনও ব্যর্থAlignment: টুল তার bounce ডোমেইনে SPF পাস করেছে, আপনারটিতে নয়ভেন্ডরের custom-domain DKIM চালু করুন (CNAMEs)
SPF permerrorআপনার include চেইন SPF-এর ১০-DNS-lookup সীমা অতিক্রম করেInclude ছাঁটুন; দেখুন too-many-lookups সমাধান
SPF fail / softfailটুল সত্যিই আপনার return-path সহ পাঠায় এবং আপনার রেকর্ডে নেইভেন্ডরের include যোগ করুন বা তার custom bounce domain সক্ষম করুন

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

বোল্ড করা সারিটি হল যেখানে বেশিরভাগ মানুষ দাঁড়িয়ে। প্রতিটি টুলের জন্য include: লাইন যোগ করা এটি স্পর্শ করে না — এবং প্রতিটি লাইন আপনাকে দ্বিতীয় সারির কাছে নিয়ে যায়: কমপক্ষে 797,263 ডোমেইন ইতিমধ্যে ১০-lookup সীমা অতিক্রম করেছে, এবং তাদের SPF এখন PermError ফেরত দেয় যা কিছুই রক্ষা করে না। SPF PermError রিপোর্টে সম্পূর্ণ সংখ্যা।

SPF আসলে কোন ডোমেইন চেক করে?

আপনার From হেডারের ডোমেইন নয়। রিসিভাররা Return-Path ডোমেইনের (RFC5321.MailFrom, bounce বা envelope-from ঠিকানাও বলা হয়) বিপরীতে SPF মূল্যায়ন করে — প্রাপক যে From হেডার দেখেন তা SPF চেকে কোনো ভূমিকা রাখে না।

এই একটি তথ্য বেশিরভাগ “SaaS SPF ব্যর্থতা” ব্যাখ্যা করে। আপনার মার্কেটিং প্ল্যাটফর্ম [email protected]-এর মতো Return-Path সহ পাঠায়; SPF vendor.com-এর বিপরীতে চেক হয় এবং পরিষ্কারভাবে পাস করে। তারপর DMARC জিজ্ঞাসা করে সেই SPF-চেক করা ডোমেইন আপনার From ডোমেইনের সাথে মেলে কিনা। মেলে না, তাই DMARC-এর SPF লেগ ব্যর্থ হয় এবং আপনার ড্যাশবোর্ড বলে “SPF ব্যর্থ হচ্ছে”। আপনার নিজের SPF রেকর্ড সম্পাদনা করা এটি ঠিক করতে পারে না — আপনার রেকর্ড কখনো পরামর্শ করা হয়নি।

সমাধানের ক্রম কী?

  1. প্রথমে বিনামূল্যে স্ক্যান চালান। এটি আপনাকে একটি পাসে বলে আপনার SPF অনুপস্থিত, নকল, lookup সীমার উপরে নাকি ঠিক আছে, এবং DMARC কোথায় দাঁড়িয়ে — DNS স্পর্শ করার আগে।
  2. টুল আসলে কোন Return-Path ব্যবহার করে তা খুঁজুন। টুল থেকে নিজেকে একটি পরীক্ষা পাঠান এবং raw মেসেজে Return-Path হেডার (এবং Authentication-Results) পড়ুন। এটি আপনাকে বলে আপনি উপরের সারণির কোন সারিতে আছেন।
  3. ভেন্ডরের custom-domain DKIM চালু করুন। প্রতিটি গুরুতর SaaS টুল “domain authentication” অফার করে: কয়েকটি CNAME রেকর্ড যা এটিকে আপনার ডোমেইন হিসেবে DKIM-স্বাক্ষর করতে দেয়। সেই স্বাক্ষর আপনার From ডোমেইনের সাথে align করে, তাই DMARC DKIM-এর মাধ্যমে পাস করে — দীর্ঘস্থায়ীভাবে, এমনকি মেইল forward করা হলেও।
  4. ভেন্ডরের SPF include শুধুমাত্র যোগ করুন যদি এটি আপনার return-path ব্যবহার করে — আপনি তার custom bounce domain সক্ষম করেছেন, বা এটি সত্যিই আপনার ডোমেইন envelope-এ রেখে পাঠায়। একটি ভেন্ডরের জন্য include যা তার নিজের ডোমেইন দিয়ে bounce করে কিছু কেনে না এবং আপনার lookup বাজেট খরচ করে।
  5. সেভ করার আগে DNS lookup গণনা করুন। সীমা হল ১০ resolved lookup, include গুলি পুনরাবৃত্তিভাবে গণনা হয়, এবং 2,119,539 ডোমেইন ইতিমধ্যে ৯–১০-এ বসে আছে — জনগণনা p99 হল 9। সীমানার কাছে? প্রথমে আপনি আর ব্যবহার করেন না এমন টুলের include সরিয়ে দিন। এইমাত্র ইমেইল প্রদানকারী পরিবর্তন করেছেন? একটি বাকি দ্বিতীয় রেকর্ড আছে কিনা দেখুন — দুটি SPF রেকর্ড মানে PermError
  6. পুনরায় স্ক্যান করুন এবং নিশ্চিত করুন। সঠিক ডোমেইনে SPF পাস, DKIM aligned, DMARC পাসিং। সম্পূর্ণ রেফারেন্স how to fix SPF-এ আছে; প্রদানকারী walk-through যেমন SPF on GoDaddy এবং DMARC on IONOS DNS-প্যানেল ক্লিক কভার করে।

HubSpot, Salesforce, Mailchimp এবং SendGrid-এর জন্য কী করা উচিত?

HubSpot। HubSpot-এর সেটিংসে আপনার sending domain সংযুক্ত করুন এবং এটি যে দুটি DKIM CNAME দেয় (hs1-… / hs2-…) প্রকাশ করুন। এটি DKIM আপনার From ডোমেইনের সাথে align করে। আপনার নিজের bounce domain ব্যবহার করতে HubSpot কনফিগার করা না থাকলে HubSpot SPF include দরকার নেই।

Salesforce। Salesforce Setup-এ একটি DKIM key তৈরি করুন এবং এটি যে CNAME pair জেনারেট করে তা প্রকাশ করুন। যদি Salesforce আপনার সংগঠনের return-path সহ পাঠায়, include:_spf.salesforce.com যোগ করুন এবং bounce domain কনফিগার করুন — এটি একটি বড় CRM যেখানে SPF include প্রায়ই সত্যিই প্রয়োজন।

Mailchimp। আপনার ডোমেইন authenticate করুন এবং k2 / k3 DKIM CNAME প্রকাশ করুন। Mailchimp alignment হল DKIM-শুধুমাত্র — আর কোনো SPF include যোগ করার নেই, এবং পুরানো টিউটোরিয়াল থেকে একটি যোগ করা শুধু lookup নষ্ট করে।

SendGrid। Domain authentication (“automated security”) সম্পন্ন করুন: তিনটি CNAME আপনার নিজের subdomain-এ DKIM এবং return-path উভয় পরিচালনা করে। কোনো SPF include দরকার নেই। 740,321 ডোমেইনের মধ্যে যাদের SPF sendgrid.net অনুমোদন করে, শুধুমাত্র 18.0% enforcing DMARC আছে (2026-06-29 তারিখের তথ্য) — বেশিরভাগ SendGrid প্রেরক এক ধাপ কম থামে।

Zendesk এবং অন্য সব: একই প্যাটার্ন। টুলের “domain authentication” পেজ খুঁজুন, তার DKIM CNAME প্রকাশ করুন, এবং শুধুমাত্র SPF স্পর্শ করুন যদি টুল ডকুমেন্ট করে যে এটি আপনার return-path ব্যবহার করে।

ইউরোপীয় ব্যবসার জন্য SPF কি ভিন্ন?

না — SPF, DKIM এবং DMARC সর্বত্র একইভাবে কাজ করে। ইউরোপে যা ভিন্ন তা হল প্রসঙ্গ: কে জিজ্ঞাসা করছে, এবং আপনার প্রতিবেশীরা ইতিমধ্যে কী করেছে।

আপনার ccTLD স্থানীয় বার সেট করে। ইউরোপীয় ccTLD গুলি .com হারের উপরে SPF ভালোভাবে প্রকাশ করে, কিন্তু যে ডোমেইনগুলি কাজ শেষ করে — উপরে একটি enforcing DMARC নীতি — সর্বত্র সংখ্যালঘু:

TLDSPF গ্রহণ (গ্রেডকৃত ডোমেইনের)Enforcing DMARC (গ্রেডকৃত ডোমেইনের)
.nl75.91%29.43%
.ie70.89%8.79%
.de64.67%21.38%
.dk50.42%19.88%
.com54.14%9.50%

2026-06-29 তারিখের তথ্য। ফ্রান্স: 13.65% enforcing DMARC; ইতালি: 5.24%।

আপনার ইউরোপীয় হোস্টের ডিফল্ট গুরুত্বপূর্ণ। 4,346,526 ডোমেইন তাদের SPF-এ IONOS-এর EU মেইল সার্ভার (_spf-eu.ionos.com) অনুমোদন করে — এবং মাত্র 0.3% strict -all-এ শেষ হয়, 1.0% DMARC-enforced সহ। OVH-এর 2,132,049 strictness-এ ভালো করে (43.7%) কিন্তু মাত্র 2.2% DMARC enforce করে (2026-06-29 তারিখের তথ্য)। আপনি কখনো আপনার রেকর্ড স্পর্শ না করলে, আপনি সেই ডিফল্টগুলিতে দাঁড়িয়ে।

নিয়ন্ত্রকরা এখন এটি উল্লেখ করেন। NIS2 আর্টিকেল 21(2)(j) in-scope entities-কে তাদের যোগাযোগ সুরক্ষিত করতে বাধ্য করে, এবং Commission Implementing Regulation (EU) 2024/2690 ইমেইল- ও DNS-নিরাপত্তা ব্যবস্থা বিশদ করে। ইমেইল authentication হল সুনির্দিষ্ট, যাচাইযোগ্য অংশ — এবং compliance-এর জন্য অস্বাভাবিকভাবে, বিনামূল্যে ঠিক করা যায়।

তথ্য আবাসিকতায়: Defaults.Exposed স্ক্যানার এবং জনগণনা AWS eu-west-1-এ চলে, আমরা শুধু সমন্বিত পরিসংখ্যান প্রকাশ করি, এবং একটি স্ক্যান শুধুমাত্র আপনি যে ডোমেইন সম্পর্কে জিজ্ঞাসা করেন তা চেক করে।

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

আমার SPF চেকার “pass” বলে কিন্তু টুলের ড্যাশবোর্ড বলে SPF ব্যর্থ হচ্ছে — কেন? চেকার আপনার রেকর্ড পরীক্ষা করেছে; রিসিভার টুল আসলে যে Return-Path ডোমেইন ব্যবহার করেছে তা পরীক্ষা করেছে, তারপর DMARC এটি আপনার From ডোমেইনের সাথে তুলনা করেছে। এটি একটি alignment ব্যর্থতা, রেকর্ড ব্যর্থতা নয় — ভেন্ডরের custom-domain DKIM দিয়ে ঠিক হয়, SPF সম্পাদনা দিয়ে নয়।

আমি কি আমাদের ব্যবহৃত প্রতিটি টুলের জন্য SPF include যোগ করব? না। প্রতিটি include SPF-এর ১০-lookup বাজেটের অংশ খরচ করে, পুনরাবৃত্তিভাবে: 2,119,539 of 138,927,207 SPF-প্রকাশকারী ডোমেইন ৯–১০ lookup-এ বসে আছে, এবং কমপক্ষে 797,263 বেশি — তাদের SPF PermError ফেরত দেয় এবং কিছুই রক্ষা করে না (2026-06-29 তারিখের তথ্য)।

include কি DMARC-ও ঠিক করে? শুধুমাত্র যদি টুল আপনার return-path সহ পাঠায়, তাই SPF পাস করে এবং aligns। বেশিরভাগ SaaS টুলের জন্য এটি হয় না — যে কারণে aligned DKIM, SPF নয়, হল সেই লেগ যা SaaS মেইলের জন্য DMARC পাস করে

EU-তে এটি কি আইনগত প্রয়োজনীয়তা? NIS2 scope-এ entities-এর জন্য, আর্টিকেল 21(2)(j) এবং Implementing Regulation (EU) 2024/2690 ইমেইল নিরাপত্তা একটি বাধ্যবাধকতা করে। Scope-এর বাইরেও, বিমাকারী এবং গ্রাহক প্রশ্নপত্র ক্রমবর্ধমানভাবে জিজ্ঞাসা করছে — এবং 2026-06-29 তারিখ পর্যন্ত, কোনো EU ccTLD তার ডোমেইনের এক তৃতীয়াংশও একটি enforcing DMARC নীতিতে পায় না (.nl-এ সর্বোচ্চ 29.43%; .it-এ 5.24%)।

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

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

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

ঠিক কোন লেগ SPF, DKIM এবং DMARC ব্যর্থ হচ্ছে দেখুন — ব্যক্তিগতভাবে এবং মালিক-শুধুমাত্র।

আপনার ডোমেইন পরীক্ষা করুন → · SPF ঠিক করুন → · SPF PermError: “too many DNS lookups” → · আমরা কীভাবে গ্রেড করি → · শুধুমাত্র সমন্বিত তথ্য। EU-তে তথ্য সংরক্ষিত এবং প্রক্রিয়া করা হয়।