অনলাইন স্টোরে SPF, DKIM ও DMARC সেটআপ: Gmail ও Yahoo-র নিয়ম

Gmail ও Yahoo-র সেন্ডার নিয়ম মানতে প্রতিটি অনলাইন স্টোরের পাঠানোর ডোমেইনে SPF অথবা DKIM থাকা দরকার। বাল্ক সেন্ডারদের দুটোই লাগবে, সঙ্গে অন্তত p=none নীতির একটি DMARC রেকর্ড, যেখানে দৃশ্যমান From ডোমেইনটি SPF বা DKIM-এর সঙ্গে অ্যালাইনড (মিলে যাওয়া) থাকবে। বাল্ক সেন্ডারদের মার্কেটিং ইমেইলে ওয়ান-ক্লিক আনসাবস্ক্রাইবের ব্যবস্থাও রাখতে হবে এবং রিপোর্ট হওয়া স্প্যাম রেট 0.3%-এর নিচে রাখতে হবে। Shopify-তে এর মানে অ্যাডমিন থেকে আপনার সেন্ডার ডোমেইন অথেনটিকেট করা এবং একটি DMARC রেকর্ড যোগ করা; WooCommerce-এ এর মানে একটি অথেনটিকেটেড ইমেইল প্রোভাইডারের মাধ্যমে মেইল পাঠানো। DMARC রিপোর্টে যখন দেখা যাবে আপনার সব বৈধ মেইল পাস করছে, তখন নীতিটি ধাপে ধাপে p=reject-এর দিকে নিতে পারবেন।

মূল বিষয়গুলো

• 1 ফেব্রুয়ারি 2024 থেকে Gmail সব প্রেরকের জন্য SPF অথবা DKIM এবং বাল্ক সেন্ডারদের জন্য SPF, DKIM ও DMARC বাধ্যতামূলক করেছে (Google (নতুন ট্যাবে খোলে))।
• 24 ঘণ্টায় ব্যক্তিগত Gmail অ্যাকাউন্টে প্রায় 5,000 বার্তা পাঠালেই Gmail আপনাকে বাল্ক সেন্ডার হিসেবে গণ্য করে, এবং এই মর্যাদার কোনো মেয়াদ শেষ হয় না (Gmail FAQ (নতুন ট্যাবে খোলে))।
• নভেম্বর 2025 থেকে Gmail নিয়ম না মানা ট্রাফিকের ওপর প্রয়োগ জোরদার করেছে, যার মধ্যে অস্থায়ী ও স্থায়ী প্রত্যাখ্যানও আছে (Gmail FAQ (নতুন ট্যাবে খোলে))।
• 5 মে 2025 থেকে Outlook.com দিনে 5,000-এর বেশি ইমেইল পাঠানো ডোমেইনের কাছে SPF, DKIM ও DMARC চায় (Microsoft (নতুন ট্যাবে খোলে))।
• প্রতিটি SPF চেকে DNS কোয়েরি লাগে এমন সর্বোচ্চ 10টি টার্ম থাকতে পারে; এর বেশি হলে ফল আসে permerror (RFC 7208 (নতুন ট্যাবে খোলে))।
• মে 2026-এ DMARC হালনাগাদ হয়েছে: RFC 9989 (নতুন ট্যাবে খোলে) RFC 7489-কে বাতিল (obsolete) করেছে এবং pct ট্যাগের জায়গায় t এনেছে।

SPF, DKIM ও DMARC আসলে কী করে?

SPF জানায় কারা আপনার ডোমেইনের হয়ে মেইল পাঠাতে পারবে, DKIM প্রতিটি বার্তায় ডিজিটাল স্বাক্ষর যোগ করে, আর DMARC এই দুটিকে আপনার গ্রাহকদের চোখে পড়া From ঠিকানার সঙ্গে যুক্ত করে।

অ্যালাইনমেন্টের বিষয়টি সহজেই চোখ এড়িয়ে যায়। আপনার ইমেইল প্ল্যাটফর্ম তার নিজের বাউন্স ডোমেইনের জন্য SPF পাস করতে পারে, অথচ From ঠিকানায় দেখা যায় আপনার স্টোরের ডোমেইন। এমন বার্তা SPF পাস করে, কিন্তু DKIM আপনার ডোমেইন দিয়ে স্বাক্ষরিত না হলে DMARC-এ ব্যর্থ হয়।

Gmail ও Yahoo প্রেরকদের কাছে কী চায়?

দুটিই প্রত্যেক প্রেরকের কাছে অথেনটিকেশন চায় এবং বাল্ক সেন্ডারদের জন্য আরও কঠোর নিয়ম যোগ করে।

সব প্রেরকের জন্য Gmail চায় SPF অথবা DKIM, বৈধ ফরওয়ার্ড ও রিভার্স DNS, TLS, RFC 5322 অনুযায়ী ফরম্যাটিং এবং Postmaster Tools-এ 0.3%-এর নিচে স্প্যাম রেট (Google (নতুন ট্যাবে খোলে))। Yahoo চায় অন্তত SPF অথবা DKIM এবং 0.3%-এর নিচে স্প্যাম রেট (Yahoo Sender Hub (নতুন ট্যাবে খোলে))। বাল্ক সেন্ডারদের জন্য:

স্টোরের জন্য কয়েকটি খুঁটিনাটি গুরুত্বপূর্ণ:

• Gmail ডোমেইন ধরে গণনা করে। একই প্রাইমারি ডোমেইন থেকে পাঠানো সব বার্তা 5,000-এর সীমায় যোগ হয়, তাই অর্ডার ইমেইল, মার্কেটিং আর সাপোর্টের উত্তর সব মিলিয়ে গণনা হয়।
• শুধু ব্যক্তিগত Gmail অ্যাকাউন্ট গণনায় আসে। Google Workspace অ্যাকাউন্টে পাঠানো বার্তায় এই নির্দেশিকা প্রযোজ্য নয়।
• ট্রানজ্যাকশনাল মেইলে ওয়ান-ক্লিক আনসাবস্ক্রাইব লাগে না। তবে অর্ডার কনফার্মেশনেও অথেনটিকেশন লাগবে।

ওয়ান-ক্লিক আনসাবস্ক্রাইব RFC 8058 (নতুন ট্যাবে খোলে)-এ সংজ্ঞায়িত দুটি হেডার ব্যবহার করে, এবং এই RFC অনুযায়ী হেডার দুটিকে একটি বৈধ DKIM স্বাক্ষরের আওতায় থাকতে হয়:

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

আপনার মার্কেটিং প্ল্যাটফর্ম এগুলো যোগ করছে কি না নিশ্চিত হতে, আপনার নিজের কোনো ক্যাম্পেইনের মূল সোর্স (raw source) খুলে দেখুন।

ফেব্রুয়ারি 2024-এর পর কী বদলেছে?

প্রয়োগ ধাপে ধাপে কঠোর হয়েছে, আর অন্যান্য মেইলবক্স প্রোভাইডারও একই ধরনের নিয়ম গ্রহণ করেছে।

Outlook.com-এর নিয়ম তার কনজিউমার ঠিকানাগুলোর (outlook.com, hotmail.com ও live.com) ক্ষেত্রে প্রযোজ্য। এতে SPF ও DKIM পাস করতে হয় এবং SPF বা DKIM-এর সঙ্গে অ্যালাইনড অন্তত p=none-এর DMARC থাকতে হয়।

Shopify-তে SPF, DKIM ও DMARC কীভাবে সেটআপ করবেন?

Shopify অ্যাডমিনে আপনার সেন্ডার ডোমেইন অথেনটিকেট করুন, তারপর আপনার DNS হোস্টে একটি DMARC রেকর্ড যোগ করুন।

Shopify-এর ইমেইল সেটআপ গাইড (নতুন ট্যাবে খোলে) অনুযায়ী, 1 ফেব্রুয়ারি 2024 থেকে ব্র্যান্ডেড ঠিকানা থেকে মেইল পাঠাতে Gmail ও Yahoo একটি অথেনটিকেটেড ডোমেইন এবং একটি DMARC রেকর্ড চায়। অথেনটিকেশন রেকর্ড কনফিগার করা না থাকলে Shopify আপনার সেন্ডার ঠিকানাকে store+123@shopifyemail.com ফরম্যাটে বদলে দেয়। ধাপগুলো:

1. Shopify অ্যাডমিনে Settings > Notifications-এ যান।
2. Sender email অংশে authenticate your domain-এ ক্লিক করুন।
3. দেখানো প্রতিটি CNAME রেকর্ড আপনার DNS প্রোভাইডারে যোগ করুন। রেকর্ডের সংখ্যা কমবেশি হতে পারে। Shopify জানায়, এই রেকর্ডগুলো আপনার সেন্ডার ঠিকানার SPF ও DKIM সামলায় এবং আপনাকে কোনো IP ঠিকানা যোগ করতে হবে না।
4. DNS পরিবর্তন কার্যকর হতে 48 ঘণ্টা পর্যন্ত সময় দিন।
5. _dmarc নামে এবং v=DMARC1; p=none; মান দিয়ে একটি TXT রেকর্ড যোগ করুন; Shopify এটিকেই ডিফল্ট হিসেবে ব্যবহার করে।

আপনি যদি Shopify থেকে ডোমেইন কিনে থাকেন বা সেখানে ট্রান্সফার করে থাকেন, তাহলে Shopify এই রেকর্ডগুলো আপনার হয়ে পরিচালনা করে। Shopify আরও সতর্ক করে যে একটি ডোমেইনে কেবল একটি DMARC রেকর্ড থাকতে পারে, এবং কঠোর অ্যালাইনমেন্ট সেটিং (adkim=s বা aspf=s) সরিয়ে ফেলা বা r-এ বদলে দেওয়া উচিত।

Shopify-এর অথেনটিকেশন কেবল Shopify যে মেইল পাঠায় সেগুলোর জন্য। ক্যাম্পেইনের জন্য অন্য কোনো প্ল্যাটফর্ম, হেল্প ডেস্ক, বা কর্মীদের মেইলের জন্য Google Workspace ব্যবহার করলে প্রত্যেকটির নিজস্ব DKIM সেটআপ লাগবে, আর যেটি বাউন্সের জন্য আপনার ডোমেইন ব্যবহার করে সেটির নিজস্ব SPF এন্ট্রিও লাগবে।

WooCommerce-এর জন্য ইমেইল অথেনটিকেশন কীভাবে সেটআপ করবেন?

WooCommerce-এর নিজের ডকুমেন্টেশনের সুপারিশ অনুযায়ী, WooCommerce-এর ইমেইল এমন একটি ডেডিকেটেড প্রোভাইডারের মাধ্যমে পাঠান যা আপনার ডোমেইন দিয়ে স্বাক্ষর করে।

WooCommerce মেইল পাঠায় WordPress-এর wp_mail() ফাংশন দিয়ে, এবং এর ইমেইল FAQ (নতুন ট্যাবে খোলে) আপনার নিজের সার্ভারের মেইল ফাংশনের চেয়ে একটি ডেডিকেটেড SMTP প্রোভাইডারকে বেশি নির্ভরযোগ্য বলে সুপারিশ করে। একটি সাধারণ সেটআপ:

1. একটি ট্রানজ্যাকশনাল ইমেইল প্রোভাইডার বেছে নিন এবং সেখানে আপনার ডোমেইন ভেরিফাই করুন। প্রোভাইডার আপনাকে প্রকাশ করার জন্য DKIM রেকর্ড এবং SPF include দেবে।
2. একটি SMTP বা API প্লাগইন দিয়ে WordPress-কে সেই প্রোভাইডারের সঙ্গে যুক্ত করুন।
3. WooCommerce > Settings > Emails-এ From address হিসেবে আপনার নিজের ডোমেইনের একটি ঠিকানা দিন। WooCommerce সতর্ক করে যে Gmail বা Yahoo-র মতো পাবলিক ঠিকানা স্প্যামে যাওয়ার বা ব্লক হওয়ার সম্ভাবনা বেশি।
4. _dmarc.yourdomain-এ একটি DMARC রেকর্ড প্রকাশ করুন।
5. কোন বার্তা পাঠানো হয়েছে বা ব্যর্থ হয়েছে তা দেখতে WooCommerce > Status > Logs খুলে transactional-emails সোর্স দিয়ে ফিল্টার করুন।

আপনার ওয়েব হোস্টও যদি ডোমেইনের হয়ে মেইল পাঠায়, তাহলে সেটিকে অথেনটিকেট করুন অথবা বন্ধ করে দিন। অ্যালাইনড SPF বা DKIM ছাড়া আপনার ডোমেইনের নামে মেইল পাঠানো যেকোনো সিস্টেম DMARC-এ ব্যর্থ হবে।

SPF-এর 10-লুকআপ সীমা কী, এবং কীভাবে এর নিচে থাকবেন?

একটি SPF চেকে DNS কোয়েরি লাগে এমন সর্বোচ্চ 10টি টার্ম ব্যবহার করা যায়; একটি বেশি হলেই ফল আসে permerror, অর্থাৎ SPF পাস করে না।

RFC 7208, সেকশন 4.6.4 (নতুন ট্যাবে খোলে)-এ গণনায় আসা টার্মগুলোর তালিকা আছে: include, a, mx, ptr ও exists মেকানিজম এবং redirect মডিফায়ার। ip4, ip6 ও all মেকানিজম গণনায় আসে না। আপনার include-এর ভেতরে থাকা নেস্টেড include-ও গণনায় আসে, কারণ সীমাটি পুরো মূল্যায়নের ওপর প্রযোজ্য। RFC আরও সুপারিশ করে যে “void lookup” (যে কোয়েরির কোনো উত্তর আসে না) দুটিতে সীমিত রাখা উচিত, এবং ptr মেকানিজম প্রকাশ না করাই উচিত।

10-এর নিচে থাকার উপায়:

• যেসব সার্ভিস আর ব্যবহার করেন না, সেগুলোর include সরিয়ে ফেলুন।
• নির্দিষ্ট ঠিকানায় চলা নিজের সার্ভারের জন্য ip4 বা ip6 ব্যবহার করুন।
• মার্কেটিং মেইল news.example.com-এর মতো একটি সাবডোমেইনে সরিয়ে নিন, যার নিজস্ব SPF রেকর্ড এবং নিজস্ব গণনা আছে।
• কখনো দুটি SPF রেকর্ড প্রকাশ করবেন না। RFC 7208 একাধিক রেকর্ড নিষিদ্ধ করে, এবং সে ক্ষেত্রে মূল্যায়নের ফল হয় permerror।

example.com.        TXT  "v=spf1 include:_spf.google.com include:spf.example-esp.com ~all"
news.example.com.   TXT  "v=spf1 include:spf.example-marketing.com ~all"

spf.example-esp.com ও spf.example-marketing.com এখানে কেবল উদাহরণ; এদের জায়গায় আপনার প্রোভাইডার যা ব্যবহার করতে বলে তা বসান।

DMARC কীভাবে p=none থেকে p=reject-এ নেবেন?

রিপোর্টিংসহ p=none দিয়ে শুরু করুন, রিপোর্টে যত বৈধ সোর্স ধরা পড়ে সবগুলো ঠিক করুন, তারপর নীতি কঠোর করুন।

পরের ধাপে যান কেবল তখনই, যখন রিপোর্টে দেখা যায় আপনার স্টোর প্ল্যাটফর্ম, মার্কেটিং টুল, হেল্প ডেস্ক ও কর্মীদের মেইল সবই পাস করছে। অ্যাগ্রিগেট রিপোর্ট RFC 9990 (নতুন ট্যাবে খোলে)-এ সংজ্ঞায়িত। rua ঠিকানাটি যদি অন্য কোনো ডোমেইনে থাকে, যেমন কোনো রিপোর্টিং সার্ভিসে, তাহলে সেই ডোমেইনকে রিপোর্ট গ্রহণের অনুমোদন জানিয়ে একটি রেকর্ড প্রকাশ করতে হবে।

পুরোনো গাইডগুলোতে pct=25 বা pct=50 দিয়ে ধাপে ধাপে চালুর পরামর্শ থাকে। RFC 9989 pct বাদ দিয়েছে (এর রেজিস্ট্রি এন্ট্রি এখন “historic”), কারণ 0 ও 100 ছাড়া অন্য মানগুলো অসামঞ্জস্যভাবে প্রয়োগ করা হতো। এর জায়গায় t=y রিসিভারদের এক ধাপ নিচের নীতি প্রয়োগ করতে বলে, যেমন reject-এর বদলে quarantine। পরীক্ষামূলক একটি ধাপ চাইলে আংশিক শতাংশের বদলে t=y ব্যবহার করুন।

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

প্রয়োগকৃত (enforced) নীতি BIMI-র পথও খুলে দেয়, যা সমর্থিত ইনবক্সে আপনার লোগো দেখায়। এর জন্য Gmail চায় p=quarantine বা p=reject পর্যায়ের DMARC এবং একটি Verified Mark Certificate বা Common Mark Certificate (Google (নতুন ট্যাবে খোলে))। আপনার ডোমেইনে আসা মেইলের জন্য MTA-STS (RFC 8461 (নতুন ট্যাবে খোলে)) দিয়ে আপনি পাঠানো সার্ভারগুলোকে জানিয়ে দিতে পারেন যে আপনার মেইল সার্ভার বিশ্বস্ত সার্টিফিকেটসহ TLS না দিলে তারা যেন ডেলিভারি না করে।

আপনার স্টোরের রেকর্ড কীভাবে যাচাই করবেন?

dig দিয়ে তিন ধরনের রেকর্ড কোয়েরি করুন, অথবা এমন একটি চেকার ব্যবহার করুন যা আপনার হয়ে সেগুলো পড়ে দেয়।

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.com

DKIM সিলেক্টর আসে আপনার প্রোভাইডারের কাছ থেকে; আপনার পাঠানো কোনো বার্তার DKIM-Signature হেডারের s= মানে এটি পাবেন। ইমেইল ডেলিভারেবিলিটি রিপোর্ট আপনার পাবলিক DNS পড়ে, SPF লুকআপ গণনা করে, প্রচলিত DKIM সিলেক্টরগুলো চেষ্টা করে এবং DMARC নীতি, rua, pct, BIMI ও MTA-STS যাচাই করে। সঠিক রেকর্ড সাহায্য করে, তবে কোনো রেকর্ড সেটই ইনবক্সে পৌঁছানোর নিশ্চয়তা দেয় না, কারণ মেইলবক্স প্রোভাইডাররা স্প্যাম অভিযোগ ও পাঠানোর ধরনও বিবেচনা করে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

আমার স্টোর দিনে 5,000-এর কম ইমেইল পাঠালেও কি DMARC লাগবে?

Gmail কেবল বাল্ক সেন্ডারদের কাছ থেকে DMARC চায়, তবে Shopify উল্লেখ করে যে ব্র্যান্ডেড ঠিকানা থেকে মেইল পাঠাতে Gmail ও Yahoo একটি অথেনটিকেটেড ডোমেইন এবং একটি DMARC রেকর্ড চায়। p=none রেকর্ডে ঝুঁকি কম এবং এটি আপনাকে রিপোর্ট এনে দেয়, তাই বেশিরভাগ স্টোরেরই একটি DMARC রেকর্ড প্রকাশ করা উচিত।

আমার ডোমেইনে কি দুটি SPF রেকর্ড থাকতে পারে?

না। RFC 7208 অনুযায়ী একটি ডোমেইনে একাধিক SPF রেকর্ড থাকা চলবে না, আর থাকলে SPF মূল্যায়নের ফল হয় permerror। সব প্রেরককে একটি রেকর্ডে একত্র করুন।

p=reject কি আমার Shopify অর্ডার ইমেইল আটকে দেবে?

না, যদি Shopify-এর CNAME রেকর্ডগুলো যুক্ত থাকে এবং আপনার DMARC রিপোর্টে দেখা যায় Shopify-এর মেইল অ্যালাইনড DKIM-এ পাস করছে। p=none থেকে এগোনোর আগে রিপোর্ট দেখে নিন, এবং Shopify-এর সুপারিশ অনুযায়ী অ্যালাইনমেন্ট রিল্যাক্সড রাখুন।

DMARC-এর pct ট্যাগ কি এখনও বৈধ?

মে 2026-এ প্রকাশিত RFC 9989 pct বাদ দিয়েছে এবং টেস্ট মোডের জন্য t=y চালু করেছে। Google-এর BIMI নির্দেশিকা এখনও pct=100 চায়, যা ট্যাগ না থাকলে ডিফল্ট মান, তাই নতুন রেকর্ডে pct না রাখাই সবচেয়ে সহজ পথ।

SPF, DKIM ও DMARC পাস করলে কি আমার ইমেইল ইনবক্সে পৌঁছানোর নিশ্চয়তা আছে?

না। অথেনটিকেশন একটি শর্ত, নিশ্চয়তা নয়। Gmail ও Yahoo স্প্যাম অভিযোগের হার, আনসাবস্ক্রাইব ব্যবস্থাপনা এবং বার্তার ফরম্যাটিংও দেখে।

তথ্যসূত্র

• Email sender guidelines (নতুন ট্যাবে খোলে), Google, দেখা হয়েছে 22 অক্টোবর 2026
• Email sender guidelines FAQ (নতুন ট্যাবে খোলে), Google, দেখা হয়েছে 22 অক্টোবর 2026
• Sender best practices (নতুন ট্যাবে খোলে), Yahoo Sender Hub, দেখা হয়েছে 22 অক্টোবর 2026
• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (নতুন ট্যাবে খোলে), Microsoft Tech Community, 2 এপ্রিল 2025, হালনাগাদ 29 এপ্রিল 2025
• Setting up your email (নতুন ট্যাবে খোলে), Shopify Help Center, দেখা হয়েছে 22 অক্টোবর 2026
• Email FAQ (নতুন ট্যাবে খোলে), WooCommerce ডকুমেন্টেশন, দেখা হয়েছে 22 অক্টোবর 2026
• RFC 7208: Sender Policy Framework (SPF) (নতুন ট্যাবে খোলে), IETF, এপ্রিল 2014
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (নতুন ট্যাবে খোলে), IETF, সেপ্টেম্বর 2011
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (নতুন ট্যাবে খোলে), IETF, মার্চ 2015 (RFC 9989 দ্বারা বাতিল)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (নতুন ট্যাবে খোলে), IETF, মে 2026
• RFC 9990: DMARC Aggregate Reporting (নতুন ট্যাবে খোলে), IETF, মে 2026
• RFC 8058: Signaling One-Click Functionality for List Email Headers (নতুন ট্যাবে খোলে), IETF, জানুয়ারি 2017
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (নতুন ট্যাবে খোলে), IETF, সেপ্টেম্বর 2018
• Set up BIMI (নতুন ট্যাবে খোলে), Google Workspace Admin Help, দেখা হয়েছে 22 অক্টোবর 2026