تُعالج بروتوكولات DKIM وSPF وDMARC ثلاثة جوانب مختلفة من مصادقة البريد الإلكتروني الصادر، ويتطلب نشر Zimbra بشكل موثوق عملها معًا. يُحدد بروتوكول SPF للمستلمين الأنظمة المسموح لها بالإرسال باستخدام نطاقك المُحدد. يُضيف بروتوكول DKIM توقيعًا تشفيريًا مرتبطًا بالنطاق. يتحقق بروتوكول DMARC من تطابق هوية SPF أو DKIM الناجحة مع النطاق الظاهر في رأس "من" الرسالة، ثم ينشر سياسة معالجة وإبلاغ.
هناك تفصيل مهم في المعايير الحالية: اعتبارًا من أكتوبر 2026، فإنّ مواصفات بروتوكول DMARC النشطة هي RFC 9989 ، المنشورة في مايو 2026. وهي تلغي RFC 7489 الأقدم وتُغيّر بعض تفاصيل النشر، بما في ذلك جعل pctالوسم القديم تاريخيًا وإضافة tوسم الاختبار. هذا مهم إذا كنت تنسخ مثال DMARC قديمًا من دليل Zimbra سابق أو درس تعليمي حول نظام أسماء النطاقات (DNS).
أنت بحاجة إلى صلاحيات وصول إدارية إلى خادم Zimbra MTA، وصلاحيات الوصول إلى منطقة DNS العامة المعتمدة لنطاق الإرسال الخاص بك، وقائمة كاملة بجميع الأنظمة التي ترسل البريد بشكل قانوني باستخدام هذا النطاق. قد تتضمن هذه القائمة خادم Zimbra الخاص بك، أو خادم ترحيل أو مضيف ذكي، أو منصات تسويقية، أو أنظمة تذاكر، أو تطبيقات سحابية، أو أي خدمة بريد مخصصة لاستعادة البيانات في حالات الكوارث.
من المفاهيم الخاطئة الشائعة الاعتقاد بأن نشر سجلات خادم Zimbra وحده كافٍ دائمًا. في الواقع، لا يكفي ذلك إلا إذا كان Zimbra هو المرسل الوحيد المُصرَّح له. يتم تقييم SPF بناءً على هوية SMTP، وقد يكشف DMARC عن مُرسِلين خارجيين منسيين بمجرد تفعيله. الإجراء: حصر جميع مصادر البريد الصادر قبل نشر سياسة SPF أو DMARC تقييدية.
يتضمن Zimbra zmdkimkeyutilأداةً لتوقيع DKIM على مستوى النطاق. تشير وثائق Zimbra الرسمية إلى ضرورة تشغيلها على خادم MTA. لإضافة بيانات DKIM لنطاق غير موجود بالفعل، انتقل إلى حساب Zimbra وقم بتشغيل الأمر التالي:
su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.comيخزن الأمر بيانات DKIM في سجل نطاق LDAP الخاص بـ Zimbra، ويطبع المُحدِّد وسجل TXT العام اللازمين للنشر. كما توضح وثائق توقيع DKIM-q الخاصة بـ Zimbra كيفية الاستعلام عن بيانات DKIM الموجودة، -uوتحديثها، -rوحذفها.
في أنظمة Zimbra الحديثة، قد يختلف مُخرَج الأمر في قيمة المُحدِّد الدقيقة عن الأمثلة الموجودة على الإنترنت. لا يُفترض أن يكون المُحدِّد كلمة ثابتة مثل " defaultأو" zimbra؛ استخدم المُحدِّد الذي يُخرِجه خادمك تحديدًا. الإجراء: انسخ سجل المفتاح العام بالكامل من مُخرَج الأمر بدلًا من إعادة إنشائه يدويًا.
تقوم أدوات التحقق من DKIM بالبحث عن المفتاح العام في نظام أسماء النطاقات (DNS) تحت اسم مُشتق من المُحدِّد و ._domainkey. هذه الآلية مُعرَّفة في RFC 6376. عمليًا، يبدو السجل لدى مُزوِّدي خدمة DNS عادةً على النحو التالي:
| مجال | مثال |
|---|---|
| يكتب | رسالة قصيرة |
| اسم | YOUR_SELECTOR._domainkey |
| قيمة | v=DKIM1; k=rsa; p=مفتاحك_العام |
يعتمد إدخال اسم النطاق YOUR_SELECTOR._domainkeyالكامل أو اسم النطاق فقط YOUR_SELECTOR._domainkey.example.comعلى لوحة تحكم نظام أسماء النطاقات (DNS) الخاصة بك. بعض مزودي الخدمة يضيفون اسم النطاق تلقائيًا. الإجراء: عاين اسم النطاق المؤهل بالكامل في لوحة تحكم مزود الخدمة قبل الحفظ لتجنب إنشاء اسم نطاق غير مؤهل عن طريق الخطأ ...example.com.example.com.
_domainkeyوالصق المفتاح العام الكامل الذي أنتجته Zimbra.يُنشر سجل SPF كسجل TXT في نظام أسماء النطاقات (DNS) على النطاق الذي ترغب في وصف صلاحيات إرساله. يشترط معيار RFC 7208 وجود سجلات TXT لـ SPF، وينص على أن وجود سجلات SPF متعددة لنفس اسم المالك يُسبب خطأً دائمًا. بعبارة أخرى، لا تُنشئ سجل TXT ثانيًا v=spf1لمجرد إضافة خدمة بريد أخرى.
إذا كان خادم Zimbra الخاص بك يرسل مباشرة من عنوان IPv4 عام ثابت واحد، فإليك مثال بسيط:
v=spf1 ip4:203.0.113.10 -allإذا كانت جميع المضيفين المشار إليهم في سجلات MX الخاصة بنطاقك جهات إرسال صادرة شرعية، فيمكنك استخدام mx`. أما إذا كانت خدمة خارجية تنشر نطاقًا مضمنًا في SPF، فقد تحتاج إلى include:آلية أخرى. يختلف السجل المحدد باختلاف عملية النشر، لذا لا توجد سلسلة SPF واحدة صحيحة عالميًا لـ Zimbra.
خطأ شائع آخر هو افتراض أن ` ~allS` أكثر أمانًا دائمًا من `P` -all. السؤال الحقيقي هو ما إذا كانت قائمة المرسلين المعتمدين لديك كاملة. يُعدّ استخدام `S` خيارًا -allمعقولًا عندما تكون كذلك. الإجراء: اعتماد كل مرسل شرعي في سجل SPF واحد، والتحقق منه في بيئة الإنتاج، ثم اختيار المُؤهِّل النهائي allبناءً على تلك الأدلة.
اجعل بروتوكول SPF بسيطًا قدر الإمكان. يحدد RFC 7208 عدد الآليات والمعدلات التي تُفعّل عمليات البحث في نظام أسماء النطاقات (DNS) إلى 10 أثناء التقييم؛ تجاوز هذا الحد قد يؤدي إلى خطأ permerror. الإجراء: احسب عدد عمليات تضمين DNS وغيرها من آليات توسيع DNS قبل إضافة أي مزود خدمة آخر.
تم نشر سياسة DMARC على الموقع الإلكتروني التالي _dmarc.example.com. أول سجل مبدئي هو:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comp=noneيطلب من المستلمين عدم تغيير طريقة معالجة البيانات بناءً على سياسة DMARC أثناء جمع البيانات. ruaيطلب العنوان تقارير مجمعة؛ ويُحدد تنسيق التقرير المجمع الحالي في RFC 9990. استخدم صندوق بريد أو خدمة تقارير قادرة على معالجة تقارير DMARC بدلاً من صندوق بريد شخصي غير مراقب.
لا تقم بنسخ أمثلة النشر أو ما شابهها من المقالات القديمة بشكل أعمى pct=10. pct=25يُعتبر RFC 9989 مرجعًا pctتاريخيًا نظرًا لأن التجربة العملية أظهرت تطبيقًا غير متسق. يستخدم المعيار الحالي t=yلاختبار السلوك عند الحاجة. الإجراء: ابدأ بتحليل p=noneالتقارير؛ ولا تعتمد على أخذ عينات نسبية كآلية أمان.
_dmarcحتى تتمكن من رؤية مصادر الإرسال الحقيقية قبل طلب الحجر الصحي أو الرفض.بعد أن ينشر مزود خدمة نظام أسماء النطاقات (DNS) السجلات، استعلم عنها من خارج الخادم المرجعي أو من مُحلِّل أسماء نطاقات (Resolver) يرى نظام أسماء النطاقات العام. على سبيل المثال:
dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.comبالنسبة لبروتوكول SPF، تأكد من وجود استجابة TXT واحدة فقط تبدأ بـ [ v=spf1اسم المستخدم] عند اسم المالك. بالنسبة لبروتوكول DKIM، تأكد من أن المُحدِّد يُطابق تمامًا القيمة المُخزَّنة حاليًا في Zimbra. بالنسبة لبروتوكول DMARC، تأكد من وجود سجل سياسة DMARC واحد صالح للاستخدام عند الاسم المُتوقع.
يعتمد انتشار نظام أسماء النطاقات (DNS) على مزود الخدمة، ومدة البقاء (TTL)، وذاكرة التخزين المؤقت للمُحلِّل. قد يظهر تغيير ما فورًا على خادم أسماء موثوق، ولكنه قد يكون مُخزَّنًا مؤقتًا في مكان آخر. الإجراء: اختبر النظام على مُحلِّل عام مستقل واحد على الأقل قبل إلقاء اللوم على Zimbra بسبب إجابة قديمة.
أرسل رسالة من نطاق Zimbra إلى صندوق بريد على مزود خدمة مختلف، وافحص رؤوس الرسالة بالكامل. عادةً ما تُظهر النتيجة الناجحة توقيع DKIM ناجحًا و/أو نتيجة SPF ناجحة، بالإضافة إلى اجتياز DMARC، وذلك لأن هوية واحدة على الأقل موثقة تتوافق مع نطاق المرسل الظاهر.
هنا يظهر سوء فهم آخر: لا يتطلب بروتوكول DMARC اجتياز كلٍ من SPF وDKIM. بل يتطلب هوية SPF متوافقة أو هوية DKIM متوافقة. يُعرّف RFC 9989 التوافق المرن كوضع افتراضي لكليهما aspf، adkimمع إمكانية طلب توافق صارم باستخدام DKIM s. الإجراء المطلوب: فحص Authentication-Resultsوتحديد الآلية التي توفر اجتياز DMARC المتوافق بدقة.
بمجرد أن تُظهر بيانات DMARC الخاصة بك أن المُرسِلين الشرعيين يُصادقون ويُطابقون بشكل صحيح، يُمكنك تغيير السياسة إلى p=quarantineأو في نهاية المطاف p=reject. في المعيار الحالي، noneتُعبّر كل quarantineمن و و rejectعن تقييم مالك النطاق للاستخدام غير المُصادق عليه، ولكن لا يزال للمُستقبِلين الحق في اتخاذ القرار بشأن التعامل المحلي.
لا يُنظر p=rejectإلى DMARC على أنه تحسين لإمكانية وصول الرسائل. فهو في الأساس أداة للتحقق من الهوية ومنع إساءة استخدام النطاق؛ ولا يجعل الرسائل المرغوبة موثوقة تلقائيًا، ولا يضمن وصولها إلى صندوق الوارد. الإجراء: اجعل تطبيق DMARC قرارًا أمنيًا قائمًا على تغطية التحقق من الهوية المتوافقة، وليس وعدًا بزيادة معدلات وصول الرسائل إلى صندوق الوارد.
لتحديث بيانات DKIM لنطاق معين، يرجى مراجعة وثائق Zimbra التالية:
/opt/zimbra/libexec/zmdkimkeyutil -u -d example.comيُنشئ هذا الأمر بيانات DKIM مُحدَّثة ويُضيف سجل DNS جديدًا. تُوصي Zimbra تحديدًا بالإبقاء على سجل TXT السابق في DNS لفترة من الوقت حتى يُمكن التحقق من الرسائل المُوقَّعة بالمفتاح السابق أثناء نقلها أو وضعها في قائمة الانتظار. الإجراء: انشر المُحدِّد الجديد أولًا، ثم تحقَّق منه، واحتفظ بالمُحدِّد السابق مؤقتًا قبل إزالته.
| يتحكم | ما الذي يتحقق منه | المكان الذي تقوم فيه بضبطه | الفشل الأساسي لتجنب |
|---|---|---|---|
| عامل الحماية من الشمس | ما إذا كان المضيف المُرسِل مُصرَّحًا لهوية SMTP | سجل TXT لنظام أسماء النطاقات العام | سجلات SPF متعددة أو جهات إرسال خارجية مفقودة |
| DKIM | ما إذا كانت الرسالة تحمل توقيعًا صالحًا لنطاق التوقيع | إنشاء مفتاح Zimbra بالإضافة إلى مفتاح TXT لنظام أسماء النطاقات العام | محدد خاطئ أو مفتاح عام مبتور |
| DMARC | سواءً تم اجتياز SPF أو DKIM وتوافق مع نطاق From | سجل DNS العام TXT في_dmarc | فرض الإجراءات قبل أن ينسجم المرسلون الشرعيون |
تشير إرشادات حماية البريد الإلكتروني من Zimbra إلى ضرورة إنشاء DKIM لكل نطاق ونشره في نظام أسماء النطاقات العام (DNS) الخاص بكل نطاق. كما توثق الإرشادات مشكلات التوافق التي قد تظهر مع بعض الشخصيات أو سلوك الرد التلقائي في الإعدادات القديمة. هذه التفاصيل خاصة بحالات معينة وليست عامة: إذا كان نظامك يستخدم أسماء مستعارة أو شخصيات أو خوادم وسيطة أو إعادة كتابة غير معتادة للمغلفات، فاختبر مسارات الرسائل هذه بشكل منفصل.
في حالة تثبيت Zimbra متعدد النطاقات، كرر إعداد DKIM ونشر DNS لكل نطاق إرسال. كذلك، تُعدّ SPF وDMARC سياسات نطاق؛ فلا تفترض أن سجلًا على نطاق مُستضاف واحد يغطي تلقائيًا نطاقًا آخر غير ذي صلة. الإجراء: أنشئ مصفوفة اختبار صغيرة لكل نطاق ولكل مسار صادر قبل تفعيل تطبيق DMARC الصارم.
v=spf1في كل نطاق إرسال.selector._domainkey._dmarc.domainويستخدم الصيغة الحالية.إذا اجتازت هذه الفحوصات بنجاح، فإن خادم Zimbra الخاص بك لا ينشر ثلاثة سجلات DNS فحسب، بل يقدم سلسلة مصادقة متماسكة يمكن للمستلمين عن بُعد التحقق منها. هذا التمييز أهم من نسخ أي سلسلة نصية من دليل، لأن مصادر SPF الصحيحة، ومحدد DKIM، وتوقيت تطبيق DMARC تعتمد على كيفية خروج بريدك الإلكتروني من المؤسسة فعليًا.
تعرف على كيفية طلب رمز التحقق من المفتاح (TOTP) من Keycloak لتسجيل الدخول إلى ownCloud Infinite Scale، وتسجيل المستخدمين الحاليين والجدد، وإعداد عملية الاسترداد، واختبار تسجيل الدخول الموحد (SSO) وترقية المصادقة متعددة العوامل (MFA).
قم بربط ownCloud Infinite Scale بـ Keycloak باستخدام OpenID Connect. قم بتهيئة مُصدر النطاق، وعميل الويب، والمطالبات، وTLS، وتوفير الحساب، وفحوصات تسجيل الدخول.
قم ببناء مجموعة Nextcloud مرنة باستخدام MariaDB Galera، والتخزين المشترك، وRedis، وموازنة الأحمال، وفحوصات النصاب، والاسترداد المختبر - بالإضافة إلى المقايضات التي يجب التخطيط لها.
تعرف على كيفية تكوين النسخ الاحتياطي لمفاتيح Element، ومفاتيح الاسترداد، والتوقيع المتبادل، ومقارنة المفاضلات الأمنية، والتحقق من الأجهزة، وتجنب فقدان السجل المشفر.
قارن بين Zextras Backup و imapsync لنقل خادم Zimbra. جهّز الحسابات، واختبر عملية النقل، وقم بمزامنة التغييرات، وانقل سجلات MX، وتحقق من بيانات البريد والتعاون.
قم بإصلاح خطأ قاعدة بيانات Nextcloud WebGUI بعد التحديث عن طريق التحقق من السجلات، وإكمال ترقية occ، وإصلاح مشكلات المخطط، والتحقق من سلامة قاعدة البيانات.
قم بتكوين Zimbra Proxy لإعادة توجيه حركة مرور البريد الإلكتروني من HTTP إلى HTTPS، وأعد تشغيل كل عقدة وكيل، وتحقق من إعادة التوجيه، وتجنب المخاطر الأمنية الشائعة.
قم بربط BigBlueButton بنظام إدارة التعلم Moodle باستخدام النشاط المدمج، وعنوان URL للخادم، والكلمة السرية المشتركة. اتبع ثماني خطوات لإعداد غرفة الدورة التدريبية واختبار وصول الطلاب.
قم بتخصيص العلامة التجارية لموقع ownCloud الإلكتروني باستخدام شعارك، وأيقونة الموقع، وخلفية تسجيل الدخول، واسم علامتك التجارية، وألوان السمة باستخدام إعدادات JSON للسمة المدعومة من Infinite Scale.
قم بتكوين توقيع Zimbra DKIM، وتفويض SPF، وسياسة DMARC بشكل صحيح، وتحقق من DNS والمحاذاة، وتجنب السجلات الشائعة التي تكسر مصادقة البريد.
