خلاصه (TL;DR): SPF، DKIM و DMARC سه رکورد DNS هستند که هویت فرستندهٔ ایمیل را ثابت میکنند: SPF میگوید کدام سرورها اجازهٔ ارسال از دامنهٔ شما را دارند، DKIM هر پیام را امضای رمزنگاریشده میکند و DMARC تعیین میکند با پیامهای جعلی چه رفتاری شود. از سال ۲۰۲۴، گوگل و یاهو این رکوردها را برای فرستندهها الزامی کردهاند — اگر فاکتورها و خبرنامههای شما اسپم میشوند، به احتمال زیاد مشکل همینجاست. در این راهنما هر سه را به زبان ساده میفهمید و در ۵ قدم راهاندازی میکنید.
چرا ایمیلهای سالمِ کسبوکارها اسپم میشوند؟
پرتکرارترین تصور غلط این است که «اسپمشدن یعنی متن بدی نوشتهایم». واقعیت فنیتر است: سرویسهای ایمیل قبل از خواندن محتوا، هویت فرستنده را بررسی میکنند. ایمیل از دامنهٔ شما میآید؟ چه کسی این را تأیید میکند؟ اگر هیچ مدرکی نباشد، پیام شما از نگاه گیرنده با پیام یک جاعل که خودش را جای شما زده هیچ فرقی ندارد — و مقصد هر دو، پوشهٔ اسپم است.
احراز هویت ایمیل دقیقاً همین مدرک است: سه رکورد کوچک در DNS دامنه که با هم ثابت میکنند «این پیام واقعاً از طرف ماست». تنظیمشان یکبار برای همیشه است، اما اثرشان روی هر ایمیلی است که تا سالها میفرستید.
یک قیاس ساده: نامهٔ اداری بدون سربرگ، مهر و امضا را هیچ دبیرخانهای جدی نمیگیرد — هرچقدر هم متنش مهم باشد. SPF سربرگ است (این نامه از دفتر ما خارج شده)، DKIM مهر و امضاست (محتوا دستنخورده و مال ماست) و DMARC دستورالعمل دبیرخانه (با نامهٔ بیمهر چه کنید و به ما هم گزارش بدهید). دنیای ایمیل همین منطق را با DNS و رمزنگاری پیاده کرده است.
SPF چیست؟ فهرست سفید سرورهای مجاز
SPF (چارچوب سیاست فرستنده) یک رکورد TXT در DNS دامنهٔ شماست که اعلام میکند کدام سرورها حق دارند از طرف این دامنه ایمیل بفرستند. وقتی پیام شما به مقصد میرسد، سرور گیرنده IP فرستنده را با این فهرست تطبیق میدهد. یک رکورد نمونه چنین شکلی دارد:
v=spf1 include:_spf.bertina.ir -all
بخش include سرورهای سرویس ایمیل شما را مجاز میکند و -all میگوید «هر چیز دیگری مردود است». مهمترین قاعدهٔ SPF که بسیاری نمیدانند: هر دامنه فقط باید یک رکورد SPF داشته باشد — دو رکورد جدا یعنی شکست اعتبارسنجی در هر دو.
علامتهای انتهای رکورد هم معنا دارند: -all یعنی رد قاطع هر فرستندهٔ خارج از فهرست، و ~all (سافتفیل) یعنی «مشکوک تلقی کن ولی رد نکن» — گزینهٔ ملایمتری که در دورهٔ گذار به کار میآید. مشخصات کامل SPF در RFC 7208 آمده، اما برای استفادهٔ عملی همینقدر کافی است: یک رکورد، شامل همهٔ سرویسهای مشروع، با پایان سختگیرانه.
DKIM چیست؟ امضای رمزنگاریشدهٔ هر پیام
SPF مسیر را تأیید میکند، اما DKIM خودِ پیام را. سرویس ایمیل شما هر پیام خروجی را با یک کلید خصوصی امضا میکند و کلید عمومی متناظر در DNS دامنه منتشر میشود. سرور گیرنده امضا را با کلید عمومی میسنجد؛ اگر پیام در مسیر دستکاری شده باشد یا امضا نامعتبر باشد، اعتبارسنجی شکست میخورد.
مزیت DKIM این است که حتی وقتی ایمیل فوروارد میشود هم معمولاً سالم میماند — چون امضا به محتوای پیام چسبیده، نه به مسیر ارسال. در سرویسهای مدیریتشده مثل ایمیل سازمانی برتینا، جفت کلید و رکورد DKIM هنگام راهاندازی برای دامنهٔ شما ساخته و نگهداری میشود.
DMARC چیست؟ سیاست برخورد با جعل
فرض کنید SPF یا DKIM برای پیامی شکست خورد — حالا چه؟ DMARC پاسخ همین سوال است: رکوردی که به سرورهای گیرنده میگوید با پیامهای مردود چه کنند و گزارش ماجرا را کجا بفرستند. سه سیاست اصلی دارد:
p=none: فقط گزارش بده (نقطهٔ شروع امن برای پایش)p=quarantine: پیام مشکوک به اسپم برودp=reject: پیام جعلی کلاً پذیرفته نشود (مقصد نهایی شما)
DMARC علاوه بر حفاظت از گیرندهها، از برند خود شما محافظت میکند: بدون آن، هر کسی میتواند از آدرس دامنهٔ شما برای مشتریانتان ایمیل جعلی بفرستد. مشخصات کامل این استاندارد در RFC 7489 تعریف شده است.
جدول جمعبندی: سه رکورد در یک نگاه
| رکورد | چه چیزی را ثابت میکند | نوع رکورد DNS | اگر نباشد چه میشود |
|---|---|---|---|
| SPF | سرور فرستنده مجاز است | TXT روی ریشهٔ دامنه | هر سروری میتواند جای شما ارسال کند؛ امتیاز اسپم بالا میرود |
| DKIM | پیام دستنخورده و از طرف دامنه است | TXT روی سلکتور (مثل selector1._domainkey) | پیامها بدون امضا؛ در فوروارد و فیلترها آسیبپذیر |
| DMARC | سیاست برخورد با پیام مردود + گزارش | TXT روی _dmarc | جعل دامنهٔ شما بیهزینه میماند؛ الزامات فرستندهٔ انبوه را رد میکنید |
الزامات ۲۰۲۴ گوگل و یاهو: دیگر اختیاری نیست
از فوریهٔ ۲۰۲۴، گوگل و یاهو برای فرستندههای انبوه (بیش از ~۵٬۰۰۰ پیام در روز به Gmail) احراز هویت را الزامی کردهاند: SPF و DKIM هر دو، DMARC حداقل با p=none، امکان لغو اشتراک تککلیکی و نرخ گزارش اسپم زیر ۰٫۳٪. متن کامل این الزامات را در راهنمای رسمی فرستندگان گوگل ببینید.
حتی اگر حجم ارسال شما پایینتر است، همین استانداردها معیار امتیازدهیاند: فرستندهٔ احرازشده همیشه در صف بهتری قرار میگیرد. به زبان ساده، این رکوردها «حداقلِ ورود به بازی» شدهاند، نه امتیاز ویژه.
نکتهٔ ایرانی ماجرا: بخش بزرگی از مکاتبات B2B داخلی هم روی Gmail شخصیِ طرف مقابل فرود میآید — یعنی حتی برای مشتری ایرانی، داور نهایی همین قوانین گوگل است. رعایت این الزامات فقط «برای خارجیها» نیست؛ شرط رسیدن فاکتور شما به صندوق مدیر شرکتی در همین شهر است.
یک سناریوی واقعی: چرا فاکتورهای فروشگاه اسپم شد؟
الگویی که بارها در پشتیبانی دیدهایم: فروشگاهی سالها فاکتورها را از طریق اسکریپت سایتش میفرستاد و همهچیز خوب بود. یک روز مشتریها زنگ میزنند که «فاکتور نرسیده». چه شده؟ هیچ تغییری در سایت نه — تغییر سمت گیرندههاست: سختگیری سرویسهای ایمیل بالا رفته و ارسالهای احرازنشده که دیروز تحمل میشدند، امروز اسپم میشوند.
ریشهیابی همیشه همان سه سوال است: آیا IP سایت در SPF دامنه هست؟ (معمولاً نه — SPF فقط برای سرویس ایمیل تنظیم شده بود.) آیا ارسال سایت امضای DKIM دارد؟ (نه.) DMARC چه سیاستی دارد؟ (تنظیم نشده.) راهحل هم همانقدر مشخص است: یا ارسال سایت از طریق SMTP همان سرویس ایمیل انجام شود تا زیر چتر SPF/DKIM موجود برود، یا سرور سایت بهصورت صریح به رکوردها اضافه شود. بعد از این اصلاح، فاکتورها دوباره به صندوق ورودی برمیگردند — بدون تغییر حتی یک کلمه در متنشان.
راهاندازی عملی در ۵ قدم
- موجودی بگیرید: فهرست کنید از کجاها ایمیل میفرستید — سرویس ایمیل سازمانی، سایت (فرمها و فاکتورها)، ابزار خبرنامه. هر کدام باید در SPF و DKIM حساب شوند.
- SPF را تنظیم کنید: یک رکورد TXT واحد که سرویسهای مجازتان را include میکند. رکورد فعلی را قبل از تغییر ذخیره کنید.
- DKIM را فعال کنید: از پنل سرویس ایمیل، کلید بسازید و رکورد اعلامشده را در DNS دامنه (که از پنل مدیریت دامنه در دسترس است) قرار دهید.
- DMARC را با p=none شروع کنید: آدرس دریافت گزارش بگذارید و دو-سه هفته پایش کنید تا مطمئن شوید ارسالکنندههای مشروع همگی پاس میشوند.
- سیاست را سفت کنید: بعد از پاکشدن گزارشها، به quarantine و سپس reject ارتقا دهید — حالا دامنهٔ شما عملاً غیرقابل جعل است.
اگر سرویس ایمیلتان مدیریتشده باشد، قدمهای ۲ تا ۴ را پشتیبانی برایتان انجام میدهد؛ در سرویس اسمارترمیل برتینا این پیکربندی بخشی از راهاندازی استاندارد است.
BIMI: جایزهٔ بعد از DMARC سختگیرانه
وقتی DMARC شما به p=quarantine یا p=reject رسید، یک قدم اختیاری اما خوشبرند باقی میماند: BIMI — استانداردی که به سرویسهای پشتیبان (از جمله Gmail و Yahoo) میگوید لوگوی رسمی برند شما را کنار ایمیلهایتان در صندوق گیرنده نمایش دهند. پیشنیازش دقیقاً همین زنجیره است: احراز هویت کامل + سیاست سختگیرانهٔ DMARC + فایل لوگوی استاندارد (و در برخی سرویسها گواهی VMC).
برای اغلب کسبوکارها BIMI اولویت نیست، اما دانستنش انگیزهٔ خوبی است: مسیر درست احراز هویت، در انتها به دیدهشدن برند شما در صندوق مشتری هم ختم میشود — همان جایی که رقبا فقط یک حرف اول بیروح دارند.
اشتباهات رایج که همهچیز را خراب میکنند
- دو رکورد SPF جدا: رایجترین خطا؛ استاندارد فقط یک رکورد را میپذیرد — سرویس جدید را باید داخل همان رکورد include کنید، نه در رکوردی تازه.
- استفاده از +all یا ?all: یعنی «همه مجازند» — کل SPF را بیاثر میکند.
- عبور از سقف ۱۰ جستوجوی DNS در SPF: با includeهای تو در توی زیاد، اعتبارسنجی خطای permerror میگیرد؛ includeهای بلااستفاده را حذف کنید.
- پرش مستقیم به p=reject: بدون دورهٔ پایش، ایمیلهای مشروعِ فراموششده (مثل فاکتورهای سایت) هم دور ریخته میشوند.
- فراموشکردن سابدامینها: سیاست DMARC سابدامینها را هم پوشش میدهد (sp=)؛ اگر از سابدامین ارسال دارید، جداگانه حسابش کنید.
چطور مطمئن شویم درست تنظیم شده؟
سادهترین آزمون: یک ایمیل به Gmail خودتان بفرستید، پیام را باز کنید و «Show original» را بزنید — سه خط بالای صفحه باید بگوید SPF: PASS، DKIM: PASS و DMARC: PASS. برای بررسی رکوردها هم ابزارهای عمومی تست DNS کافیاند. اگر هر کدام FAIL بود، بهترتیبِ همین راهنما برگردید: اول SPF، بعد DKIM، آخر DMARC.
این آزمون را بعد از هر تغییر زیرساختی تکرار کنید: عوضکردن سرویس ایمیل، اضافهشدن ابزار خبرنامه، یا جابهجایی هاست سایت. پنج دقیقه بررسی، جلوی هفتهها مکاتبهٔ گمشده را میگیرد — و اگر سرویس ایمیل و دامنه یکجا مدیریت شوند، همین بررسی هم بخشی از پشتیبانی استاندارد است.
پیشنیاز همهٔ اینها داشتن ایمیل روی دامنهٔ اختصاصی است؛ اگر هنوز با آدرس رایگان کار میکنید، اول تفاوت ایمیل سازمانی با Gmail را بخوانید و برای انتخاب پروتکل دریافت هم راهنمای مقایسهٔ IMAP، POP3 و Exchange را ببینید.
این رکوردها با انتخاب سرویس ایمیل چه ربطی دارد؟
تفاوت واقعی سرویسهای ایمیل، در همین لایهٔ نامرئی معلوم میشود. در سرویسهای مدیریتشده، رکوردها هنگام راهاندازی درست تنظیم میشوند، کلیدهای DKIM نگهداری و در صورت نیاز چرخانده میشوند و وقتی گزارش DMARC چیز عجیبی نشان داد، کسی هست که بفهمد یعنی چه. در راهکارهای دستساز، همهٔ اینها وظیفهٔ شماست — و معمولاً اولین قربانیِ مشغلهاند.
هنگام مقایسهٔ سرویسها این سه سوال را بپرسید: SPF/DKIM را خودتان تنظیم میکنید یا من باید درگیر شوم؟ اعتبار ارسال (Deliverability) دامنهٔ من را چه کسی پایش میکند؟ و اگر ایمیلهایم اسپم شد، پشتیبانی تا کجا همراهی میکند؟ پاسخ این سه سوال، ارزش واقعی هر پلن را شفافتر از فهرست امکاناتش نشان میدهد.
سوالات متداول
آیا در سرویس ایمیل برتینا باید این رکوردها را خودم تنظیم کنم؟
خیر؛ SPF و DKIM هنگام راهاندازی سرویس برای دامنهٔ شما پیکربندی میشود و پشتیبانی ۲۴ ساعته در تنظیم DMARC و خواندن گزارشهای آن همراه شماست.
برای ارسال کم (چند ایمیل در روز) هم لازم است؟
بله؛ الزامِ سختگیرانه برای فرستندههای انبوه است، اما امتیازدهی برای همه اعمال میشود. تنظیم یکباره است و هر ایمیلِ بعدی از آن سود میبرد.
آیا این رکوردها اسپمشدن را صددرصد حل میکنند؟
احراز هویت شرط لازم است نه کافی: محتوا، کیفیت فهرست گیرندگان و نرخ گزارش اسپم هم امتیاز میسازند. اما بدون این رکوردها، بقیهٔ تلاشها دیده نمیشود.
گزارشهای DMARC را چطور بخوانم؟
گزارشها XML هستند و روزانه از سرویسهای گیرنده میرسند؛ خلاصهشان میگوید چه IPهایی از طرف دامنهٔ شما ارسال کردهاند و نتیجهٔ اعتبارسنجی چه بوده. برای شروع، همین که فرستندههای مشروعتان PASS باشند کافی است؛ ابزارهای تجمیع گزارش هم برای حجم بالا وجود دارد.
SPF و DKIM را دارم؛ DMARC واجب است؟
بله؛ بدون DMARC، گیرنده نمیداند با پیامهای مردود چه کند و جعل دامنهٔ شما همچنان ممکن است. الزامات ۲۰۲۴ هم حداقل p=none را میخواهد — و مسیر درست، رسیدن تدریجی به reject است.
