إعداد DKIM للنطاقات المخصصة: خطوات التحقق

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

لإعداد النطاق كاملا، بما يشمل MX وSPF وصناديق البريد وبرامج البريد، ابدأ بمقال إنشاء بريد باستخدام نطاقك. وإذا كنت تختار المنصة أولا، فمقال البريد التجاري يناقش القرار الأوسع.

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

ما الذي يفعله إعداد DKIM فعليا؟

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

يستخدم DKIM التشفير غير المتماثل. يحتفظ نظام الإرسال بالمفتاح الخاص، وينشر DNS المفتاح العام. تحصل الرسالة الصادرة على ترويسة DKIM-Signature تتضمن نطاق التوقيع (d=) والمحدد (s=). يبحث خادم الاستقبال عن المحدد في DNS ويتحقق من التوقيع مقابل محتوى الرسالة. توضح RFC 6376 هذه الآلية.

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

هذا مهم لأن التوقيع الصالح تقنيا ليس بالضرورة مفيدا للغرض المطلوب. إعداد DKIM المعطل أو غير المحاذي قد يسهم في تصنيف الرسائل كغير مرغوب فيها أو في مشكلات DMARC أو كليهما.

قبل تعديل DNS لإعداد DKIM

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

اسأل أولا: من يرسل البريد الصادر لهذا النطاق؟

1. إذا كان Google Workspace هو المرسل، فأنشئ مفتاح DKIM في Google Admin.
2. إذا كان Microsoft 365 هو المرسل، ففعل DKIM هناك.
3. إذا كان SendGrid أو Mailgun أو Amazon SES هو المرسل، فتحقق من النطاق لدى ذلك المزود.
4. إذا كان TrekMail Managed SMTP هو المرسل، فاستخدم قيم DKIM الظاهرة في TrekMail.
5. إذا كان TrekMail يدير صناديق البريد مع استخدام SMTP خارجي، فاتبع تعليمات التوقيع لدى مزود SMTP، ثم اضبط SMTP في TrekMail عند الحاجة.

يدعم TrekMail المسارين. تستخدم Nano نظام BYO SMTP، ويمكن للخطط المدفوعة استخدام SMTP المدار بحسب الشروط. تعرض وثائق Bring Your Own SMTP أمثلة لـ SES وSendGrid وMailgun. وتشير وثائق معالجة مشكلات الوصول إلى أن Managed SMTP يوقع بمفتاح DKIM الخاص بنطاقك. قد يساعد ذلك DMARC عند إعادة التوجيه والترحيل إذا بقي التوقيع صالحا ومحاذيا ولم يتغير المحتوى الموقع.

مثال: صندوق بريدك في TrekMail، لكن الإرسال يمر عبر SendGrid. يجب أن يكون SendGrid هو الموقع. تخزين الصندوق في TrekMail لا ينجز تلقائيا إعداد DKIM في SendGrid.

هذه أول قاعدة: أنشئ المفاتيح في النظام الذي يوقع الرسالة. إن أنشأتها في مكان آخر، فقد يوجد سجل DNS دون أن يؤدي أي دور في الإرسال.

أنواع سجلات DKIM: TXT مقابل CNAME

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

يستخدم الإعداد التقليدي سجل TXT في:

selector._domainkey.example.com

وتبدو القيمة كما يلي:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

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

المشكلة الشائعة في حقل المضيف. إذا كان نطاقك example.com والمحدد k1، فعادة يكون المضيف:

k1._domainkey

وليس:

k1._domainkey.example.com

تضيف لوحات DNS كثيرة النطاق الرئيسي تلقائيا. إذا أدخلت الاسم الكامل في لوحة كهذه، فقد تنشر k1._domainkey.example.com.example.com. ولن يوجد السجل في المكان الذي تتوقعه خوادم الاستقبال.

لمرجع TrekMail حول إعداد DNS المطلوب، راجع سجلات DNS المطلوبة. يوضح أيضا أن بعض مزودي DNS يطلبون تقسيم قيم DKIM TXT إلى أجزاء بين علامتي اقتباس.

خطوات إعداد DKIM في DNS

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

اتبع هذه الإجراءات.

1. افتح منصة مزود الإرسال وأنشئ سجل DKIM أو أظهره.
2. انسخ المحدد كما هو. لا تغير اسمه إلا إذا دعم المزود ذلك.
3. أنشئ سجل DNS عند selector._domainkey.
4. الصق قيمة TXT الكاملة أو هدف CNAME كما قدما تماما.
5. اضبط TTL على 3600، ما لم يوجد سبب لاختيار قيمة أخرى.
6. انتظر انتشار التحديث.
7. تحقق باستخدام dig أو nslookup قبل إرسال بريد الإنتاج.
8. فعل التوقيع لدى المزود إذا كانت الواجهة تتضمن مفتاح تفعيل نهائيا.

مثال لإعداد DKIM باستخدام TXT:

; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

مثال باستخدام CNAME:

; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.

تظهر تحديثات DNS بسرعة غالبا، لكنها ليست فورية. يذكر دليل TrekMail أن كثيرا منها يظهر خلال نحو 5 إلى 15 دقيقة. هذا ليس موعدا مضمونا، فقد تؤخر TTL والذاكرة المؤقتة ظهور التغيير. إذا لم تتغير الحالة بعد ذلك، فافحص التنسيق والسجلات المكررة واسم المضيف.

إعداد DKIM ومشكلة مفتاح 2048 بت

ينبغي استخدام مفاتيح RSA بطول 2048 بت عندما يدعمها المزود ومضيف DNS. فهي أقوى، لكنها أطول أيضا، مما يسبب مشكلات في بعض اللوحات القديمة. المفتاح المقتطع قد يبدو موجودا رغم فشل التحقق، فيصعب التشخيص.

توصي Google بمفاتيح 2048 بت عند دعمها، مع 1024 بت كخيار بديل للمضيفين الذين لا يعالجون السجلات الأطول. المشكلة العملية غالبا في لوحة الإدارة أمام DNS، لا في DNS نفسه.

تظهر مشكلات إعداد DKIM بطول 2048 بت عادة بإحدى الصور التالية:

1. تقتطع اللوحة القيمة دون تنبيه.
2. تتطلب اللوحة أجزاء بين علامتي اقتباس دون توضيح ذلك.
3. تضيف اللوحة فواصل أسطر داخل مفتاح base64.
4. تعالج اللوحة المحارف بطريقة لا يتوقعها المزود.

إذا طلب المضيف تقسيم السلاسل، فانشر القيمة هكذا:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"

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

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

التحقق من DKIM عبر DNS والرسائل الفعلية

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

ابدأ بسطر الأوامر.

# macOS / Linux
dig txt k1._domainkey.example.com +short

# Windows
nslookup -type=txt k1._domainkey.example.com

ينبغي أن ترى سجل v=DKIM1 كاملا أو أجزاء مقتبسة تتجمع في مفتاح كامل. إذا كان الناتج خاليا، فتحقق بالترتيب من:

1. صحة المحدد.
2. عدم تكرار النطاق في حقل المضيف.
3. مطابقة نوع السجل لما طلبه المزود.
4. اكتمال القيمة وعدم اقتطاعها.
5. عدم بقاء السجل القديم في الذاكرة المؤقتة.

أرسل بعدها رسالة تجريبية إلى Gmail أو صندوق يتيح فحص الترويسات. ابحث عن نتائج التحقق وسطر توقيع DKIM.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...

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

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

إعداد DKIM وفخ المحاذاة

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

مثال شائع:

From: ceo@example.com
نطاق توقيع DKIM: d=sendgrid.net
النتيجة: قد ينجح DKIM، لكن محاذاة DMARC عبره قد تفشل لأن نطاق التوقيع لا يحاذي example.com.

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

قد تسمى الإعدادات لدى المزود التحقق من النطاق أو white-labeling أو إعداد return-path مخصص. يؤثر return-path في محاذاة SPF، ولا يغير نطاق توقيع DKIM بمفرده. ولـ DKIM، اضبط التحقق من النطاق ليبدو التوقيع النهائي هكذا:

DKIM-Signature: ... d=example.com; s=s1; ...

هذا هو إعداد DKIM الذي يمكن أن يسهم في نجاح DMARC. أما التوقيع بنطاق غير محاذ فلا يكفي لهذا الغرض.

النهج القديم والجديد لإعداد DKIM

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

يناسب TrekMail هذا النموذج. تشمل الإمكانات المعلنة إدارة عدة نطاقات مخصصة من لوحة واحدة، وتخزينا مشتركا بدلا من الدفع لكل صندوق، وترحيل الصناديق عبر IMAP، واختيار BYO SMTP أو SMTP مضمن حسب الخطة. السعر الابتدائي المذكور للخطط المدفوعة هو $3.50 شهريا؛ تحقق من شروط الفوترة الحالية. تستهدف المنصة الفرق والشركات الصغيرة والوكالات ومزودي الخدمات المدارة الراغبين في تقليل عبء البنية البريدية.

إذا كانت المشكلة في الإجراءات أكثر من DNS، فاقرأ عن إدارة بريد العملاء. ترتبط مشكلات الوصول في البيئات متعددة النطاقات غالبا بمسؤوليات الإدارة قبل تفاصيل السجلات.

قائمة التحقق النهائية لإعداد DKIM

يتطلب الإعداد الجيد نظام التوقيع الصحيح واسم مضيف DNS الصحيح والمفتاح الكامل وفحص DNS العام والتوقيع المحاذي لـ DMARC. قد يضعف الخطأ في أي عنصر منها سلسلة التحقق كلها.

1. حدد النظام الذي يوقع البريد الصادر.
2. انشر محدد المزود ونوع السجل بدقة.
3. استخدم selector._domainkey في حقل المضيف ما لم يطلب مضيف DNS الاسم الكامل صراحة.
4. حافظ على مفاتيح 2048 بت كاملة. قسم السلاسل المقتبسة فقط إذا طلبت اللوحة ذلك.
5. تحقق باستخدام dig أو nslookup.
6. أرسل اختبارا وافحص الترويسات بحثا عن dkim=pass وheader.d محاذ.
7. افحص نتائج DMARC بعد بدء التشغيل.

هذه هي الفكرة: إعداد DKIM يتطلب الدقة أساسا. لتقليل العناصر المتغيرة، وحد نطاقاتك ومسار الإرسال في TrekMail، واجعل DNS واضحا في مكان واحد، واستبدل المعالجة الفردية المتكررة بإجراءات ثابتة.