DKIM يفشل بعد تبديل أدوات البريد: دليل ترحيل CNAME والمُحدِّد (2026)

نُشر 2026-07-08

الأرقام بتاريخ 2026-06-29 · المنهجية v7. بيانات إحصاء مجمّعة عبر 261 مليون نطاق مُصنَّف. اطلع على طريقة التصنيف.

DKIM ينكسر بعد تبديل الأداة لسببَين ميكانيكيَّين: لوحة DNS الخاصة بك شوَّهت أهداف CNAME الخاصة بالأداة الجديدة — عادةً بإلصاق منطقتك الخاصة — أو مُحدِّدات الأداة القديمة أُزيلت قبل استنزاف بريدها. 3.87% فقط من النطاقات — 10,092,481 — يُكمل ثلاثية SPF+DKIM+DMARC، وفقاً لإحصاء Defaults.Exposed لـ 261,086,232 نطاق مُصنَّف.

ترتيب الإصلاح: افحص النطاق، ثم افحص الهدف المخزَّن لكل CNAME جديد بـ dig — هدف ينتهي باسم نطاقك الخاص هو الدليل القاطع. أصلح السجلات عند خوادم الاسم التفويضية، أكّد أن الأداة الجديدة تُوقِّع وتنجح قبل توجيه بريد حقيقي عبرها، وابقِ مُحدِّدات الأداة القديمة منشورة حتى استنزاف حركتها.

لماذا انكسر DKIM حين بدّلت الأدوات؟

لم يتغير في DKIM نفسه شيء — مُحدِّداتك تغيّرت. الأداة القديمة تُوقِّع بمُحدِّداتها؛ الجديدة تُوقِّع بمُحدِّدات مختلفة، مُفوَّضة عادةً عبر سجلَين أو ثلاثة CNAMEs تُضاف أثناء الإعداد. أربعة مزالق تُفسِّر تقريباً كل إخفاق DKIM بعد الترحيل:

لوحة DNS ألصقت منطقتك بهدف CNAME. كثير من اللوحات تُعامل أي اسم مضيف مُلصَق كاسم نسبي وتخزِّن target.provider.com.yourdomain.com بدلاً من target.provider.com بصمت. السجل موجود، اللوحة تُظهر علامة اختيار خضراء، ولا يُحلّ إلى شيء.
إرباك النقطة الإنهائية. بعض اللوحات تشترط نقطة إنهائية (target.provider.com.) لتعني “مطلق — أوقف إلصاق منطقتي”؛ أخرى ترفض النقطة كغير صالحة وتتعامل مع الإطلاق بنفسها. نفس القيمة الملصوقة صحيحة في لوحة ومشوَّهة في أخرى.
مُحدِّدات الأداة القديمة حُذفت يوم التبديل. البريد الذي وقَّعته الأداة القديمة يجلس في طوابير الإعادة ومسارات التوجيه لأيام؛ إزالة مُحدِّداتها — أو إغلاق الحساب القديم الذي يقتل CNAMEs المُفوَّضة — يكسر ذلك البريد بأثر رجعي.
التحقق تمَّ عند خوادم الاسم الخاطئة. إن اشتمل الترحيل على تغيير خوادم الاسم، السجلات المُصحَّحة قد توجد عند مجموعة NS واحدة بينما المستقبِلون لا يزالون يستعلمون الأخرى.

51.84% فقط من 261 مليون نطاق في الإحصاء يُقدِّم مفتاح DKIM قابلاً للاكتشاف وقت الفحص (البيانات بتاريخ 2026-06-29).

نفس الترحيل عادةً ما يُخلِّف حطاماً في SPF أيضاً — 1,013,416 نطاق، تقريباً 1 من كل 138 ممن يُحاوِلون SPF، يشغّلون سجلَي v=spf1، العلامة الكلاسيكية على أن تبديل مزوّد أضاف سجلاً بدلاً من دمجه. لذلك الجانب من الانتقال دليله الخاص: SPF توقف عن العمل بعد تبديل مزوّد البريد.

كيف أكتشف سجل CNAME مشوَّهاً؟

لا تثق باللوحة — اسأل DNS ما خزَّنه فعلاً. استعلم عن هدف CNAME لكل مُحدِّد أعطتك إياه الأداة الجديدة. مثال توضيحي يحاكي مُحدِّداً مُفوَّضاً بأسلوب SendGrid (شكل هدف مزوّدك سيختلف):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

المزوّد طلب s1.domainkey.u1234567.wl123.sendgrid.net — لكن الهدف المخزَّن ينتهي بـ .yourdomain.com. اللوحة ألصقت المنطقة؛ ذلك الاسم لا يُحلّ إلى شيء فلا يجد المستقبِلون مفتاحاً. النسخة السليمة:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(نقطة إنهائية واحدة في مخرجات dig طبيعية — تُشير إلى اسم مُؤهَّل بالكامل.) إن كان الهدف صحيحاً، تابعه خطوة واحدة: dig TXT s1._domainkey.yourdomain.com +short يجب أن يُعيد مفتاح المزوّد. إجابة فارغة مع CNAME صحيح تعني المشكلة في جانب المزوّد من التفويض — أتمَّ خطوة التحقق الخاصة به، أو انظر DKIM “لا مفتاح للتوقيع” للتشخيص على مستوى المُحدِّد.

إجراء الترحيل: قبل وأثناء وبعد

الإخفاق عادةً ليس في السجلات — بل في الترتيب. ترحيلات DKIM تسوء عند الإطلاق لأن التحقق يحدث بعد التبديل، حين البريد الحقيقي يفشل بالفعل.

المرحلة	ما تفعله	الشرط قبل المضي قدماً
قبل التبديل	أضف CNAMEs لـ DKIM الخاصة بالأداة الجديدة (وسجلات نطاق الارتداد)، ثم أثبتها: `dig` لهدف كل CNAME المخزَّن من خارج شبكتك، أتمَّ خطوة تحقق الأداة الخاصة بها، وأرسل اختباراً عبر الأداة الجديدة إلى صندوق بريد تتحكم فيه	رسالة الاختبار تُظهر `dkim=pass` مع `d=` = نطاقك — لا توجِّه بريداً حقيقياً عبر أداة غير مُتحقَّق منها أبداً
يوم التبديل	انقل الحركة الحقيقية إلى الأداة الجديدة. لا تلمس شيئاً يخص الأداة القديمة: ابقِ مُحدِّداتها وCNAMEs وحساباتها حيّة	بريد الأداة الجديدة ينجح عند المستقبِلين الحقيقيين؛ الأداة القديمة تستمر في النجاح لأي شيء لا يزال يتدفق عبرها
بعد الاستنزاف	راقب تقارير DMARC المجمَّعة حتى تتوقف مُحدِّدات الأداة القديمة عن الظهور (طوابير الإعادة والتوجيهات تعمل لأيام — اسمح بأسبوع أو أكثر)، ثم أبطل سجلاتها وحسابها	المُحدِّدات القديمة غائبة من التقارير ≥ 7 أيام قبل الإزالة

السطر بالخط العريض هو حيث تُنقَذ الترحيلات أو تُخسَر: كل فحص فيه يمكن إجراؤه قبل أيام من الإطلاق، بصفر خطر على البريد الحي. ميكانيكية إبطال المُحدِّدات — بما في ذلك لماذا إعادة النشر بـ p= فارغ أفضل من الحذف — مُغطاة في إجراء التدوير؛ هذا الجدول عن تسلسل تبديل الأداة نفسه.

كيف أُصلح DKIM بعد التبديل؟

شغّل الفحص المجاني على defaults.exposed قبل أن تلمس DNS. يقرأ سجلاتك الحية ويُظهر ما يراه المستقبِلون فعلاً — بما في ذلك أهداف CNAME الملصَق بها المنطقة والمُحدِّدات التي لا تُحلّ.
أدرج سجلات DKIM التي تتوقعها الأداة الجديدة. من لوحة إدارتها — لمزوّدي صناديق البريد، أدلة إعداد Google Workspace وMicrosoft 365 تُظهر أين؛ أدوات النشرات وCRM تسرد CNAMEs الخاصة بها تحت مصادقة النطاق (انظر رسائل Mailchimp/Brevo/Klaviyo الفاشلة في DMARC).
افحص القيمة المخزَّنة لكل سجل بـ dig CNAME <name> +short وقارنها حرفاً بحرف بما طلبته الأداة. هدف ينتهي بنطاقك الخاص = إلصاق منطقة؛ أعد إدخاله، وإن استمرت اللوحة في الإلصاق، أضف النقطة الإنهائية (أو أزلها، إن كانت اللوحة ترفض النقاط).
تحقق عند خوادم الاسم التفويضية. dig +short NS yourdomain.com، ثم كرر فحوصات CNAME @<ذلك_الخادم>. إن غيَّر الترحيل خوادم الاسم، افحص كلتا المجموعتَين — المستقبِلون قد لا يزالون يستعلمون القديمة حتى انتشار التفويض.
أعد تشغيل تحقق الأداة وأرسل رسالة اختبار. يجب أن تُظهر ترويسة Authentication-Results dkim=pass مع d= مساوياً لنطاقك — النجاح على النطاق الافتراضي للأداة لا يتوافق مع DMARC.
ابقِ مُحدِّدات الأداة القديمة منشورة حتى استنزاف بريدها، ثم أبطلها بوعي. ثم أعد الفحص واعمل على أي شيء آخر يُشير إليه في صفحة إصلاح DKIM.

الأسئلة الشائعة

هل أحتاج النقطة الإنهائية على CNAME لـ DKIM أم لا؟ يعتمد كلياً على اللوحة. النقطة تعني “اسم مطلق — لا تلصق منطقتي”؛ بعض اللوحات تشترطها، بعضها يضيفها بنفسه، بعضها يرفضها. الاختبار الوحيد المهم هو مخرجات dig CNAME <selector>._domainkey.yourdomain.com +short بعد الحفظ: إن انتهى الهدف بنطاقك الخاص، اللوحة ألصقت المنطقة وتحتاج النقطة (أو صيغة إدخال مختلفة).

هل يمكنني حذف سجلات DKIM للأداة القديمة يوم التبديل؟ لا. البريد الذي وقَّعته الأداة القديمة لا يزال في طوابير الإعادة ومسارات التوجيه، وحذف المفتاح الذي تشير إليه يكسر تلك الرسائل بأثر رجعي. ابقِ المُحدِّدات القديمة حيّة حتى تتوقف عن الظهور في تقارير DMARC المجمَّعة — أسبوع أو أكثر — ولا تُغلق الحساب القديم قبل ذلك أيضاً.

لوحتي والأداة الجديدة تقولان “مُتحقَّق منه”، لكن المستقبِلين لا يزالون يُخفقون في DKIM. كيف؟ حالتان شائعتان: الأداة تحقّقت مقابل فحص مخزَّن مؤقتاً بينما خوادم الاسم التفويضية تخدم شيئاً آخر (استعلمها مباشرةً بـ dig @<ns>)، أو DKIM ينجح لكن على نطاق توقيع افتراضي للأداة لا نطاقك، فلا يزال DMARC يفشل في التوافق. الفحص يُميِّز بين الحالتَين.

هل يمكن لسجلات DKIM لكلتا الأداتَين التعايش خلال فترة التداخل؟ نعم — ويجب ذلك. DKIM لا توجد فيه قاعدة السجل الواحد: كل مُحدِّد هو اسم DNS خاص به، فسجلات كلتا الأداتَين تتعايش جانباً لبعض بلا تعارض، مما يجعل قاعدة إبقاء المُحدِّدات القديمة خلال الاستنزاف متاحة للاتباع بلا تكلفة. (SPF هو النقيض — سجلَا v=spf1 يُبطلانه، ولهذا دليل ترحيل SPF عن الدمج.)

أرسل للمالك التقرير

إن كنت تُشغِّل هذا الترحيل لعميل أو صاحب عمل، أغلقه بالدليل. بمجرد توقيع الأداة الجديدة وتوافقها، أعد الفحص المجاني وأرسل التقرير المُصنَّف لصاحب العمل: دليل مؤرَّخ بلغة بسيطة أن التبديل ترك النطاق موثَّقاً بالكامل. هذه هي الوثيقة التي يحتاجها لتجديد تأمين الإنترنت واستبيان أمان المورد القادم — تحوّل “الترحيل انتهى” من ادعاء إلى وثيقة.

افحص DKIM مجاناً

اعرف هل مُحدِّدات أداتك الجديدة تُحلّ — وما الذي يجب إصلاحه بالضبط — بخصوصية تامة ومقتصرة على المالك.

افحص نطاقك ← · SPF انكسر بعد تبديل المزوّد ← · إصلاح DKIM ← · إعداد DKIM على Google Workspace ← · بيانات إجمالية فقط. البيانات مخزّنة ومعالَجة في الاتحاد الأوروبي.