Defaults.Exposed › رفع اشکالها › Guides
DMARC شکست میخورد اما SPF و DKIM تأیید میشوند؟ رفع Alignment (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
DMARC به بیش از یک تأیید نیاز دارد — دامنهای که SPF یا DKIM را تأیید کرد باید با دامنه From شما مطابقت داشته باشد. بیشتر ایمیلهای «SPF تأیید، DMARC شکست» SPF را روی دامنه bounce فروشنده تأیید کردند، نه دامنه شما. فقط 7.4٪ از 261,086,232 دامنه درجهبندیشده با alignment زیر یک سیاست DMARC اجرایی SPF را تأیید میکنند، بر اساس سرشماری Defaults.Exposed (2026-06-29).
رفع سریعتر از سردرگمی پیشنهاد میکند. هدر Authentication-Results را بخوانید تا ببینید کدام پا — SPF یا DKIM — روی دامنه اشتباه تأیید میشود؛ سپس یا امضای DKIM با دامنه سفارشی سرویس ارسالتان را فعال کنید (معمولاً چند CNAME، و رفعی که forwarding را تاب میآورد)، یا return-path سفارشی آن را تنظیم کنید تا SPF روی دامنه شما تأیید شود. یک پای همراستا تمام چیزی است که DMARC نیاز دارد.
چطور DMARC میتواند شکست بخورد وقتی SPF و DKIM هر دو تأیید میشوند؟
چون DMARC هرگز نمیپرسد «آیا SPF تأیید شد؟» بلکه میپرسد: آیا SPF یا DKIM برای دامنهای که با آدرس From که گیرندهتان میبیند مطابقت دارد تأیید شد؟ این شرط اضافی alignment نام دارد، و این نقطه اصلی DMARC است — بدون آن، هر کسی میتوانست SPF را روی دامنهای که خودش دارد تأیید کند در حالی که دامنه شما را در هدر From نشان میدهد.
هر بررسی یک دامنه متفاوت را احراز هویت میکند:
| بررسی | دامنهای که واقعاً ارزیابی میکند | کجا میتوان دید |
|---|---|---|
| SPF | Return-Path (RFC5321.MailFrom، آدرس bounce/envelope-from) — نه هدر From | smtp.mailfrom= در Authentication-Results |
| DKIM | دامنه در تگ d= امضا — هر چیزی که امضاکننده انتخاب کرد | header.d= در Authentication-Results |
| DMARC | دامنه هدر From شما — و نیاز دارد دامنه SPF یا d= DKIM با آن مطابقت داشته باشد | header.from= در Authentication-Results |
این نحوه معمول اشتباه رفتن قطعات است: پلتفرم خبرنامه یا CRM شما با یک Return-Path مثل [email protected] ارسال میکند، SPF در مقابل vendor.com بررسی میشود و تأیید میشود، DKIM با d=vendor.com تأیید میشود — و DMARC شکست میخورد، چون هیچکدام از دامنههای تأیید شده با yourcompany.com مطابقت ندارند. هر بررسی حقیقت را گفت؛ هیچکدام شما را احراز هویت نکردند. ویرایش رکورد SPF خودتان نمیتواند این را رفع کند — هرگز مشورت نشد. این همان تلهای است که در SPF برای ابزارهای SaaS شما شکست میخورد پوشش داده شده است.
سرشماری نشان میدهد چه تعداد کمی از فرستندهها این گام آخر را کامل میکنند: 27,640,987 از 261,086,232 دامنه درجهبندیشده (10.59٪) اصلاً یک سیاست DMARC اجرایی دارند، و فقط 7.4٪ با alignment زیر یکی SPF را تأیید میکنند. در میان 77.5 میلیون دامنهای که SPF آنها به softfail ختم میشود (~all)، فقط 9.2٪ زیر یک سیاست DMARC اجرایی هستند؛ در میان ناشران hardfail (-all)، 12,142,351 اجرایی هستند در حالی که 42,514,532 نیستند. بیشتر دامنهها در «SPF تأیید میشود» میمانند — که بدون عمل DMARC روی آن، تقریباً هیچچیز را محافظت نمیکند.
چطور Authentication-Results را بخوانم تا ببینم کدام پا همراستا نیست؟
از طریق سرویس شکست خورده برای خودتان یک پیام ارسال کنید، منبع خام را باز کنید، و هدر Authentication-Results را پیدا کنید. یک نتیجه معمول همراستا نشده اینطور به نظر میرسد:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounces.espmail.net;
dkim=pass header.d=espmail.net;
dmarc=fail (p=NONE) header.from=yourcompany.com
آن را در سه مقایسه بخوانید:
- پای SPF: آیا
smtp.mailfrom=به دامنه شما ختم میشود؟ اینجاbounces.espmail.netاست — همراستا نیست. - پای DKIM: آیا
header.d=به دامنه شما ختم میشود؟ اینجاespmail.netاست — همراستا نیست. - حکم DMARC:
header.from=دامنهای است که DMARC از آن دفاع میکند. هیچکدام از پاها با آن مطابقت نداشتند، پسdmarc=fail— حتی اگر هر دو بررسی فردیpassبگویند.
هر پایی که قبلاً دامنه خودتان را درگیر میکند (یا میتواند) پایی است که باید رفع کنید. فقط به یکی نیاز دارید.
تفاوت بین alignment relaxed و strict چیست؟
DMARC دو حالت تطابق ارائه میدهد، با تگهای aspf (SPF) و adkim (DKIM) در رکورد DMARC تنظیم میشوند:
- Relaxed (
r، پیشفرض): دو دامنه باید دامنه سازمانی یکسانی داشته باشند — دامنه قابل ثبت بر اساس Public Suffix List.bounce.yourcompany.comباyourcompany.comهمراستا میشود؛ یک DKIMd=mail.yourcompany.comنیز همینطور. به همین دلیل return-path های سفارشی و DKIM سفارشی فروشنده، که روی زیردامنهها زندگی میکنند، کار میکنند. - Strict (
s): دامنهها باید دقیقاً مطابقت داشته باشند، کاراکتر به کاراکتر.bounce.yourcompany.comدیگر باyourcompany.comهمراستا نیست.
اگر رکورد شما به aspf یا adkim اشاره نمیکند، در حالت relaxed هستید — و تقریباً مطمئناً میخواهید همانجا بمانید. حالت strict هیچ امنیت معناداری برای بیشتر فرستندهها اضافه نمیکند و هر فرستنده زیردامنه قانونی که تنظیم کردهاید را بیصدا خراب میکند. اگر DMARC شکست میخورد و رکورد شما aspf=s یا adkim=s دارد، این تنها میتواند باگ باشد.
چطور DMARC alignment را رفع کنم؟
۱. قبل از لمس DNS، اسکن رایگان در defaults.exposed را اجرا کنید. رکورد و سیاست DMARC، اینکه SPF و DKIM برای alignment تنظیم شدهاند، و چه چیز دیگری شکسته را نشان میدهد — پس ابتدا پای صحیح را رفع کنید.
۲. هر سرویس ارسال را آزمایش کنید و Authentication-Results آن را بخوانید (مثل بالا). هر منبع را فهرست کنید — ارائهدهنده صندوق پستی، ابزار خبرنامه، CRM، اپلیکیشن صدور فاکتور — و برای هر منبع یادداشت کنید آیا smtp.mailfrom و header.d دامنه شما هستند یا دامنه فروشنده.
۳. امضای DKIM با دامنه سفارشی را برای هر فروشنده فعال کنید — رفعی که دوام میآورد. هر سرویس ارسال جدی «domain authentication» ارائه میدهد: چند رکورد CNAME که اجازه میدهد به عنوان d=yourcompany.com امضا کند (یا یک زیردامنه که در حالت relaxed همراستا میشود). DKIM همراستا معمولاً رفع آسانتری است و تنها چیزی است که forwarding را تاب میآورد، چون forwarding SPF را طراحاً خراب میکند.
۴. برای SPF alignment، return-path سفارشی فروشنده را فعال کنید (اغلب دامنه bounce سفارشی نامیده میشود) — معمولاً یک CNAME مثل bounce.yourcompany.com که به فروشنده اشاره میکند. SPF سپس روی دامنه سازمانی شما تأیید میشود و همراستا میشود. این را جایی که ارائه میشود انجام دهید، اما آن را به عنوان پای دوم در نظر بگیرید، نه جایگزین DKIM همراستا.
۵. alignment را در حالت relaxed بگذارید مگر اینکه دلیل خاص و مشخصی برای aspf=s/adkim=s دارید.
۶. دوباره اسکن کنید و هر دو پا را تأیید کنید، سپس به سمت enforcement حرکت کنید. یک سیاست DMARC با p=none گزارش میدهد اما چیزی را بلوک نمیکند؛ وقتی فرستندههای واقعی شما همراستا شدند، مسیر کامل به سیاستی که از شما محافظت میکند در صفحه رفع DMARC است، و راهنماهای ارائهدهنده مثل DMARC روی IONOS کلیکهای پانل DNS را پوشش میدهند.
آیا باید SPF alignment یا DKIM alignment را رفع کنم؟
برای هر منبع ارسال به یک پای همراستا نیاز دارید. اگر فقط میتوانید یکی انجام دهید، انتخاب نزدیک نیست:
| رفع | چه چیزی در بر میگیرد | آیا forwarding را تاب میآورد؟ |
|---|---|---|
| DKIM همراستا (امضای دامنه سفارشی) | چند CNAME در پانل «domain authentication» فروشنده | بله — امضا با پیام میرود |
| SPF همراستا (return-path/bounce domain سفارشی) | یک CNAME، جایی که فروشنده ارائه میدهد | خیر — IP هر forwarder جایگزین IP فروشنده میشود |
حالت خاص ارزش دانستن: Google Workspace و Microsoft 365 ایمیل شما را به طور پیشفرض با دامنههای fallback خودشان DKIM امضا میکنند (gappssmtp.com، onmicrosoft.com) — پس DKIM pass نشان میدهد در حالی که DMARC همچنان شکست میخورد. این رایجترین مثال خاص از کل این مشکل است، و راهنمای خودش را دارد: DKIM تأیید میشود اما DMARC همچنان شکست میخورد: تله امضای پیشفرض.
پرسشهای متداول
آیا هر دو SPF و DKIM باید برای تأیید DMARC همراستا باشند؟ خیر — یک تأیید همراستا کافی است. بهترین روش این است که هر دو را به هر حال همراستا کنید، تا وقتی forwarding پای SPF را خراب میکند، پای DKIM همچنان تأیید DMARC را حمل کند. از 261,086,232 دامنه درجهبندیشده در سرشماری 2026-06-29، فقط 3.87٪ سهگانه کامل SPF + DMARC + DKIM را تکمیل میکنند.
داشبورد ESP من میگوید SPF و DKIM «verified» هستند — چرا DMARC همچنان شکست میخورد؟ «Verified» معمولاً به این معنی است که ارسال خود فروشنده روی دامنههای فروشنده تأیید میشود. مگر اینکه مراحل دامنه سفارشی آنها را کامل کرده باشید (CNAME های DKIM، return-path سفارشی)، ایمیل به عنوان فروشنده احراز هویت میشود، نه به عنوان شما — و DMARC در مقابل دامنه From شما مقایسه میکند.
آیا یک رکورد SPF سختگیرانه -all بدون alignment کافی است؟
خیر. یک qualifier سختگیرانه حکم SPF را روی دامنه Return-Path تقویت میکند، اما DMARC همچنان نیاز دارد آن دامنه دامنه شما باشد. تا سرشماری 2026-06-29، فقط 12,142,351 از دامنههایی که -all منتشر میکنند زیر یک سیاست DMARC اجرایی هستند — 42,514,532 دیگر یک رکورد سختگیرانه دارند که هیچ سیاستی روی آن عمل نمیکند.
آیا باید به alignment سختگیرانه (aspf=s/adkim=s) برای امنیت بیشتر تغییر دهم؟
تقریباً هرگز. alignment relaxed قبلاً همان دامنه قابل ثبت را نیاز دارد، که یک جعلکننده کنترل نمیکند. حالت strict بیشتر فرستندههای زیردامنه خودتان را خراب میکند — وقتی alignment به طور غیرمنتظرهای شکست میخورد، آن را بررسی کنید.
DMARC فقط روی ایمیلهایی که گیرندهها forward میکنند شکست میخورد — همان رفع؟ این پای SPF است که در حین انتقال میمیرد: سرور forwarder در رکورد SPF هیچکس برای return-path شما نیست. نمیتوانید SPF را برای ایمیلهای forwarded رفع کنید؛ DKIM همراستا جواب است، چون امضا forwarding را سالم تاب میآورد. جزئیات در ایمیل forwarded شده SPF را شکست میدهد.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. اسکن رایگان را بعد از نشست CNAME ها دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، نشاندهنده SPF، DKIM و DMARC همراستا و در حال تأیید. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده نیاز دارند — اثبات یک پیکربندی کارآمد، نه فقط «چند رکورد DNS اضافه کردم».
دامنهتان را بررسی کنید ← · DKIM تأیید میشود اما DMARC همچنان شکست میخورد ← · رفع DMARC ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.