ایمیلهایتان به پوشهٔ اسپم مشتریان میرود؟ SPF، DKIM و DMARC را به زبان ساده و با نمونه رکوردهای DNS توضیح میدهیم و به سیاستهای DMARC، استقرار گامبهگام، اشتباهات رایج و قوانین ارسال ارائهدهندگان بزرگ ایمیل میپردازیم.
پیشفاکتوری میفرستید و مشتری میگوید «ایمیلتان هرگز نرسید». بعداً آن را در پوشهٔ اسپم پیدا میکند. در بیشتر موارد مشکل از محتوای پیام نیست، بلکه از تنظیمات احراز هویت دامنهٔ شماست. وقتی سرور گیرنده نتواند مطمئن شود که ایمیل واقعاً از طرف شما آمده، با آن بهعنوان پیامی مشکوک برخورد میکند.
در این مقاله سه رکن اصلی احراز هویت ایمیل، یعنی SPF، DKIM و DMARC را بدون اصطلاحات پیچیده توضیح میدهیم. خواهید آموخت که هر کدام چه کاری انجام میدهد، رکورد DNS آن چه شکلی دارد و چگونه آنها را گامبهگام مستقر کنید.
چرا ایمیلها به اسپم میروند؟
پروتکل ایمیل دهها سال پیش و بدون هیچ راهی برای تأیید فرستنده طراحی شد. به همین دلیل هر کسی میتواند به نام هر نشانیای ایمیل بفرستد. کلاهبرداران از این موضوع سوءاستفاده میکنند تا پیامهای جعلی بفرستند که به نظر میرسد از دامنهٔ شما آمدهاند.
برای مقابله با این مشکل، ارائهدهندگان بزرگی مانند Gmail، Outlook و Yahoo هر پیام ورودی را بررسی میکنند: آیا این سرور اجازهٔ ارسال برای این دامنه را دارد؟ آیا پیام در مسیر تغییر کرده است؟ صاحب دامنه میخواهد با پیامهایی که در این بررسیها رد میشوند چه شود؟ پاسخ این سه پرسش، SPF، DKIM و DMARC است.
احراز هویت تنها عامل نیست. اعتبار IP فرستنده، فهرستهای سیاه، محتوا و میزان علامتگذاری پیامهایتان بهعنوان اسپم توسط گیرندگان نیز نقش دارند. اما بدون SPF، DKIM و DMARC درست، تحویلپذیری ایمیل حتی اگر همه چیز دیگر درست باشد ضعیف میماند.
SPF: چه کسی میتواند از طرف من ایمیل بفرستد؟
SPF (Sender Policy Framework) فهرستی از سرورهایی است که اجازهٔ ارسال ایمیل برای دامنهٔ شما را دارند. این فهرست بهصورت رکورد TXT در DNS دامنهٔ شما منتشر میشود. سرور گیرنده بررسی میکند که آیا سرور فرستندهٔ پیام در این فهرست هست یا نه.
نمونهای از رکورد SPF اینگونه است:
companyname.com TXT "v=spf1 mx include:spf.provider.com ip4:203.0.113.10 ~all"
- v=spf1: نشان میدهد که این یک رکورد SPF است.
- mx: سرورهای MX دامنه مجاز به ارسال هستند.
- include: فهرست ارائهدهندهٔ دیگری را اضافه میکند؛ برای مثال سرویس ایمیل یا خبرنامهٔ شما.
- ip4: یک نشانی IP مشخص را مجاز میکند؛ مانند یک سرور اپلیکیشن در دفتر شما.
- ~all: یعنی «هر چیزی را که در فهرست نیست مشکوک در نظر بگیر». -all یعنی «رد کن».
DKIM: آیا این پیام در مسیر تغییر کرده است؟
DKIM (DomainKeys Identified Mail) به هر پیامی که میفرستید یک امضای دیجیتال اضافه میکند. این امضا با یک کلید خصوصی که روی سرور ایمیل شما نگهداری میشود ساخته میشود. کلید عمومی متناظر در DNS منتشر میشود. سرور گیرنده امضا را با کلید عمومی تأیید میکند و میفهمد که پیام واقعاً از سرور شما آمده و در مسیر تغییر نکرده است.
نمونهای از رکورد DKIM:
mail2026._domainkey.companyname.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...long-public-key..."
- mail2026: انتخابگر (selector). امکان استفاده از بیش از یک کلید برای یک دامنه را فراهم میکند.
- k=rsa: نوع کلید.
- p=: خود کلید عمومی. ارائهدهندهٔ ایمیل شما این مقدار را تولید میکند؛ شما فقط آن را به DNS اضافه میکنید.
DKIM یکی از ضعفهای SPF را نیز برطرف میکند: وقتی پیامی از یک فورواردکننده عبور میکند، سرور فرستنده تغییر میکند و ممکن است بررسی SPF رد شود، اما امضای DKIM همراه پیام میرود و معتبر میماند.
DMARC: وقتی بررسیها رد میشوند چه اتفاقی میافتد؟
DMARC (Domain-based Message Authentication, Reporting and Conformance) لایهٔ سیاستی است که SPF و DKIM را به هم پیوند میدهد. دو کار انجام میدهد:
- به سرورهای گیرنده میگوید با پیامهایی که احراز هویت نمیشوند چه کنند.
- گزارشهایی برایتان میفرستد که نشان میدهد چه کسانی به نام دامنهٔ شما ایمیل میفرستند.
DMARC همچنین همترازی (alignment) را بررسی میکند: دامنهای که SPF یا DKIM تأیید کرده باید با دامنهٔ نشانی «From» که گیرنده میبیند یکسان باشد. به این ترتیب هیچکس نمیتواند با دامنهای دیگر از SPF عبور کند و همچنان خود را به جای نشانی شما جا بزند.
نمونهای از رکورد DMARC:
_dmarc.companyname.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@companyname.com"
سیاستهای DMARC
- p=none: فقط پایش. با پیامهای ردشده کاری انجام نمیشود، اما گزارشها میرسند. این نقطهٔ شروع است.
- p=quarantine: پیامهای ردشده به پوشهٔ اسپم میروند.
- p=reject: پیامهای ردشده کاملاً پذیرفته نمیشوند. این قویترین حفاظت در برابر جعل دامنهٔ شماست.
استقرار گامبهگام
- فهرستبرداری کنید. هر چیزی را که به نام دامنهٔ شما ایمیل میفرستد فهرست کنید: ایمیل سازمانی، نرمافزار فاکتور الکترونیکی، CRM، سرویس خبرنامه، فرمهای وبسایت، چاپگرها و اسکنرها.
- یک رکورد SPF واحد بسازید. همهٔ این منابع را در یک رکورد جمع کنید و با ~all شروع کنید.
- DKIM را فعال کنید. کلیدهای DKIM را از ارائهدهندهٔ ایمیل و سایر سرویسهای ارسال دریافت و به DNS اضافه کنید.
- DMARC را در حالت پایش منتشر کنید. با p=none شروع کنید و یک نشانی برای دریافت گزارش تعیین کنید.
- گزارشها را چند هفته بررسی کنید. منابع ارسالی که فراموش کرده بودید در این گزارشها ظاهر میشوند. آنها را به SPF و DKIM اضافه کنید.
- سیاست را بهتدریج سختگیرانهتر کنید. وقتی همهٔ ایمیلهای مشروع از بررسی عبور کردند، به quarantine و بعد به reject بروید. برای نرمتر کردن این گذار، میتوانید با پارامتر pct در DMARC سیاست را در ابتدا فقط روی بخشی از پیامها اعمال کنید.
اشتباهات رایج
بیش از یک رکورد SPF
هر دامنه فقط میتواند یک رکورد SPF داشته باشد. افزودن رکورد «v=spf1» دوم برای یک سرویس جدید به جای بهروزرسانی رکورد موجود، اشتباهی بسیار رایج است و باعث میشود هر دو رکورد نامعتبر شوند.
محدودیت 10 جستجوی DNS
بررسی SPF حداکثر میتواند 10 جستجوی DNS انجام دهد. هر سازوکار include، mx و a در این محدودیت شمرده میشود و includeهای تودرتو هم حساب میشوند. با افزودن سرویسهای بیشتر از این محدودیت عبور میکنید و بررسی SPF خطا برمیگرداند. سرویسهایی را که دیگر استفاده نمیکنید حذف کنید و در صورت مناسب بودن، نشانیهای IP ثابت را با ip4 فهرست کنید.
شروع DMARC با reject
رفتن به سیاست reject پیش از کامل شدن فهرستبرداری ممکن است باعث رد شدن ایمیلهای مشروعی مانند فاکتورها یا اعلانها شود. همیشه با حالت پایش شروع کنید.
فعالکردن DKIM فقط روی ارائهدهندهٔ اصلی
سرویسهای شخص ثالث مانند خبرنامه و CRM نیز باید با کلیدهای DKIM خودشان و به نام دامنهٔ شما امضا کنند. در غیر این صورت همترازی DMARC رد میشود.
کسی نشانی گزارش را نمیخواند
گزارشهای DMARC بهصورت XML میرسند و ممکن است حجیم باشند. به ابزاری نیاز دارید که آنها را خوانا کند، یا فردی که مسئول بررسی منظم آنها باشد.
احراز هویت بهتنهایی کافی نیست
حتی با تنظیم درست SPF، DKIM و DMARC، ایمیلها گاهی ممکن است به اسپم بروند. به این نکات نیز توجه کنید:
- اعتبار IP فرستنده: اگر کاربر دیگری روی یک سرور اشتراکی اسپم بفرستد، ممکن است بر ایمیلهای شما از همان IP اثر بگذارد. فهرستهای سیاه را بهطور منظم بررسی کنید.
- بهداشت فهرست: ارسال به فهرستهای خریداریشده یا افرادی که هرگز رضایت ندادهاند، نرخ شکایت را بالا میبرد و بهسرعت به اعتبار دامنهٔ شما آسیب میزند.
- محتوا: ایمیلهایی که فقط تصویر دارند، لینکهای کوتاهشده و عبارات اغراقآمیز توجه فیلترها را جلب میکنند.
- جدا کردن خبرنامه از ایمیلهای روزمره: ارسال بازاریابی انبوه از یک زیردامنهٔ جداگانه، از اعتبار مکاتبات روزمرهٔ کاری شما محافظت میکند.
قوانین ارسال ارائهدهندگان بزرگ
از اوایل سال 2024، Google و Yahoo قوانین سختگیرانهتری برای فرستندگان اعمال کردهاند و Microsoft نیز الزامات مشابهی را برای Outlook.com اعلام کرده است. چارچوب کلی چنین است:
- از همهٔ فرستندگان انتظار میرود دستکم از SPF یا DKIM استفاده کنند، رکورد reverse DNS معتبر داشته باشند و از طریق TLS متصل شوند.
- فرستندگان انبوه (طبق تعریف Google، کسانی که روزانه بیش از 5,000 پیام به نشانیهای Gmail میفرستند) باید SPF، DKIM و یک رکورد DMARC با دستکم سیاست p=none داشته باشند و نشانی «From» باید همتراز باشد.
- پیامهای بازاریابی باید لغو اشتراک با یک کلیک را ارائه دهند و نرخ شکایت اسپم را پایین نگه دارند.
پیامهایی که این قوانین را رعایت نکنند ممکن است به اسپم بروند یا کاملاً رد شوند. حتی اگر کسبوکار کوچکی هستید، راهاندازی کامل SPF، DKIM و DMARC اکنون یک الزام پایه است.
اگر در حال مهاجرت به ایمیل سازمانی هستید، راهاندازی این رکوردها بهعنوان بخشی از مهاجرت سادهترین مسیر است.
پرسشهای متداول
آیا راهاندازی فقط یکی از SPF، DKIM و DMARC کافی است؟
خیر. این سه با هم کار میکنند. SPF و DKIM هویت را تأیید میکنند و DMARC اطمینان میدهد که این تأیید با نشانی «From» مطابقت دارد و تعیین میکند در صورت رد شدن چه اتفاقی بیفتد.
رکوردها را اضافه کردم. تغییرات کی اعمال میشوند؟
رکوردهای DNS معمولاً ظرف چند دقیقه تا چند ساعت منتشر میشوند. بازیابی اعتبار دامنه ممکن است کمی بیشتر طول بکشد؛ با ارسال منظم و سالم، معمولاً ظرف چند روز یا چند هفته بهبود را خواهید دید.
چگونه بررسی کنم که رکوردهایم درست هستند؟
پیامی به یکی از نشانیهای Gmail خودتان بفرستید و با گزینهٔ «نمایش پیام اصلی» (show original) نتایج SPF، DKIM و DMARC را ببینید. ابزارهای آنلاین بررسی DNS نیز خطاهای نحوی رکوردهایتان را نشان میدهند.
آیا سیاست reject در DMARC ایمیلهای مشروع من را مسدود میکند؟
نه، اگر فهرستبرداری شما کامل باشد و همهٔ منابع ارسال از طریق SPF یا DKIM همتراز باشند. به همین دلیل بررسی گزارشها در حالت پایش پیش از رفتن به reject ضروری است.
ایمیل سازمانی CloudRUX
راهاندازی SPF، DKIM و DMARC ممکن است فقط چند رکورد DNS به نظر برسد، اما جزئیات است که تحویلپذیری را تعیین میکند. با ایمیل سازمانی CloudRUX، مهندسان ما این رکوردها را بهعنوان بخشی از راهاندازی پیکربندی میکنند، شما را در استقرار DMARC راهنمایی میکنند و وقتی مشکلی پیش بیاید، مهندسی که به زبانهای فارسی و ترکی پاسخگوست آن سوی خط است. طرحها از 1.19 USD به ازای هر کاربر در ماه (بدون مالیات بر ارزش افزوده) شروع میشوند و راهاندازی و انتقال رایگان است. برای جزئیات، صفحهٔ ایمیل سازمانی را ببینید، یا برای بررسی مشکلات تحویل ایمیلتان با ما تماس بگیرید.



