DNS আর email নিরাপত্তা — DNSSEC, SPF, DKIM আর DMARC

১ · নামের ওপর বিশ্বাস — কেন DNS আর email একসাথে

এলাকার পোস্ট অফিসের কথা ভাবুন। ঠিকানা-খাতায় লেখা আছে কোন বাড়ি কোথায়। পিয়ন সেই খাতা দেখে চিঠি দেন। কেউ খাতার একটি লাইন বদলে দিলে আপনার চিঠি অন্য বাড়িতে যাবে। আবার কেউ খামে আপনার নাম লিখে চিঠি পাঠালে প্রাপক ভাববেন, চিঠিটি আপনারই।

ইন্টারনেটে এই ঠিকানা-খাতা হলো DNS, আর চিঠি পৌঁছানোর নিয়ম হলো SMTP. দুটিই ১৯৮০-এর দশকের নকশা। তখন network-এর মানুষ একে অপরকে চিনতেন, তাই পরিচয় প্রমাণের ব্যবস্থা মূল নকশায় ছিল না। DNS কীভাবে কাজ করে তা Computer Networks-এর DNS পর্বে আর চিঠি কীভাবে পৌঁছায় তা email পর্বে দেখানো হয়েছে। এখানে আমরা রক্ষকের চোখে দেখব: কী ভাঙতে পারে, কীভাবে ঠেকাবেন, আর কীভাবে জানবেন।

দুটি বিষয় একই পর্বে থাকার কারণ সহজ। Email-এর সব প্রতিরক্ষা DNS-এর record-এ প্রকাশ হয়। আর ওয়েবের certificate পাওয়ার domain validation-ও অনেক সময় DNS বা mail-এর ওপর নির্ভর করে। নিচের ছবিটি দেখুন: ওপরের স্তর ভাঙলে নিচের সবকিছু একসাথে ঝুঁকিতে পড়ে।

২ · DNS-এর তিন ঝুঁকি আর তাদের প্রতিরক্ষা

DNS-এর ভুল উত্তর তিনটি জায়গা থেকে আসতে পারে: পথের মাঝে বা resolver-এর cache-এ, উৎসে অর্থাৎ registrar বা authoritative server-এ, আর আপনার নিজের ভুলে যাওয়া পুরোনো record থেকে।

ক. Cache poisoning — খাতায় ভুল লাইন ঢোকা

Resolver একবার উত্তর পেলে TTL শেষ না হওয়া পর্যন্ত সেটি মনে রাখে। Cache poisoning মানে সেই cache-এ ভুল উত্তর ঢুকে যাওয়া। তখন একই resolver-এর সব ব্যবহারকারী ভুল ঠিকানা পান। Spoofing-এর সাধারণ ধারণা পর্ব ২১-এ, আর network-এর দিক Computer Networks-এর আক্রমণ ও প্রতিরক্ষা পর্বে আছে। পুরোনো resolver শুধু ১৬ bit-এর query ID মেলাত, আর আধুনিক resolver এলোমেলো source port-ও মেলায়। হিসাবটি দেখুন।

প্রতিরক্ষা: Resolver আপডেট রাখা, port randomization, RFC 5452-এর সুপারিশ মানা, ভেতরের resolver বাইরের সবার জন্য খোলা না রাখা, আর সম্ভব হলে DNSSEC যাচাই চালু করা।

খ. Registrar বা DNS account দখল — দলিলই বদলে যাওয়া

DNS hijacking-এ NS, A বা MX record বদলে যায়। সবচেয়ে পরিচিত প্রকাশিত উদাহরণ যুক্তরাষ্ট্রের CISA-র Emergency Directive 19-01 (জানুয়ারি ২০১৯). সেখানে বলা হয়, আক্রমণকারীরা DNS বদলানোর অধিকারওয়ালা account-এর credential পেয়ে record বদলেছিল, ট্রাফিক নিজেদের দিকে নিয়েছিল, আর ওই domain-এর জন্য বৈধ certificate-ও পেয়েছিল। সংস্থাগুলোকে যা করতে বলা হয়: record audit, DNS account-এর password বদল, MFA চালু, আর Certificate Transparency log নজরে রাখা।

• Account: Phishing-প্রতিরোধী MFA (পর্ব ১৬), SMS নয়। ব্যক্তিগত নয়, প্রতিষ্ঠানের নিয়ন্ত্রিত account. কম মানুষের হাতে অধিকার (পর্ব ২০).
• Lock: Registrar lock চালু রাখুন। গুরুত্বপূর্ণ domain-এ registry lock দেখুন, যদি আপনার TLD আর registrar দেয়।
• চক্র ভাঙুন: Registrar account-এর recovery email ওই একই domain-এ রাখবেন না। Domain হারালে recovery-ও হারাবে। অন্য domain-এর একটি নিয়ন্ত্রিত ঠিকানা রাখুন।
• নবায়ন: Auto-renew চালু রাখুন, একাধিক যোগাযোগ দিন, মেয়াদের তারিখ asset তালিকায় লিখুন।
• পরিবর্তন নজরদারি: বাইরে থেকে নিজের NS, MX, DS, CAA আর TXT নিয়মিত মেলান। DNS পরিবর্তনে review আর ticket রাখুন। CAA record দিয়ে অনুমোদিত CA সীমিত করুন, আর CT monitoring চালান।

গ. Dangling record আর subdomain takeover — পুরোনো সাইনবোর্ড

দোকান উঠে গেছে, কিন্তু মোড়ে সাইনবোর্ড রয়ে গেছে: “এই গলিতে আমাদের শাখা।” কেউ সেই জায়গা ভাড়া নিলে সাইনবোর্ডের বিশ্বাসটুকুও পেয়ে যায়। Dangling record-ও তাই। promo.example.com-এর CNAME একটি cloud সেবার দিকে ছিল। সেবা মোছা হলো, record থাকল। অন্য কেউ সেই নামটি নিতে পারলে আপনার subdomain তার হাতে চলে যায়। একে বলে subdomain takeover. ফল হতে পারে phishing পাতা, cookie-র ঝুঁকি, এমনকি আপনার নামে certificate.

Guardio Labs-এর ২০২৪ সালের “SubdoMailing” প্রতিবেদনে বলা হয়, বহু প্রতিষ্ঠানের ভুলে যাওয়া CNAME আর SPF include-এর লক্ষ্য মেয়াদোত্তীর্ণ domain ছিল। সেগুলো নতুন করে কিনে spam পাঠানো হচ্ছিল, আর চিঠিগুলো যাচাইও পার হতো। শিক্ষা হলো: SPF include মানে বিশ্বাস ধার দেওয়া। যাকে দিয়েছেন, সে না থাকলে বিশ্বাসটি ফিরিয়ে নিন।

• ক্রম ঠিক রাখুন: আগে DNS record মুছুন, তারপর সেবা। শুরুতে উল্টোটি করলে মাঝের সময়টি ঝুঁকির।
• তালিকা রাখুন: প্রতিটি record-এর মালিক আর কারণ লিখে রাখুন। Infrastructure as Code হলে record আর সেবা একসাথে তৈরি ও মোছা যায়।
• নিয়মিত মিলিয়ে দেখুন: নিজের zone-এর CNAME, NS, MX আর SPF include-এর লক্ষ্য এখনও আপনার বা আপনার vendor-এর কি না।

৩ · DNSSEC — উত্তরের ওপর সিলমোহর

DNSSEC (মূল মান RFC 4033–4035, ২০০৫) প্রতিটি record-সেটে digital signature জোড়ে। সরকারি চিঠিতে সিলের মতো: সিল দেখে বোঝা যায় চিঠি কোন দপ্তরের, চিঠি গোপন থাকে না। Signature আর key-র ভিত্তি পর্ব ১১-এ দেখেছেন। DNSSEC-এর বিশ্বাসের শিকল PKI-র মতো, তবে CA-র বদলে DNS-এর গাছ ধরে চলে। নিচে একটি resolver কীভাবে www.example.com-এর উত্তর যাচাই করছে দেখুন। মানগুলো কাল্পনিক।

www.example.com.  300  IN  A      192.0.2.10
www.example.com.  300  IN  RRSIG  A 13 3 300 (...)
signer = example.com, key tag = 11111

example.com. DNSKEY  ZSK (tag 11111)  record সই করে
example.com. DNSKEY  KSK (tag 22222)  DNSKEY-সেট সই করে
RRSIG(A) ZSK দিয়ে যাচাই: মিলেছে
প্রশ্ন বাকি: এই key কি সত্যিই example.com-এর?

example.com. DS  22222 13 2 h1
hash(KSK 22222) = h1  মিলেছে
এই DS-এ .com-এর নিজের RRSIG আছে

com. DS  33333 13 2 h2   root-এর সই করা
hash(.com KSK) = h2     মিলেছে
root key = resolver-এ আগে থেকে রাখা trust anchor

flags: qr rd ra ad
www.example.com.  300  IN  A  192.0.2.10
ad = resolver যাচাই করেছে

www.example.com.  300  IN  A  203.0.113.66
RRSIG(A) যাচাই: মেলেনি
Client পায়: status: SERVFAIL
ভুল ঠিকানার বদলে কোনো ঠিকানাই নয়

নিজের domain-এ DNSSEC আছে কি না দেখতে নিচের কমান্ড কাজে লাগে। example.com-এর জায়গায় নিজের domain বসাবেন।

# ১. উত্তরে RRSIG আছে কি না, আর ad flag বসেছে কি না
dig +dnssec A example.com

# ২. Parent-এ DS প্রকাশিত আছে কি না
dig +short DS example.com

নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে (কমান্ড ১-এর অংশ, হাতে সাজানো; কোনো আসল query নয়):

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  300  IN  A      192.0.2.10
example.com.  300  IN  RRSIG  A 13 2 300 20261130000000 20261101000000 11111 example.com. example-signature==

৪ · DoT, DoH, protective DNS আর DNS log

সাধারণ DNS খোলা পোস্টকার্ডের মতো: পথের যে কেউ পড়তে পারে আপনি কোন নাম খুঁজছেন। DoT (RFC 7858) আর DoH (RFC 8484) সেই পোস্টকার্ডকে খামে ভরে। তবে এটি শুধু আপনার device থেকে resolver পর্যন্ত। Resolver সব দেখে। তাই “এনক্রিপ্ট করেছি, এখন কেউ দেখে না” কথাটি ঠিক নয়, শুধু দেখার লোক বদলেছে।

এখানে দুটি ন্যায্য স্বার্থের টানাপোড়েন আছে। কফিশপের Wi-Fi-তে ব্যক্তির গোপনীয়তা বাড়ে, কিন্তু প্রতিষ্ঠানের নিরাপত্তা দল DNS-ভিত্তিক দৃশ্যমানতা হারাতে পারে। NSA-এর ২০২১ সালের নির্দেশিকা “Adopting Encrypted DNS in Enterprise Environments” প্রতিষ্ঠানের জন্য যা বলে তার সারকথা: সব DNS, এনক্রিপ্টেড হোক বা না হোক, নির্ধারিত প্রতিষ্ঠানের resolver-এ যাবে, আর সেই resolver এনক্রিপ্টেড DNS সমর্থন করবে। ভালো নকশা তাই encrypted DNS বন্ধ করা নয়, বরং অনুমোদিত resolver-এ encrypted DNS দেওয়া।

Protective DNS হলো সেই resolver, যা threat intelligence দেখে পরিচিত ক্ষতিকর নাম আটকায়। DNS sinkhole ক্ষতিকর নামের জন্য নিজের নিয়ন্ত্রণের ঠিকানা ফেরত দেয়, যেমন 192.0.2.53. ফলে C2 সংযোগ আসল সার্ভারে পৌঁছায় না, আর log দেখায় কোন device প্রশ্নটি করেছিল। সীমাও আছে: সরাসরি IP-তে সংযোগ এটি থামায় না, আর নতুন domain তালিকায় ঢুকতে সময় লাগে। এটি defense in depth-এর একটি স্তর মাত্র।

DNS log — ছোট log, বড় ইঙ্গিত

প্রায় সব সংযোগের আগে একটি নাম খোঁজা হয়। তাই DNS log সস্তায় অনেক কিছু দেখায়। নিচের ইঙ্গিতগুলো প্রমাণ নয়, তদন্তের শুরু।

title: DNS over TLS to an unapproved resolver
status: experimental
description: Port 853 traffic to any address other than the approved resolver
logsource:
  category: firewall
detection:
  selection:
    dst_port: 853
  filter_approved:
    dst_ip: 192.0.2.53
  condition: selection and not filter_approved
falsepositives:
  - A lab network that is not yet registered
level: medium

DNS log ব্যক্তিগত তথ্যও বটে, কারণ এতে কে কোন সাইট খুঁজেছে তা থাকে। তাই সংরক্ষণের মেয়াদ আর পড়ার অধিকার সীমিত রাখুন। Log রাখা আর নিয়ম লেখা নিয়ে পর্ব ৫৫ (নিরাপত্তার log) আর পর্ব ৫৬ (SIEM আর detection rule)-এ আরও আছে।

৫ · SMTP-র ফাঁক আর SPF

SMTP-র প্রথম মান RFC 821 (১৯৮২), আর বর্তমান মূল মান RFC 5321 (২০০৮). একটি চিঠিতে দুটি আলাদা “প্রেরক” থাকে। ডাকঘরের খাম আর খামের ভেতরের চিঠির প্যাডের মতো। খামে এক ঠিকানা, প্যাডে আরেক ঠিকানা লেখা সম্ভব। মূল প্রোটোকল দুটির কোনোটিই যাচাই করে না। তাই spoofing এত সহজ ছিল, আর phishing এত সফল।

SPF (RFC 7208, ২০১৪) domain-এর TXT record-এ অনুমোদিত প্রেরকের তালিকা রাখে। Receiver খামের MAIL FROM-এর domain ধরে দেখে, সংযোগের IP তালিকায় আছে কি না। বাঁ থেকে ডানে প্রথম মিলেই ফল ঠিক হয়।

; নিজের নিয়ন্ত্রিত zone-এর উদাহরণ। ঠিকানাগুলো documentation block.
example.com.                     3600 IN MX  10 mail.example.com.
example.com.                     3600 IN TXT "v=spf1 ip4:192.0.2.0/25 include:_spf.example.net -all"
sel2026._domainkey.example.com.  3600 IN TXT "v=DKIM1; k=rsa; p=example-public-key-base64"
_dmarc.example.com.              3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

১০-lookup সীমা: include, a, mx, ptr, exists আর redirect, এই সবগুলো DNS প্রশ্ন ঘটায়। RFC 7208 (অংশ ৪.৬.৪) বলে, পুরো যাচাইয়ে এদের মোট সংখ্যা ১০ পেরোলে ফল permerror. ভেতরের include-গুলোও এই হিসাবে ঢোকে। শূন্য উত্তর দেওয়া lookup-এর (void lookup) সীমা ২ রাখা উচিত, এমন সুপারিশও আছে। ip4 আর all কোনো DNS প্রশ্ন করে না, তাই গোনা হয় না। আর একটি domain-এ SPF record একটিই থাকবে।

নিচের simulator-এ DNS নেই, record একটি object-এ রাখা। এটি শুধু ip4, include আর all বোঝে, পূর্ণ SPF নয়। heavy.example.org-এ ১১টি include আছে।

// Toy SPF evaluator: in-memory records only, no DNS query is sent.
const zone = {
  'example.com': 'v=spf1 ip4:192.0.2.0/25 include:_spf.example.net -all',
  '_spf.example.net': 'v=spf1 ip4:198.51.100.0/26 ~all',
  'soft.example.org': 'v=spf1 ip4:192.0.2.128/25 ~all',
  'heavy.example.org': 'v=spf1 ' + Array.from({ length: 11 },
    (_, i) => `include:v${i + 1}.example.net`).join(' ') + ' -all',
};
for (let i = 1; i <= 11; i++) zone[`v${i}.example.net`] = 'v=spf1 ip4:203.0.113.' + i + '/32 -all';
const num = ip => ip.split('.').reduce((a, b) => a * 256 + Number(b), 0);
const inCidr = (ip, cidr) => { const [net, bits = '32'] = cidr.split('/'), size = 2 ** (32 - Number(bits));
  return Math.floor(num(ip) / size) === Math.floor(num(net) / size); };
const QUAL = { '+': 'pass', '-': 'fail', '~': 'softfail', '?': 'neutral' };
function spf(domain, ip, st) {
  const rec = zone[domain]; if (!rec) return 'none';
  for (const term of rec.split(' ').slice(1)) {
    const q = QUAL[term[0]] ? term[0] : '+';
    const t = term.replace(/^[-+~?]/, ''), [mech, arg] = t.split(':');
    if (mech === 'all') return QUAL[q];
    if (mech === 'ip4' && inCidr(ip, arg)) return QUAL[q];
    if (mech === 'include') {
      if (++st.lookups > 10) return 'permerror';   // RFC 7208 section 4.6.4
      const r = spf(arg, ip, st);
      if (r === 'pass') return QUAL[q];
      if (r === 'permerror' || r === 'none') return 'permerror';
    }
  }
  return 'neutral';                                // no match, no "all"
}
for (const [d, ip] of [['example.com', '192.0.2.10'], ['example.com', '198.51.100.5'],
  ['example.com', '203.0.113.9'], ['soft.example.org', '203.0.113.9'], ['heavy.example.org', '192.0.2.10']]) {
  const st = { lookups: 0 };
  console.log(d.padEnd(18), ip.padEnd(13), spf(d, ip, st).padEnd(10), 'lookups=' + st.lookups);
}

example.com        192.0.2.10    pass       lookups=0
example.com        198.51.100.5  pass       lookups=1
example.com        203.0.113.9   fail       lookups=1
soft.example.org   203.0.113.9   softfail   lookups=0
heavy.example.org  192.0.2.10    permerror  lookups=11

সীমা পেরোলে কী করবেন: অব্যবহৃত vendor-এর include সরান। প্রতিটি vendor-কে আলাদা subdomain দিন, যেমন news.example.com. ptr এড়িয়ে চলুন। IP-তে “flatten” করলে lookup কমে, কিন্তু vendor-এর IP বদলালে record পুরোনো হয়ে যায়, তাই সতর্ক থাকুন।

৬ · DKIM — চিঠির ওপর সিলমোহর

SPF পিয়নের তালিকা দেখে। DKIM (RFC 6376, ২০১১) দেখে চিঠির সিলমোহর। পাঠানো সার্ভার private key দিয়ে নির্বাচিত header আর body-র hash-এর ওপর সই করে। Receiver public key আনে DNS থেকে। Selector দিয়ে একই domain-এ একাধিক key রাখা যায়। তাই s=sel2026 আর d=example.com হলে key থাকে sel2026._domainkey.example.com-এ।

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=sel2026;
  h=from:to:subject:date:message-id;
  bh=example-body-hash-base64=;
  b=example-signature-base64=

• কী প্রমাণ করে: d= domain-এর key-ধারী এই চিঠি সই করেছে, আর সই করা অংশ বদলায়নি।
• কী করে না: চিঠি encrypt করে না। বিষয়বস্তু সত্য কি না বলে না। From-এর সাথে d=-এর মিল নিজে দেখে না।
• Key: RFC 8301 (২০১৮) rsa-sha1 সই নিষেধ করে, আর RSA key-তে ন্যূনতম ১০২৪ bit, পছন্দসই ২০৪৮ bit বলে। RFC 8463 (২০১৮) Ed25519 যোগ করেছে, তবে সব receiver সমর্থন করে না বলে অনেকে RSA-ও রাখেন।
• Rotation: নতুন selector প্রকাশ, সই বদল, পুরোনো চিঠি পৌঁছানোর সময় দেওয়া, তারপর পুরোনো key-র p= খালি করা। এটিই নিরাপদ key rotation.

নিচের Python কোডে আসল hashlib দিয়ে শুধু bh= অংশটি বোঝানো হয়েছে। এটি সরলীকৃত উদাহরণ: সই নেই, key নেই, আর DKIM-এর সব নিয়ম নেই। লক্ষ্য একটি প্রশ্ন: body-র কোন বদল hash ভাঙে?

# Simplified DKIM-style body hash: the "bh=" part only, no key and no signature.
# Based on the relaxed body rules of RFC 6376, section 3.4.4. A teaching sketch.
import base64, hashlib, re

def relaxed_body(text):
    lines = text.replace("\r\n", "\n").split("\n")
    lines = [re.sub(r"[ \t]+", " ", ln).rstrip(" ") for ln in lines]
    while lines and lines[-1] == "":
        lines.pop()
    return "".join(ln + "\r\n" for ln in lines) if lines else ""

def simple_body(text):
    body = text.replace("\r\n", "\n").rstrip("\n")
    return body.replace("\n", "\r\n") + "\r\n"

def bh(canonical):
    digest = hashlib.sha256(canonical.encode("utf-8")).digest()
    return base64.b64encode(digest).decode("ascii")

original = "Your invoice 1042 is ready.\nAmount: 500 BDT\n"
samples = [
    ("original", original),
    ("spaces changed", "Your invoice  1042 is ready.   \nAmount: 500 BDT\n\n\n"),
    ("amount changed", "Your invoice 1042 is ready.\nAmount: 900 BDT\n"),
    ("footer added", original + "--\nTo leave this list, see the list page.\n"),
]
signed_relaxed = bh(relaxed_body(original))
signed_simple = bh(simple_body(original))
print("signed bh (relaxed):", signed_relaxed)
print("signed bh (simple) :", signed_simple)
print(f"{'version':16} {'relaxed':9} simple")
for name, body in samples:
    r = "match" if bh(relaxed_body(body)) == signed_relaxed else "MISMATCH"
    s = "match" if bh(simple_body(body)) == signed_simple else "MISMATCH"
    print(f"{name:16} {r:9} {s}")

signed bh (relaxed): qOCIdhqYXswU0nEXgpKCVf9k9onSaZg4JRHoSQE8vFk=
signed bh (simple) : qOCIdhqYXswU0nEXgpKCVf9k9onSaZg4JRHoSQE8vFk=
version          relaxed   simple
original         match     match
spaces changed   match     MISMATCH
amount changed   MISMATCH  MISMATCH
footer added     MISMATCH  MISMATCH

৭ · DMARC — পাঠকের দেখা From-এর সাথে মিল

SPF আর DKIM একটি domain প্রমাণ করে, কিন্তু সেটি পাঠকের দেখা domain কি না বলে না। ধরুন প্রতারক নিজের example.net-এর SPF আর DKIM ঠিক রাখল, আর From-এ লিখল example.com. দুটিই pass, পাঠক ঠকলেন। DMARC এখানে একটি শর্ত যোগ করে: pass করতে হবে, এবং aligned হতে হবে।

Alignment-এর দুটি রূপ। Relaxed (r, ডিফল্ট): একই organizational domain হলেই চলে, যেমন mail.example.com আর example.com. Strict (s): হুবহু একই। RFC 9989-ই বলছে, প্রায় সব domain-মালিকের জন্য relaxed যথেষ্ট হয়েছে।

নিচে একটি বৈধ চিঠির যাত্রা দেখুন। example.com তার newsletter পাঠায় একটি vendor দিয়ে, যার খাম mailer.example.net-এর, কিন্তু DKIM সই example.com-এর।

connection IP : 198.51.100.7
MAIL FROM     : bounce@mailer.example.net
From          : news@example.com
DKIM          : d=example.com; s=sel2026

mailer.example.net TXT
  "v=spf1 ip4:198.51.100.0/26 -all"
198.51.100.7 আছে .0 থেকে .63-এর মধ্যে
spf=pass, domain=mailer.example.net

sel2026._domainkey.example.com TXT
  "v=DKIM1; k=rsa; p=example-public-key-base64"
body hash মিলেছে, signature মিলেছে
dkim=pass, d=example.com

_dmarc.example.com TXT
  "v=DMARC1; p=quarantine;
   rua=mailto:dmarc-reports@example.com"
adkim, aspf নেই, তাই ডিফল্ট r

From org domain   = example.com
SPF  org domain   = example.net  মেলেনি
DKIM org domain   = example.com  মিলেছে

(SPF pass, not aligned)  = false
(DKIM pass, aligned)     = true
dmarc=pass

Authentication-Results: mx.example.org;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

এবার ছয়টি চিঠিতে relaxed আর strict পাশাপাশি দেখুন। সব চিঠির From example.com. এখানে organizational domain “শেষ দুই label” ধরে সরল করা হয়েছে, আসল receiver DNS tree walk করে।

// Toy DMARC alignment checker. Real receivers find the organizational domain
// with a DNS tree walk (RFC 9989); here "last two labels" stands in for it.
const orgDomain = d => d.split('.').slice(-2).join('.');
const aligned = (a, b, mode) => mode === 's' ? a === b : orgDomain(a) === orgDomain(b);

function dmarc(m, adkim = 'r', aspf = 'r') {
  const dkimOk = m.dkim.pass && aligned(m.from, m.dkim.d, adkim);
  const spfOk = m.spf.pass && aligned(m.from, m.spf.d, aspf);
  return { dkimOk, spfOk, pass: dkimOk || spfOk };
}
const messages = [
  { name: 'own server', from: 'example.com',
    spf: { pass: true, d: 'example.com' }, dkim: { pass: true, d: 'example.com' } },
  { name: 'subdomain mail', from: 'example.com',
    spf: { pass: true, d: 'mail.example.com' }, dkim: { pass: true, d: 'news.example.com' } },
  { name: 'vendor, own DKIM', from: 'example.com',
    spf: { pass: true, d: 'bounce.example.net' }, dkim: { pass: true, d: 'example.com' } },
  { name: 'forwarded', from: 'example.com',
    spf: { pass: false, d: 'example.org' }, dkim: { pass: true, d: 'example.com' } },
  { name: 'list changed body', from: 'example.com',
    spf: { pass: true, d: 'lists.example.org' }, dkim: { pass: false, d: 'example.com' } },
  { name: 'claimed From', from: 'example.com',
    spf: { pass: true, d: 'example.net' }, dkim: { pass: true, d: 'example.net' } },
];
const yn = b => (b ? 'yes' : 'no ');
console.log('message            relaxed: dkim spf dmarc | strict: dkim spf dmarc');
for (const m of messages) {
  const r = dmarc(m), s = dmarc(m, 's', 's');
  console.log(m.name.padEnd(18), '        ', yn(r.dkimOk), yn(r.spfOk), r.pass ? 'PASS ' : 'FAIL ', '|',
    '       ', yn(s.dkimOk), yn(s.spfOk), s.pass ? 'PASS' : 'FAIL');
}

message            relaxed: dkim spf dmarc | strict: dkim spf dmarc
own server                  yes yes PASS  |         yes yes PASS
subdomain mail              yes yes PASS  |         no  no  FAIL
vendor, own DKIM            yes no  PASS  |         yes no  PASS
forwarded                   yes no  PASS  |         yes no  PASS
list changed body           no  no  FAIL  |         no  no  FAIL
claimed From                no  no  FAIL  |         no  no  FAIL

৮ · DMARC rollout আর aggregate report

প্রথম দিনেই p=reject দিলে নিজের বিল, রসিদ বা OTP-এর চিঠিই ফেরত যেতে পারে। কারণ প্রতিষ্ঠান প্রায়ই জানে না কতগুলো সেবা তার নামে চিঠি পাঠায়। মহল্লায় নতুন গেট বসানোর আগে দারোয়ান যেমন কিছুদিন শুধু রেজিস্টার খাতায় লেখেন, কাউকে ফেরান না, DMARC-ও তেমন শুরু হয়। RFC 9989-ও p=none-এ অন্তত এক মাস, তারপর একই রকম সময় quarantine রাখার পরামর্শ দেয়।

Aggregate report সাধারণত দিনে একবার আসে, XML আকারে, RFC 9990 অনুযায়ী। এতে চিঠির বিষয়বস্তু থাকে না, থাকে উৎস IP, সংখ্যা আর ফল। অফিসের রেজিস্টার খাতার মাসিক সারসংক্ষেপের মতো। নিচের simulator একই কাল্পনিক ডেটা সাজিয়ে দেখায়। spf আর dkim এখানে মানে “pass এবং aligned”.

// Toy DMARC aggregate report summary. Real reports arrive as XML (RFC 9990);
// these rows are invented, and the source labels are our own inventory notes.
const rows = [
  { ip: '192.0.2.10',    src: 'own mail server',  n: 8200, spf: true,  dkim: true  },
  { ip: '198.51.100.7',  src: 'newsletter vendor', n: 3100, spf: false, dkim: true  },
  { ip: '198.51.100.40', src: 'billing vendor',   n: 640,  spf: false, dkim: false },
  { ip: '203.0.113.50',  src: 'known forwarder',  n: 210,  spf: false, dkim: true  },
  { ip: '203.0.113.99',  src: '(unknown)',        n: 150,  spf: false, dkim: false },
];
// spf and dkim here mean "passed AND aligned", so either one gives DMARC pass.
const pct = (a, b) => (100 * a / b).toFixed(1) + '%';
const total = rows.reduce((s, r) => s + r.n, 0);
const passed = rows.filter(r => r.spf || r.dkim).reduce((s, r) => s + r.n, 0);

console.log('source             ip             count  share  dmarc  action');
for (const r of [...rows].sort((a, b) => b.n - a.n)) {
  const ok = r.spf || r.dkim;
  let action = 'none';
  if (!ok) action = r.src === '(unknown)' ? 'investigate' : 'fix: sign with DKIM';
  console.log(r.src.padEnd(18), r.ip.padEnd(14), String(r.n).padStart(5),
    pct(r.n, total).padStart(6), ok ? ' pass ' : ' FAIL ', action);
}
console.log(`total=${total} dmarc_pass=${passed} rate=${pct(passed, total)}`);

const fixed = passed + rows.find(r => r.src === 'billing vendor').n;
console.log(`after billing fix: rate=${pct(fixed, total)}, still failing=${total - fixed}`);

source             ip             count  share  dmarc  action
own mail server    192.0.2.10      8200  66.7%  pass  none
newsletter vendor  198.51.100.7    3100  25.2%  pass  none
billing vendor     198.51.100.40    640   5.2%  FAIL  fix: sign with DKIM
known forwarder    203.0.113.50     210   1.7%  pass  none
(unknown)          203.0.113.99     150   1.2%  FAIL  investigate
total=12300 dmarc_pass=11510 rate=93.6%
after billing fix: rate=98.8%, still failing=150

Forwarding, mailing list আর ARC

চিঠি forward হলে নতুন সংযোগের IP আলাদা, তাই SPF ব্যর্থ হয়। DKIM টেকে, যদি চিঠি না বদলায়। Mailing list subject-এ ট্যাগ বা নিচে footer বসালে DKIM-ও ভাঙে, তখন নির্দোষ চিঠি DMARC ব্যর্থ হয়। ২০১৪ সালে বড় mail সেবা p=reject দেওয়ার পর mailing list-এ এই সমস্যা ব্যাপকভাবে দেখা দেয়। RFC 9989 নিজেও সতর্ক করে: যে domain-এর ব্যবহারকারীরা mailing list-এ লেখেন, তাদের p=reject না দেওয়াই ভালো।

• List-এর সমাধান: অনেক list From-কে নিজের ঠিকানায় বদলে দেয় (“From rewriting”), আর মূল প্রেরক অন্য header-এ থাকে।
• ARC (RFC 8617, ২০১৯, Experimental): মাঝের সার্ভার যা দেখেছিল তার ফল সই করে পরের সার্ভারকে জানায়। Receiver সেই মধ্যস্থতাকারীকে বিশ্বাস করলে তবেই এটি কাজে লাগে। ARC নিজে কিছু pass করায় না।

যে domain চিঠি পাঠায় না

ব্র্যান্ড রক্ষার জন্য কেনা বা পড়ে থাকা domain-ও নকলের লক্ষ্য। চিঠি না পাঠালে সেটি ঘোষণা করুন। Null MX (RFC 7505) জানায় এই domain চিঠি নেয় না।

; এই domain কোনো চিঠি পাঠায় না, নেয়ও না
nomail.example.com.                3600 IN MX  0 .
nomail.example.com.                3600 IN TXT "v=spf1 -all"
_dmarc.nomail.example.com.         3600 IN TXT "v=DMARC1; p=reject"
*._domainkey.nomail.example.com.   3600 IN TXT "v=DKIM1; p="

৯ · MTA-STS, TLS-RPT, BIMI আর বড় mail সেবার নিয়ম

বড় mail সেবার নিয়ম

কয়েক বছরে email authentication ঐচ্ছিক থেকে কার্যত প্রয়োজনীয় হয়েছে। Google-এর প্রকাশিত নির্দেশিকা অনুযায়ী Gmail-এ দিনে ৫,০০০-এর বেশি চিঠি পাঠালে SPF আর DKIM দুটিই, DMARC (p=none হলেও), From alignment, আর বিপণনের চিঠিতে one-click unsubscribe লাগে। Spam হার ০.৩০%-এর নিচে রাখতে বলা হয়, আর সব প্রেরকের জন্যও SPF বা DKIM, TLS আর বৈধ PTR লাগে। Yahoo-র নিয়ম কাছাকাছি, আর Microsoft ২০২৫ সালে consumer mail সেবার জন্য একই ধরনের নিয়ম ঘোষণা করে। এই নিয়ম বদলায়, প্রয়োগের ধরনও সেবাভেদে আলাদা। তাই সিদ্ধান্তের আগে প্রতিটি সেবার বর্তমান সরকারি পাতা পড়ে নিন। ছোট প্রতিষ্ঠানও এই ভিত্তি রাখলে লাভ পায়।

১০ · AI-এর যুগে DNS আর email record

AI দিয়ে SPF বা DMARC record লেখানো সহজ, আর ভুলও সহজে হয়। Record সিনট্যাক্সে ঠিক থাকলেও আপনার প্রবাহ না জেনে লেখা record বৈধ চিঠি আটকে দিতে পারে। AI সাধারণত যেসব ভুল করে:

• পুরোনো তথ্য: DMARC-এর জন্য শুধু RFC 7489 আর pct বলা, RFC 9989 না জানা।
• বানানো মান বা CVE নম্বর, ভুল RFC নম্বর, আর আত্মবিশ্বাসী ভঙ্গিতে ভুল vendor include.
• সমস্যা “সমাধান” করতে নিয়ন্ত্রণ দুর্বল করা: +all, DNSSEC বন্ধ, p=none-এ ফিরিয়ে দিয়ে ভুলে যাওয়া, TLS যাচাই বন্ধ (verify=False).
• একই domain-এ দুটি SPF record দেওয়া, ১০-lookup সীমা না গোনা, পুরোনো rsa-sha1 বা ছোট key.
• Prompt-এ পুরো DMARC report বা ব্যবহারকারীর ঠিকানা পেস্ট করলে ব্যক্তিগত তথ্য ফাঁস। DKIM private key বা API token কখনো নয়।

• প্রতিটি RFC নম্বর আর নিয়ম মূল উৎসে পড়েছি
• নিজের domain-এ বা test subdomain-এ যাচাই করেছি, অন্যের domain-এ নয়
• SPF lookup নিজে গুনেছি, আর SPF record একটিই আছে
• Prompt-এ কোনো key, token বা ব্যবহারকারীর তথ্য দিইনি
• DNS বদলের আগে পুরোনো মান আর rollback পথ লিখে রেখেছি
• reject বা DNSSEC-এর সিদ্ধান্ত একজন মানুষ দায়িত্ব নিয়ে নিয়েছেন