SPF چیست و چگونه از جعل ایمیل جلوگیری می‌کند؟

چند سال پیش، در یک پروژهٔ فروشگاهی، مشتری با نگرانی زنگ زد که ایمیل‌های تأیید سفارش به دست مشتریان نمی‌رسد. اول فکر کردیم مشکل از افزونهٔ فرم است، بعد از سرور ایمیل، بعد از SMTP. چند ساعت عیب‌یابی کردیم تا این‌که با ابزار تست تحویل ایمیل، پیام واضحی دیدیم: ایمیل‌های سایت با وضعیت SPF Fail در سرورهای دریافت‌کننده علامت خورده بودند. یعنی Gmail و سایر سرویس‌ها به‌طور خودکار این ایمیل‌ها را در پوشهٔ اسپم می‌گذاشتند، چون هیچ تضمینی وجود نداشت که واقعاً از دامنهٔ مشتری ارسال شده باشند. مشکل نه در کد بود، نه در سرور، نه در افزونه؛ در یک رکورد DNS گم‌شده بود که هیچ‌کس تا آن روز به آن فکر نکرده بود.

SPF یا Sender Policy Framework (چارچوب سیاست فرستنده)، یک استاندارد امنیتی برای ایمیل است که به دامنه‌ها اجازه می‌دهد مشخص کنند کدام سرورها مجاز به ارسال ایمیل به‌نام آن‌ها هستند. این استاندارد در سال ۲۰۰۳ معرفی شد و امروز یکی از ستون‌های اصلی امنیت ایمیل است، در کنار DKIM و DMARC. اگر سایت شما ایمیل می‌فرستد — برای تأیید سفارش، بازیابی رمز عبور، اطلاع‌رسانی — و SPF درست تنظیم نکرده‌اید، اکثر آن ایمیل‌ها هرگز به مخاطب نمی‌رسند. مفهوم پایهٔ جعل هویت در ایمیل را در حمله فیشینگ چیست و چگونه شناسایی می‌شود؟ آورده‌ام؛ این مقاله، به لایهٔ تکنیکال دفاع می‌پردازد.

SPF چیست و چه مسئله‌ای را حل می‌کند؟

SPF یا Sender Policy Framework، یک استاندارد باز است که در آن، صاحب دامنه با اضافه کردن یک رکورد خاص در سیستم DNS (Domain Name System)، فهرست سرورهایی را که مجاز به ارسال ایمیل به‌نام دامنه هستند، اعلام می‌کند. مفهوم DNS و رکوردها را در DNS چیست و چگونه کار می‌کند؟ آورده‌ام.

مسئله‌ای که SPF حل می‌کند، در ظاهر ساده و در عمل پیچیده است. سیستم ایمیل سنتی بر پایهٔ اعتماد کامل ساخته شده بود: هر سروری می‌توانست به هر سرور دیگری ایمیل بفرستد و بگوید «من از طرف فلان دامنه هستم» و هیچ مکانیزمی وجود نداشت که صحت این ادعا را بررسی کند. نتیجه: هر مهاجمی می‌توانست به‌نام هر دامنه‌ای ایمیل بفرستد و مشخصاً ایمیل‌های جعلی به‌نام بانک‌ها و سرویس‌های معتبر، ابزار اصلی حمله‌های فیشینگ شد.

SPF این مسئله را با اضافه کردن یک لایهٔ تأیید حل می‌کند. وقتی سروری ایمیلی دریافت می‌کند، از DNS می‌پرسد که آیا سرور فرستنده مجاز به ارسال ایمیل به‌نام دامنهٔ اعلام‌شده است یا نه. اگر جواب منفی باشد، ایمیل یا رد می‌شود یا به‌عنوان مشکوک علامت می‌خورد. کاربر نهایی این فرآیند را نمی‌بیند، ولی در پس‌صحنه، تصمیم‌گیری مهمی انجام می‌شود.

SPF مثل یک لیست مدعوین در ورودی مراسم است. سرور دریافت‌کنندهٔ ایمیل، این لیست را از DNS دامنهٔ فرستنده می‌خواند و اگر اسم آن سرور در فهرست نباشد، آن ایمیل جعلی تلقی می‌شود.

جعل ایمیل: از Sender Spoofing تا Phishing

برای درک اهمیت SPF، باید بدانید که جعل ایمیل (Email Spoofing) در چند شکل اتفاق می‌افتد:

شکل اول: Sender Address Spoofing

مهاجم آدرس «From» ایمیل را طوری تنظیم می‌کند که به‌نظر از یک دامنهٔ معتبر بیاید، مثلاً support@bank.com. کاربر که ایمیل را باز می‌کند، آدرس فرستنده را معتبر می‌بیند و طبق دستورهای ایمیل عمل می‌کند.

شکل دوم: Display Name Spoofing

مهاجم نام نمایشی (Display Name) را شبیه برند معتبر تنظیم می‌کند، ولی آدرس ایمیل واقعی متفاوت است. بسیاری از سرویس‌ها فقط نام نمایشی را نشان می‌دهند و آدرس واقعی را در جزئیات پنهان می‌کنند.

شکل سوم: Lookalike Domain

مهاجم دامنه‌ای می‌سازد که شبیه دامنهٔ اصلی است، مثلاً bankk.com به‌جای bank.com یا bank.com با کاراکترهای یونیکد مشابه. SPF در این حالت کمک نمی‌کند چون دامنهٔ فرستنده متفاوت است.

SPF فقط شکل اول را به‌طور کامل پوشش می‌دهد. برای شکل دوم، نیازمند بررسی محتوای ایمیل و DMARC هستید. برای شکل سوم، نیازمند آموزش کاربران هستید که در آموزش کاربران برای مقابله با فیشینگ آمده است. امنیت ایمیل، چندلایه است و SPF یکی از مهم‌ترین این لایه‌هاست.

مکانیزم SPF: سرور دریافت‌کننده چطور بررسی می‌کند؟

وقتی ایمیلی به یک سرور دریافت‌کننده می‌رسد، این سرور پنج گام را برای بررسی SPF طی می‌کند:

1. استخراج دامنهٔ فرستنده: سرور، دامنه را از فیلد Return-Path (که در ایمیل‌های فنی به آن Envelope From هم می‌گویند) استخراج می‌کند.
2. کوئری DNS: سرور به DNS دامنه، درخواست رکورد SPF می‌فرستد (نوع رکورد TXT).
3. تطبیق IP فرستنده: سرور، IP فرستنده را با فهرست IPهای موجود در رکورد SPF مقایسه می‌کند.
4. اعمال نتیجه: بر اساس مکانیزم‌های تعریف‌شده در رکورد، یکی از چهار نتیجهٔ ممکن تعیین می‌شود.
5. تصمیم‌گیری: سرور دریافت‌کننده بر اساس نتیجه، ایمیل را می‌پذیرد، به اسپم می‌فرستد یا رد می‌کند.

همهٔ این فرآیند در چند میلی‌ثانیه انجام می‌شود. برای کاربر، ایمیل به‌سادگی می‌رسد یا نمی‌رسد. اما در پس‌صحنه، چند مرحلهٔ تأیید انجام شده که اگر یکی از آن‌ها مشکل داشته باشد، ایمیل شما ممکن است در پوشهٔ اسپم یا در سبد هرزنامهٔ سرور گیر کند.

ساختار رکورد SPF: هر بخش چه معنایی دارد؟

رکورد SPF یک رکورد TXT در DNS است که ساختار مشخصی دارد. مثال ساده:

v=spf1 ip4:192.0.2.1 include:_spf.google.com -all

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

بخش اول: v=spf1

همیشه با این شروع می‌شود و نسخهٔ SPF را اعلام می‌کند. SPF1 تنها نسخهٔ رایج امروز است.

بخش دوم: مکانیزم‌های مجاز

هر مکانیزم نشان می‌دهد کدام سرورها مجاز به ارسال ایمیل به‌نام دامنه هستند:

• ip4:192.0.2.1: یک IP مشخص مجاز است.
• ip4:192.0.2.0/24: یک زیرشبکه مجاز است.
• include:_spf.google.com: از یک SPF دامنهٔ دیگر دعوت می‌شود. مثلاً اگر از Google Workspace استفاده می‌کنید، این ورودی اجازه می‌دهد سرورهای گوگل ایمیل بفرستند.
• a: رکورد A دامنه، IP مجاز است.
• mx: سرورهای MX دامنه مجاز هستند.

بخش سوم: کوالیفایر نهایی

در انتهای رکورد، یک کوالیفایر نهایی قرار می‌گیرد که تعیین می‌کند سرورهایی که در فهرست بالا نبودند چه رفتاری داشته باشند:

قاعدهٔ من در پروژه‌ها: بعد از اطمینان از صحت تنظیمات، همیشه با -all تمام کنم. اما اگر تازه SPF را اضافه می‌کنید، اول با ~all شروع کنید، چند هفته پایش کنید، و اگر خطاها نزدیک صفر شد، به -all تغییر دهید.

چهار نتیجهٔ بررسی SPF: Pass، Fail، SoftFail، Neutral

سرور دریافت‌کننده بعد از بررسی SPF، یکی از چهار نتیجه را تعیین می‌کند:

Pass

سرور فرستنده در فهرست مجاز بود. ایمیل پذیرفته می‌شود. اکثر سرویس‌های ایمیل، ایمیل با SPF Pass را از فیلترهای شدید معاف می‌کنند.

Fail

سرور فرستنده در فهرست مجاز نبود و کوالیفایر نهایی -all بود. اکثر سرویس‌ها این ایمیل را یا کاملاً رد می‌کنند یا به پوشهٔ اسپم می‌فرستند. این همان حالتی است که در پروژهٔ ابتدای مقاله دیده بودیم.

SoftFail

سرور فرستنده در فهرست نبود ولی کوالیفایر ~all بود. سرویس دریافت‌کننده ایمیل را پذیرش می‌کند ولی به‌عنوان مشکوک علامت می‌زند. معمولاً این ایمیل‌ها به اسپم می‌روند.

Neutral

SPF نتوانست تصمیم بگیرد، معمولاً چون رکورد SPF وجود ندارد یا کوالیفایر ?all بود. در این حالت، تصمیم به DMARC یا فیلترهای دیگر واگذار می‌شود.

در تحلیل پروژه‌ها، هر بار که مشکل تحویل ایمیل دیده‌ام، در نزدیک به هفتاد درصد موارد، SPF Fail یا Neutral بوده. و مهم‌تر از آن، در اکثر موارد، صاحب دامنه حتی نمی‌دانسته که رکورد SPF دارد یا نه.

تنظیم SPF در پنل دامنه: گام‌به‌گام

مسیر عملی تنظیم SPF، هفت گام دارد:

1. فهرست سرورهای ارسال ایمیل: تمام سرورها، سرویس‌ها و ابزارهایی که با دامنهٔ شما ایمیل می‌فرستند را فهرست کنید. معمولاً شامل: سرور هاست، سرویس ایمیل تراکنشی، ابزار بازاریابی ایمیلی، و سرویس خارجی مثل Google Workspace.
2. ورود به پنل DNS: از پنل هاست یا پنل ثبت دامنه، به بخش مدیریت DNS بروید.
3. ساخت یا ویرایش رکورد TXT: یک رکورد TXT با نام دامنهٔ اصلی (یا ساب‌دامین مربوطه) بسازید. مقدار آن با v=spf1 شروع می‌شود.
4. اضافه کردن مکانیزم‌ها: برای هر سرویس، مکانیزم مربوطه را اضافه کنید. اگر سرویس، SPF آمادهٔ خودش را دارد (مثل include:_spf.google.com)، فقط مکانیزم include را وارد کنید.
5. تعیین کوالیفایر نهایی: با ~all شروع کنید یا اگر اطمینان دارید، با -all ببندید.
6. ذخیره و تست: رکورد را ذخیره کنید و با ابزارهایی مثل MXToolbox یا Kitterman SPF Validator، اعتبار رکورد را چک کنید.
7. تست تحویل ایمیل: با ابزارهایی مثل mail-tester.com، از یک ایمیل آزمایشی به یک حساب واقعی، وضعیت SPF و تحویل را بسنجید.

در پروژه‌های خودم، این هفت گام معمولاً کمتر از سی دقیقه طول می‌کشد و بعد از آن، تحویل ایمیل‌های سایت به‌طور محسوسی بهبود پیدا می‌کند. جزئیات بیشتر در MX Record و تنظیمات ایمیل دامنه آمده است.

SPF در وردپرس: ارسال ایمیل‌های تراکنشی

در وردپرس، ارسال ایمیل معمولاً از طریق تابع wp_mail() انجام می‌شود که به‌طور پیش‌فرض از تابع mail() سرور استفاده می‌کند. اما اکثر سرورهای اشتراکی، در پیکربندی پیش‌فرض، ایمیل‌ها را با آدرس سرور ارسال می‌کنند نه با دامنهٔ شما. این یعنی حتی اگر رکورد SPF داشته باشید، ایمیل با دامنهٔ دیگری فرستاده می‌شود و SPF به‌طور خودکار Fail می‌شود.

راه‌حل اول: SMTP Plugin

استفاده از یک افزونهٔ SMTP مثل WP Mail SMTP یا FluentSMTP، که اجازه می‌دهد ایمیل‌ها از طریق یک سرویس SMTP اختصاصی ارسال شوند. این سرویس می‌تواند هاست خودتان، Google Workspace، یا یک سرویس ایمیل تراکنشی مثل SendGrid یا Mailgun باشد. راهنمای پیکربندی در پیکربندی ایمیل‌های وردپرس آمده است.

راه‌حل دوم: سرویس ایمیل تراکنشی

برای سایت‌های فروشگاهی و سایت‌هایی با حجم بالای ایمیل تراکنشی، استفاده از سرویس اختصاصی توصیه می‌شود. مقایسهٔ این سرویس‌ها در بهترین سرویس ایمیل تراکنشی آمده است.

راه‌حل سوم: پیکربندی SPF برای سرویس انتخابی

بعد از انتخاب سرویس، باید رکورد SPF دامنه را بر اساس آن سرویس به‌روز کنید. اکثر سرویس‌های ایمیل، یک راهنمای دقیق برای مقدار SPF می‌دهند. مثلاً SendGrid می‌گوید include:sendgrid.net را اضافه کنید.

در پروژه‌های خودم، ترکیبی که همیشه کار می‌کند: هاست اختصاصی برای دریافت ایمیل + Google Workspace برای ارسال ایمیل کاربران داخلی + یک سرویس ایمیل تراکنشی برای ایمیل‌های وردپرس. هر سه سرویس در رکورد SPF به‌صورت جداگانه include می‌شوند. با این ترکیب، نرخ تحویل ایمیل معمولاً بالای ۹۸ درصد است.

SPF به‌تنهایی کافی نیست: DKIM و DMARC

SPF یکی از سه ستون امنیت ایمیل است، ولی به‌تنهایی برای دفاع کامل کافی نیست. سه ستون:

SPF

تأیید می‌کند که سرور فرستنده مجاز است. ولی فقط بر اساس IP است و اگر مهاجم از یک سرویس معتبر سوءاستفاده کند، می‌تواند SPF را پاس کند.

DKIM (DomainKeys Identified Mail)

امضای دیجیتال روی ایمیل می‌زند و اطمینان می‌دهد محتوا در مسیر تغییر نکرده. تفاوت DKIM و SPF در سطح عملکرد بسیار مهم است. مفهوم کامل در DKIM و امضای دیجیتال ایمیل‌ها آمده است.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

لایهٔ بالای SPF و DKIM است و به صاحب دامنه اجازه می‌دهد سیاست مشخصی برای ایمیل‌های ناموفق تعیین کند: reject (رد)، quarantine (قرنطینه/اسپم) یا none (بدون اقدام). همچنین گزارش‌های تحلیلی از ایمیل‌های دریافتی می‌دهد. راهنمای کامل در DMARC چیست و چگونه امنیت ایمیل را تقویت می‌کند؟ آمده است.

ترتیب راه‌اندازی صحیح: اول SPF، بعد DKIM، بعد DMARC. SPF و DKIM را به‌عنوان داده‌های ورودی برای DMARC استفاده کنید. با فعال‌سازی هر سه، امنیت ایمیل دامنهٔ شما به سطح بالایی می‌رسد.

اشتباهات رایج در تنظیم SPF

شش اشتباه که در بازبینی دامنه‌ها زیاد دیده‌ام:

• داشتن چند رکورد SPF: طبق استاندارد، هر دامنه فقط یک رکورد SPF می‌تواند داشته باشد. اگر دو رکورد TXT با v=spf1 وجود داشته باشد، بررسی نامعتبر می‌شود. اگر روی افزونه‌های ایمیل مختلف کار می‌کنید، همه باید در یک رکورد واحد ترکیب شوند.
• استفاده از +all: این کوالیفایر می‌گوید همهٔ سرورها مجاز هستند. نتیجه: SPF بی‌فایده می‌شود و مهاجم می‌تواند به‌راحتی ایمیل جعلی بفرستد.
• عدم به‌روزرسانی بعد از تغییر هاست: با مهاجرت سایت به هاست جدید، IP سرور عوض می‌شود و رکورد SPF باید به‌روز شود. فراموش‌کردن این کار، ایمیل‌های سایت را از اعتبار می‌اندازد.
• تعداد زیاد include: استاندارد SPF حداکثر ۱۰ کوئری DNS را مجاز می‌داند. اگر رکورد شما از ده include بیشتر داشته باشد، بررسی خودکار نامعتبر می‌شود. باید رکورد را بهینه کنید یا از ابزارهای Flatten SPF استفاده کنید.
• نادیده گرفتن ساب‌دامین‌ها: رکورد SPF دامنهٔ اصلی، ساب‌دامین‌ها را پوشش نمی‌دهد. اگر از ساب‌دامین مثل mail.example.com ایمیل می‌فرستید، آن هم رکورد SPF جداگانه نیاز دارد.
• فرض این‌که SPF جلوی همهٔ اسپم‌ها را می‌گیرد: SPF فقط جلوی IP Spoofing را می‌گیرد. جلوی Spam محتوایی، ویروس‌های تبلیغاتی یا Phishing با دامنهٔ مشابه را نمی‌گیرد. برای این‌ها، لایه‌های دیگر لازم است. راهنمای جامع در راهنمای امنیت وردپرس برای مبتدیان.

پرسش‌های پرتکرار درباره SPF و جعل ایمیل

SPF چیست به زبان ساده؟

SPF یا Sender Policy Framework یک استاندارد امنیتی ایمیل است که به صاحب دامنه اجازه می‌دهد مشخص کند کدام سرورها مجاز به ارسال ایمیل به‌نام دامنهٔ او هستند. این اطلاع در یک رکورد DNS ذخیره می‌شود و سرورهای دریافت‌کنندهٔ ایمیل با بررسی آن، می‌توانند ایمیل‌های جعلی را تشخیص دهند و رد کنند.

چرا ایمیل‌های سایت من به اسپم می‌رود؟

سه دلیل عمده: اول، SPF نامعتبر یا غایب — سرور دریافت‌کننده نمی‌تواند تأیید کند که ایمیل از دامنهٔ شماست. دوم، DKIM نامعتبر — محتوای ایمیل امضای دیجیتال معتبر ندارد. سوم، DMARC غایب یا با سیاست اشتباه. بدون این سه، اکثر سرویس‌های ایمیل مدرن، ایمیل شما را اسپم می‌کنند. تشخیص دقیق نیازمند بررسی گزارش‌ها با ابزارهایی مثل mail-tester.com است.

آیا SPF برای سایت‌های کوچک هم مهم است؟

بله. فرقی نمی‌کند سایت شما بزرگ یا کوچک است؛ هر سایت وردپرسی معمولاً حداقل چند ایمیل در روز می‌فرستد (تأیید ثبت‌نام، بازیابی رمز، اطلاع‌رسانی). اگر این ایمیل‌ها به دست مخاطب نرسد، تجربهٔ کاربری و اعتماد به سایت آسیب می‌بیند. تنظیم SPF کار چند دقیقه‌ای است که اثر بلندمدت دارد.

چگونه بفهمم SPF دامنه‌ام درست است؟

سه ابزار عالی: اول، MXToolbox یا Kitterman برای بررسی صرفاً رکورد SPF. دوم، mail-tester.com برای ارسال ایمیل آزمایشی و دریافت امتیاز کلی. سوم، از Google Postmaster Tools اگر حجم ایمیل به Gmail بالاست. اگر امتیاز mail-tester شما بالای ۹ از ۱۰ است، SPF و DKIM و DMARC درست تنظیم شده‌اند.

تفاوت SPF و DKIM چیست؟

SPF تأیید می‌کند که سرور فرستنده مجاز است (بر اساس IP). DKIM تأیید می‌کند که محتوای ایمیل در مسیر دستکاری نشده (بر اساس امضای دیجیتال). این دو مکمل هم هستند: SPF جلوی IP Spoofing را می‌گیرد و DKIM جلوی تغییر محتوا در مسیر. برای دفاع کامل، به هر دو نیاز دارید. راهنمای DKIM در DKIM و امضای دیجیتال ایمیل‌ها آمده است.

آیا SPF جلوی فیشینگ را می‌گیرد؟

تاحدی. SPF جلوی فیشینگی که از دامنهٔ جعل‌شدهٔ شما استفاده می‌کند را می‌گیرد، ولی جلوی فیشینگ از دامنهٔ مشابه (مثل example-bank.com به‌جای example.com) را نمی‌گیرد. برای دفاع کامل، باید آموزش کاربران و DMARC را هم جدی بگیرید. مفاهیم کامل در حمله فیشینگ چیست و چگونه شناسایی می‌شود؟

چند رکورد SPF می‌توانم داشته باشم؟

طبق استاندارد، فقط یک رکورد SPF برای هر دامنه مجاز است. اگر چند رکورد TXT با v=spf1 وجود داشته باشد، بررسی نامعتبر می‌شود و نتیجه Neutral یا Fail برمی‌گردد. اگر از چند سرویس ایمیل استفاده می‌کنید، همه را در یک رکورد واحد با include ترکیب کنید.

نگاه پایانی: SPF به‌عنوان اعتبار دامنه

SPF یکی از آن ابزارهایی است که تا وقتی همه‌چیز درست کار می‌کند، کسی به آن فکر نمی‌کند. اما روزی که ایمیل‌های سایت به دست مشتری نمی‌رسد یا برند شما در یک حملهٔ فیشینگ جعل می‌شود، همه نگاه‌ها به این رکورد گم‌شده برمی‌گردد. در دنیایی که اعتماد دیجیتال گران‌ترین سرمایه است، SPF یکی از ارزان‌ترین و مؤثرترین ابزارهای محافظت از آن است.

پیشنهاد عملی من سه گام است. اول، همین امروز با ابزار MXToolbox بررسی کنید که آیا دامنهٔ شما رکورد SPF دارد یا نه. دوم، اگر ندارد یا ناقص است، با فهرست کامل سرویس‌های ارسال ایمیلتان، یک رکورد SPF جامع بسازید. سوم، به SPF بسنده نکنید — DKIM و DMARC را هم به‌عنوان لایه‌های تکمیلی اضافه کنید تا دامنهٔ شما در برابر جعل هویت و فیشینگ، واقعاً مقاوم شود.

اگر تجربه‌ای از تنظیم SPF در پروژه‌های خودتان دارید — به‌خصوص اگر با چالش خاصی مثل مهاجرت هاست یا سرویس ایمیل چندگانه مواجه شده‌اید — برایم بنویسید. امنیت ایمیل موضوعی است که جزئیات میدانی در آن ارزش فوق‌العاده‌ای دارد. 🔐