- الرئيسية
- الحلول
- لماذا Klytic
- الأدلة
- الأسعار
- الشركاء
- اتصل بنا
-
-
الرئيسية›الأدلة›أمن البريد الإلكتروني
أمن البريد الإلكتروني · الفهم
نعم، يمكن تعزيز حماية Microsoft 365 أو Google Workspace أو Exchange أو أي خادم آخر دون تغيير نظام البريد. يشير سجل MX للنطاق إلى البوابة، التي تحلّل البريد ثم تسلّمه إلى الخادم الحالي. يحتفظ المستخدمون بصناديقهم؛ ولكل من مدير DNS ومسؤول نظام البريد إعداد واحد عليه القيام به.
تغيير نظام البريد وتغيير الحماية مشروعان مختلفان. الأول ينقل الصناديق والسجل والتقويمات والحسابات على الهواتف. والثاني لا يمس إلا مسار البريد الوارد.
هذا المسار يتحدد في سجل DNS واحد: سجل MX، الذي يبيّن للخوادم المرسِلة أين تسلّم بريد نطاقكم. حين يشير إلى البوابة، تستقبل البوابة الرسالة وتحلّلها ثم تسلّمها إلى خادم الصناديق. وينطبق ذلك على:
يتناول هذا الدليل حالة الاحتفاظ بالصندوق. وإذا كنتم ستغيّرون الخادم أيضًا، فإن دليلي الترحيل من Microsoft 365 والترحيل من Google Workspace يصفان ذلك المشروع.
| الإعداد | أين | من |
|---|---|---|
| سجل MX للنطاق | منطقة DNS، لدى مسجّل النطاقات أو مستضيف DNS | الشخص الذي يدير DNS، أو مزوّد الخدمات الذي فُوّض إليه ذلك |
| التصريح بالبوابة لدى نظام البريد | وحدة إدارة Microsoft 365 أو Google Workspace أو الخادم | مسؤول نظام البريد |
| SPF وDKIM وDMARC | منطقة DNS | مدير DNS، بعد جرد الخوادم التي ترسل باسم النطاق |
| النطاقات وخادم التسليم | البوابة | مزوّد البوابة، الذي يُعدّ الإعدادات |
وثائق Microsoft حول التصفية عبر خدمة خارجية واضحة: يجب أن يشير سجل MX للنطاق إلى هذه الخدمة، التي تسلّم بعد ذلك إلى Exchange Online. وتوصي Microsoft بموصل وارد من نوع «شريك»، يمكنه رفض البريد الذي يصل دون المرور بالخدمة. كما توصي بتفعيل التصفية المحسّنة للموصلات، حتى يقيّم تحليلها الخاص المرسِلَ الحقيقي لا عنوانَ البوابة. وتنصح بعدم الاكتفاء بتجاوز تصفيتها لعناوين الخدمة الخارجية.
تصف Google «بوابة بريد وارد»: يشير سجل MX إلى البوابة، ثم يصرّح المسؤول بعناوين IP الخاصة بها في وحدة الإدارة. ويستعملها Gmail لاستخراج العنوان الحقيقي للمرسِل من الترويسات، الذي يتوقف عليه SPF وتقييمه للبريد غير المرغوب فيه. ويمكن أيضًا رفض البريد الذي لا يأتي من البوابة. وتوضّح Google أنها لا تطبّق سياسة DMARC الخاصة بالمرسِل على البريد الوارد عبر بوابة مصرّح بها: فيعود هذا الفحص حينئذ إلى البوابة.
لا ينقل هذا الدليل شاشات وحدات الإدارة هذه، لأنها تتغيّر. اتبعوا الصفحة الرسمية المذكورة أسفل الصفحة وقت الإعداد.
حالة شائعة في المجموعات: الشركة الأم على Microsoft 365، وشركة تابعة على Google Workspace، وثالثة على خادم قديم. يمكن لبوابة واحدة أن تسبق الثلاثة.
المبدأ هو التوجيه حسب النطاق. يشير سجل MX لكل نطاق إلى البوابة. وتعرف البوابة، لكل نطاق، الخادم الذي تسلّم إليه البريد بعد التحليل. التحليل مشترك، والوجهة تتغيّر.
الفائدة: سياسة تصفية واحدة، أو إعدادات مختلفة بحسب النطاق، وقراءة كل القرارات في مكان واحد. نقطة يجب التحضير لها: النطاق الذي تتوزع صناديقه على خادمين يتطلب معرفة وجهة التسليم عنوانًا بعنوان. وتُدرس هذه الحالة قبل الانتقال.
لا يتغيّر: العناوين، والصناديق، والسجل، وبرنامج البريد، وواجهة الويب، والهواتف. ويستمر المرشّح المدمج في نظام البريد في العمل. وتبقى الصلاحيات والمشاركات الداخلية كما هي في المنصة.
يتغيّر:
يوم تغيّرون خادم الصناديق أيضًا، يمكن أن تبقى البوابة في مكانها: فلا يتغيّر سوى خادم التسليم. ويبقى دليل ترحيل نظام البريد دون انقطاع المرجع في ذلك اليوم، بما في ذلك بالنسبة إلى SPF وDKIM وDMARC.
العودة إلى الوضع السابق بسيطة: إعادة سجل MX القديم. وتُحضَّر كما في أي ترحيل، مع شخص يملك صلاحية اتخاذ القرار.
ترى البوابة البريد الذي يعبرها، وهذا فقط. فهي لا ترى الرسائل المتبادلة بين صندوقين في المنصة نفسها دون أن تخرج منها، ولا الملفات المشتركة في مساحة تخزين عبر الإنترنت، ولا عمليات تسجيل دخول المستخدمين.
وبالتالي فهي لا تحل محل الإعدادات الداخلية لـ Microsoft 365 أو Google Workspace: الصلاحيات، والمصادقة الثنائية، وتنبيهات تسجيل الدخول، وقواعد إعادة التوجيه التلقائي. ويبقى الحساب المسروق مسألة تخص نظام البريد أولًا. ويفصل دليل البريد غير المرغوب فيه والتصيّد والبرمجيات الخبيثة والحساب المخترق بين الأمرين.
أخيرًا، المرسِل الذي يعرف العنوان التقني لخادم الصناديق قد يحاول التسليم إليه مباشرة، دون المرور عبر MX. وهذا سبب الإغلاق الذي تقترحه Microsoft (الموصل الشريك) وGoogle (رفض البريد الوارد من خارج البوابة).
عناوينهم لا تتغيّر. لكن أبلغوهم بأنهم قد يتلقون إشعارات حجر: راجعوا الحجر والإيجابيات الكاذبة والإبلاغات.
لا. توصي Microsoft بإبقاء تحليلها مفعّلًا وضبطه حتى يرى المرسِل الحقيقي، بدل تجاوزه.
يسري تغيير MX نفسه بوتيرة ذاكرة التخزين المؤقت لـ DNS. أما التحضير فيتوقف على عدد النطاقات والخوادم. وبالنسبة إلى Klytic MTA، راجعوا القسم التالي.
فقط إذا كانت ترحّل أيضًا البريد الصادر. وفي هذه الحالة يجب أن يأخذها SPF وDKIM بعين الاعتبار: راجعوا SPF وDKIM وDMARC.
هذا قرار آخر، بمعايير أخرى. ويتناوله دليل اختيار بريد مهني أوروبي.
تتموضع Klytic MTA أمام نظام البريد الذي تملكونه: Microsoft 365 أو Google Workspace أو Exchange أو Klytic Mail أو أي خادم آخر. وهي لا تفترض وجود صندوق لدى Klytic.
لا تدير Klytic MTA صلاحيات نظام بريدكم الحالي ولا حساباته، ولا تعد بالتكافؤ مع أدوات الأمان المدمجة في Microsoft 365 أو Google Workspace: بل تُضاف أمامها.
تصف هذه الصفحة مبدأً عامًا. ووحدات إدارة Microsoft وGoogle تتطوّر: ووثائقها الرسمية هي المرجع في الخطوات العملية.
اطُّلع عليها في أكتوبر 2026.
تجربة مجانية لمدة 30 يومًا دون تغيير نظام البريد: لا يتغيّر سوى سجل MX.
عرض الترحيب
عرض تجريبي دون التزام. سيتصل بك مستشار لفهم احتياجاتك وتجهيز مساحة Klytic الخاصة بك.
