دليل عملي لضبط سجلات SPF وDKIM وDMARC على حساب Microsoft 365
أغلب فرق المبيعات في الخليج ترسل من Outlook عبر Microsoft 365، وتفترض أن الحماية جاهزة من طرف مايكروسوفت. الحقيقة أن SPF وDKIM وDMARC تحتاج ضبطًا يدويًا في سجلات DNS، وأي خطأ فيها يجعل رسائل cold email B2B تُصنَّف كبريد غير موثوق حتى لو كان المحتوى ممتازًا. هذا الدليل يشرح الخطوات الفعلية داخل مركز الإدارة والفروقات التي تهم النطاقات الخليجية تحديدًا.
- SPF في Microsoft 365 يتطلب include:spf.protection.outlook.com إضافة لأي مزوّد آخر ترسل منه، مع عدم تجاوز 10 عمليات بحث DNS
- DKIM يُفعَّل من Microsoft Defender ويحتاج سجلّي CNAME منفصلين لكل نطاق، ولا يعمل تلقائيًا إلا بعد تفعيلهما يدويًا
- DMARC يجب أن يبدأ بـ p=none للمراقبة قبل الانتقال إلى quarantine ثم reject، وإلا قد تُحجب رسائل مشروعة
- أكبر خطأ شائع لدى الشركات الخليجية هو وجود سجل SPF مكرر بعد ترحيل من مزوّد بريد محلي إلى Microsoft 365
- التحقق بعد كل تعديل عبر رؤوس الرسالة (Message Headers) أهم من الاكتفاء بأدوات فحص خارجية فقط
لماذا يتعطل SPF وDKIM وDMARC تحديدًا في Microsoft 365
الفرق بين إعداد هذه السجلات على مزوّد بريد بسيط وإعدادها على Microsoft 365 أن الأخير يضيف طبقات: بوابة Exchange Online، اتصال هجين محتمل مع خادم Exchange محلي قديم، وربما أدوات إرسال إضافية مثل CRM أو منصة تسويقية. كل واحدة من هذه الأطراف تحتاج أن تكون مذكورة في سجل SPF واحد، وليس عدة سجلات متفرقة.
المشكلة الأكثر تكرارًا لدى شركات في الرياض ودبي والدوحة أنها انتقلت من مزوّد محلي (مثل استضافة بريد عبر GoDaddy أو شركة اتصالات محلية) إلى Microsoft 365 دون حذف سجل SPF القديم، فينتج سجلان منفصلان بدلًا من سجل واحد موحّد — وهذا يُبطل الحماية كاملة من منظور خوادم الاستقبال.
بما أن رسائل cold email B2B تُرسل من نطاق الشركة نفسه (وليس نطاق تسويقي منفصل)، فإن أي خلل في هذه السجلات ينعكس مباشرة على صندوق الوارد الرئيسي للشركة، وليس فقط على الحملة.
خطوات تفعيل SPF داخل مركز إدارة Microsoft 365
قبل أي تعديل، افحص السجل الحالي عبر أداة بحث DNS (مثل nslookup -type=txt أو أي أداة فحص SPF مستقلة) لمعرفة ما هو موجود فعلًا، لا ما تتذكره فرق تقنية المعلومات.
- تأكد من وجود سجل TXT واحد فقط يبدأ بـ v=spf1 على النطاق الجذري
- أضف include:spf.protection.outlook.com داخل هذا السجل — هذا هو المكوّن الإلزامي لأي بريد صادر من Microsoft 365
- إن كنت تستخدم أداة إرسال إضافية (CRM للمبيعات، منصة فوترة) أضف include الخاص بها داخل نفس السجل، لا في سجل منفصل
- أنهِ السجل بـ -all (رفض صارم) بعد التأكد من استقرار كل مصادر الإرسال، أو ~all (رفض ناعم) خلال فترة الاختبار الأولى
- احسب عدد عمليات include بعناية: تجاوز 10 عمليات بحث DNS يجعل SPF يفشل تلقائيًا بحسب معيار RFC، بغض النظر عن صحة المحتوى
- انتظر من 30 دقيقة إلى بضع ساعات لانتشار DNS قبل الاختبار
تفعيل DKIM لكل نطاق مُرسِل
DKIM في Microsoft 365 لا يعمل بشكل افتراضي على النطاقات المخصّصة (custom domains) — فقط على نطاق onmicrosoft.com الاحتياطي. يجب تفعيله يدويًا من Microsoft Defender for Office 365، تبويب Email Authentication، لكل نطاق تُرسل منه فرق المبيعات.
التفعيل يتطلب إضافة سجلّي CNAME (selector1 وselector2) يشير كل منهما إلى مسار على onmicrosoft.com الخاص بالمستأجر (tenant). بعد إضافتهما في DNS، يظهر خيار التفعيل نشطًا داخل لوحة Defender، وعندها فقط يبدأ التوقيع الفعلي للرسائل الصادرة.
للتحقق: أرسل رسالة تجريبية إلى بريد Gmail شخصي، افتح 'إظهار الأصل' (Show original)، وابحث عن السطر dkim=pass header.d=nطاقك.com — إن ظهرت القيمة header.d=onmicrosoft.com بدلًا من نطاقك، فهذا يعني أن DKIM لم يُفعَّل بعد على النطاق المخصص.
بناء سجل DMARC تدريجيًا دون كسر البريد الحالي
السجل الأكثر إهمالًا في هذه العائلة الثلاثية هو DMARC، رغم أنه الطبقة التي تقرر فعليًا ماذا يحدث عندما يفشل SPF أو DKIM. الخطأ الشائع هو القفز مباشرة إلى p=reject، ما قد يحجب رسائل مشروعة صادرة من أدوات لم تُدرَج بعد في SPF أو DKIM.
الممارسة السليمة هي البدء بـ p=none مع تفعيل التقارير المجمّعة (rua) لمدة أسبوعين إلى أربعة أسابيع، مراجعة التقارير للتأكد من أن كل مصادر الإرسال المشروعة تمر بنجاح، ثم الانتقال إلى quarantine بنسبة جزئية (pct=25 مثلًا)، وأخيرًا reject الكامل.
الأرقام تقديرية من ممارسة إعداد نطاقات مرسلة لحملات B2B مستهدفة، وتختلف حسب عدد مصادر الإرسال لدى كل شركة
أخطاء شائعة لدى الشركات الخليجية عند ضبط هذه السجلات
معظم المشاكل التي نراها في مراجعات النطاقات قبل إطلاق حملات LDM تتكرر ضمن نمط محدود من الأخطاء، غالبًا بسبب الانتقال بين مزوّدين أو تعدد الأطراف المسؤولة عن DNS داخل نفس الشركة.
- سجلا SPF منفصلان على نفس النطاق بدلًا من دمجهما في سجل واحد
- نسيان تفعيل DKIM بعد إضافة سجلّي CNAME، فتبقى الرسائل موقّعة باسم onmicrosoft.com فقط
- ضبط p=reject من اليوم الأول دون مراقبة، ما يوقف رسائل داخلية مشروعة من أنظمة الفوترة أو الدعم
- استخدام نفس النطاق الرئيسي للشركة في إرسال حجم كبير من رسائل التنقيب (prospecting) دون نطاق فرعي مخصص لحماية سمعة النطاق الأساسي
- الاعتماد على تقرير فحص واحد وقت الإعداد فقط، دون مراجعة دورية بعد إضافة أدوات إرسال جديدة لاحقًا
قائمة التحقق النهائية وكيف تتعامل LDM مع الأمر
قبل تفعيل أي حملة cold email من نطاق يعتمد على Microsoft 365، نراجع في LDM ثلاثة أشياء بالترتيب: سجل SPF واحد يشمل كل مصادر الإرسال دون تجاوز حد البحث، DKIM نشط فعليًا على النطاق المخصص (وليس فقط onmicrosoft.com)، وسجل DMARC بحد أدنى p=none مع تقارير مفعّلة. بدون هذه الثلاثة، لا نطلق أي حملة حتى لو كان المحتوى جاهزًا.
الهدف ليس فقط اجتياز فحوصات spf dkim and dmarc اللحظية، بل الحفاظ على سمعة النطاق على المدى الطويل — لأن نفس النطاق يُستخدم لاحقًا في التواصل مع عملاء حاليين، فواتير، ودعم فني.
الأسئلة الشائعة
هل تفعيل SPF وDKIM وDMARC كافٍ لضمان وصول رسائل cold email إلى صندوق الوارد؟
هذه السجلات شرط ضروري وليست ضمانًا كاملًا. هي تمنع تصنيف النطاق كمنتحل أو غير موثوق، لكن معدل الفتح ونسبة الردود يعتمدان أيضًا على جودة القائمة وتخصيص المحتوى وحجم الإرسال اليومي.
كم يستغرق ظهور نتيجة تفعيل هذه السجلات على Microsoft 365؟
انتشار DNS عادة يستغرق من 30 دقيقة إلى بضع ساعات، لكن تحسّن السمعة الفعلي لدى مزوّدي البريد الكبار قد يحتاج أسابيع من الإرسال المستقر بعد التفعيل الصحيح.
ماذا يحدث إذا أضفنا مزوّد إرسال جديد بعد ضبط SPF وDMARC؟
يجب إضافة include الخاص بالمزوّد الجديد داخل سجل SPF الموجود فور ربطه، وإلا ستفشل رسائله في التحقق ويُحتمل حجبها إن كان DMARC على quarantine أو reject.
هل نحتاج نطاقًا فرعيًا منفصلًا لحملات التنقيب B2B؟
يُنصح به عند الإرسال بحجم يومي كبير نسبيًا، لأنه يعزل تأثير أي مشكلة تسليم محتملة عن النطاق الرئيسي المستخدم في المراسلات الرسمية والفوترة.
كيف نتحقق أن DKIM يعمل فعليًا وليس فقط 'مفعّل' في اللوحة؟
افحص رؤوس رسالة صادرة فعلية عبر خيار عرض المصدر (Show original) في Gmail أو ما يعادله، وتأكد أن قيمة dkim=pass مرتبطة بنطاقك الخاص لا بنطاق onmicrosoft.com الاحتياطي.
هل يمكن الانتقال مباشرة إلى p=reject لتوفير الوقت؟
لا يُنصح بذلك. القفز إلى reject دون مرور بمرحلة none ثم quarantine يخاطر بحجب رسائل مشروعة من أنظمة لم تُدرج بعد في SPF، وقد يعطّل بريدًا تشغيليًا حساسًا مثل الفواتير أو إشعارات العملاء.