ইমেইলের DNS: MX, SPF, DKIM, DMARC

গল্পে বুঝি

রুশদের বড় মেয়ের বিয়ে। পরিবার ঠিক করেছে দাওয়াতের কার্ড পাঠাবে একটা নির্দিষ্ট কুরিয়ার কোম্পানি দিয়ে, আর প্রতিটা কার্ডের খামে থাকবে পরিবারের নিজস্ব গালার সিল। শহরে সবাই জানে রুশদের বাসায় চিঠি দিতে হলে কোথায় দিতে হয়: পাড়ার মসজিদের পাশের দোকানে একটা বোর্ড টাঙানো, “রুশদ পরিবারের চিঠি: প্রথমে বড় ছেলের অফিসে, না পেলে চাচার বাসায়”। এদিকে মহল্লার নোটিশবোর্ডে রুশদ আরেকটা ঘোষণা সেঁটে দিয়েছেন: “আমাদের পরিবারের কার্ড শুধু ‘দ্রুত কুরিয়ার’ আর ‘আমাদের ভাগ্নে ফারাবি’ আনবে। অন্য কেউ আনলে সেটা আমাদের নয়।” পাশেই পরিবারের সিলের একটা ছাপ রাখা, যে কেউ মিলিয়ে দেখতে পারে।

দাওয়াত পেয়ে মরিয়মের বাসায় সবাই খুশি, কিন্তু মরিয়মের বাবা সাবধানী মানুষ। তিনি আগে দেখেন কার্ডটা কে এনেছে: নোটিশবোর্ডের তালিকার কুরিয়ার কিনা। তারপর খামের সিলটা নোটিশবোর্ডের ছাপের সাথে মেলান, আর সিলটা অক্ষত কিনা দেখেন, ভেতরের লেখা কেউ বদলেছে কিনা। সবশেষে দেখেন কার্ডের ওপরে যে নাম লেখা, “রুশদ পরিবার”, সিল আর কুরিয়ারের তালিকা সেই একই পরিবারের তো? কারণ কেউ নিজের সিল দিয়ে খাম বন্ধ করে ওপরে রুশদের নাম লিখে দিলে সিল ঠিক থাকলেও পরিবার ভুল। রুশদ নোটিশবোর্ডে আরো লিখে রেখেছেন: “এই নিয়ম না মিললে কার্ডটা ফেলে দিন, আর আমাকে মাসে একবার জানান কে কে আমাদের নামে কার্ড পাঠাল।”

মিলিয়ে নিই: দোকানের বোর্ডে “চিঠি কোথায় দিতে হবে” হলো MX রেকর্ড, আর “প্রথমে বড় ছেলে, না পেলে চাচা” হলো MX-এর priority। নোটিশবোর্ডের অনুমোদিত কুরিয়ারের তালিকা হলো SPF। খামের গালার সিল হলো DKIM signature, আর নোটিশবোর্ডে রাখা সিলের ছাপ DNS-এ প্রকাশ করা DKIM public key। কার্ডের ওপরের নাম আর সিল বা কুরিয়ার একই পরিবারের কিনা মেলানো হলো DMARC alignment, আর “না মিললে ফেলে দিন, মাসে মাসে জানান” হলো DMARC policy আর rua রিপোর্ট। মরিয়মের বাবা হলেন রিসিভিং মেইল সার্ভার, যেমন Gmail। বাস্তবে Gmail আর Yahoo এখন এই যাচাইগুলো ছাড়া বেশি পরিমাণে আসা মেইল নিতে চায় না, তাই নিজের ডোমেইন থেকে মেইল পাঠাতে চাইলে এই চার রেকর্ড ঠিক রাখা ঐচ্ছিক নয়।

পুরো ছবিটা এক নজরে

প্রথম লাইনে মেইল কোথায় যাবে (MX)। তারপর বাকি সব প্রশ্ন একটাই: যে বলছে সে baytalhikma.org থেকে পাঠাচ্ছে, সে কি আসলেই তা? SMTP প্রোটোকলে যে কেউ যেকোনো From: লিখে মেইল পাঠাতে পারে; SPF, DKIM আর DMARC হলো পরে যোগ করা প্রমাণপত্র, আর সবই DNS-এ থাকে।

MX: মেইল কোথায় নামবে

dig +short MX baytalhikma.org

10 mx1.baytalhikma.org.
20 mx2.baytalhikma.org.

• সংখ্যা ছোট মানে আগে। পাঠানো সার্ভার আগে 10-এ চেষ্টা করে, না পারলে 20-এ। একই সংখ্যার একাধিক MX থাকলে লোড ভাগ হয়।
• MX-এর টার্গেট একটা হোস্টনেম, যার A বা AAAA থাকতে হবে। IP সরাসরি লেখা যায় না (10 203.0.113.25 ভুল)। আর RFC 2181 অনুযায়ী টার্গেট একটা CNAME হতে পারবে না; অনেক সার্ভার মেনে নেয়, কিছু নেয় না, তাই ঝুঁকি নেবেন না।
• MX না থাকলে পাঠানো সার্ভার ডোমেইনের A রেকর্ডে মেইল দিতে চেষ্টা করে (implicit MX)। মানে আপনার ওয়েব সার্ভারে পোর্ট ২৫-এ কেউ মেইল দিতে আসবে।
• ডোমেইন যদি কখনোই মেইল না নেয়, RFC 7505-এর null MX বসান। এটা পাঠানো সার্ভারকে সাথে সাথে জানিয়ে দেয় চেষ্টা করে লাভ নেই:

cordoba-landing.example.  3600  IN  MX  0 .

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

SPF (RFC 7208) একটা TXT রেকর্ড, ডোমেইনের apex-এ (বা যে নাম envelope sender হিসেবে ব্যবহৃত হয় সেখানে):

dig +short TXT baytalhikma.org

"v=spf1 ip4:203.0.113.25 include:_spf.google.com include:sendgrid.net ~all"

বাঁ থেকে ডানে পড়া হয়, প্রথম যেটা মেলে সেটাই রায়:

অংশ	মানে
v=spf1	এটা SPF রেকর্ড; শুরুতে থাকতেই হবে
ip4:203.0.113.25 / ip6:2001:db8::25	এই IP বা রেঞ্জ অনুমোদিত
a / mx	এই ডোমেইনের A বা MX যে IP-তে, সেটাও অনুমোদিত
include:_spf.google.com	ওই ডোমেইনের SPF যা অনুমোদন করে, তা-ও অনুমোদিত (Google Workspace-এর জন্য)
redirect=_spf.baytalhikma.org	পুরো সিদ্ধান্ত অন্য রেকর্ডের হাতে দেওয়া
-all	বাকি সবাই অননুমোদিত: fail
~all	বাকি সবাই সন্দেহজনক: softfail (সাধারণত গ্রহণ, তবে চিহ্নিত)
?all	কোনো মত নেই: neutral
+all	যে কেউ পাঠাতে পারবে। কখনো ব্যবহার করবেন না

SPF যাচাই হয় envelope sender (SMTP-র MAIL FROM, যাকে Return-Path বা bounce address-ও বলে) এর ডোমেইনের বিপরীতে, ইউজার যে From: দেখেন তার বিপরীতে নয়। এই পার্থক্যটাই DMARC-এর alignment-কে দরকারি করে তোলে।

SPF-এর তিন ফাঁদ

১. একটা ডোমেইনে একটাই SPF রেকর্ড। দুটো v=spf1 TXT থাকলে ফলাফল permerror, মানে SPF পুরো ব্যর্থ। নতুন ইমেইল সার্ভিস যোগ করার সময় অনেকে তাদের নির্দেশমতো আরেকটা SPF রেকর্ড বসিয়ে দেন। সঠিক কাজ: বিদ্যমান রেকর্ডে একটা include: যোগ করা।

২. দশটা DNS লুকআপের সীমা। RFC 7208 অনুযায়ী SPF যাচাই করতে সর্বোচ্চ ১০টা DNS লুকআপ করা যাবে। include, a, mx, ptr, exists, redirect, প্রতিটা একটা করে গোনে, আর include-এর ভেতরের include-ও। ip4/ip6/all গোনে না। Google Workspace, একটা মার্কেটিং টুল, একটা হেল্পডেস্ক, একটা CRM, প্রত্যেকে কয়েকটা করে লুকআপ খায়, আর হঠাৎ ১১ হয়ে গেলে SPF permerror। তাছাড়া যে লুকআপের উত্তর খালি বা NXDOMAIN আসে (void lookup), RFC সেগুলো দুইটার বেশি না হওয়ার সুপারিশ করে।

গুনে দেখার সহজ উপায় হলো রেকর্ড ধরে ধরে নিচে নামা:

dig +short TXT baytalhikma.org | grep spf1
dig +short TXT _spf.google.com
dig +short TXT _netblocks.google.com

৩. “Flattening”-এর ঝুঁকি। সীমা পার হলে কিছু টুল সব include-কে IP-তে খুলে একটা লম্বা ip4: তালিকা বানায়। লুকআপ কমে, কিন্তু প্রোভাইডার যেদিন নিজের IP বদলাবে, আপনার রেকর্ড পুরনো থেকে যাবে আর মেইল ফেল করবে। ভালো বিকল্প: যে সার্ভিসগুলো আসলে ব্যবহার হয় না সেগুলো সরানো, আর আলাদা সার্ভিসকে আলাদা সাবডোমেইন থেকে পাঠানো (যেমন news.baytalhikma.org-এর নিজস্ব SPF)।

DKIM: খামের সিল

DKIM (RFC 6376) মেইলের হেডার আর বডির একটা অংশের উপর ক্রিপ্টোগ্রাফিক সিগনেচার। পাঠানো সার্ভার প্রাইভেট কী দিয়ে সাইন করে আর মেইলে একটা DKIM-Signature হেডার বসায়:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baytalhikma.org;
 s=s2026; h=from:to:subject:date:message-id; bh=...; b=...

d= হলো সাইন করা ডোমেইন, s= হলো selector। রিসিভার পাবলিক কী খোঁজে selector._domainkey.domain নামে:

dig +short TXT s2026._domainkey.baytalhikma.org

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx..." "...IDAQAB"

২০৪৮-বিট কী-র পাবলিক অংশ একটা TXT স্ট্রিংয়ের ২৫৫ অক্ষরের সীমার চেয়ে লম্বা, তাই সেটা কয়েকটা কোট করা টুকরোয় ভাঙা থাকে; রিসিভার টুকরোগুলো জোড়া দিয়ে পড়ে। প্যানেলে বসানোর সময় পুরো কী একটা লাইনে দিলে বেশিরভাগ প্যানেল নিজেই ভেঙে নেয়, কিন্তু কোট আর ফাঁকা জায়গা ভুল হলে কী অকেজো।

Selector কেন আছে: একসাথে একাধিক কী রাখা যায়। Google Workspace একটা selector-এ, আপনার নিউজলেটার সার্ভিস আরেকটায়, আর কী বদলানোর (rotation) সময় নতুন selector-এ নতুন কী প্রকাশ করে সাইনিং সেখানে সরিয়ে নিন, কয়েকদিন পর পুরনোটা মুছে দিন। পুরনো কী সাথে সাথে মুছে দিলে পথে থাকা মেইল যাচাই ফেল করবে।

ESP-কে CNAME দিয়ে দায়িত্ব দেওয়া: অনেক ইমেইল সার্ভিস প্রোভাইডার (ESP) আপনাকে TXT না দিয়ে CNAME বসাতে বলে, যেমন s1._domainkey.baytalhikma.org CNAME s1.domainkey.u123.sendgrid.net.। এতে কী রোটেট করার কাজ তারা নিজেরাই করতে পারে, আপনার DNS না ছুঁয়ে।

DMARC: নাম, সিল আর নির্দেশ এক জায়গায়

SPF আর DKIM একা একটা বড় ফাঁক রেখে যায়: দুটোই অন্য কোনো ডোমেইনের জন্য পাস করতে পারে। একজন প্রতারক নিজের ডোমেইন evil.example থেকে SPF আর DKIM ঠিক রেখে মেইল পাঠাল, কিন্তু From: হেডারে লিখল billing@baytalhikma.org। SPF পাস (evil.example-এর জন্য), DKIM পাস (d=evil.example), অথচ ইউজার দেখছেন আপনার নাম।

DMARC (RFC 7489) এই ফাঁক বন্ধ করে alignment দিয়ে: মেইল তখনই DMARC পাস করবে যখন SPF বা DKIM-এর অন্তত একটা পাস করে এবং সেটার ডোমেইন From: হেডারের ডোমেইনের সাথে মেলে।

dig +short TXT _dmarc.baytalhikma.org

"v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@baytalhikma.org; adkim=r; aspf=r; pct=100"

ট্যাগ	মানে
p=none	শুধু পর্যবেক্ষণ: ফেল করলেও কিছু করবেন না, শুধু রিপোর্ট পাঠান
p=quarantine	ফেল করলে স্প্যাম ফোল্ডারে
p=reject	ফেল করলে SMTP-তেই প্রত্যাখ্যান
sp=	সাবডোমেইনের জন্য আলাদা policy
rua=mailto:...	দৈনিক aggregate রিপোর্ট (XML) কোথায় যাবে: কোন IP আপনার নামে কত মেইল পাঠাল, কোনটা পাস করল
ruf=mailto:...	প্রতিটা ফেলের বিস্তারিত রিপোর্ট; অনেক বড় প্রোভাইডার প্রাইভেসির কারণে এটা পাঠায় না
adkim=r / s	DKIM alignment relaxed (সাবডোমেইন মেলে: d=mail.baytalhikma.org চলবে) বা strict (হুবহু মিলতে হবে)
aspf=r / s	SPF alignment-এর একই নিয়ম
pct=	policy কত শতাংশ মেইলে প্রয়োগ হবে, ধীরে ধীরে চালু করার জন্য

রিপোর্ট যদি অন্য ডোমেইনের ঠিকানায় পাঠাতে চান (যেমন একটা DMARC অ্যানালাইসিস সার্ভিসে), সেই ডোমেইনকে একটা অনুমতি রেকর্ড প্রকাশ করতে হয় (baytalhikma.org._report._dmarc.reports.example নামে v=DMARC1), নইলে রিসিভার রিপোর্ট পাঠাবে না।

নিরাপদে চালু করার ধাপ

1. p=none আর rua দিয়ে শুরু। দুই-চার সপ্তাহ রিপোর্ট পড়ুন। দেখবেন আপনার নামে কারা কারা পাঠায়: আপনার CRM, ইনভয়েস সিস্টেম, হয়তো কোনো পুরনো সার্ভার যার কথা কেউ মনে রাখেনি।
2. প্রতিটা বৈধ উৎসের জন্য SPF include আর DKIM ঠিক করুন যাতে aligned পাস করে।
3. p=quarantine; pct=25, তারপর ধীরে ধীরে ১০০।
4. শেষে p=reject।

সরাসরি p=reject দিয়ে শুরু করলে প্রথম দিনেই আপনার নিজের ইনভয়েস বা পাসওয়ার্ড রিসেট মেইল প্রত্যাখ্যাত হতে পারে, আর আপনি জানবেন রিপোর্ট আসার পর।

Gmail আর Yahoo-র সেন্ডার নিয়ম

Google ১ ফেব্রুয়ারি ২০২৪ থেকে Gmail-এ পাঠানো মেইলের জন্য নিয়ম চালু করেছে (Yahoo-ও কাছাকাছি নিয়ম চালু করেছে)। Google-এর সেন্ডার গাইডলাইন পাতা অনুযায়ী, ২০২৬ সালের অক্টোবরে:

সব সেন্ডারের জন্য:

• SPF অথবা DKIM
• সেন্ডিং IP-র বৈধ forward ও reverse DNS (PTR, নিচে দেখুন)
• মেইল পাঠাতে TLS
• Postmaster Tools-এ স্প্যাম রেট ০.৩%-এর নিচে (লক্ষ্য রাখুন ০.১%-এর নিচে)

দিনে ৫,০০০-এর বেশি মেইল Gmail-এ পাঠালে, ওপরেরগুলোর সাথে:

• SPF এবং DKIM দুটোই
• DMARC রেকর্ড, policy কমপক্ষে p=none
• From: ডোমেইন SPF বা DKIM ডোমেইনের সাথে aligned
• মার্কেটিং মেইলে one-click unsubscribe

PTR আর FCrDNS: সেন্ডিং IP-র পরিচয়

রিসিভার সেন্ডিং IP-র reverse DNS দেখে। IP থেকে নাম বের করতে in-addr.arpa নামের একটা বিশেষ zone-এ PTR রেকর্ড খোঁজা হয়:

dig +short -x 203.0.113.25
dig +short A mail.baytalhikma.org

mail.baytalhikma.org.
203.0.113.25

এটাই FCrDNS (forward-confirmed reverse DNS): IP থেকে নাম, আর সেই নাম থেকে আবার একই IP। দুটো না মিললে বা PTR না থাকলে অনেক রিসিভার মেইল প্রত্যাখ্যান করে বা স্প্যামে পাঠায়।

MTA-STS আর TLS-RPT: মেইল যেন এনক্রিপ্টেড পথেই যায়

সার্ভার থেকে সার্ভারে SMTP ঐতিহ্যগতভাবে “পারলে TLS” (STARTTLS) ব্যবহার করে। মাঝখানে কেউ STARTTLS-এর অফারটা মুছে দিলে মেইল প্লেইন টেক্সটে যায়, কেউ টেরও পায় না। MTA-STS (RFC 8461) রিসিভিং ডোমেইনকে বলতে দেয়: “আমার কাছে মেইল দিতে হলে বৈধ সার্টিফিকেটসহ TLS বাধ্যতামূলক, আর আমার MX শুধু এগুলো।”

দুটো অংশ লাগে। একটা DNS রেকর্ড, যা বলে policy আছে আর তার ভার্সন:

_mta-sts.baytalhikma.org.  3600  IN  TXT  "v=STSv1; id=2026102301"

আর HTTPS-এ একটা policy ফাইল, ঠিক এই ঠিকানায়: https://mta-sts.baytalhikma.org/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.baytalhikma.org
mx: mx2.baytalhikma.org
max_age: 604800

policy বদলালে TXT-এর id বদলাতে হয়, নইলে পাঠানো সার্ভারগুলো ক্যাশ করা পুরনো policy-ই রাখবে। শুরু করুন mode: testing দিয়ে।

TLS-RPT (RFC 8460) হলো এর রিপোর্টিং অংশ: পাঠানো সার্ভারগুলো আপনার কাছে TLS ব্যর্থতার দৈনিক রিপোর্ট পাঠায়।

_smtp._tls.baytalhikma.org.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@baytalhikma.org"

BIMI, সংক্ষেপে

BIMI ইনবক্সে আপনার ব্র্যান্ডের লোগো দেখানোর একটা ব্যবস্থা, default._bimi.baytalhikma.org নামে একটা TXT রেকর্ড দিয়ে, যেটা একটা SVG লোগোর দিকে নির্দেশ করে। এটা কাজ করে শুধু DMARC enforcement-এ থাকলে (quarantine বা reject), আর বড় প্রোভাইডাররা সাধারণত একটা সার্টিফিকেটও (VMC বা এই ধরনের মার্ক সার্টিফিকেট) চায়, যা টাকা দিয়ে কিনতে হয়। কোন প্রোভাইডার কী চায় সময়ের সাথে বদলায়, তাই আগে DMARC ঠিক করুন; BIMI হলো একেবারে শেষের সাজসজ্জা, ডেলিভারির জন্য দরকারি কিছু নয়।

রিসিভারের রায় পড়া: Authentication-Results হেডার

মেইল কেন স্প্যামে গেল, তার সবচেয়ে ভালো প্রমাণ রিসিভারের নিজের রায়। Gmail-এ মেইল খুলে “Show original” দিলে হেডারের মধ্যে পাবেন:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@baytalhikma.org header.s=s2026 header.b=Qm3x...;
       spf=pass (google.com: domain of bounce@baytalhikma.org designates 203.0.113.25 as permitted sender) smtp.mailfrom=bounce@baytalhikma.org;
       dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=baytalhikma.org

পড়ার ক্রম:

1. dmarc= আগে দেখুন। pass হলে প্রমাণপত্রের দিক থেকে মেইল ঠিক; স্প্যামে গেলে কারণ কন্টেন্ট বা সুনাম।
2. fail হলে দেখুন spf= আর dkim= কী বলছে, আর কোন ডোমেইনের জন্য: smtp.mailfrom আর header.i/header.d কি header.from-এর সাথে মেলে? না মিললে সেটা alignment-এর সমস্যা, SPF বা DKIM নিজে ঠিক থাকলেও।
3. spf=permerror মানে রেকর্ডে গঠনগত সমস্যা (দুটো SPF, বা দশ লুকআপের বেশি)। spf=softfail মানে IP তালিকায় নেই আর আপনি ~all দিয়েছেন।
4. dkim=fail (body hash did not verify) মানে পথে কেউ মেইলের বডি বদলেছে, প্রায়ই মেইলিং লিস্ট বা সিকিউরিটি গেটওয়ে ফুটার যোগ করে।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত হবেন যেভাবে	সমাধান
ডোমেইনে কোনো মেইলই আসছে না	dig +short MX ডোমেইন; টার্গেটের dig +short A; nc -vz mx1... 25	MX বসান বা ঠিক করুন; টার্গেটের শেষে ডট; টার্গেট যেন CNAME বা IP না হয়
মেইল আসে, কিন্তু একটা নির্দিষ্ট প্রোভাইডার থেকে আসে না	পাঠানো দিকের bounce মেসেজ পড়ুন	bounce-এর কারণ ধরে MX, TLS বা ফায়ারওয়াল দেখুন
spf=permerror	dig +short TXT ডোমেইন এ দুটো v=spf1? include গুনে দেখুন	একটা রেকর্ডে মেলান; অব্যবহৃত include সরান; সার্ভিসকে সাবডোমেইনে পাঠান
নতুন ESP যোগ করার পর SPF ফেল	ESP-র include বিদ্যমান রেকর্ডে আছে কিনা; লুকআপ সংখ্যা	include যোগ করুন, আলাদা SPF রেকর্ড নয়
dkim=fail বা dkim=neutral (no key)	হেডারের s= আর d= নিয়ে dig +short TXT s._domainkey.d	কী প্রকাশ করুন; TXT-এর কোট বা ভাঙা টুকরো ঠিক করুন; ESP-র CNAME ঠিক আছে কিনা দেখুন
কী রোটেশনের পর কিছু মেইল DKIM ফেল	পুরনো selector-এর রেকর্ড আগেই মুছে ফেলা হয়েছে	নতুন selector-এ সাইন শুরুর পর কয়েকদিন পুরনো কী রেখে তারপর মুছুন
SPF আর DKIM pass, তবু dmarc=fail	smtp.mailfrom আর header.d ডোমেইন বনাম header.from	ESP-তে custom return-path আর custom DKIM ডোমেইন চালু করুন যাতে আপনার ডোমেইনে aligned হয়
DMARC p=reject চালুর পর নিজের কিছু মেইল হারিয়ে গেছে	rua রিপোর্টে কোন উৎস ফেল করছে	p=none বা quarantine-এ ফিরে গিয়ে সেই উৎস ঠিক করুন, তারপর আবার বাড়ান
DMARC রিপোর্ট আসছে না	rua ঠিকানা অন্য ডোমেইনে হলে সেখানে _report._dmarc অনুমতি রেকর্ড আছে কিনা	অনুমতি রেকর্ড বসান
নিজের সার্ভার থেকে পাঠানো মেইল প্রত্যাখ্যাত, PTR নিয়ে অভিযোগ	dig +short -x সেন্ডিং-IP আর ফলাফলের নামের dig +short A	প্রোভাইডারের প্যানেলে rDNS সেট করুন যাতে FCrDNS মেলে
মেইলিং লিস্টে পাঠানো মেইল রিসিভারে DMARC ফেল	dkim=fail (body hash), From: অপরিবর্তিত	লিস্ট সফটওয়্যারে From: rewrite বা ARC চালু; নিজের দিকে কিছু করার থাকে না
MTA-STS চালুর পর কিছু সেন্ডার মেইল দিতে পারছে না	TLS-RPT রিপোর্ট; policy ফাইলের mx: লাইন বনাম আসল MX; MX সার্ভারের সার্টিফিকেট	mode: testing-এ ফিরে গিয়ে MX তালিকা আর সার্টিফিকেট মেলান; policy বদলালে TXT-এর id বদলান
Gmail-এ সব মেইল স্প্যামে, অথচ তিনটাই pass	Postmaster Tools-এ স্প্যাম রেট ও ডোমেইন সুনাম	তালিকা পরিষ্কার, unsubscribe সহজ, পাঠানোর পরিমাণ ধীরে বাড়ান; এটা DNS-এর সমস্যা নয়

মূল শিক্ষা

1. MX বলে মেইল কোথায় নামবে। ছোট সংখ্যা আগে, টার্গেট হোস্টনেম (IP বা CNAME নয়), মেইল না নিলে null MX।
2. SPF বলে কোন IP আপনার নামে পাঠাতে পারবে, envelope sender-এর বিপরীতে। একটাই রেকর্ড, দশটা লুকআপের সীমা, আর নতুন সার্ভিস মানে include যোগ, নতুন রেকর্ড নয়।
3. DKIM মেইলের উপর সিগনেচার, পাবলিক কী selector._domainkey-এ। Selector দিয়ে একাধিক কী আর নিরাপদ রোটেশন।
4. DMARC দেখে SPF বা DKIM-এর অন্তত একটা From: ডোমেইনের সাথে aligned হয়ে পাস করল কিনা, আর না করলে কী হবে বলে দেয়। p=none আর রিপোর্ট দিয়ে শুরু, ধীরে ধীরে reject।
5. Gmail আর Yahoo এখন এগুলো চায়, বেশি পাঠালে তিনটাই। নিয়ম বদলায়, পাঠানোর আগে তাদের বর্তমান পাতা দেখুন।
6. সেন্ডিং IP-র PTR আর তার forward রেকর্ড মিলতে হবে (FCrDNS), আর PTR বসে IP-র মালিকের কাছে, আপনার zone-এ নয়।
7. MTA-STS আর TLS-RPT সার্ভার থেকে সার্ভারের পথে TLS বাধ্যতামূলক করে আর ব্যর্থতার খবর দেয়।
8. Authentication-Results হেডার রিসিভারের রায়। অনুমানের বদলে আগে ওটা পড়ুন: কোনটা ফেল, আর কোন ডোমেইনের জন্য।