پاسخ کوتاه
تفاوت SPF، DKIM و DMARC چیست؟
SPF فهرست سرورهایی است که اجازه ارسال نامه برای دامنه شما را دارند، DKIM امضای رمزنگاری‌شده به هر پیام می‌افزاید، و DMARC به گیرنده‌ها میگوید وقتی هر دو با نشانی From همتراز نشوند چه کنند. Postelva هر سه را به‌عنوان رکورد DNS روی یک .com در $ 12.49/سال در سال با DNS رایگان میزبانی می‌کند.
SPF، DKIM و DMARC کنار هم
| نکته | SPF | DKIM | DMARC |
|---|---|---|---|
| چه چیزی را بررسی می‌کند | نشانی IP سروری که پیام را تحویل میدهد | امضایی که با کلید خصوصی دامنه فرستنده ساخته میشود | اینکه SPF یا DKIM قبول شده باشد و با دامنه نشانی From هم‌خوان باشد |
| کجا در DNS قرار دارد | رکورد TXT در نام دامنه، با شروع v=spf1 | کلید عمومی در selector._domainkey.domain (TXT، یا CNAME به کلید ارائهدهنده) | رکورد TXT در _dmarc.domain، با شروع v=DMARC1 |
| چه کسی آن را منتشر می‌کند | صاحب دامنه، از include ارائهدهنده | ارائهدهنده کلیدها را می‌سازد؛ صاحب دامنه آنها را منتشر می‌کند | فقط صاحب دامنه |
| Standard | RFC 7208 (استاندارد پیشنهادی) | RFC 6376 (استاندارد اینترنتی، STD 76) | RFC 9989 (استاندارد پیشنهادی، مه ۲۰۲۶، جایگزین RFC 7489) |
| تعداد رکوردها | یکی برای هر دامنه، هرگز دو تا | یکی برای هر selector: ۳ برای Proton Mail و Fastmail، ۴ برای Mailbox.org | یکی برای هر دامنه |
| محدودیت اصلی | حداکثر ۱۰ جستجوی DNS | کلید حداقل ۱۰۲۴ بیتی برای امضاکنندگان | باید با یک شناسه همتراز قبول شود |
| گزارش میدهد | خیر | خیر | بله، گزارش‌های تجمیعی به نشانی rua |
آخرین بررسی در ؛ ارقام قدیمی‌تر تاریخ خودشان را دارند
SPF چه کاری انجام میدهد؟
SPF به یک پرسش پاسخ میدهد: آیا سروری که این پیام را تحویل داده مجاز است برای این دامنه ارسال کند؟ صاحب دامنه یک رکورد TXT منتشر می‌کند که با v=spf1 شروع میشود و منابع مجاز را فهرست می‌کند، برای مثال include:_spf.protonmail.ch برای Proton Mail. گیرنده نشانی IP متصل را با فهرست مقایسه می‌کند و نتیجه‌ای می‌گیرد: قبول، رد، ردّ نرم یا خنثی، بسته به قیدی که در پایان می‌آید (-all، ~all یا ?all).
SPF فرستنده پوشش (MAIL FROM) و نام HELO را بررسی می‌کند، نه نشانی From که خواننده می‌بیند. همین شکاف دلیل وجود DMARC است. SPF محدودیت‌های سخت هم دارد: یک دامنه فقط باید یک رکورد SPF داشته باشد، و ارزیابی پس از ۱۰ عبارت که جستجوی DNS انجام می‌دهند (include، a، mx، ptr، exists، redirect) با خطای دائمی متوقف میشود. روش کامل در راهنمای ایجاد رکورد SPF آمده است.
DKIM چه کاری انجام میدهد؟
DKIM به پرسش دیگری پاسخ میدهد: آیا این پیام با دامنه‌ای که ادعا می‌کند امضا شده و بدون تغییر رسیده است؟ سرور فرستنده سرآیندهای انتخاب‌شده و بدنه را با یک کلید خصوصی امضا می‌کند. گیرنده دامنه امضاکننده (d=) و selector (s=) را از سرآیند DKIM-Signature می‌خواند، کلید عمومی را در selector._domainkey.domain روی DNS می‌گیرد و امضا را بررسی می‌کند.
چون امضا همراه پیام حرکت می‌کند، DKIM از فورواردی که پیام را دستنخورده نگه دارد جان سالم به در می‌برد، که SPF نمی‌برد، زیرا فورواردکننده از نشانی IP خودش میفرستد. RFC 6376 میگوید امضاکنندگان برای کلیدهای بلندمدت باید از کلیدهای RSA با حداقل ۱۰۲۴ بیت استفاده کنند و هنگام تغییر کلیدها selector جدید توصیه می‌کند. ارائه‌دهندگان کلیدها را برای شما منتشر میکنند: سه رکورد CNAME برای Proton Mail و Fastmail، و چهار رکورد برای Mailbox.org. جزئیات در راهنمای نحوه راهاندازی DKIM است.
DMARC چه کاری انجام میدهد؟
DMARC، SPF و DKIM را به دامنه قابل‌مشاهده From وصل می‌کند و به گیرنده‌ها میگوید وقتی هیچ‌کدام از بررسی‌ها هم‌خوان نیست چه کنند. پیامی از DMARC عبور می‌کند که SPF یا DKIM قبول شده باشد و دامنه‌ای که احراز شده با دامنه From یکی باشد. هم‌ترازی به‌طور پیش‌فرض آسان است (همان دامنه سازمانی) و وقتی با aspf=s یا adkim=s تنظیم شود سخت‌گیرانه میشود.
رکورد در _dmarc.yourdomain قرار دارد و یک سیاست دارد: p=none (فقط پایش)، p=quarantine (مشکوک تلقی شود) یا p=reject (رد شود). یک نشانی rua گزارش‌های تجمیعی دریافت می‌کند که نشان میدهد چه کسی به نام شما نامه میفرستد. RFC 9989 که در مه ۲۰۲۶ منتشر شد مشخصات فعلی است؛ جایگزین RFC 7489 است، برچسب pct را حذف می‌کند و یک پرچم آزمون t اضافه می‌کند. گذار از پایش به رد در راهنمای نحوه راهاندازی DMARC آمده است.
آیا به هر سه نیاز دارم؟
بله: یک دامنه سفارشی که نامه میفرستد باید SPF، DKIM و DMARC منتشر کند، چون گیرنده‌های بزرگ آنها را می‌خواهند. رهنمودهای فرستنده Google برای فرستنده‌هایی که بیش از ۵٬۰۰۰ پیام در روز به حساب‌های Gmail می‌فرستند SPF، DKIM و یک رکورد DMARC را لازم می‌داند (سیاست none کافی است). Microsoft از فرستنده‌های بالای ۵٬۰۰۰ پیام در روز به Outlook.com همین سه را از ۵ مه ۲۰۲۵ می‌خواهد، و Yahoo هم برای فرستنده‌های انبوه SPF، DKIM و DMARC را الزامی می‌کند.
یک صندوق شخصی بسیار کمتر میفرستد، پس آستانه‌ها به شما ربطی ندارند. با این حال رکوردها همچنان تعیین میکنند که نامه شما به صندوق ورودی برسد یا نه، و جلوی جعل نشانی شما را می‌گیرند. طبق شمارش Postelva در ۱۲ نوامبر ۲۰۲۶ از صفحات راهنمای ارائه‌دهندگان، یک راهاندازی کامل Proton Mail به ۸ رکورد DNS و یک راهاندازی کامل Mailbox.org به ۱۱ رکورد نیاز دارد که از آنها ۳ و ۴ تا کلید DKIM است. رکوردهای MX در MX چیست پوشش داده شده‌اند.
کدام اشتباه‌ها هر سه رکورد را خراب میکنند؟
سه اشتباه بیشتر شکست‌ها را ایجاد می‌کند: رکورد SPF دوم، بیش از ۱۰ جستجو، و سیاست DMARC که زودتر از موعد سخت‌گیرانه شده است. دامنه‌ای با دو رکورد SPF خطای دائمی برمی‌گرداند، پس include ارائهدهنده جدید را به رکورد موجود اضافه کنید. انباشتن یک میزبان نامه، یک ابزار خبرنامه و یک میز پشتیبانی ممکن است شمار جستجوها را از ۱۰ بالاتر ببرد، و رکورد آن وقت برای هر فرستنده شکست میخورد. Mailbox.org و Proton هر دو توصیه میکنند DMARC را با p=none شروع کنید، و Mailbox.org هشدار میدهد که سیاست سخت‌گیرانه‌ای که زودهنگام اعمال شود ممکن است نامه معتبر را برگرداند.
اشتباه چهارم نگه داشتن ورودی‌های DKIM و SPF ارائهدهنده قبلی برای ماه‌هاست. آنها به تحویل آسیبی نمی‌زنند، اما فهرست سرورهای مجازی را که از جانب شما صحبت میکنند گسترده‌تر میکنند. وقتی انتقال تأیید شد آنها را حذف کنید.
این سه روی یک پیام چگونه با هم کار میکنند؟
گیرنده SPF و DKIM را اجرا می‌کند، سپس DMARC نتایج را ترکیب می‌کند. پیامی از [email protected] که از طریق Proton Mail فرستاده شده را در نظر بگیرید. SPF قبول میشود اگر سرور متصل در فهرست _spf.protonmail.ch باشد. DKIM قبول میشود اگر امضای ساخته‌شده با کلید زیر yourname.com تأیید شود. سپس DMARC می‌پرسد آیا حداقل یکی از این دو با شناسه همتراز yourname.com قبول شده است. اگر بله، پیام قبول میشود؛ اگر نه، گیرنده سیاست شما را اعمال می‌کند و نتیجه را در گزارش تجمیعی بعدی ثبت می‌کند.
RFC 9989 میگوید دامنه‌ای که روی p=reject است نباید فقط به SPF تکیه کند و باید با DKIM امضا کند، زیرا SPF در فوروارد خراب میشود. ARC (RFC 8617)، یک استاندارد آزمایشی، به فوروارد‌کننده‌ها اجازه میدهد نتایج اصلی را ثبت کنند، هرچند جزو راهاندازی خودتان نیست. پس از منتشر کردن رکوردها، آنها را با dig بررسی کنید پیش از آنکه سیاست را سخت‌تر کنید.
یک تعریف قابل استناد: SPF سرورها را مجاز می‌کند، DKIM پیام‌ها را احراز هویت می‌کند، و DMARC هم‌خوانی با دامنه From را اعمال می‌کند و نتیجه را گزارش میدهد.
پرسش‌های SPF، DKIM و DMARC
اول کدام رکورد را راهاندازی کنم؟
ابتدا SPF و DKIM را راهاندازی کنید، زیرا از ارائهدهنده ایمیل شما میآیند، سپس DMARC را با p=none همراه با یک نشانی گزارش منتشر کنید. DMARC بدون حداقل یکی از دو مورد دیگر نمیتواند قبول شود.
آیا DMARC میتواند فقط با SPF یا فقط با DKIM قبول شود؟
بله. یک قبولی همتراز کافی است. برای سیاست p=reject، RFC 9989 میگوید به SPF تنها تکیه نکنید و امضای DKIM اضافه کنید.
آیا یک دامنه شخصی به DMARC نیاز دارد؟
قواعد فرستنده Google و Microsoft بالای ۵٬۰۰۰ پیام در روز اعمال میشود. یک رکورد DMARC با p=none همچنان فقط یک رکورد TXT هزینه دارد و نشان میدهد چه کسی به نام شما نامه میفرستد.
چرا وقتی نامه را فوروارد میکنم SPF شکست میخورد؟
فورواردکننده از نشانی IP خودش میفرستد که در فهرست SPF شما نیست. DKIM همچنان تأیید میشود، اگر فورواردکننده پیام را دستنخورده نگه دارد.
آیا SPF، DKIM و DMARC نامه مرا رمزگذاری میکنند؟
نه. آنها فرستنده را احراز هویت میکنند و محتوا را پنهان نمیکنند. رمزگذاری انتقال بین سرورها لایه دیگری است که MTA-STS پوشش میدهد.
خلاصه
- SPF فهرست سرورهای مجاز ارسال برای دامنه شماست: یک رکورد TXT، حداکثر ۱۰ جستجو.
- DKIM هر پیام را امضا می‌کند؛ کلید عمومی در selector._domainkey قرار دارد.
- DMARC به یک قبولی همتراز SPF یا DKIM نیاز دارد و p=none، quarantine یا reject تنظیم می‌کند.
- DMARC با RFC 9989 (مه ۲۰۲۶) تعریف شده که جایگزین RFC 7489 است.
- Google، Yahoo و Microsoft از فرستنده‌های انبوه بالای ۵٬۰۰۰ پیام در روز هر سه را می‌خواهند.
- یک راهاندازی کامل Proton Mail شامل ۸ رکورد DNS است، و یک راهاندازی Mailbox.org شامل ۱۱.
- Postelva رکوردها را در DNS رایگان میزبانی می‌کند؛ یک .com $ 12.49/سال در سال هزینه دارد.
منابع (8)
- RFC 7208، Sender Policy Framework — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 6376، امضاهای DomainKeys Identified Mail — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 9989، DMARC — RFC Editor (خوانده‌شده در 2026-11-12)
- RFC 8617، زنجیره دریافت احراز شده — RFC Editor (خوانده‌شده در 2026-11-12)
- دستورالعمل‌های فرستنده‌ی ایمیل — Google Workspace Admin Help (خوانده‌شده در 2026-11-12)
- تقویت امنیت ایمیل: الزامات جدید برای فرستنده‌های پرحجم — Microsoft Tech Community (خوانده‌شده در 2026-11-12)
- بهترین شیوه‌های فرستنده — Yahoo Sender Hub (خوانده‌شده در 2026-11-12)
- SPF، DKIM و DMARC برای یک دامنه‌ی سفارشی — Mailbox.org (خوانده‌شده در 2026-11-12)