Defaults.Exposed › رفع اشکالها › Guides
DKIM بعد از تغییر ابزارهای ایمیل شکست میخورد: راهنمای مهاجرت CNAME و انتخابگر (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
DKIM بعد از تغییر ابزار به دو دلیل مکانیکی خراب میشود: پانل DNS شما هدفهای CNAME ابزار جدید را خراب کرده — معمولاً با اضافه کردن zone خودتان — یا انتخابگرهای ابزار قدیمی قبل از تخلیه ایمیل آن حذف شدند. فقط 3.87٪ از دامنهها — 10,092,481 — سهگانه SPF+DKIM+DMARC را تکمیل میکنند، بر اساس سرشماری Defaults.Exposed از 261,086,232 دامنه درجهبندیشده.
ترتیب رفع: دامنه را اسکن کنید، سپس هدف ذخیره شده هر CNAME جدید را با dig بررسی کنید — یک هدف که به نام دامنه خودتان ختم میشود نشانه قطعی است. رکوردها را در nameserver های authoritative تعمیر کنید، تأیید کنید ابزار جدید قبل از هدایت ایمیل واقعی از طریق آن امضا میکند و تأیید میشود، و انتخابگرهای ابزار قدیمی را تا تخلیه ترافیک آن منتشر نگه دارید.
چرا DKIM وقتی ابزار را عوض کردید خراب شد؟
هیچ چیز در مورد DKIM خودش تغییر نکرد — انتخابگرهایتان تغییر کرد. ابزار قدیمی با انتخابگرهای خودش امضا میکرد؛ ابزار جدید با انتخابگرهای متفاوت، معمولاً delegate شده از طریق دو یا سه رکورد CNAME که در طول onboarding اضافه شدند، امضا میکند. چهار مشکل تقریباً هر شکست DKIM بعد از مهاجرت را تشکیل میدهند:
۱. پانل DNS شما zone را به هدف CNAME اضافه کرد. بسیاری از پانلها هر hostname پیست شده را به عنوان relative در نظر میگیرند و به صورت خاموش target.provider.com.yourdomain.com را به جای target.provider.com ذخیره میکنند. رکورد وجود دارد، پانل یک تیک سبز نشان میدهد، و به هیچ چیز resolve نمیشود.
۲. سردرگمی trailing-dot. بعضی پانلها نیاز دارند یک trailing dot (target.provider.com.) به معنای «absolute — از اضافه کردن zone من خودداری کن»؛ دیگران dot را به عنوان نامعتبر رد میکنند و از طرف خود absolute را مدیریت میکنند. همان مقدار پیست شده در یک پانل درست است و در بعدی خراب شده.
۳. انتخابگرهای ابزار قدیمی در روز سوئیچ حذف شدند. ایمیلی که ابزار قدیمی قبلاً امضا کرده در صفهای retry و مسیرهای forwarding برای روزها مینشیند؛ حذف انتخابگرهایش — یا بستن حساب قدیمی، که CNAME های delegate شده آن را از بین میبرد — آن ایمیل را به صورت retroactive خراب میکند.
۴. در nameserver های اشتباه تأیید کردید. اگر مهاجرت شامل تغییر nameserver بود، رکوردهای رفع شده ممکن است در یک مجموعه NS وجود داشته باشند در حالی که گیرندهها هنوز دیگری را جستجو میکنند.
فقط 51.84٪ از 261 میلیون دامنه در سرشماری یک کلید DKIM قابل کشف در زمان اسکن ارائه میدهند (دادهها تا 2026-06-29).
همان مهاجرت معمولاً debris SPF هم باقی میگذارد — 1,013,416 دامنه، تقریباً ۱ در 138 از آنهایی که SPF را تلاش میکنند، دو رکورد v=spf1 اجرا میکنند، نشانه کلاسیک اینکه تغییر ارائهدهنده یک رکورد اضافه کرده به جای ادغام یکی. این طرف از اقدام راهنمای خودش را دارد: SPF بعد از تغییر ارائهدهنده ایمیل متوقف شد.
چطور یک رکورد CNAME خراب شده را تشخیص دهم؟
به پانل اعتماد نکنید — از DNS بپرسید واقعاً چه ذخیره کرده. هدف CNAME را برای هر انتخابگری که ابزار جدید داده جستجو کنید. یک مثال، تقلید از یک انتخابگر delegate شده به سبک SendGrid (شکل هدف ارائهدهنده شما متفاوت خواهد بود):
$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.
ارائهدهنده s1.domainkey.u1234567.wl123.sendgrid.net را خواست — اما هدف ذخیره شده به .yourdomain.com ختم میشود. پانل zone را اضافه کرد؛ آن نام به هیچ چیز resolve نمیشود، پس گیرندهها هیچ کلیدی پیدا نمیکنند. نسخه سالم:
$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.
(یک trailing dot در خروجی dig عادی است — یک نام fully-qualified را مشخص میکند.) اگر هدف درست است، یک hop دنبالش کنید: dig TXT s1._domainkey.yourdomain.com +short باید کلید ارائهدهنده را برگرداند. پاسخ خالی با یک CNAME درست به این معناست که مشکل در طرف ارائهدهنده delegation است — گام تأیید آنها را کامل کنید، یا برای تشخیص سطح انتخابگر DKIM «no key for signature» را ببینید.
runbook مهاجرت: قبل، در حین، بعد
شکست معمولاً رکوردها نیست — ترتیب است. مهاجرتهای DKIM در cutover خراب میشوند چون تأیید بعد از سوئیچ اتفاق میافتد، وقتی ایمیل واقعی قبلاً شکست خورده.
| مرحله | چه کاری باید کرد | Gate قبل از ادامه |
|---|---|---|
| قبل از سوئیچ | CNAME های DKIM ابزار جدید (و رکوردهای bounce-domain) را اضافه کنید، سپس آنها را اثبات کنید: dig هدف ذخیره شده هر CNAME را از خارج از شبکه، گام تأیید خود ابزار را کامل کنید، و یک آزمایش از طریق ابزار جدید به یک صندوق پستی که کنترل میکنید ارسال کنید | پیام آزمایشی dkim=pass با d= = دامنه شما نشان میدهد — هرگز ایمیل واقعی از طریق یک ابزار تأیید نشده هدایت نکنید |
| روز سوئیچ | ترافیک واقعی را به ابزار جدید منتقل کنید. هیچ چیز متعلق به ابزار قدیمی را لمس نکنید: انتخابگرها، CNAME ها و حساب آن را زنده بگذارید | ایمیل ابزار جدید در گیرندههای واقعی تأیید میشود؛ ابزار قدیمی برای هر چیزی که هنوز از طریق آن جاری است تأیید میشود |
| بعد از تخلیه | گزارشهای aggregate DMARC را تماشا کنید تا انتخابگرهای ابزار قدیمی ظاهر شدن متوقف شوند (صفهای retry و forwards برای روزها اجرا میشوند — یک هفته یا بیشتر در نظر بگیرید)، سپس رکوردها و حساب آن را بازنشسته کنید | انتخابگرهای قدیمی حداقل ۷ روز از گزارشها غایب قبل از حذف |
ردیف بولد جایی است که مهاجرتها ذخیره یا از دست میروند: هر بررسی در آن میتواند روزها قبل از cutover انجام شود، بدون هیچ ریسکی برای ایمیل زنده. مکانیک بازنشستگی انتخابگر — از جمله اینکه چرا دوباره انتشار با یک p= خالی بهتر از حذف است — در runbook چرخش پوشش داده شده؛ این جدول در مورد ترتیببندی خود سوئیچ ابزار است.
چطور DKIM را بعد از سوئیچ رفع کنم؟
۱. قبل از لمس DNS، اسکن رایگان در defaults.exposed را اجرا کنید. رکوردهای زنده شما را میخواند و نشان میدهد گیرندهها واقعاً چه میبینند — از جمله هدفهای CNAME که zone-appended شدند و انتخابگرهایی که resolve نمیشوند.
۲. رکوردهای DKIM که ابزار جدید انتظار دارد را فهرست کنید. از کنسول مدیریت آن — برای ارائهدهندگان صندوق پستی، راهنماهای تنظیم Google Workspace و Microsoft 365 نشان میدهند کجا؛ ابزارهای خبرنامه و CRM CNAME های خود را زیر domain authentication فهرست میکنند (ببینید ایمیلهای Mailchimp/Brevo/Klaviyo که DMARC شکست میخورند).
۳. مقدار ذخیره شده هر رکورد را با dig CNAME <name> +short بررسی کنید و کاراکتر به کاراکتر با آنچه ابزار خواسته مقایسه کنید. یک هدف که به دامنه خودتان ختم میشود = zone-appended؛ دوباره وارد کنید، و اگر پانل همچنان اضافه میکند، trailing dot اضافه کنید (یا آن را حذف کنید، اگر پانل dots را رد میکند).
۴. در nameserver های authoritative تأیید کنید. dig +short NS yourdomain.com، سپس بررسیهای CNAME را @<آن nameserver> تکرار کنید. اگر مهاجرت nameserver ها را تغییر داده، هر دو مجموعه را بررسی کنید — گیرندهها ممکن است تا زمانی که delegation propagate شود همچنان قدیمی را جستجو کنند.
۵. تأیید ابزار را دوباره اجرا کنید و یک پیام آزمایشی ارسال کنید. هدر Authentication-Results باید dkim=pass با d= برابر با دامنه شما نشان دهد — یک تأیید روی دامنه پیشفرض ابزار برای DMARC hمراستا نیست.
۶. انتخابگرهای ابزار قدیمی را تا تخلیه ایمیل منتشر نگه دارید، سپس آنها را عمداً بازنشسته کنید. سپس دوباره اسکن کنید، و هر چیز دیگری که در صفحه رفع DKIM پرچم میخورد را کار کنید.
پرسشهای متداول
آیا به trailing dot روی CNAME DKIM نیاز دارم یا نه؟
کاملاً بستگی به پانل دارد. dot به معنای «نام absolute — zone مرا اضافه نکن» است؛ بعضی پانلها آن را نیاز دارند، بعضی آن را برای شما اضافه میکنند، بعضی آن را رد میکنند. تنها آزمایشی که اهمیت دارد خروجی dig CNAME <selector>._domainkey.yourdomain.com +short بعد از ذخیره کردن است: اگر هدف به دامنه خودتان ختم میشود، پانل zone را اضافه کرد و به dot (یا یک فرمت ورودی متفاوت) نیاز دارید.
آیا میتوانم رکوردهای DKIM ابزار قدیمی را در روز سوئیچ حذف کنم؟ خیر. ایمیلی که ابزار قدیمی امضا کرده هنوز در صفهای retry و مسیرهای forwarding است، و حذف کلیدی که به آن اشاره میکند آن پیامها را به صورت retroactive خراب میکند. انتخابگرهای قدیمی را تا اینکه در گزارشهای aggregate DMARC ظاهر شدن متوقف شوند — یک هفته یا بیشتر — زنده نگه دارید، و حساب قدیمی را هم قبل از آن نبندید.
پانل DNS و ابزار جدید هر دو «verified» میگویند، اما گیرندهها همچنان DKIM شکست میخورد. چطور؟
دو حالت رایج: ابزار در مقابل یک بررسی cached تأیید کرده در حالی که nameserver های authoritative چیز دیگری سرو میکنند (آنها را مستقیماً با dig @<ns> جستجو کنید)، یا DKIM تأیید میشود اما روی دامنه امضای پیشفرض ابزار نه دامنه شما، پس DMARC همچنان alignment را شکست میدهد. اسکن بین این دو تمایز میگذارد.
آیا رکوردهای DKIM هر دو ابزار میتوانند در طول overlap همزیستی داشته باشند؟
بله — و باید. DKIM هیچ قانون single-record ندارد: هر انتخابگر نام DNS خودش است، پس رکوردهای هر دو ابزار کنار هم بدون تعارض زندگی میکنند، که باعث میشود قانون keep-old-selectors-through-the-drain رایگان برای پیروی باشد. (SPF برعکس است — دو رکورد v=spf1 آن را باطل میکند، که به همین دلیل راهنمای مهاجرت SPF در مورد ادغام است.)
گزارش را به صاحب ارسال کنید
اگر این مهاجرت را برای یک مشتری یا کارفرمایتان اجرا میکنید، آن را با شواهد ببندید. وقتی ابزار جدید امضا و همراستا میکند، اسکن رایگان را دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: اثبات تاریخدار، با زبان ساده که سوئیچ دامنه را کاملاً احراز هویت شده باقی گذاشته. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه امنیتی بعدی تأمینکننده نیاز دارند — «مهاجرت انجام شد» را از یک ادعا به یک سند تبدیل میکند.
DKIM خود را رایگان بررسی کنید
ببینید انتخابگرهای ابزار جدید شما resolve میشوند — و دقیقاً چه چیزی باید رفع شود — به صورت خصوصی و فقط برای صاحب.
دامنهتان را بررسی کنید ← · SPF بعد از تغییر ارائهدهنده خراب شد ← · رفع DKIM ← · تنظیم DKIM روی Google Workspace ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.