آموزش تنظیم SPF، DKIM و DMARC برای جلوگیری از جعل ایمیل

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

این آموزش برای دامنه‌ای است که از سرویس میزبانی ایمیل، Google Workspace، Microsoft 365، سرور اختصاصی یا سامانه‌های ارسال تراکنشی استفاده می‌کند. مقدارهای واقعی SPF و DKIM را باید از ارائه‌دهنده همان سرویس بگیرید؛ نمونه‌های این مقاله عمداً با دامنه‌های مستنداتی نوشته شده‌اند و نباید بدون جایگزینی در DNS کپی شوند.

SPF، DKIM و DMARC چه تفاوتی دارند؟

• SPF: بررسی می‌کند IP یا سرویس ارسال‌کننده اجازه دارد برای دامنه Envelope From ایمیل بفرستد.
• DKIM: با کلید خصوصی پیام را امضا می‌کند و گیرنده کلید عمومی را از DNS می‌خواند تا اصالت دامنه امضاکننده و سالم‌ماندن بخش‌های امضاشده را بسنجد.
• DMARC: نتیجه SPF و DKIM را با دامنه Author From هم‌تراز می‌کند و سیاست none، quarantine یا reject را برای پیام نامعتبر اعلام می‌کند.

برای عبور DMARC کافی است حداقل یکی از SPF یا DKIM هم pass شود و هم دامنه آن با From هم‌ترازی معتبر داشته باشد. عبور DMARC تضمین نمی‌کند محتوای ایمیل بی‌خطر یا حتماً وارد Inbox شود؛ شهرت دامنه، کیفیت محتوا، شکایت کاربران و رفتار ارسال همچنان اثر دارند.

SPF و DKIM هویت دامنه را بررسی می‌کنند و DMARC نتیجه هم‌تراز را به سیاست دریافت ایمیل متصل می‌کند.

مرحله اول: همه منابع ارسال ایمیل را فهرست کنید

قبل از تغییر DNS، تمام فرستنده‌های قانونی را پیدا کنید: سرویس ایمیل کارکنان، فرم تماس سایت، فروشگاه، CRM، خبرنامه، سیستم تیکت، درگاه صدور فاکتور و سرورهایی که با SMTP یا API ایمیل می‌فرستند. فراموش‌کردن حتی یک سرویس می‌تواند پس از سخت‌گیری DMARC باعث اسپم یا ردشدن ایمیل واقعی شود.

برای هر منبع، دامنه Return-Path، دامنه DKIM، selector و راهنمای رسمی SPF را ثبت کنید. اگر برنامه وردپرس یا Laravel مستقیماً با تابع محلی mail ارسال می‌کند، بهتر است آن را به یک SMTP یا سرویس تراکنشی معتبر منتقل کنید تا DKIM و مدیریت bounce قابل‌اعتماد داشته باشد.

مرحله دوم: یک رکورد SPF درست بسازید

SPF به‌صورت رکورد TXT روی دامنه ارسال‌کننده منتشر می‌شود. برای دامنه اصلی معمولاً Host برابر @ است. نمونه زیر فقط قالب را نشان می‌دهد:

Type: TXT
Host: @
Value: v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all

IP و دامنه provider.example نمونه هستند. مقدار رسمی ارائه‌دهنده خود را وارد کنید. روی هر hostname فقط یک رکورد SPF با v=spf1 داشته باشید؛ ساخت دو رکورد جدا باعث خطای دائمی SPF می‌شود. اگر چند سرویس دارید، همه را در همان رکورد ترکیب کنید.

طبق RFC 7208، مجموع عبارت‌هایی که هنگام ارزیابی DNS lookup ایجاد می‌کنند—مانند include، a، mx، exists و redirect—نباید از ۱۰ عبور کند؛ در غیر این صورت نتیجه permerror است. هر include ممکن است lookupهای تو در تو داشته باشد، پس فقط شمردن کلمات رکورد کافی نیست.

~all برای شروع softfail است. تغییر عجولانه به -all می‌تواند فرستنده‌های جاافتاده را رد کند. پس از کامل‌شدن فهرست فرستنده‌ها و مشاهده نتایج، درباره سخت‌گیری تصمیم بگیرید.

مرحله سوم: DKIM را در سرویس ارسال فعال کنید

DKIM فقط با ساخت دستی یک TXT تصادفی فعال نمی‌شود. ابتدا در پنل سرویس ایمیل، کلید DKIM و selector بسازید. ارائه‌دهنده معمولاً یک TXT یا CNAME با نامی شبیه زیر می‌دهد:

selector1._domainkey.example.com

مقدار رکورد را دقیقاً از ارائه‌دهنده کپی کنید و سپس در همان پنل گزینه شروع امضای پیام‌ها را بزنید. کلید خصوصی باید فقط روی سامانه ارسال بماند و هرگز در DNS یا مقاله عمومی قرار نگیرد؛ DNS فقط کلید عمومی یا CNAME مقصد را نگه می‌دارد.

Selector امکان چرخش کلید را فراهم می‌کند. هنگام تعویض، رکورد قدیمی را فوراً حذف نکنید؛ ابتدا ارسال را روی selector جدید ببرید و برای پیام‌های در مسیر زمان کافی بگذارید. برای چند سرویس می‌توانید selectorهای جدا داشته باشید تا مدیریت و عیب‌یابی ساده‌تر شود.

مرحله چهارم: DMARC را ابتدا در حالت مانیتورینگ منتشر کنید

رکورد DMARC روی Host برابر _dmarc قرار می‌گیرد. یک mailbox اختصاصی و محافظت‌شده برای گزارش‌های تجمیعی بسازید و با سیاست p=none شروع کنید:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

آدرس نمونه را با mailbox دامنه خود جایگزین کنید. گزارش‌های rua معمولاً XML و ماشین‌خوان هستند و نشان می‌دهند چه IPها و سرویس‌هایی با نام دامنه شما ایمیل فرستاده‌اند، SPF و DKIM چه نتیجه‌ای داشته‌اند و آیا alignment برقرار بوده است. این mailbox را عمومی استفاده نکنید و برای حجم گزارش و پیام‌های ناخواسته آماده کنید.

RFC 9989 که در سال ۲۰۲۶ جای RFC 7489 را گرفته، همچنان شروع با p=none و تحلیل گزارش‌ها را توصیه می‌کند. پس از اصلاح همه جریان‌های قانونی، سیاست را به p=quarantine و سپس در صورت اطمینان به p=reject ارتقا دهید. تگ قدیمی pct در استاندارد جدید حذف شده است؛ برای تنظیم تازه روی آن تکیه نکنید.

none، quarantine و reject دقیقاً چه می‌کنند؟

• p=none: فقط مانیتورینگ و گزارش؛ DMARC درخواست تغییر رفتار تحویل نمی‌دهد.
• p=quarantine: پیام نامعتبر مشکوک تلقی می‌شود و ممکن است وارد Spam یا بررسی بیشتر شود.
• p=reject: مالک دامنه اعلام می‌کند استفاده نامعتبر از دامنه باید رد شود؛ گیرنده همچنان سیاست محلی خود را دارد.

بدون مشاهده چند چرخه گزارش، مستقیم به reject نروید. فوروارد، mailing list و سرویس‌های ثالث می‌توانند alignment را بشکنند. اگر یک سرویس نمی‌تواند DKIM هم‌تراز بسازد یا Return-Path اختصاصی بدهد، آن را روی subdomain جدا اجرا کنید تا سیاست و شهرت آن از ایمیل اصلی جدا باشد.

مرحله پنجم: رکوردهای DNS و هدر پیام را آزمایش کنید

روی Ubuntu ابزار dig در بسته dnsutils است. پس از انتشار و گذشت TTL، مقدارهای واقعی دامنه و selector خود را بررسی کنید:

sudo apt update
sudo apt install -y dnsutils

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

اگر DKIM از CNAME استفاده می‌کند، دستور زیر مقصد را نشان می‌دهد:

dig +short CNAME selector1._domainkey.example.com

سپس از هر منبع قانونی یک ایمیل آزمایشی به صندوقی خارج از دامنه بفرستید و هدر کامل آن را باز کنید. در بخش Authentication-Results به‌دنبال نتیجه‌های spf=pass، dkim=pass و dmarc=pass بگردید. فقط سبزشدن ابزار بررسی DNS کافی نیست؛ آزمون باید از مسیر واقعی ارسال انجام شود.

خطاهای رایج که تحویل ایمیل را خراب می‌کنند

• داشتن دو رکورد SPF جدا به‌جای ادغام همه فرستنده‌ها در یک رکورد.
• عبور از سقف ۱۰ DNS lookup در SPF به‌دلیل includeهای زنجیره‌ای.
• انتشار کلید DKIM بدون فعال‌کردن signing در پنل سرویس ایمیل.
• قبولی SPF برای دامنه Return-Path، اما نبود alignment با دامنه From.
• استفاده فوری از p=reject پیش از شناسایی فرم سایت، CRM و خبرنامه.
• کپی‌کردن رکورد نمونه سرویس دیگر یا باقی‌گذاشتن selector و کلید منقضی.

جمع‌بندی

پیاده‌سازی درست از inventory شروع می‌شود: همه فرستنده‌ها را ثبت کنید، یک SPF معتبر و کم‌lookup بسازید، DKIM را با selector اختصاصی فعال کنید و DMARC را در حالت گزارش‌گیری قرار دهید. وقتی گزارش‌ها نشان دادند همه ایمیل‌های قانونی حداقل یک نتیجه هم‌تراز دارند، سیاست را مرحله‌ای سخت‌گیرانه کنید.

برای شناخت دقیق TXT، CNAME و TTL ابتدا راهنمای رکوردهای DNS را بخوانید. اگر پس از انتقال وردپرس به هاست جدید ایمیل فرم‌ها قطع شده، منابع ارسال و SPF را دوباره بررسی کنید. در سرور شخصی نیز چک‌لیست امن‌سازی Ubuntu VPS را کنار تنظیمات ایمیل اجرا کنید.

منابع رسمی: RFC 7208 برای SPF، RFC 6376 برای DKIM، استاندارد جدید DMARC در RFC 9989، گزارش‌های تجمیعی DMARC در RFC 9990، راهنمای رسمی SPF در Google Workspace و راهنمای عیب‌یابی احراز هویت ایمیل Microsoft.