একটি টার্মিনাল তিনটি ডোমেইনের জন্য DMARC রেকর্ড তালিকাভুক্ত করে, একটি সবুজে p=reject চিহ্নিত এবং দুটি লাল রঙে p=none চিহ্নিত

read receipts

দশ সেকেন্ডে কোনো কোম্পানির DMARC পলিসি কীভাবে পড়ব (এবং এটি আপনাকে কী বলে না)

যে লাইনটি ডোমেইন মালিক জাল মেইলের সাথে কী করতে চান তা বলে তা সর্বজনীন এবং একটি লুকআপের দূরত্বে আছে। এটি একটি উল্লিখিত পছন্দ — স্প্যাম ফিল্টার নয়, এবং আপনার ইনবক্সের জন্য কোনো প্রতিশ্রুতি নয়।

·5 মিনিটের পাঠ

একটি DNS লুকআপ বলে যে একটি কোম্পানি বিশ্বের মেইল সার্ভারগুলিকে তার নামে পাঠানো জাল মেইলের সাথে কী করতে বলেছে। রেকর্ডটি সর্বজনীন, এবং কমান্ডটি একটি লাইন: dig +short TXT _dmarc.example.com। যা ফিরে আসে তা হল সেটিংসের একটি সংক্ষিপ্ত স্ট্রিং, এবং এর মধ্যে একটি নির্দেশনা রয়েছে — p=none, p=quarantine বা p=reject — যা ডোমেইন মালিকের পছন্দ বলে যখন সেই ডোমেইন ব্যবহার করে একটি বার্তা প্রমাণীকরণ ব্যর্থ হয়।

বর্তমান স্পেসিফিকেশন, RFC 9989, মে 2026 এ একটি IETF স্ট্যান্ডার্ডস ট্র্যাক ডকুমেন্ট হিসাবে প্রকাশিত, পুরানো RFC 7489 প্রতিস্থাপন করেছে। এটি তিনটি মান প্রায় সংক্ষিপ্তভাবে সংজ্ঞায়িত করে:

  • p=none — "ডোমেইন মালিক কোনো পছন্দের প্রকাশ দেয় না।"
  • p=quarantine — "ডোমেইন মালিক এই ধরনের মেইলকে সন্দেহজনক বলে বিবেচনা করে। মেইলটি বৈধ হওয়া সম্ভব, যদিও ব্যর্থতা একটি উল্লেখযোগ্য উদ্বেগ তৈরি করে।"
  • p=reject — "ডোমেইন মালিক এই সমস্ত ব্যর্থতাকে একটি স্পষ্ট ইঙ্গিত বলে বিবেচনা করে যে ডোমেইন নামের ব্যবহার বৈধ নয়।"

সেই শব্দগুলি আবার পড়ুন, কারণ সেগুলি DMARC-এর বেশিরভাগ ব্যাখ্যা স্বীকার করে তার চেয়ে দুর্বল। একটি পলিসি একটি পছন্দ, প্রেরক দ্বারা প্রকাশিত যাতে প্রাপকরা বিবেচনা করে। এটি এমন একটি নির্দেশ নয় যা একটি প্রাপক পালন করতে বাধ্য। RFC 9989 এটি একটি বাক্যে বলে: "যেকোনো বার্তার চূড়ান্ত পরিচালনা সর্বদা স্থানীয় নীতির বিষয় এবং মেইল প্রাপকের বিবেচনার জন্য রেখে দেওয়া হয়।" একই বিভাগে উভয় পক্ষ যোগ করা হয় — প্রাপকরা "DMARC বৈধতা পরীক্ষা পাস করলেও একটি বার্তা প্রত্যাখ্যান বা কোয়ারেন্টাইন করতে পারে," এবং তারা "'প্রত্যাখ্যান' এর প্রকাশিত নীতির কারণেই বার্তা প্রত্যাখ্যান করবে না," ঠিক যাতে বৈধ মেইল যা DMARC বর্ণনা করতে পারে না এমন উপায়ে পাঠানো হয়, এবং মেইলিং তালিকা ধ্বংস না হয়।

তাহলে p=none প্রকৃতপক্ষে কী স্বীকার করে? এটি সাধারণত অভিযুক্ত হয় তার চেয়ে কম। স্পেসিফিকেশনের নিজস্ব শর্তে এটি মনিটরিং মোড: ডোমেইন মালিক সমষ্টিগত রিপোর্ট সংগ্রহ করছে এবং "DMARC বৈধতা ব্যর্থ বার্তাগুলির জন্য কোনো পরিচালনা পছন্দ প্রকাশ করে না," যখন DMARC স্থাপন করে এমন একটি প্রাপক এখনও ডোমেইনের ব্যবহার যাচাই করতে পারে। এটি যা করে না তা গ্রহণকারীর প্রান্তে কিছু চালু করা। আপনার প্রদানকারীর স্প্যাম ফিল্টারিং, খ্যাতি স্কোরিং, URL চেক এবং সংযুক্তি বিশ্লেষণ অনুসরণকারী আলাদা যন্ত্রপাতি যা প্রেরক যা প্রকাশ করেছে তা নির্বিশেষে চলে। একটি p=none ডোমেইনে আসা একটি জাল বার্তা রেকর্ড দ্বারা আপনার ইনবক্সে প্রচার করা হয় না; এটি কেবল প্রাপককে একটি উল্লিখিত পছন্দ ছাড়াই হস্তান্তর করা হয়, এবং প্রাপক সিদ্ধান্ত নেয়।

বোঝার অন্য অর্ধ দিকটি চলে। DMARC একটি ফিশিং ইমেইলের বিপজ্জনক অংশ পড়ে না। এর নিজস্ব স্পেসিফিকেশন তালিকাভুক্ত করে যা ইচ্ছাকৃতভাবে সুযোগের বাইরে, এবং "কন্টেন্ট বিশ্লেষণ" সেই শব্দে সেই তালিকায় আছে। এটি আরও বলে যে DMARC "দৃষ্টিনন্দন অনুরূপ ডোমেইন নাম বা RFC5322.From মানব-পঠনযোগ্য ডিসপ্লে নামের অপব্যবহার" সম্বোধন করে না — দুটি কৌশল যা বেশিরভাগ ব্র্যান্ড-নকল মেইল বহন করে। এবং একটি পাসের মূল্যে: "একটি DMARC পাস নিজেই গ্যারান্টি দেয় না যে প্রাপকের ইনবক্সে ডেলিভারি নিরাপদ বা কাঙ্ক্ষিত হবে।" একটি সঠিকভাবে প্রমাণীকৃত বার্তা একটি ফেলে দেওয়া ডোমেইন থেকে DMARC পরিষ্কারভাবে পাস করে। DMARC উত্তর দেয় কে From: হেডারে ডোমেইন ব্যবহার করতে অনুমোদিত ছিল। আর কিছু নয়।

এটি যেখানে 2024 বাল্ক-প্রেরক নিয়মগুলি রুটিনভাবে ভুল রিপোর্ট করা হয়, এই নিবন্ধের প্রথম সংস্করণ সহ। Google এর প্রেরক নির্দেশিকা দৈনিক 5,000 বা তার বেশি বার্তা প্রেরণকারীদের Gmail অ্যাকাউন্টে "আপনার প্রেরণ ডোমেইনের জন্য DMARC ইমেইল প্রমাণীকরণ সেট আপ করতে" প্রয়োজন করে, এবং তারপর একই শ্বাসে বলে: "আপনার DMARC প্রয়োগ নীতি কোনটিতে সেট করা যেতে পারে।" Yahoo-এর নিজস্ব Sender Hub, যা Google অনুলিপি করার জন্য আলাদাভাবে পড়া যেতে হবে, প্রয়োজনটিকে "কমপক্ষে p=none সহ একটি বৈধ DMARC নীতি প্রকাশ করুন - DMARC অবশ্যই পাস করতে হবে" বলে বর্ণনা করে, এবং কোনো সংখ্যাগত ভলিউম থ্রেশহোল্ড প্রকাশ করে না। উভয় সেটের প্রয়োজনীয়তা ফেব্রুয়ারি 2024 থেকে কার্যকর হয়েছে। কেউই p=none থেকে কাউকে জোর দেয় না। যা উভয়ে প্রকৃত জোর করে তা প্রমাণীকরণ যা সারিবদ্ধ হয়: Google প্রয়োজন করে যে "প্রেরকের From: হেডারের ডোমেইন SPF ডোমেইন বা DKIM ডোমেইনের সাথে সারিবদ্ধ থাকতে হবে," এবং Yahoo বলে শিথিল সারিবদ্ধতা গ্রহণযোগ্য। সারিবদ্ধতা, তীব্রতা নয়, গেট।

যা ডোমেইনগুলি মনিটরিংয়ে বসে আছে সে সম্পর্কে প্রকৃত কারণ ছেড়ে দেয়, এবং এটি পরিচালনামূলক বরং ভীরু নয়। quarantine বা reject এ যাওয়ার অর্থ প্রথমে প্রতিটি সেবা খুঁজে পাওয়া যা আপনার নামে মেইল পাঠায় — পেরোল, টিকেটিং, বিপণন, একটি সাপোর্ট ডেস্ক কেউ ডকুমেন্ট করেনি — এবং প্রতিটিকে প্রমাণীকরণ করা যাতে এটি সারিবদ্ধ হয়। স্ট্যান্ডার্ড নিজেই এই ধীর করে তোলে এমন ঝুঁকিগুলি স্বীকার করে: তৃতীয় পক্ষের প্রেরক DMARC দ্বারা প্রবর্তিত বা অন্তর্ভুক্ত নয়, অগ্রবর্তী এবং মেইলিং তালিকা প্রেরকের অপরাধের মাধ্যমে সারিবদ্ধতা ভাঙতে পারে, এবং স্পেসিফিকেশন সেই ব্যর্থতার মোডগুলির জন্য RFC 7960 এ প্রাপকদের নির্দেশনা দেয়। একটি সংস্থা যা p=none প্রকাশ করে এবং তার রিপোর্ট পড়ে স্পেসিফিকেশন যে ক্রমে বর্ণনা করে সেই ক্রমে কাজ করছে। একটি যা p=none প্রকাশ করে এবং রিপোর্টগুলি উপেক্ষা করে নয়। বাইরে থেকে, রেকর্ড একাই আপনাকে বলতে পারে না আপনি দুটির মধ্যে কোনটি দেখছেন।

একটি টার্মিনাল প্রয়োজন নেই দেখতে। ফ্রি লুকআপ সরঞ্জাম — dmarcian-এর ডোমেইন চেকার, MXToolbox-এর DMARC চেক — রেকর্ড আনে এবং পলিসি আপনার জন্য প্রিন্ট করে। এটি আপনার ব্যাংকের জন্য, আপনার পেরোল প্রদানকারীর জন্য, আপনি যে এয়ারলাইন ব্যবহার করেন তার জন্য করুন। শুধু উত্তর পড়ুন এটি যা: ডোমেইন মালিকের দ্বারা একটি অভিপ্রায়ের বিবৃতি, আপনার মেইল প্রদানকারী নিজের উপর যে সিদ্ধান্ত নেয় তাতে অনেক ইনপুটের মধ্যে একটি, এক নির্দিষ্ট ধরনের জালিয়াতি সম্পর্কে। এটি দশ সেকেন্ডে পড়তে পারার জন্য একটি খাঁটি উপযোগী জিনিস। পরবর্তী বার্তা যা সেই ব্র্যান্ডের দাবি করে তা নিরাপদ কিনা তার একটি সিদ্ধান্ত নয়।

সংশোধন, 20 অক্টোবর 2026। এই নিবন্ধের একটি পূর্ববর্তী সংস্করণ p=none কে ইনবক্সে জালিয়াতি পাঠানো হিসাবে এবং p=reject কে একটি স্পুফড বার্তা ব্লক করার একমাত্র সেটিং হিসাবে বর্ণনা করেছে, বলেছে যে 2024 Google এবং Yahoo বাল্ক-প্রেরক নিয়মগুলি p=none থেকে প্রেরকদের জোর করেছে, এবং মোটামুটি তিনটির একটি ডোমেইনের একটি চিত্র উদ্ধৃত করেছে প্রয়োগে। পলিসি বর্ণনা RFC 9989 এর বিপরীতে সঠিক করা হয়েছে; Google এবং Yahoo উভয়ই প্রকৃতপক্ষে p=none গ্রহণ করে, উপরে তাদের নিজস্ব ডকুমেন্টেশন থেকে উদ্ধৃত; এবং প্রয়োগ চিত্র অপসারণ করা হয়েছে কারণ অন্তর্নিহিত রিপোর্ট তার নমুনা বা হর প্রকাশ করে না। নিবন্ধ এখন DMARC যা পরীক্ষা করে না তা নির্দেশ করে।

The weakest DMARC policy, and the one both Google and Yahoo accept from bulk senders under rules in force since February 2024

সূত্র

  1. RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF, Standards Track, May 2026; obsoletes RFC 7489. Policy values §4.7, Monitoring Mode §3.2.12, out-of-scope list §2.4, policy enforcement §5.4
  2. Google — Email sender guidelines — Requirements in force from 1 February 2024, including "Your DMARC enforcement policy can be set to none" and the 5,000-messages-a-day threshold (checked 20 October 2026)
  3. Yahoo Sender Hub — Best practices — Yahoo's own bulk-sender requirements: "Publish a valid DMARC policy with at least p=none"; no numeric volume threshold published (checked 20 October 2026)
  4. DMARC.org — Overview — Plain-language introduction to SPF, DKIM and identifier alignment
  5. dmarcian Domain Checker — Free lookup that fetches and reads a domain's DMARC record

← সব নিবন্ধ