قائمة التحقق الكاملة لإعداد SPF وDKIM وDMARC قبل توسيع حملات B2B الموجّهة
قبل أن ترسل رسالة واحدة لمدير مشتريات في شركة سعودية أو مسؤول مبيعات في شركة إماراتية، يحدد DNS النطاق مصيرها: بريد وارد، أو مجلد عشوائي، أو رفض كامل. هذا دليل إعداد SPF وDKIM وDMARC (spf dkim dmarc setup guide) بترتيب عملي: إعداد، ثم اختبار، ثم مراقبة، قبل أي زيادة في حجم الإرسال اليومي.
- السجلات الثلاثة تعمل كمنظومة واحدة، ووجود واحد منها بدون الآخرين لا يحمي النطاق فعلياً
- محاذاة نطاق From مع SPF وDKIM هي الشرط الحقيقي، وليس مجرد وجود السجلات في DNS
- البدء بـ p=none ثم p=quarantine قبل p=reject يمنع فقدان رسائل مشروعة أثناء الانتقال
- أداة اختبار SPF DKIM DMARC (spf dkim dmarc tester) على رسالة حقيقية أدق من فحص DNS منفصل
- فصل نطاق الحملات الموجّهة عن نطاق المراسلات الإدارية يحمي سمعة الشركة الرئيسية
لماذا يتوقف نجاح حملات B2B الموجّهة عند سجلات DNS؟
مزودو البريد الكبار مثل Google Workspace وMicrosoft 365 يعتمدون على المحاذاة بين SPF وDKIM وDMARC ليقرروا هل تصل رسالتك إلى بريد مدير المشتريات الوارد، أم إلى مجلد البريد العشوائي، أم تُرفض قبل أن يراها أحد.
حملات B2B الموجّهة تتميز بحجم إرسال يومي صغير ودرجة شخصنة عالية، وهذا يجعلها أكثر حساسية لثقة النطاق الفنية: كل رسالة تُرسل باسم شخص محدد إلى شركة محددة، وفشل مصداقية واحد يكفي لوضع علامة على النطاق كاملاً عند مزود بريد الشركة المستهدفة.
هذا الدليل يقدّم إعداد SPF وDKIM وDMARC (spf dkim dmarc setup guide) بترتيب تسلسلي واحد فقط: أولاً الإعداد الصحيح في DNS، ثم الاختبار بأداة موثوقة، ثم المراقبة الدورية، قبل أي قرار برفع حجم الإرسال.
خطوة بخطوة: إعداد السجلات الثلاثة في DNS
الترتيب العملي الذي يقلل الأخطاء هو: SPF أولاً لأنه الأبسط، ثم DKIM، ثم DMARC كطبقة تجمع بينهما وتحدد سياسة التعامل مع الرسائل غير المتوافقة.
- SPF: سجل TXT واحد فقط على النطاق الجذر يضم كل مصادر الإرسال المصرح لها (include:_spf.google.com لمن يستخدم Google Workspace، أو النطاق الفني لمنصة الإرسال)، مع عدم تجاوز 10 عمليات بحث DNS داخل السجل.
- DKIM: فعّل التوقيع من لوحة تحكم مزود البريد أو منصة الإرسال، ثم انشر مفتاح selector._domainkey كسجل TXT بطول 2048-bit كلما كان ذلك مدعوماً.
- DMARC: أنشئ سجل _dmarc.yourdomain.com بسياسة أولية p=none مع علامة rua= بعنوان بريد لتلقي تقارير التجميع اليومية.
- تأكد من محاذاة نطاق From الظاهر للمستقبِل مع نطاقي SPF وDKIM الفعليين، فهذا هو الشرط الذي يفحصه DMARC، لا مجرد وجود السجلات الثلاثة منفصلة.
- إذا كنت ترسل من نطاق فرعي مخصص للحملات الموجّهة مثل outreach.yourcompany.com، كرر الإعداد كاملاً عليه، لأن DMARC لا يورّث الحماية تلقائياً بين النطاقات الفرعية ما لم تُحدَّد سياسة sp= صراحة.
اختبار السجلات قبل أي إرسال فعلي
بعد الإعداد، لا تعتمد على أن السجل «يبدو صحيحاً»، بل استخدم أداة اختبار SPF وDKIM وDMARC (spf dkim dmarc tester) ترسل رسالة تجريبية فعلية وتُرجع تقرير رؤوس Authentication-Results الكامل، وهو أدق من فحص وجود السجلات في DNS بشكل منعزل.
بالتوازي، استخدم أداة فحص DMARC (dmarc check tool) للتحقق من صياغة السجل نفسه قبل تفعيله، لأن خطأً بسيطاً في الصياغة يجعل DMARC غير موجود فعلياً من وجهة نظر مزودي البريد رغم ظهوره في DNS.
من واقع إعداد حملات B2B موجّهة عبر منصات إرسال احترافية، هذا هو التوزيع التقريبي لأسباب فشل أول اختبار عند شركات تُعدّ السجلات لأول مرة:
الأرقام تقديرية من ممارسة إعداد حملات B2B موجّهة، وليست دراسة رسمية
أخطاء شائعة تُبطئ أو تُلغي مفعول الإعداد
معظم المشاكل بعد الإعداد الأولي لا تأتي من نقص في المعرفة، بل من تسرّع في التشديد أو إهمال في المتابعة.
- الانتقال مباشرة إلى p=reject دون المرور بمرحلتي none ثم quarantine لأسابيع كافية لمراقبة التقارير أولاً.
- ترك أكثر من سجل SPF واحد على النطاق نفسه، فمزودو البريد يتجاهلون السجل بالكامل عند وجود أكثر من TXT من نوع SPF.
- نسيان تحديث DKIM عند تغيير منصة الإرسال، مثل الانتقال من Google Workspace إلى أداة outreach متخصصة، مما يترك توقيعاً قديماً غير متطابق.
- عدم قراءة تقارير rua الواردة من DMARC بشكل دوري، فتفوت إشارات مبكرة عن انتحال النطاق أو مصادر إرسال غير مصرح بها.
- استخدام النطاق الرئيسي نفسه لحملات الإرسال الموجّه ولمراسلات الإدارة الحساسة، فأي مشكلة سمعة في الحملات تنعكس فوراً على البريد الرسمي.
من none إلى reject: خارطة طريق تدريجية آمنة
التشديد التدريجي عبر علامة pct يتيح تطبيق السياسة على نسبة محدودة من الرسائل أولاً، قبل تعميمها، وهذا يمنع فقدان رسائل مشروعة أثناء الانتقال، خصوصاً لشركات تبدأ للتو حملات B2B موجّهة نحو عملاء في الخليج والشرق الأوسط.
في الإمارات مثلاً، تشترط هيئة تنظيم الاتصالات والحكومة الرقمية (TDRA) في لوائحها الخاصة بالرسائل التجارية الإلكترونية وجود هوية واضحة للمرسل وآلية إلغاء اشتراك، وهو ما يدعم عملياً تطبيق DMARC بشكل صحيح بدلاً من اعتباره عبئاً إضافياً.
نسب pct تقديرية لتوضيح سرعة التشديد الآمن، وتُعدَّل حسب حجم الإرسال الفعلي لكل نطاق
قائمة التحقق النهائية وكيف تتعامل LDM مع الأمر
في LDM، مراجعة السجلات الثلاثة جزء من مرحلة التهيئة الفنية لكل حملة B2B موجّهة، قبل السماح بزيادة حجم الإرسال اليومي، مع مراقبة يومية لسمعة النطاق وربط الردود الفعلية بـ CRM بدلاً من الحكم على النجاح بالحجم فقط.
قائمة تحقق مختصرة قبل إطلاق أي حملة:
- سجل SPF واحد فقط لكل نطاق أو نطاق فرعي مُستخدم في الإرسال
- DKIM مفعّل بمفتاح 2048-bit، مع تحقق فعلي من رأس Authentication-Results في رسالة اختبار
- DMARC يبدأ بـ p=none لأسبوعين على الأقل قبل الانتقال إلى quarantine
- مراجعة تقارير rua أسبوعياً خلال أول شهرين على الأقل
- فصل نطاق الحملات الموجّهة عن النطاق الرئيسي للمراسلات الإدارية
- إعادة الاختبار بعد أي تغيير في منصة الإرسال أو مزود البريد
الأسئلة الشائعة
ما الفرق بين SPF وDKIM وDMARC ولماذا نحتاج الثلاثة معاً؟
SPF يحدد الخوادم المصرح لها بالإرسال نيابة عن النطاق، وDKIM يوقّع الرسالة رقمياً لإثبات عدم تعديلها أثناء النقل، أما DMARC فيربط الاثنين ويحدد ماذا يحدث للرسائل التي تفشل في المحاذاة. غياب أي واحد منها يترك ثغرة يستغلها مزود البريد لتصنيف الرسالة كمشبوهة.
ما أفضل أداة اختبار SPF DKIM DMARC قبل إطلاق حملة؟
أي أداة ترسل رسالة تجريبية فعلية إلى صندوق اختبار وتُرجع تقرير رؤوس Authentication-Results الكامل تكفي. المهم اختبار رسالة حقيقية عبر منصة الإرسال نفسها، لا مجرد فحص وجود السجلات في DNS بشكل منفصل.
هل تعمل أداة فحص DMARC (dmarc checker tool) على النطاقات الفرعية تلقائياً؟
لا، كل نطاق فرعي يحتاج فحصاً مستقلاً، لأن DMARC لا يطبق نفس النتيجة تلقائياً على النطاقات الفرعية ما لم تُحدَّد ذلك صراحة عبر علامة sp= في السجل الرئيسي.
كم من الوقت يستغرق إعداد السجلات الثلاثة والتأكد من عملها؟
الإعداد الفني نفسه يستغرق ساعة إلى ساعتين، لكن المرحلة الآمنة الكاملة من p=none إلى p=reject مع مراقبة التقارير تحتاج عادة أربعة إلى ثمانية أسابيع حسب حجم الإرسال.
أداة فحص DMARC (dmarc check tool) أظهرت فشلاً في المحاذاة رغم إعداد السجلات، ما السبب؟
غالباً السبب أن نطاق From لا يطابق فعلياً نطاق SPF أو selector DKIM المستخدم في الإرسال، وليس خطأً في صياغة سجل DMARC نفسه. راجع رؤوس الرسالة الفعلية بدلاً من إعادة فحص DNS فقط.
هل تتولى LDM إعداد هذه السجلات لعملاء حملات B2B الموجّهة؟
نعم، ضمن مرحلة التهيئة الفنية قبل أي حملة، وتشمل مراجعة السجلات الثلاثة واختبارها قبل السماح بزيادة حجم الإرسال اليومي.