Defaults.Exposed › رفع اشکالها › Guides
DKIM تأیید میشود اما DMARC شکست میخورد: تله امضای پیشفرض gappssmtp.com / onmicrosoft.com (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
ایمیل شما با امضای پیشفرض ارائهدهنده DKIM را تأیید میکند — d= که به gappssmtp.com (Google Workspace) یا onmicrosoft.com (Microsoft 365) ختم میشود — اما آن دامنه با دامنه From شما مطابقت ندارد، پس DMARC هیچ تأیید همراستایی دریافت نمیکند. امضای با دامنه سفارشی را فعال کنید تا رفع شود. از 12,145,313 دامنهای که سرورهای ایمیل Google را مجاز میدانند، فقط 18.5٪ DMARC را اجرا میکنند، بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه درجهبندیشده.
رفع یکی از تمیزترین رفعها در احراز هویت ایمیل است: امضای DKIM با دامنه سفارشی را روشن کنید. در Google Workspace این صفحه «Authenticate email» Admin console است — کلید را ایجاد کنید، یک رکورد TXT منتشر کنید، روشن کنید. در Microsoft 365 صفحه DKIM پورتال Defender است — دو CNAME انتخابگر را منتشر کنید، فعال کنید. بیست دقیقه کار، و DMARC بالاخره تأیید همراستایی که منتظرش بود را دریافت میکند.
چرا DKIM تأیید میشود اما DMARC همچنان شکست میخورد؟
چون DMARC نمیپرسد «آیا یک امضای DKIM معتبر وجود دارد؟» — بلکه میپرسد «آیا یک امضای DKIM معتبر برای دامنه در هدر From وجود دارد؟» آن شرط دوم alignment نامیده میشود، و این کل هدف DMARC است: اثبات اینکه دامنهای که گیرندهتان میبیند دامنهای است که امضا کرده.
از ابتدا، Google Workspace ایمیل شما را با یک دامنه مثل yourdomain-com.20230601.gappssmtp.com امضا میکند (تمبر تاریخ برای هر دامنه متفاوت است) و Microsoft 365 با yourtenant.onmicrosoft.com امضا میکند. هر دو امضا از نظر رمزنگاری معتبر هستند — ابزارهای بررسی DKIM pass میگویند — اما دامنه d= متعلق به Google یا Microsoft است، نه شما. حتی تحت alignment relaxed DMARC که فقط نیاز دارد دامنههای سازمانی مطابقت داشته باشند، gappssmtp.com برابر yourdomain.com نیست. هیچ تطابقی، هیچ تأیید همراستایی، و اگر SPF نیز همراستا نباشد (اغلب نمیتواند — گیرندهها SPF را در مقابل دامنه Return-Path ارزیابی میکنند، نه هدر From، و forwarding آن را کاملاً خراب میکند)، DMARC شکست میخورد.
این تله تعریفکننده پیشفرضهای ارائهدهنده است: پیشفرض به شما تحویلپذیری میدهد، نه محافظت — alignment نقطه مفقود چرخش کلید است. سرشماری نشان میدهد چه تعداد فرستنده در پیشفرض میمانند: از 12,145,313 دامنهای که سرورهای ایمیل Google را از طریق _spf.google.com مجاز میدانند (از 138,927,207 ناشر SPF در جهان)، فقط 18.5٪ DMARC را اجرا میکنند. تصویر Microsoft همان شکل را دارد: 10,205,070 دامنه spf.protection.outlook.com را مجاز میدانند، 85.0٪ رکورد SPF سختگیرانهای دارند که تنظیم M365 به آنها میدهد — و فقط 21.7٪ DMARC را اجرا میکنند. مقایسه کامل در جدول SPF ارائهدهندگان ایمیل ما.
تله در استفاده روزمره نامرئی است: ایمیل تحویل میشود، تستهای inbox خوب به نظر میرسند، هیچ خطایی نمیدهند — تا وقتی که یک سیاست DMARC منتشر کنید و ایمیل خودتان شروع به شکست خوردن در آن کند. اسکن رایگان ما دقیقاً این شکاف را آشکار میکند.
چطور تله امضای پیشفرض را در Authentication-Results تشخیص دهم؟
یک پیام ارسال شده (به یک صندوق Gmail یا Outlook) را باز کنید، منبع اصلی/خام را مشاهده کنید، و هدر Authentication-Results را پیدا کنید. نشانه یک pass DKIM با d= اشتباه است — یک مثال دریافت شده توسط Gmail اینطور به نظر میرسد:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass smtp.mailfrom=yourdomain.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com
آن را به عنوان سه سؤال بخوانید:
| قطعه هدر | به چه معناست | حکم |
|---|---|---|
dkim=pass header.d=yourdomain.com | امضا معتبر است AND با دامنه From شما مطابقت دارد | همراستا — این هدف است |
dkim=pass header.d=…gappssmtp.com یا …onmicrosoft.com | امضا معتبر است اما دامنه پیشفرض ارائهدهنده است — DMARC آن را برای alignment نادیده میگیرد | تله: pass بدون محافظت |
dkim=fail (هر d=) | امضا نامعتبر است — مشکل دیگری | چطور DKIM را رفع کنیم را ببینید |
در ایمیل دریافت شده توسط Microsoft، همان داستان به عنوان dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com در کنار compauth=fail ظاهر میشود — الگویی که در راهنمای ریجکت Outlook پوشش داده شده است.
اگر هدر شما به جای آن هم dkim=pass و هم spf=pass را با یک شکست DMARC نشان میدهد، در حالت کلیتر alignment هستید — راهنمای DMARC شکست میخورد اما SPF و DKIM تأیید میشوند relaxed در مقابل strict alignment را به طور کامل توضیح میدهد.
چطور امضای DKIM با دامنه سفارشی را فعال کنم؟
۱. قبل از لمس هر چیزی، اسکن رایگان در defaults.exposed را اجرا کنید. نشان میدهد آیا دامنه شما DKIM همراستا دارد، سیاست DMARC شما واقعاً چیست، و آیا چیز دیگری (SPF، syntax رکورد DMARC) همچنان بعد از این رفع شما را بلوک میکند — پس کل کار را یکبار انجام دهید.
۲. مشخص کنید با کدام پیشفرض امضا میکنید. header.d= را در Authentication-Results مثل بالا بررسی کنید: gappssmtp.com به معنای پیشفرض Google Workspace است، onmicrosoft.com به معنای پیشفرض Microsoft 365.
۳. Google Workspace: کلید خودتان را ایجاد و منتشر کنید. در Admin console به Apps → Google Workspace → Gmail → Authenticate email بروید، دامنهتان را انتخاب کنید و روی Generate New Record کلیک کنید (2048-bit مگر اینکه host DNS شما نمیتواند آن را ذخیره کند). رکورد TXT که به شما میدهد را در google._domainkey.yourdomain.com منتشر کنید، منتظر DNS بمانید (تا ۴۸ ساعت)، سپس — گامی که مردم از دست میدهند — Start authentication را کلیک کنید. ایجاد رکورد هیچ کاری نمیکند تا امضا را روشن کنید. راهنمای کامل: تنظیم DKIM روی Google Workspace.
۴. Microsoft 365: دو CNAME انتخابگر را منتشر و فعال کنید. در پورتال Defender به Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM بروید، دامنه سفارشیتان را انتخاب کنید و کلیدها را ایجاد کنید. هر دو CNAME را منتشر کنید — selector1._domainkey و selector2._domainkey، اشارهکننده به اهدافی که Microsoft به شما نشان میدهد (اهداف دقیق را از پورتال کپی کنید — دامنههای فعال شده قبل از مه ۲۰۲۵ به .onmicrosoft.com تنانت شما ختم میشوند؛ جدیدترها به .dkim.mail.microsoft ختم میشوند) — سپس امضا را روشن کنید. دو انتخابگر اختیاری نیست: Microsoft کلیدها را بین آنها میچرخاند. راهنمای کامل: تنظیم DKIM روی Microsoft 365.
۵. امضای جدید را تأیید کنید. یک پیام تازه به یک صندوق خارجی ارسال کنید و Authentication-Results را دوباره بررسی کنید: dkim=pass اکنون باید header.d=yourdomain.com نشان دهد. اگر پانل DNS شما به طور خودکار zone را به هدف CNAME اضافه کرد یا مقدار TXT طولانی را خراب کرد، امضا سوئیچ نمیکند — ایرادات پانل، نه ارائهدهنده، بیشتر شکستها اینجا ایجاد میشوند.
۶. دوباره اسکن کنید و تأیید همراستا را جایی ببرید. تأیید کنید اسکن DKIM همراستا را نشان میدهد، سپس از آن استفاده کنید: یک سیاست DMARC با p=none هیچچیز را محافظت نمیکند. در تمام 261,086,232 دامنه درجهبندیشده، فقط 10.59٪ DMARC را اجرا میکنند (دادهها تا 2026-06-29) — DKIM همراستا چیزی است که enforcement را ایمن میکند. از چطور DMARC را رفع کنیم شروع کنید.
آیا فعال کردن DKIM سفارشی چیزی را خراب میکند؟
خیر — این رفع نادر احراز هویت ایمیل با اساساً هیچ شعاع انفجاری است: ایمیلی که با امضای پیشفرض خارج میشد فقط با یک بهتر خارج میشود، و ارائهدهنده همچنان مدیریت کلیدها را انجام میدهد (Microsoft به طور خودکار در دو انتخابگر میچرخاند). حالت شکست واقعی نیمهکاره انجام دادن است — TXT Google را منتشر کردن اما هرگز Start authentication را کلیک نکردن، یا یک انتخابگر M365 به جای هر دو منتشر کردن. و بعداً رکوردهای DNS را «برای تمیز کردن» حذف نکنید؛ امضا لحظهای که کلید ناپدید میشود متوقف میشود.
یک نکته در مورد محدوده: این ایمیل ارسال شده از طریق Google یا Microsoft را رفع میکند. ابزارهای خبرنامه و CRM نیز با پیشفرضهای خودشان امضا میکنند، و هر کدام باید DKIM سفارشی دامنه خودشان را روشن کنند — این الگو، و قوانین فرستنده انبوه Gmail که اکنون آن را الزامی میکنند، در راهنمای 550-5.7.26 پوشش داده شده است.
پرسشهای متداول
DKIM در هر ابزار آزمایشی «pass» نشان میدهد — چرا چیزی نیاز به رفع دارد؟
چون ابزارها سؤال محدودتری نسبت به DMARC میپرسند. امضا معتبر است — اما متعلق به gappssmtp.com یا onmicrosoft.com است، نه شما، پس در alignment DMARC هیچ اهمیتی ندارد. به همین دلیل است که بسیاری از فرستندهها در پیشفرض میمانند: از 12,145,313 دامنهای که Google را مجاز میدانند، فقط 18.5٪ DMARC را اجرا میکنند (دادهها تا 2026-06-29).
آیا alignment relaxed DMARC اجازه میدهد امضای پیشفرض تأیید شود؟
خیر. alignment relaxed فقط تطابق را به دامنههای سازمانی شل میکند — mail.yourdomain.com با yourdomain.com همراستا میشود. دامنه سازمانی امضای پیشفرض gappssmtp.com یا onmicrosoft.com است، که هیچ اشتراکی با دامنه شما ندارد. هیچ حالت alignment یک d= شخص ثالث را نجات نمیدهد.
آیا امضای gappssmtp.com / onmicrosoft.com بد است؟ آیا باید آن را حذف کنم؟ بد نیست — اطمینان میدهد ایمیل شما یک امضای معتبر دارد، که به فیلتر اسپم کمک میکند. فقط مال شما نیست. آن را حذف نمیکنید؛ با فعال کردن امضای دامنه سفارشی آن را جایگزین میکنید.
دامنه من روی Microsoft 365 با SPF سختگیرانه است — آیا قبلاً پوشش داده شدهام؟
احتمالاً نه: آن رکورد سختگیرانه پیشفرض M365 است که کار خودش را میکند. از 10,205,070 دامنهای که spf.protection.outlook.com را مجاز میدانند، 85.0٪ SPF سختگیرانه دارند اما فقط 21.7٪ DMARC را اجرا میکنند (دادهها تا 2026-06-29). SPF همچنین در forwarding خراب میشود، چون در مقابل Return-Path ارزیابی میشود نه هدر From — DKIM همراستا پایی است که دوام میآورد، که دقیقاً همین است که این رفع اهمیت دارد.
رفع چقدر طول میکشد؟ کار console دقایقی برای هر ارائهدهنده. DNS انتظار است: Google میگوید تا ۴۸ ساعت قبل از شروع احراز هویت صبر کنید؛ CNAME های Microsoft معمولاً در چند ساعت زنده هستند. برای کل فرآیند یک روز کاری را در نظر بگیرید، بیشتر آن صبر کردن.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. وقتی امضای جدید زنده است اسکن رایگان را دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، نشاندهنده DKIM همراستا با دامنه آنها. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده نیاز است — اثبات اینکه دامنه به عنوان خودش احراز هویت میکند، نه به عنوان یک زیرمستأجر gappssmtp.com.
DKIM alignment خود را رایگان بررسی کنید
ببینید ایمیل شما با دامنه خودتان امضا میشود — و دقیقاً چه چیزی باید رفع شود — به صورت خصوصی و فقط برای صاحب.
دامنهتان را بررسی کنید ← · DMARC شکست میخورد اما SPF و DKIM تأیید میشوند ← · رفع DKIM ← · تنظیم DKIM روی Google Workspace ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.