আপনার DNS নিয়ে আন্দাজ বন্ধ করুন: MX, SPF, DKIM এবং DMARC নিয়ে ডেভেলপার-বান্ধব ভ্রমণ

এখন ইমেইল DNS রেকর্ড কেন গুরুত্বপূর্ণ

ইমেইল অথেন্টিকেশন একসময় ঐচ্ছিক ছিল। 2026 সালে এটি মৌলিক আবশ্যকতা। Gmail এবং Outlook—দুটিই বাল্ক সেন্ডারদের জন্য SPF এবং DKIM বাধ্যতামূলকভাবে প্রয়োগ করে, আর যে কোনো ডোমেইন ট্রানজ্যাকশনাল ইমেইল পাঠায় তার জন্য DMARC দ্রুত বাধ্যতামূলক হয়ে উঠছে। আপনার DNS রেকর্ড ভুল হলে আপনার ইমেইল পৌঁছায় না—কোনো বাউন্স নেই, কোনো সতর্কতা নেই, শুধু নীরবতা।

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

এই গাইডে MX, SPF, DKIM এবং DMARC নিয়ে সেই ক্রমেই আলোচনা করা হয়েছে যেভাবে আপনি বাস্তবে এগুলোর মুখোমুখি হবেন—সঠিকভাবে কনফিগার করার মতো যথেষ্ট বিস্তারিত এবং ভেঙে গেলে ডিবাগ করার মতো যথেষ্ট প্রেক্ষাপটসহ।

MX রেকর্ড: ইনবাউন্ড ইমেইল কোথায় যায়

MX রেকর্ড ইন্টারনেটকে জানায় আপনার ডোমেইনের জন্য কোন মেইল সার্ভার ইমেইল গ্রহণ করে। চারটির মধ্যে এগুলো সবচেয়ে সহজ, তবে ভুল কনফিগার করার সম্ভাবনাও সবচেয়ে বেশি।

একটি MX রেকর্ডের দুটি অংশ থাকে: একটি প্রায়োরিটি নম্বর এবং একটি hostname। কম প্রায়োরিটি নম্বর আগে চেষ্টা করা হয়। আপনি Google Workspace ব্যবহার করলে আপনার MX রেকর্ডগুলো এমন হতে পারে:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

শেষের ডটগুলো গুরুত্বপূর্ণ—এগুলো বোঝায় hostname সম্পূর্ণভাবে qualified। বেশিরভাগ DNS প্রোভাইডার এগুলো স্বয়ংক্রিয়ভাবে যোগ করে, কিন্তু সবাই নয়।

সাধারণ ভুল: hostname-এর বদলে A record-এ MX record নির্দেশ করা, সব প্রায়োরিটি একই নম্বরে সেট করা (যা ব্যাকআপ রাখার উদ্দেশ্যই নষ্ট করে), অথবা প্রোভাইডার মাইগ্রেট করার সময় পুরোনো MX record সরাতে ভুলে যাওয়া। পুরোনো MX record নিরীহভাবে পড়ে থাকে না—এগুলো mail loop তৈরি করতে পারে বা দুইটি inbox-এ delivery ভাগ করে দিতে পারে।

আপনি যদি নিজের contact form চালান এবং third-party service-এর ওপর নির্ভর না করে spam এড়াতে চান, তাহলে ফর্ম কীভাবে spam vector হয়ে ওঠে তা বোঝা একটি ভালো শুরুর জায়গা।

SPF: কোন সার্ভার আপনার নামে পাঠাতে পারবে

SPF (Sender Policy Framework) হলো একটি TXT record, যেখানে আপনার domain-এর পক্ষ থেকে email পাঠানোর অনুমোদিত IP address এবং domain তালিকাভুক্ত থাকে। আপনার কাছ থেকে এসেছে দাবি করা কোনো message পেলে বেশিরভাগ mail server প্রথমে এটিই পরীক্ষা করে।

একটি basic SPF record এমন দেখায়:

v=spf1 include:_spf.google.com ~all

এটি ভেঙে দেখলে:

• v=spf1 SPF version ঘোষণা করে
• include:_spf.google.com Google-এর SPF record-এ delegate করে
• ~all হলো soft fail—তালিকাভুক্ত নয় এমন source থেকে mail reject করে, তবে খুব কঠোর নয়

নির্দিষ্ট address whitelist করতে আপনি ip4: বা ip6: ব্যবহার করতে পারেন, অথবা আপনার domain-এর A এবং MX record reference করতে a এবং mx ব্যবহার করতে পারেন। শেষে থাকা all mechanism নির্ধারণ করে আপনি তালিকাভুক্ত করেননি এমন source থেকে আসা mail-এর কী হবে: -all হলো hard fail (reject), ~all হলো soft fail (suspicious হিসেবে mark), ?all হলো neutral (কোনো মতামত নেই), এবং +all হলো free-for-all (এটি ব্যবহার করবেন না)।

SPF-এর দুটি তীক্ষ্ণ প্রান্ত আছে। প্রথমত, email forward করা হলে এটি ভেঙে যায়, কারণ forwarding server আপনার SPF record-এ থাকে না। দ্বিতীয়ত, SPF record-এর lookup limit দশটি DNS query। আপনি খুব বেশি third-party service include করলে limit ছাড়িয়ে যাবেন এবং SPF কাজ করা বন্ধ করবে। সমাধান হলো SPF record flatten করা—include: directive-এর বদলে actual IP range বসানো—কিন্তু provider তাদের IP বদলালে এর maintenance দরকার হয়।

DKIM: sender identity-এর cryptographic proof

DKIM (DomainKeys Identified Mail) আপনার outbound email-এ একটি digital signature যোগ করে। receiving server আপনার DNS-এ প্রকাশিত public key-এর সঙ্গে signature মিলিয়ে দেখে। signature valid হলে এবং message tamper না করা হলে DKIM pass করে।

SPF-এর বিপরীতে, DKIM forwarding টিকে থাকে, কারণ signature message-এর সঙ্গে ভ্রমণ করে। এটি আরও flexible—ভিন্ন sending service-এর জন্য একাধিক DKIM key থাকতে পারে, প্রতিটির নিজস্ব selector সহ।

একটি DKIM DNS record এমন দেখায়:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

selector (এই উদাহরণে default) arbitrary—আপনার email provider এটি বেছে নেয়। p= value হলো public key, সাধারণত একটি দীর্ঘ base64-encoded string। আপনার email provider private key generate করে এবং outgoing message sign করতে তা ব্যবহার করে।

DKIM setup প্রায় সবসময় আপনার email provider সামলে নেয়। আপনার কাজ হলো তারা যে TXT record দেয় সেটি copy করে আপনার DNS-এ paste করা। জটিল অংশ হলো কিছু DNS provider দীর্ঘ TXT record ভালোভাবে handle করে না—তারা হয় সেগুলো truncate করে, নয়তো value-টি একাধিক quoted string-এ split করতে বলে।

DKIM কাজ করছে কিনা verify করতে একটি Gmail address-এ test email পাঠান এবং headers পরীক্ষা করুন। Authentication-Results header-এ dkim=pass খুঁজুন।

DMARC: policy enforcement এবং reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) SPF এবং DKIM-কে একসঙ্গে যুক্ত করে এবং authentication fail হলে receiving server কী করবে তা জানায়। এটি reporting-ও চালু করে, ফলে আপনি দেখতে পারেন কে আপনার domain হিসেবে email পাঠাচ্ছে—legitimate এবং spoofed উভয়ই।

একটি minimal DMARC record এমন দেখায়:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none মানে শুধু monitor—failed message reject বা quarantine করবেন না
• rua=mailto:[email protected] aggregate report কোথায় পাঠাতে হবে তা নির্দিষ্ট করে

SPF এবং DKIM কাজ করছে নিশ্চিত হলে policy কঠোর করে p=quarantine (failure spam-এ পাঠান) বা p=reject (সরাসরি bounce করুন) করতে পারেন। আপনি sp= দিয়ে subdomain policy সেট করতে পারেন এবং pct= দিয়ে কত শতাংশ message-এ policy প্রয়োগ হবে তা নির্দিষ্ট করতে পারেন।

DMARC report হলো major receiver-দের পাঠানো daily XML file। raw অবস্থায় এগুলো verbose এবং পড়া কঠিন, কিন্তু কোন message authentication pass বা fail করেছে এবং কেন—তা এগুলো সঠিকভাবে জানায়। legitimate mail reject হতে দেখলে report-গুলো দেখাবে কোন SPF বা DKIM check fail করছে।

একটি gotcha: DMARC alignment চায়। SPF-এর ক্ষেত্রে Return-Path header-এর domain অবশ্যই From header-এর domain-এর সঙ্গে match করতে হবে (অথবা subdomain হতে হবে)। DKIM-এর ক্ষেত্রে DKIM signature-এর d= domain অবশ্যই From domain-এর সঙ্গে match করতে হবে। আপনি third-party sending service ব্যবহার করলে, তাদের custom return path বা আপনার domain দিয়ে DKIM signing support করতে হবে, তাদের domain দিয়ে নয়।

আপনার বর্তমান setup কীভাবে audit করবেন

বেশিরভাগ DNS issue সমস্যা তৈরি করার আগ পর্যন্ত অদৃশ্য থাকে। কিছু ভাঙার আগেই আপনার record কীভাবে check করবেন:

1. আপনার MX record query করুন: dig MX example.com আপনার mail server hostname এবং priority return করা উচিত। সেগুলো আপনার email provider-এর documentation-এর সঙ্গে match করছে কিনা verify করুন।

1. SPF syntax check করুন: dig TXT example.com চালান এবং v=spf1 record খুঁজুন। syntax error এবং lookup limit violation ধরতে SPF validator দিয়ে সেটি চালান।

1. DKIM key verify করুন: একটি test email পাঠান এবং DKIM-Signature header inspect করুন। selector এবং domain extract করুন, এরপর public key আছে কিনা confirm করতে dig TXT selector._domainkey.example.com query করুন।

1. DMARC policy validate করুন: dig TXT _dmarc.example.com আপনার DMARC record return করা উচিত। নিশ্চিত করুন rua= এমন address-এ point করছে যা আপনি সত্যিই monitor করেন।

1. End-to-end test করুন: mail-tester.com-এর মতো service ব্যবহার করুন বা Gmail address-এ পাঠিয়ে full header check করুন। Authentication-Results header-এ spf=pass, dkim=pass, এবং dmarc=pass খুঁজুন।

ইমেইল কেন পৌঁছাচ্ছে না তা debug করলে headers আপনার সেরা tool। বেশিরভাগ mail client raw header দেখতে দেয়—Gmail-এ message খুলুন, তিনটি dot-এ click করুন, এবং 'Show original' select করুন। Authentication-Results header আপনাকে ঠিক কোন check fail করেছে এবং কেন তা জানাবে।

কখন subdomain policy ব্যবহার করবেন

আপনি যদি একাধিক subdomain থেকে email পাঠান—ধরা যাক marketing-এর জন্য newsletter.example.com এবং transactional mail-এর জন্য app.example.com—তাহলে per-subdomain DMARC policy সেট করতে পারেন। এতে আপনি নিয়ন্ত্রণ করেন এমন subdomain-এ strict policy enforce করতে পারবেন, আর main domain-এ তুলনামূলক looser policy রাখতে পারবেন।

trade-off হলো complexity। প্রতিটি subdomain-এর নিজস্ব SPF, DKIM, এবং DMARC record দরকার, এবং কোন sending service কোন subdomain-এর জন্য authorized তা track করতে হবে। বেশিরভাগ ছোট team-এর জন্য একটি well-configured domain সহজ এবং ঠিক ততটাই secure।

authentication ভেঙে গেলে কী করবেন

সবচেয়ে common failure mode হলো DNS update না করেই নতুন sending service যোগ করা। আপনি যদি নতুন transactional email provider ব্যবহার শুরু করেন, তাহলে তাদের SPF include বা IP range যোগ করতে হবে, আপনার domain দিয়ে DKIM signing configure করতে হবে, এবং DMARC alignment verify করতে হবে।

দ্বিতীয় সবচেয়ে common issue হলো forwarding। user-রা আপনার email অন্য address-এ forward করলে SPF fail করবে, কারণ forwarding server আপনার SPF record-এ নেই। DKIM সাধারণত forwarding টিকে থাকে, তাই DKIM pass করলে এবং আপনার DMARC policy partial alignment allow করলে message এখনও deliver হওয়া উচিত। forwarded mail reject হতে দেখলে আপনার DMARC policy check করুন—strict alignment সহ p=reject forwarding ভেঙে দেবে।

তৃতীয় issue হলো DNS propagation। DNS record-এ change propagate হতে কয়েক ঘণ্টা লাগতে পারে, এবং ভিন্ন mail server ভিন্ন সময়ের জন্য record cache করে। আপনি সদ্য কোনো record update করে থাকলে এবং সেটি কাজ না করলে, কয়েক ঘণ্টা অপেক্ষা করুন এবং আবার test করুন। whatsmydns.net-এর মতো tool দিয়ে propagation check করতে পারেন।

মূল takeaway

• MX record inbound mail route করে; SPF, DKIM এবং DMARC outbound mail authenticate করে। এগুলো ভিন্ন সমস্যা সমাধান করে এবং আপনার চারটিই দরকার।
• SPF forwarding-এ ভেঙে যায় এবং এর ten-lookup limit আছে। DKIM forwarding টিকে থাকে কিন্তু per-service configuration দরকার। DMARC এগুলোকে একসঙ্গে যুক্ত করে এবং reporting enable করে।
• DMARC-এ p=none দিয়ে শুরু করুন, কয়েক সপ্তাহ report monitor করুন, এরপর legitimate mail pass করছে নিশ্চিত হলে p=quarantine বা p=reject-এ tighten করুন।
• DNS error নীরব। real email দিয়ে আপনার configuration test করুন এবং SPF, DKIM ও DMARC pass করছে কিনা confirm করতে headers inspect করুন।
• নতুন sending service যোগ করার পর authentication ভেঙে গেলে SPF include, DKIM selector, এবং DMARC alignment check করুন। কোন check fail করেছে তা headers আপনাকে জানাবে।

FAQ

Q: আমার কি একাধিক SPF record থাকতে পারে?

A: না। একাধিক SPF record থাকলে সবগুলোই ignore হবে। একাধিক service authorize করতে হলে একটি single SPF record-এর মধ্যে include: directive ব্যবহার করুন, অথবা সরাসরি IP range list করুন। ten-lookup limit খেয়াল রাখুন।

Q: আমি যদি দিনে মাত্র কয়েকটি email পাঠাই, তবুও কি DMARC দরকার?

A: হ্যাঁ। DMARC volume নিয়ে নয়—আপনি যিনি বলছেন সত্যিই তিনি কিনা তা প্রমাণ করা নিয়ে। ছোট domain-ও DMARC থেকে benefit পায়, কারণ এটি spoofing প্রতিরোধ করে এবং delivery issue-এর visibility দেয়। p=none এবং একটি reporting address দিয়ে শুরু করুন।

Q: DKIM এবং SPF দুটোই fail করলে কিন্তু email legitimate মনে হলে কী হয়?

A: এটি আপনার DMARC policy-এর ওপর নির্ভর করে। p=none হলে mail warning সহ deliver হয়। p=quarantine হলে spam-এ যায়। p=reject হলে bounce হয়। এই কারণেই strict policy enforce করার আগে DMARC report monitor করা উচিত—আপনার অজানা legitimate sender থাকতে পারে।

Q: আমি কি একাধিক domain-এর জন্য একই DKIM key ব্যবহার করতে পারি?

A: technically হ্যাঁ, কিন্তু করবেন না। প্রতিটি domain-এর নিজস্ব DKIM key pair থাকা উচিত। key share করলে rotation কঠিন হয় এবং private key compromise হলে blast radius বাড়ে।

Q: DKIM key কত ঘন ঘন rotate করা উচিত?

A: universal rule নেই, তবে বেশিরভাগ domain-এর জন্য বছরে একবার reasonable। কোনো key compromise হয়েছে সন্দেহ হলে সঙ্গে সঙ্গে rotate করুন। নতুন private key দিয়ে signing শুরু করার আগে DNS-এ নতুন public key publish করা নিশ্চিত করুন, এবং delayed mail handle করতে rotation-এর পর কয়েক দিন পুরোনো key DNS-এ রেখে দিন।

<!-- tool-cta:start -->

💡 এটি চেষ্টা করুন: DMARC Lookup দিয়ে যেকোনো ডোমেইনের প্রকাশিত নীতি পরীক্ষা করুন, যাতে বাস্তবে MX, SPF এবং DMARC রেকর্ড কীভাবে একসঙ্গে কাজ করে তা দেখতে পারেন।

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — SPF specification, যার মধ্যে syntax rule এবং ten-lookup limit আছে।
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specification, যেখানে signature generation এবং verification cover করা হয়েছে।
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC specification, যার মধ্যে policy syntax এবং aggregate reporting format আছে।
• Google Workspace: spoofing এবং spam প্রতিরোধ — Google Workspace domain-এর জন্য SPF, DKIM এবং DMARC configuration নিয়ে practical guidance।