مولد مفاتيح DKIM: إعداد DNS والتحقق من التوقيع

إذا كنت تبحث عن مولد مفاتيح DKIM، فربما لا يوقع نطاقك الرسائل بعد، أو يوقعها لكن خوادم الاستقبال لا تتحقق منها بنجاح. قد تخضع الرسائل غير الموقعة لتصفية أشد. وقد يؤدي خلل DKIM إلى فشل DMARC، إلا إذا نجح SPF المتوافق. عندها قد تصل رسائل إعادة تعيين كلمات المرور والفواتير والمبيعات إلى البريد المزعج أو الحجر.

المشكلة مزعجة، لكن خطوات معالجتها غالبا أوضح مما توحي به بعض الأدلة. ينشئ مولد مفاتيح DKIM مفتاحا خاصا لنظام الإرسال ومفتاحا عاما مطابقا تنشره في DNS. تستخدم خوادم الاستقبال المفتاح العام للتحقق من التوقيع باسم نطاق التوقيع وسلامة البيانات الموقعة وفق قواعد التسوية المستخدمة. لا يثبت DKIM وحده هوية المرسل الظاهر.

إذا كنت لا تزال تبني بيئة البريد، فابدأ بدليل البريد الإلكتروني للأعمال. أما إذا كنت تستخدم نطاقك بالفعل، فيشرح هذا الدليل مخرجات مولد مفاتيح DKIM، وحجم المفتاح المناسب، ودور المحددات، وطريقة نشر السجل بعناية.

ما الذي يفعله مولد مفاتيح DKIM؟

ينشئ مولد مفاتيح DKIM زوج مفاتيح تشفير. يبقى المفتاح الخاص في نظام الإرسال لتوقيع الرسائل الصادرة. وينشر المفتاح العام في DNS تحت محدد، لتتحقق خوادم الاستقبال من توقيع DKIM في ترويسات الرسالة.

الأمر ليس سحرا. يؤدي مولد مفاتيح DKIM الجيد المهام التالية:

إنشاء مفتاح خاص يستطيع نظام الإرسال استخدامه.
استخراج المفتاح العام المطابق.
تنسيق المفتاح العام في سجل DNS من نوع TXT ينشر تحت selector._domainkey.example.com.

التحدي عادة ليس في الحسابات، بل في توافق المحدد واسم مضيف DNS وتنسيق الأسطر وإعدادات الإرسال، حتى ينجح التحقق من التوقيع في الاستخدام الفعلي.

يتيح استخدام المحددات في RFC 6376 نشر مفاتيح متعددة وتدويرها بصورة منظمة. ويشترط RFC 8301 مفاتيح RSA لا تقل عن 1024 بت، بينما تكون مفاتيح 2048 بت خيارا افتراضيا أنسب عادة. إذا كان مولد مفاتيح DKIM يوصي بمفاتيح 512 بت أو SHA-1، فاختر أداة ملائمة بدلا منه.

كيف تبدو المخرجات الصحيحة؟

يوفر مولد مفاتيح DKIM المناسب مفتاحا خاصا للتوقيع وسجلا للمفتاح العام بصيغة مناسبة لـ DNS. ينشر السجل في اسم مضيف المحدد، لا في جذر النطاق، ويحتوي الوسم p= على المفتاح العام.

الشكل المطلوب يشبه المثال التالي.

Host: tm2026._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

يمكن إنشاء الزوج محليا باستخدام OpenSSL بدلا من مولد مفاتيح DKIM على الويب، حيث قد تتعرض بيانات المفتاح الخاص للخدمة المستخدمة. وانتبه إلى أن آخر أمر في المثال يعرض معلومات سرية من المفتاح الخاص؛ لا تشارك مخرجاته ولا تحفظها في السجلات.

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
openssl rsa -in dkim-private.pem -text -noout

ثم حول المفتاح العام إلى قيمة في سطر واحد، كما تتطلب كثير من لوحات DNS:

awk 'NF {sub(/\r/, ""); printf "%s",$0;}' dkim-public.pem \
| sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//g'

يمكن تقسيم قيمة TXT الطويلة إلى سلاسل محاطة بعلامات اقتباس داخل السجل نفسه، إذ تجمع عند قراءتها. أما إدخال مسافات داخل المفتاح فخطأ. لا تنشر الأجزاء كسجلات TXT منفصلة.

للتوضيح: المحدد هو اسم يدل على المفتاح، وليس المفتاح نفسه. إذا احتوى التوقيع على s=tm2026، يبحث المستقبل عن tm2026._domainkey.yourdomain.com. إذا لم يوجد السجل، تعذر التحقق من DKIM.

اختيار المحدد وحجم المفتاح المناسبين

اختر مولد مفاتيح DKIM ينتج مفتاحا بحجم 2048 بت ويدعم أسماء محددات واضحة للتدوير. نظام الإرسال هو الذي يختار التوقيع باستخدام RSA مع SHA-256، وليس مولد المفاتيح. تعامل مع المحددات كأسماء تشغيلية للإصدارات، لا كزينة عشوائية.

استخدم أسماء توضح وقت استخدام المفتاح والجهة التي تستخدمه. أمثلة مناسبة:

tm2026
app1q1
marketing2026

أمثلة أقل ملاءمة:

الإبقاء على default إلى أجل غير محدد
استخدام test في بيئة الإنتاج
إعادة استخدام dkim لكل جهات الإرسال

الخيار	هل يستخدم؟	السبب
RSA بحجم 1024 بت	عند الضرورة فقط	مقبول في بعض البيئات، لكنه الحد الأدنى لا الهدف الموصى به.
RSA بحجم 2048 بت	نعم	خيار افتراضي ملائم عادة لأنظمة الإرسال وموفري DNS الحديثة.
محدد دائم واحد	لا	يعقد تدوير المفاتيح وقد يبطئ الاستجابة للحوادث.
محددات مرتبطة بإصدارات	نعم	تتيح نشر مفتاح جديد قبل إيقاف المفتاح القديم.

يحدد RFC 8301 الحد الأدنى عند 1024 بت ويوصي باستخدام 2048 بت. وتشترط إرشادات Google لمرسلي البريد الجماعي استخدام DKIM وSPF، وتوافق أحدهما على الأقل مع نطاق From عند الإرسال المباشر إلى حسابات Gmail الشخصية. راجع شروط التطبيق في الأسئلة الشائعة حول إرشادات المرسلين.

عند اختيار مولد مفاتيح DKIM، لا تكتف بالسؤال عن قدرته على إنشاء مفتاح. انظر إلى دعم 2048 بت ووضوح أسماء المحددات وسهولة التدوير. هذه هي الجوانب المهمة للتشغيل.

نشر سجل DNS بعناية

استخدام مولد مفاتيح DKIM جزء من العمل فقط. انشر سجل TXT في اسم مضيف المحدد الذي يستخدمه المرسل بالضبط، ثم تحقق من إتاحة المفتاح العام مع مراعاة ذاكرة DNS المؤقتة، قبل تفعيل التوقيع.

من الأخطاء الشائعة:

نشر سجل TXT عند @ بدلا من selector._domainkey.
لصق غلاف PEM كاملا في DNS بدلا من المفتاح المشفر بصيغة base64 وحده.
تفعيل التوقيع قبل أن يصبح سجل DNS قابلا للاستعلام.
ضبط محدد خاطئ في منصة البريد.

عند إعداد نطاق في TrekMail، اتبع إرشادات DNS التي تعرضها المنصة. يشرح دليل إضافة نطاق السجلات المطلوبة، ومنها قيمة DKIM TXT المناسبة. إذا كنت تستخدم SMTP خاصا بك، فخذ المفتاح والمحدد من مزود الإرسال الفعلي. بعد الحفظ نفذ التحقق المدمج. وإذا بقيت مشكلة، فاستعن بأداة فحص حالة DNS.

قد يفشل SPF في البريد المعاد توجيهه بينما ينجح DKIM. ويمكن أن ينجح DMARC حين يكون توقيع DKIM متوافقا مع نطاق From أيضا. ويتطلب ذلك ألا تتغير البيانات الموقعة بطريقة تؤثر في التحقق وفق قواعد التسوية. لذلك قد يكون فشل SPF وحده متوقعا أثناء إعادة التوجيه. اقرأ إعادة توجيه بريد النطاق إلى Gmail للتفاصيل.

اختبار عمل مفتاح DKIM فعليا

بعد استخدام مولد مفاتيح DKIM ونشر السجل، اختبر الترويسات الفعلية. لا تكتف بسلامة استعلام DNS. تحقق من ظهور dkim=pass ومن توافق النطاق بما يحقق شروط DMARC في البريد الذي ترسله بالفعل.

أرسل رسالة إلى صندوق Gmail وافحص الترويسات الأصلية. قد تبدو نتيجة ناجحة كما يلي:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tm2026 header.b=...
       spf=pass smtp.mailfrom=example.com
       dmarc=pass header.from=example.com

إذا فشل DKIM، افحص النقاط بالترتيب:

راجع المحدد s= في ترويسة DKIM-Signature.
استعلم عن اسم مضيف DNS نفسه باستخدام dig.
تأكد من تطابق المفتاح العام في DNS مع المفتاح الخاص في نظام الإرسال.
تأكد من استخدام نطاق التوقيع الصحيح في d=.
تحقق مما إذا كانت قائمة بريدية أو إضافة تذييل أو خادم وسيط قد عدل الترويسات الموقعة أو محتوى الرسالة.

dig +short TXT tm2026._domainkey.example.com

قد يعقد مولد مفاتيح DKIM غير الواضح معالجة الأخطاء إذا لم يشرح اسم مضيف المحدد والتحقق والتوافق. وجود مفتاح في DNS لا يكفي لكي يسهم DKIM في نجاح DMARC إذا لم يتوافق نطاق d= مع نطاق From الظاهر. في التوافق المرن يكفي اشتراكهما في النطاق التنظيمي، بينما يتطلب التوافق الصارم تطابقا تاما. وقد يظل DMARC ناجحا عبر SPF المتوافق.

لاستكمال إعداد البيئة، راجع إنشاء بريد بنطاقك، وإعداد إعادة توجيه البريد، ودليل TrekMail حول مشكلات البريد المزعج.

أدوات DKIM المتفرقة أم مسار تشغيل موحد؟

قد يصعب الحفاظ على الاتساق عند إدارة مولد مفاتيح DKIM منفصل، ولوحة DNS، ومزود SMTP لرسائل التطبيقات وآخر للنشرات، مع إعداد DMARC غير مكتمل. تبديل المزود أو تدوير مفتاح بطريقة خاطئة أو إعادة توجيه البريد قد يكشف أخطاء مصادقة لم تكن ظاهرة.

يجمع المسار الموحد إدارة النطاقات وصناديق البريد وفحوص DNS وإعدادات الإرسال في عملية مترابطة.

يوفر TrekMail، بحسب الخطة والإعدادات:

نطاقات مخصصة وصناديق IMAP في لوحة واحدة.
استخدام SMTP خاص بك في Nano، أو SMTP مدار حين تتضمنه الخطة المدفوعة.
ترحيلا مدمجا لجلب البريد القديم عبر IMAP.
الاستقبال الشامل وإعادة توجيه الصناديق والوصول إلى API حين تشملها الخطة.
مسار إعداد DNS ومصادقة يراعي SPF وDKIM وDMARC معا.

تزداد أهمية التنظيم عند إدارة نطاقات متعددة. فقد تشكل رسوم المستخدمين وأخطاء المصادقة عبر نطاقات كثيرة عبئا على الوكالات ومزودي الخدمات المدارة. تبدأ الأسعار المعروضة هنا لـ Starter من $3.50 شهريا، مع Nano بسعر $0 لما يصل إلى 10 نطاقات و5GB عند استخدام SMTP خاص بك. تحقق من الأسعار والحدود الحالية. قد تتضمن الخطط المدفوعة تجربة مجانية لمدة 14 يوما تتطلب بطاقة ائتمان؛ أما شروط Nano الموصوفة فلا تتطلب بطاقة.

إذا أردت نقل البريد القديم أثناء تصحيح المصادقة، فقد يتيح مسار ترحيل IMAP في TrekMail جلب رسائل Gmail أو Microsoft 365 أو مصادر IMAP الأخرى إلى صندوق TrekMail. تعتمد النتيجة على صلاحيات المصدر وطريقة المصادقة والبيانات المدعومة.

تدوير المفاتيح وإبطالها وصيانتها

مولد مفاتيح DKIM ليس خطوة تنتهي مرة واحدة. خطط لتدوير المفاتيح وسحب المحددات القديمة بعناية، واستخدم محددات منفصلة لجهات الإرسال حين يقلل ذلك أثر الحوادث ويسهل التشخيص.

يمكن اتباع هذا المسار:

أنشئ مفتاحا جديدا بحجم 2048 بت مع محدد جديد.
انشر المفتاح العام الجديد في DNS.
حول المرسل إلى التوقيع بالمحدد الجديد.
تحقق من ظهور dkim=pass في الرسائل الجديدة.
أبق المحدد القديم منشورا حتى تمر الرسائل المؤجلة والموجودة في الطوابير.
احذف المفتاح العام القديم بعد انتهاء الانتقال.

إذا انكشف مفتاح خاص، فاستبدله وراجع إجراءات الاستجابة اللازمة. وهذا سبب إضافي لاستخدام محددات بإصدارات بدلا من الإبقاء على default دائما.

لا يصلح مولد مفاتيح DKIM ممارسات الإرسال السيئة. المصادقة شرط أساسي، لكن السمعة مهمة أيضا. تتناول إرشادات Google لمرسلي البريد الجماعي ضبط شكاوى البريد المزعج واستخدام SPF وDKIM وDMARC. ومن المهم عمليا الحفاظ على إعدادات DNS الصحيحة وزيادة الإرسال ذي الصلة تدريجيا وتجنب البريد الجماعي غير المطلوب. لا تضمن هذه الإجراءات الوصول إلى الوارد.

الخلاصة: إنشاء المفتاح بداية وليس نهاية

مولد مفاتيح DKIM هو نقطة البداية. يجب أن يتوافق المحدد والمفتاح العام المنشور والمفتاح الخاص لدى المرسل، وأن تظهر في البريد الفعلي نتيجة dkim=pass مع توافق DMARC المناسب.

ابدأ بمفتاح 2048 بت ومحدد مرتبط بإصدار، وانشر TXT بصورة صحيحة واختبر الترويسات الفعلية. إذا كنت تدير مزودين ونطاقات متعددة، فقد يسهل توحيد المسار متابعة الإعدادات. يوفر TrekMail، بحسب الخطة، نطاقات مخصصة وصناديق IMAP وتخزينا مشتركا وترحيل IMAP وإدارة DNS والمصادقة. تحقق من الميزات الحالية وطريقة التسعير، بما فيها رسوم المستخدمين. اطلع على الخيار المجاني في trekmail.net أو قارن الخطط في trekmail.net/pricing.