كيف تبني سجل DMARC وتنتقل بسياسته من none إلى reject دون كسر التسليم

كل مرة يفتح فيها خادم بريد رسالة من نطاقك، يسأل سؤالاً واحداً بصمت: هل يحق لهذا المُرسِل أن يتحدث باسم هذا النطاق؟ سجل DMARC هو من يجيب. المشكلة أن أغلب من يولّده يكتفي بنسخ سطر جاهز من أداة أونلاين ثم ينساه، فتبقى السياسة عند p=none إلى الأبد، أو يقفز صاحبها مباشرة إلى reject فيوقف وصول حملات تواصل بارد سليمة 100 بالمئة. هذا الدليل يشرح كيف تبني السجل بشكل صحيح وكيف تتدرّج بالسياسة بأمان.

ما الذي يفعله سجل DMARC فعلياً

DMARC يعني Domain-based Message Authentication, Reporting and Conformance، وهو الطبقة الثالثة فوق SPF وDKIM. لا يتحقق الأخيران من الهوية بمفردهما بشكل كافٍ للمستقبِل: قد ينجح SPF لأن الخادم مصرح له بالإرسال، لكن حقل From يظل مختلفاً عن النطاق الفعلي المُرسِل. DMARC يربط النتيجتين بمفهوم يسمى Alignment، ثم يخبر خادم الاستقبال بوضوح ماذا يفعل عند الفشل: لا شيء، أو عزل في مجلد مشبوه، أو رفض تام.

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

تركيب سجل DMARC حقلاً بحقل

السجل نفسه هو TXT واحد فقط تحت _dmarc.نطاقك.com، ووجود أكثر من سجل واحد في هذا الموضع يجعل DMARC بالكامل غير صالح من منظور المستقبِل حتى لو كان كل سطر صحيحاً على حدة. البنية تتكون من أزواج مفتاح=قيمة مفصولة بفاصلة منقوطة، وأهم الحقول تُقرأ بالترتيب التالي.

استخدام مولّد جاهز — سواء أداة عامة أو مولّد داخل موقع فحص مثل مولّدات mxtoolbox — يوفر عليك أخطاء الصياغة الشائعة كنسيان علامة الاقتباس أو ترتيب الحقول الخاطئ، لكنه لا يعرف حجم إرسالك ولا نطاق نضج بنيتك التحتية. القرارات الثلاثة الحقيقية — قيمة p، ونسبة pct، وعنوان استقبال التقارير rua — تبقى قراراً بشرياً يجب اتخاذه بناءً على بيانات فعلية لا على القيمة الافتراضية للأداة.

• v=DMARC1 — إصدار البروتوكول، ثابت دائماً
• p= — السياسة الرئيسية: none أو quarantine أو reject
• rua=mailto:عنوان — أين تُرسل تقارير الملخص اليومية (aggregate reports)
• ruf=mailto:عنوان — تقارير فورية عن كل حالة فشل (اختياري، ويكشف بيانات حساسة فتجنّبه إن لم تكن مضطراً)
• pct= — النسبة المئوية من الرسائل التي تُطبّق عليها السياسة، مفيدة للتدرّج الآمن
• adkim= وaspf= — صرامة المحاذاة، s للصارمة وr للمرنة
• sp= — سياسة منفصلة للنطاقات الفرعية إن أردت معاملتها بشكل مختلف عن النطاق الرئيسي

ثلاث مراحل التدرّج: none إلى quarantine إلى reject

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

المسار الآمن عملياً هو البقاء في p=none حتى ترى في التقارير أن كل مصادر الإرسال الشرعية تمر بمحاذاة ناجحة، ثم الانتقال إلى quarantine بنسبة pct منخفضة (10 إلى 25 بالمئة) ورفعها تدريجياً على مدى أسبوعين، ثم أخيراً reject بنفس المنطق. لا يوجد جدول زمني واحد يناسب الجميع، لكن الأرقام أدناه تعكس المدى الذي نراه عملياً في نطاقات إرسال B2B متوسطة الحجم.

قراءة تقارير rua واتخاذ قرار الترقية

تقارير rua تصل بصيغة XML مضغوطة يومياً من كل مزود بريد رئيسي تعامل مع نطاقك، وتحتوي لكل عنوان IP مُرسِل: عدد الرسائل، ونتيجة SPF، ونتيجة DKIM، ونتيجة المحاذاة الكلية. القراءة اليدوية لهذه الملفات مرهقة، لذا يفضّل أغلب الفرق تمرير التقارير عبر لوحة تجميع بسيطة أو حتى جدول بيانات يستخرج منها الحقول المهمة أسبوعياً.

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

أخطاء شائعة عند توليد السجل وضبط السياسة

أغلب الأعطال التي نراها في نطاقات عملاء B2B لا تأتي من تعقيد البروتوكول، بل من تسرّع في الإعداد أو نسيان تفصيل صغير أثناء التوليد.

• أكثر من سجل TXT واحد تحت _dmarc — يُبطل السياسة بالكامل بغض النظر عن صحة كل سطر
• القفز إلى p=reject في اليوم الأول دون أي فترة مراقبة
• نسيان sp= فيصبح النطاق الفرعي بلا حماية بينما النطاق الرئيسي محمي بالكامل
• الاعتماد على مولّد سجل دون مراجعة القيمة الافتراضية لـ pct التي قد تكون 100 منذ البداية
• عدم تضمين خدمة تتبّع الفتح والنقر أو منصة الحملة ضمن SPF وDKIM قبل تفعيل DMARC صارم
• تجاهل تقارير ruf الفورية التي قد تكشف محاولات انتحال مبكرة

أثر DMARC على وصول حملات التواصل البارد تحديداً

الفارق الجوهري بين تواصل بارد B2B مسؤول وبين الإرسال الجماعي العشوائي هو أن الأول يستهدف عدداً محدوداً من صناع القرار بأسماء ومناصب محددة، برسائل شخصية ومحتوى مخصص لكل شركة، وبحجم يومي منخفض من نطاق واحد أو عدة نطاقات مُدارة بعناية. هذا النمط بالذات هو الأكثر حساسية لغياب DMARC، لأن حجمه الصغير يجعل أي خلل في المحاذاة يظهر بوضوح في عيّنة صغيرة من الرسائل بدل أن يذوب في آلاف الرسائل.

من واقع العمل مع فرق مبيعات ووكالات تواصل، النطاقات التي تُبنى عليها الحملات الباردة تستفيد من DMARC مرتين: مرة كإشارة ثقة إضافية يقرأها خوارزم تصنيف البريد عند مزودات مثل Gmail وOutlook، ومرة كحماية فعلية من انتحال النطاق في حملات تصيّد قد تضر بسمعة الشركة لدى نفس العملاء المستهدفين.

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