چرا ایمیل ها به اسپم می روند؟ تنظیم SPF، DKIM و DMARC

ایمیل سازمانی معمولاً به یکی از این دلیل‌ها به اسپم می‌رود: دامنه احراز هویت ندارد، رکورد PTR آی‌پی سرور با نام آن نمی‌خواند یا آی‌پی در یک لیست سیاه ثبت شده است. با تنظیم SPF، DKIM و DMARC و درست کردن PTR، سرور گیرنده (Gmail، Outlook یا میل سرور یک سازمان دیگر) می‌تواند ثابت کند نامه واقعاً از طرف دامنه شما آمده و در مسیر تغییر نکرده است.

مراحل زیر برای مدیر شبکه یا مسئول IT است که میل سرور اختصاصی دارد یا از سرویس ارسال ایمیل استفاده می‌کند و نامه‌هایش در Inbox گیرنده نمی‌نشیند. اگر سرور شما ناگهان شروع به ارسال انبوه ایمیل کرده، مشکل احتمالاً نفوذ است و تنظیم DNS آن را حل نمی‌کند؛ این حالت در نشانه‌های نیاز به مدیریت سرور توضیح داده شده است. رکوردهای این راهنما بر اساس RFC 7208 برای SPF، RFC 6376 برای DKIM و استاندارد جدید DMARC (RFC 9989) و راهنمای فرستندگان Google و Microsoft نوشته شده‌اند.

اول تشخیص: از هدر نامه شروع کنید

پیش از تغییر هر رکوردی، یک نامه آزمایشی به یک حساب Gmail بفرستید، در منوی سه‌نقطه گزینه Show original را باز کنید و سه خط SPF، DKIM و DMARC را ببینید. در Outlook همین اطلاعات در Message source و هدر Authentication-Results آمده است. خروجی چیزی شبیه این است:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=mail2026;
       spf=pass (google.com: domain of info@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=info@example.com;
       dmarc=pass (p=QUARANTINE) header.from=example.com

اگر هر سه pass هستند و نامه باز هم به اسپم می‌رود، مشکل از اعتبار آی‌پی، محتوای نامه یا شکایت کاربران است و باید سراغ بخش لیست سیاه بروید. اگر یکی fail، softfail، none یا permerror است، همان را اول درست کنید. رکوردهای فعلی دامنه را هم از خط فرمان ببینید:

dig +short TXT example.com
dig +short TXT mail2026._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

# در ویندوز
nslookup -type=TXT _dmarc.example.com

الزامات Gmail و Outlook برای فرستندگان ایمیل

Google از فوریه ۲۰۲۴ از همه فرستندگان می‌خواهد دست‌کم SPF یا DKIM داشته باشند، رکورد PTR و DNS رفت‌وبرگشتی معتبر داشته باشند، نامه را روی TLS بفرستند و نرخ اسپم گزارش‌شده در Postmaster Tools را زیر 0.3 درصد نگه دارند. توصیه خود Google نرخی زیر 0.1 درصد است. فرستنده‌ای که روزانه بیش از ۵۰۰۰ نامه به Gmail می‌فرستد باید SPF و DKIM و DMARC را هم‌زمان داشته باشد، دامنه From با دامنه SPF یا DKIM هم‌راستا باشد و نامه‌های تبلیغاتی لغو اشتراک یک‌کلیکی داشته باشند.

Microsoft هم از ۵ مه ۲۰۲۵ همین الزام را برای فرستندگان بیش از ۵۰۰۰ نامه در روز به Outlook.com، Hotmail و Live اجرا کرد. نامه‌ای که شرایط را نداشته باشد با خطای 550 5.7.515 Access denied رد می‌شود. برای یک شرکت کوچک که روزانه چند صد نامه می‌فرستد این آستانه‌ها الزام رسمی نیستند، ولی فیلترها با همان معیارها امتیاز می‌دهند و بدون این سه رکورد، نامه شما هم‌ردیف نامه‌های جعلی دیده می‌شود.

تنظیم رکورد SPF

SPF یک رکورد TXT روی دامنه است که فهرست آی‌پی‌ها و سرویس‌های مجاز به ارسال ایمیل با آن دامنه را اعلام می‌کند. سرور گیرنده آی‌پی فرستنده را با دامنه‌ای که در فرمان MAIL FROM (آدرس برگشت نامه) آمده مقایسه می‌کند. نمونه برای دامنه‌ای که از میل سرور خودش و یک سرویس ارسال خبرنامه استفاده می‌کند:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 include:spf.newsletter-provider.example -all"

• هر دامنه فقط یک رکورد SPF می‌تواند داشته باشد. دو رکورد v=spf1 نتیجه permerror می‌دهد؛ مقادیر را در یک رکورد ادغام کنید.
• طبق بخش 4.6.4 در RFC 7208، سازوکارهای include، a، mx، ptr، exists و redirect روی هم حداکثر ۱۰ جست‌وجوی DNS مجازند و بیشتر از آن permerror است. ip4 و ip6 در این شمارش نیستند، پس برای آی‌پی‌های ثابت از آن‌ها استفاده کنید.
• -all یعنی هر فرستنده خارج از فهرست رد شود و ~all یعنی مشکوک علامت بخورد. تا وقتی همه منابع ارسال را نشناخته‌اید ~all بگذارید و بعد از چند هفته گزارش DMARC به -all بروید.
• زیردامنه‌ای که ایمیل نمی‌فرستد (مثلاً shop.example.com) را با v=spf1 -all ببندید تا برای جعل استفاده نشود.

تنظیم DKIM و انتخاب Selector

DKIM هدرها و بدنه نامه را با کلید خصوصی میل سرور امضا می‌کند و کلید عمومی در DNS زیر نامی به شکل selector._domainkey.domain منتشر می‌شود. گیرنده امضا را با کلید عمومی بررسی می‌کند؛ اگر کسی در مسیر متن نامه را تغییر دهد، امضا نامعتبر می‌شود. Google کلید دست‌کم ۱۰۲۴ بیتی را می‌پذیرد و کلید ۲۰۴۸ بیتی را توصیه می‌کند.

کلید را معمولاً خود نرم‌افزار میل سرور می‌سازد: در Exchange با یک ابزار جانبی یا Gateway، در Zimbra و Carbonio با دستور مدیریتی، و در iRedMail یا سرورهای Postfix با Amavis، OpenDKIM یا Rspamd. خروجی یک رکورد TXT است:

mail2026._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3...بخش-اول"
  "...بخش-دوم-کلید...IDAQAB" )

کلید ۲۰۴۸ بیتی از ۲۵۵ کاراکتر یک رشته TXT بلندتر است. بیشتر پنل‌های DNS آن را خودکار به چند رشته تقسیم می‌کنند؛ اگر پنل شما این کار را نمی‌کند، کلید را خودتان در رشته‌های کوتاه‌تر بگذارید و فاصله یا نقل‌قول اضافه وارد نکنید. نام Selector را با تاریخ انتخاب کنید (مثل mail2026) تا هنگام تعویض کلید، رکورد جدید را کنار قبلی منتشر کنید، امضا را به کلید جدید منتقل کنید و چند روز بعد رکورد قدیمی را بردارید.

تنظیم DMARC و سیاست گام‌به‌گام

DMARC به گیرنده می‌گوید اگر نامه‌ای با دامنه شما در هدر From نه SPF هم‌راستا داشت و نه DKIM هم‌راستا، با آن چه کند، و گزارش‌ها را به کجا بفرستد. هم‌راستایی یعنی دامنه‌ای که SPF یا DKIM را پاس کرده با دامنه From یکی باشد. نامه‌ای که از طریق یک سرویس خبرنامه با دامنه برگشت همان سرویس ارسال شود، SPF را پاس می‌کند ولی هم‌راستا نیست؛ به همین دلیل DKIM با دامنه خودتان برای سرویس‌های بیرونی ضروری است.

# مرحله ۱: فقط پایش
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

# مرحله ۲: بعد از رفع منابع ناشناخته
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

# مرحله ۳: سیاست نهایی
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

با p=none شروع کنید و گزارش‌های تجمیعی (rua) را چند هفته بخوانید. این گزارش‌ها فایل XML هستند و نشان می‌دهند چه آی‌پی‌هایی با دامنه شما نامه فرستاده‌اند؛ معمولاً یک سامانه پیامکی، CRM یا چاپگر شبکه پیدا می‌شود که هیچ‌کس در فهرست SPF نیاورده بود. پس از رفع آن‌ها به quarantine و سپس reject بروید.

در مه ۲۰۲۶ استاندارد DMARC با RFC 9989، RFC 9990 و RFC 9991 به‌روز شد و جای RFC 7489 را گرفت. رکوردهای فعلی v=DMARC1 معتبر می‌مانند، ولی برچسب‌های pct، rf و ri حذف شده‌اند و بهتر است در به‌روزرسانی بعدی DNS آن‌ها را از رکورد بردارید. برچسب جدید np سیاست زیردامنه‌های ناموجود را تعیین می‌کند.

رکورد PTR و نام HELO میل سرور

PTR یا Reverse DNS آی‌پی را به نام برمی‌گرداند. این رکورد در پنل DNS دامنه شما تعریف نمی‌شود؛ صاحب آی‌پی، یعنی دیتاسنتر یا ارائه‌دهنده سرور، باید آن را ثبت کند. سه مقدار باید با هم بخوانند: PTR آی‌پی، رکورد A همان نام و نامی که میل سرور در فرمان HELO یا EHLO اعلام می‌کند.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

# بررسی نام HELO از بیرون سرور
telnet mail.example.com 25
EHLO test.example.net

PTR عمومی مثل static-203-0-113-10.provider.example یکی از رایج‌ترین دلیل‌های رد شدن نامه‌های سرورهای تازه است. در برخی دیتاسنترهای داخل ایران ثبت PTR فقط با درخواست تیکت ممکن است یا پورت ۲۵ خروجی بسته است؛ پیش از خرید سرور برای میل سرور این دو مورد را از ارائه‌دهنده بپرسید. اگر ممکن نیست، ارسال از طریق یک Relay (Smarthost) خارجی با آی‌پی و PTR درست راه‌حل رایجی است. برای طراحی این مدل و تحویل رکوردهای درست، خدمت راه‌اندازی میل سرور سازمانی همین موارد را پوشش می‌دهد.

بررسی لیست سیاه (Blacklist) و اعتبار آی‌پی

اگر احراز هویت درست است و نامه‌ها باز هم رد می‌شوند یا به اسپم می‌روند، آی‌پی سرور را در لیست‌های سیاه جست‌وجو کنید. Spamhaus در صفحه Check Your IP وضعیت آی‌پی را در لیست‌های خودش نشان می‌دهد و ابزارهایی مانند MXToolbox ده‌ها لیست را هم‌زمان بررسی می‌کنند. از خط فرمان هم می‌توانید با معکوس کردن آی‌پی یک لیست را بپرسید:

# آی‌پی 203.0.113.10 به صورت معکوس
dig +short 10.113.0.203.zen.spamhaus.org
# خروجی خالی یعنی در این لیست نیست

Spamhaus پرس‌وجو از طریق DNS Resolverهای عمومی بزرگ را مسدود می‌کند و ممکن است پاسخ خطا بگیرید؛ در این حالت از صفحه وب خود Spamhaus استفاده کنید. پیش از درخواست حذف از لیست، علت را پیدا کنید: حساب کاربری با رمز لو رفته که اسپم فرستاده، فرم تماس سایت که بدون کپچا ایمیل می‌فرستد یا Open Relay. اگر علت را پیدا نکنید، آی‌پی چند روز بعد دوباره در لیست قرار می‌گیرد. اگر نشانه‌ای از نفوذ یا اسکریپت مخرب روی سرور دیدید، رفع هک و پاک‌سازی مالور سرور مقدم بر هر درخواست حذفی است.

برای پایش دائمی، دامنه را در Google Postmaster Tools ثبت کنید تا نرخ اسپم و اعتبار دامنه را ببینید، و آی‌پی را در Microsoft SNDS تا وضعیت آن نزد Outlook.com مشخص شود. بررسی خودکار لیست‌های سیاه را هم می‌توانید به سامانه مانیتورینگ سرور اضافه کنید تا ثبت آی‌پی پیش از شکایت کاربران گزارش شود.

خطاهای رایج و راه‌حل آن‌ها

یک حالت خاص هم هست: نامه‌ای که گیرنده آن را به آدرس دیگری Forward می‌کند، SPF را از دست می‌دهد، چون سرور میانی آی‌پی مجاز شما نیست. DKIM در این مسیر معمولاً سالم می‌ماند و DMARC با همان پاس می‌شود. دلیل دیگری که نباید فقط به SPF تکیه کرد همین است.

ترتیب اجرای تنظیم SPF، DKIM و DMARC

1. فهرست همه منابعی که با دامنه ایمیل می‌فرستند: میل سرور، سایت، CRM، سامانه خبرنامه، دستگاه‌های اسکن.
2. ثبت PTR و هم‌خوان کردن نام HELO با آن.
3. انتشار یک رکورد SPF با ~all.
4. فعال کردن DKIM روی میل سرور و همه سرویس‌های بیرونی.
5. DMARC با p=none و خواندن گزارش‌ها به مدت چند هفته.
6. رفتن به quarantine، سپس reject، و تغییر SPF به -all.
7. ثبت دامنه در Postmaster Tools و SNDS و پایش لیست سیاه.

میل سروری که روی سرور اصلی سایت هم اجرا می‌شود، با هر آسیب‌پذیری سایت اعتبار ایمیل را هم به خطر می‌اندازد. جدا کردن این دو و بستن پورت‌ها و سرویس‌های اضافه بخشی از امن‌سازی سرور است.

سوالات متداول

آیا فقط SPF برای رسیدن ایمیل به Inbox کافی است؟

برای فرستنده کم‌حجم، Google حداقل SPF یا DKIM را می‌خواهد، ولی بدون DMARC هر کسی می‌تواند با دامنه شما نامه جعلی بفرستد و اعتبار دامنه آسیب ببیند. هر سه رکورد را با هم تنظیم کنید؛ هزینه اضافه‌ای جز چند رکورد DNS ندارد.

تغییرات DNS چقدر طول می‌کشد تا اعمال شود؟

به TTL رکورد قبلی بستگی دارد. اگر TTL یک ساعت بوده، گیرنده‌ها حداکثر پس از همین مدت مقدار جدید را می‌بینند. پیش از تغییرات مهم TTL را کم کنید و بعد از پایدار شدن دوباره افزایش دهید.

آیا p=reject باعث از دست رفتن نامه‌های درست می‌شود؟

اگر پیش از آن گزارش‌های DMARC را نخوانده باشید و منبعی مثل سامانه فاکتور یا خبرنامه هم‌راستا نباشد، بله. به همین دلیل مسیر none، quarantine و reject را با فاصله چند هفته طی کنید.

PTR را کجا تنظیم کنم؟

در پنل یا تیکت ارائه‌دهنده سرور یا دیتاسنتری که آی‌پی متعلق به آن است. رجیسترار دامنه یا پنل DNS دامنه امکان ثبت PTR برای آی‌پی شما را ندارد.