SPF وDKIM وDMARC: الأساس الذي يقرر وصول رسائل التواصل البارد B2B من عدمه

أي فريق مبيعات يرسل رسائل تواصل بارد إلى جهات اتصال محدّدة في شركات مستهدفة سيصطدم عاجلاً بثلاثة اختصارات: SPF وDKIM وDMARC. بدونها، حتى رسالة مكتوبة بعناية لشخص واحد ومخصّصة له قد تنتهي في مجلد Spam أو تُرفض قبل أن تصل. هذا الدليل يشرح كل بروتوكول بشكل عملي، بلا تعقيد تقني زائد، مع ما يهمّ فريق مبيعات B2B تحديداً وليس مرسلي النشرات الجماعية.

لماذا يهتم فريق مبيعات B2B بهذه البروتوكولات أصلاً

التواصل البارد الموجّه (cold email) يختلف جوهرياً عن الإرسال الجماعي: رسالة واحدة إلى مدير مشتريات محدد في شركة محددة، بحجم يومي صغير، وبمحتوى مخصّص لسياقه. لكن من زاوية خوادم البريد المستقبِلة (Gmail، Outlook، بريد الشركات)، لا فرق في آلية الفحص الأولى: هل هذا النطاق مُصادق عليه فعلاً؟ رسالة من نطاق بلا SPF أو DKIM أو DMARC صحيحة تبدو من منظور تقني مطابقة لرسالة مُنتحلة، حتى لو كان المرسل شخصاً حقيقياً يكتب بيده لعميل محتمل حقيقي.

المشكلة تتفاقم مع نطاقات الشركات في منطقة الخليج والشرق الأوسط تحديداً، لأن كثيراً منها استُخدم لسنوات فقط للتواصل الداخلي أو الفواتير، ولم يُضبط أصلاً لإرسال بريد خارجي بانتظام. عندما يبدأ فريق المبيعات حملة تواصل بارد من نطاق كهذا دون تجهيزه، النتيجة المعتادة هي معدل وصول منخفض ومعدل رد شبه معدوم، بصرف النظر عن جودة الرسالة نفسها.

الخلاصة العملية: قبل أي نقاش حول صياغة الرسالة أو توقيت الإرسال أو حجم القائمة، يجب التأكد من أن النطاق المُرسِل منه مُهيأ بشكل صحيح. هذا ليس تفصيلاً تقنياً هامشياً، بل هو الشرط الذي يحدد ما إذا كانت الرسالة ستُقرأ أصلاً.

SPF: من المسموح له الإرسال باسم نطاقك

SPF (Sender Policy Framework) هو سجل نصي (TXT) في DNS يُدرج فيه أصحاب النطاق قائمة بالخوادم والخدمات المصرّح لها بإرسال بريد باسم هذا النطاق. عندما يستقبل خادم بريد رسالة، يتحقق من عنوان IP المُرسِل مقابل هذه القائمة. إذا لم يكن الـ IP مذكوراً، فهذا مؤشر قوي على أن الرسالة قد تكون منتحلة أو غير مصرّح بها.

سجل SPF بسيط يبدو كالتالي: v=spf1 include:_spf.google.com include:sendgrid.net ~all. كل جزء include يشير إلى خدمة مسموح لها بالإرسال، وas مقطع all في النهاية يحدد ماذا يحدث لأي مرسل آخر غير مذكور (~all يعني فشل ناعم، -all يعني رفض صارم).

القيد الأهم الذي يتجاهله كثيرون: SPF يسمح بحد أقصى عشرة عمليات بحث DNS (lookups) ضمن السجل الواحد، وأي تجاوز لهذا الحد يجعل الفحص كله يفشل بصمت. شركة تستخدم عدة أدوات إرسال (بريد الموظفين، أداة CRM، أداة تواصل بارد) يجب أن تراجع سجل SPF دورياً حتى لا تتراكم فيه includes زائدة تتجاوز الحد.

DKIM: التوقيع الذي يثبت أن الرسالة لم تُعبث بها

DKIM (DomainKeys Identified Mail) يعمل بمنطق مختلف تماماً عن SPF. بدلاً من التحقق من عنوان IP، يُضاف توقيع رقمي مشفّر إلى رأس كل رسالة صادرة، باستخدام مفتاح خاص محفوظ لدى مزوّد الإرسال. خادم الاستقبال يجلب المفتاح العام المقابل من سجل DNS للنطاق (عادة على شكل selector._domainkey.yourdomain.com) ويتحقق من أن التوقيع صحيح وأن محتوى الرسالة لم يتغيّر أثناء النقل.

الفائدة العملية لفريق التواصل البارد: DKIM يحمي من مشكلة شائعة وهي أن بعض الخوادم الوسيطة (relays) قد تعدّل رأس الرسالة أثناء التمرير، فيفشل التحقق ويُنظر إلى الرسالة كمشبوهة. توقيع DKIM صحيح يمنح الرسالة مصداقية إضافية مستقلة عن مصدر IP.

نقطة عملية غالباً ما تُنسى: مزوّدو الخدمة الكبار (Google Workspace، Microsoft 365، أدوات التواصل البارد المتخصصة) يوفرون لكل منهم selector خاصاً به. إذا غيّرت الشركة أداة الإرسال أو أضافت أداة جديدة، يجب إضافة سجل DKIM منفصل لها في DNS، وإلا ستُرسل رسائل بلا توقيع صالح من تلك الأداة تحديداً.

DMARC: السياسة التي تجمع الاثنين وتقرر مصير الرسالة

DMARC (Domain-based Message Authentication, Reporting and Conformance) هو الطبقة الثالثة التي تربط SPF وDKIM معاً، وتضيف شرطاً مهماً اسمه المحاذاة (alignment): يجب أن يتطابق نطاق الرسالة الظاهر في خانة From مع النطاق الذي اجتاز SPF أو DKIM، وليس فقط أن يجتاز أحدهما لأي نطاق كان. بدون DMARC، يمكن لمرسل خبيث أن يمرّر SPF بنطاق مختلف تماماً عن النطاق الظاهر للمستلم.

سجل DMARC يوضع أيضاً كـ TXT على _dmarc.yourdomain.com، ويحدد سياسة واضحة عبر وسم p=: none (لا إجراء، فقط مراقبة وتقارير)، quarantine (إرسال الرسائل المشبوهة إلى Spam)، أو reject (رفضها كلياً قبل وصولها). السجل يتضمن أيضاً عنوان بريد لاستقبال تقارير rua التي تُظهر من يرسل باسم نطاقك فعلياً، وهي أداة تشخيص قيّمة لا يستغلها كثيرون.

الممارسة السليمة لنطاق شركة يبدأ التواصل البارد لأول مرة هي التدرّج: البدء بـ p=none لمدة أسبوعين إلى أربعة أسابيع لمراقبة التقارير والتأكد من أن كل مصادر الإرسال المشروعة (بريد الموظفين، أدوات المبيعات) تمرّ المحاذاة بنجاح، ثم الانتقال إلى quarantine، وأخيراً reject بعد التأكد التام. القفز المباشر إلى reject قبل التحقق قد يُسقط رسائل مشروعة من الشركة نفسها.

كيف تعمل الثلاثة معاً أثناء تسليم رسالة واحدة

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

النتيجة النهائية ليست ثنائية (وصول أو رفض) فقط؛ كثير من مزوّدي البريد يستخدمون نتيجة هذا الفحص كإشارة ضمن نظام تسجيل نقاط أوسع يشمل سمعة IP وسلوك المستلمين السابقين ومحتوى الرسالة. رسالة تجتاز الثلاثة بنجاح تبدأ من نقطة أفضل بكثير في هذا التقييم، لكنها ليست ضمانة مطلقة إذا كانت عناصر أخرى (كالحجم أو النمط المشبوه) موجودة.

أخطاء شائعة عند إعداد هذه السجلات لأول مرة

معظم المشكلات التي يقابلها فريق مبيعات يبدأ تواصلاً بارداً من نطاق شركته لأول مرة تتكرر بنفس الأنماط تقريباً، ومعرفتها مسبقاً توفر وقتاً كبيراً.

• نسيان تحديث سجل SPF بعد إضافة أداة إرسال جديدة (مثل أداة تواصل بارد متخصصة) إلى جانب بريد الموظفين
• تجاوز حد عشر عمليات بحث DNS في SPF بسبب تراكم includes قديمة لم تُنظّف
• الانتقال المباشر إلى p=reject في DMARC دون مرحلة مراقبة، فتُرفض رسائل مشروعة من داخل الشركة نفسها
• استخدام نفس النطاق الرئيسي للإرسال البارد وللمراسلات اليومية الحساسة (فواتير، عقود)، فيؤثر أي تدهور في سمعة الحملة على البريد الحيوي
• الاعتماد على SPF فقط وترك DKIM غير مفعّل، رغم أن DKIM أكثر مقاومة لمشاكل إعادة التوجيه عبر الخوادم الوسيطة
• عدم مراجعة تقارير rua من DMARC، فتفوت الشركة اكتشاف مصدر إرسال غير مصرّح به باسم نطاقها

الأسئلة الشائعة