SPF وDKIM وDMARC بشرح مبسط (وكيف تتحقق من إعداداتك في خمس دقائق)
ما فائدة SPF وDKIM وDMARC، وما الذي يطلبه Gmail وYahoo وOutlook الآن، وكيف تقرأ سجلات DNS لديك وتصحح أكثر الأخطاء شيوعاً قبل التنقيب عن العملاء.
نُشر في 10 نوفمبر 2026 · 4 دقيقة قراءة
ثلاثة اختصارات تتكرر كلما تحدثنا عن إمكانية التسليم: SPF وDKIM وDMARC. غالباً ما نُعدّها مرة واحدة، عبر نسخ أسطر وجدناها في صفحة مساعدة مزوّد الاستضافة، ثم ننساها. إلى أن يأتي اليوم الذي تذهب فيه رسائل البريد إلى مجلد الرسائل غير المرغوب فيها، ولا يعود أحد يعرف بدقة ما الذي تم إعداده.
غير أن هذه الآليات الثلاث تجيب عن سؤال بسيط يطرحه كل خادم يتلقى بريدك: «هل تأتي هذه الرسالة فعلاً ممن تدّعي أنها منه؟» ومن دون إجابة واضحة، تُعامَل الرسالة على أنها مشبوهة.
لماذا أصبح ذلك إلزامياً
ظلّت هذه السجلات لفترة طويلة موصى بها بشدة. أما اليوم فهي مطلوبة. في فبراير 2024، فرض Gmail وYahoo على المرسِلين الذين يرسلون أعداداً كبيرة من الرسائل أن يمتلكوا سجلات SPF وDKIM صالحة، وسياسة DMARC منشورة، ورابط إلغاء اشتراك بنقرة واحدة، ومعدل شكاوى منخفضاً. وأعلنت Microsoft متطلبات مماثلة لـOutlook.com، تُطبَّق اعتباراً من مايو 2025.
تستهدف الحدود الرسمية كبار المرسِلين، لكن في الواقع، النطاق الذي يفتقر إلى مصادقة صحيحة تُفلتر رسائله قبل بلوغ تلك الأحجام بكثير. وفي التنقيب عن العملاء، ينبغي اعتبار السجلات الثلاثة الحد الأدنى.
SPF: قائمة الخوادم المصرح لها
SPF (Sender Policy Framework) هو سطر يُنشر في سجلات DNS الخاصة بنطاقك. وهو يقول: «لا يمكن أن تنطلق رسائل هذا النطاق إلا من هذه الخوادم تحديداً». وعندما يتلقى خادم رسالة موقّعة من نطاقك، يتحقق من أن خادم الإرسال مدرج في القائمة.
يبدو سجل SPF على هذا النحو:
v=spf1 include:_spf.mail.hostinger.com ~all
اقرأه من اليسار إلى اليمين: الإصدار، ثم الخوادم المصرح لها (وهي هنا خوادم مزوّد الاستضافة)، ثم ما ينبغي فعله بالخوادم الأخرى. وتطلب «~all» الأخيرة التعامل مع الخوادم الأخرى بحذر من دون رفضها، وهو خيار حصيف.
أكثر الأخطاء شيوعاً:
- سجلا SPF على النطاق نفسه: هذا غير مسموح، وتصبح النتيجة غير صالحة. يجب دمج السجلين في سطر واحد؛
- خدمة منسية: أنت ترسل أيضاً فواتير من برنامج طرف ثالث، لكنه غير موجود في القائمة؛
- كثرة «include»: يحدّ SPF عدد عمليات البحث في DNS بعشر. وما يزيد على ذلك يُفشل السجل.
DKIM: توقيع الرسالة
يُضيف DKIM (DomainKeys Identified Mail) إلى كل رسالة بريد توقيعاً مشفّراً. يوقّع خادم الإرسال بمفتاح خاص، ويُنشر المفتاح العام المقابل له في سجلات DNS لديك. ويتحقق المستلم من التوقيع: فإن كان صالحاً، علم أن الرسالة تأتي فعلاً من نطاقك وأنها لم تُعدَّل في الطريق.
يوجد المفتاح العام في عنوان DNS محدد، يُبنى باستخدام «مُحدِّد» يختاره مزوّد الاستضافة، على سبيل المثال:
hostingermail1._domainkey.votredomaine.fr
وهنا تكمن معظم مشكلات DKIM: مفتاح نُسخ ناقصاً (فهي طويلة)، أو مُحدِّد مختلف عن الذي يستخدمه الخادم فعلاً، أو مفتاح لم يُنشر قط لأن مزوّد الاستضافة كان ينتظر تفعيلاً يدوياً. والتحقق الوحيد الموثوق هو إرسال بريد حقيقي والنظر في ترويسته عند الوصول.
DMARC: التوجيه عند فشل التحقق
يربط DMARC (Domain-based Message Authentication, Reporting and Conformance) بين السجلين السابقين. فهو يطلب من الخادم المستلِم: «إذا ادّعت رسالة أنها من نطاقي لكنها فشلت في SPF وDKIM، فها هو ما عليك فعله بها». كما يتيح لك تلقي تقارير عن الرسائل المرسلة باسمك.
يبدو سجل DMARC الأولي على هذا النحو:
v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr
تعني «p=none»: عدم حجب أي شيء، لكن مع إرسال التقارير. وهي السياسة الدنيا التي يطلبها Gmail وYahoo، ونقطة بداية جيدة. وبعد أن تتأكد من أن جميع إرسالاتك المشروعة تجتاز المصادقة، يمكنك الانتقال إلى «p=quarantine» (وضع الرسائل غير الموثقة في مجلد الرسائل غير المرغوب فيها)، ثم إلى «p=reject» عند الحاجة.
وهناك نقطة دقيقة: يشترط DMARC أن يكون النطاق الموثَّق عبر SPF أو DKIM هو نفسه النطاق الظاهر في عنوان الإرسال. وهذا ما يُعرف بالمحاذاة. فبريد يُرسَل من paul@votredomaine.fr لكنه موقَّع بـDKIM من النطاق التقني لمزوّد الاستضافة قد يجتاز DKIM ومع ذلك يفشل في DMARC.
تحقق من سجلاتك في خمس دقائق
لست بحاجة إلى أن تكون مسؤول نظام. تكفي ثلاث عمليات تحقق:
- افحص سجلات TXT لنطاقك بأداة بحث DNS على الإنترنت. يجب أن تجد سطراً واحداً فقط يبدأ بـ«v=spf1»، وسطر «v=DMARC1» على العنوان _dmarc.votredomaine.fr.
- أرسل بريداً من صندوق البريد المعني إلى عنوان Gmail شخصي، ثم افتحه واعرض الرسالة الأصلية. يُظهر Gmail بوضوح «SPF: PASS» و«DKIM: PASS» و«DMARC: PASS»، مع النطاق المستخدم لكل منها.
- تحقق من أن النطاق المذكور في DKIM هو نطاقك فعلاً، لا نطاق مزوّد الاستضافة.
في SmartOutbound، يُجرى هذا التحقق تلقائياً: يُفحص كل نطاق يومياً، ويؤكد بريد اختباري يُرسَل عند ربط صندوق البريد توقيع DKIM الفعلي الذي لوحظ عند الوصول، ويُعيد زر «التحقق من DNS» في صفحة صناديق البريد تشغيل الفحص عند الطلب. وإذا كان DMARC مفقوداً وكان نطاقك لدى Hostinger، تستطيع الأداة إضافته لك حتى.
وماذا عن الباقي؟
لا تضمن هذه السجلات الثلاثة أن رسائلك ستبلغ صندوق الوارد. إنها تضمن فقط أنها لن تُرفض لسبب تقني كان يمكن تفاديه. أما ما بعد ذلك فيعتمد على سمعة نطاقك، وجودة قوائمك، ومحتوى رسائلك. وبالنسبة إلى النطاقات الجديدة، ينبغي أيضاً احتساب مدة التسخين. وإن كنت متردداً في التنقيب عن العملاء من نطاقك الرئيسي، فسيساعدك مقالنا عن النطاق المخصص على حسم القرار.
الأسئلة الشائعة
+هل يمكن أن يكون لدينا سجلان لـSPF؟
لا. يجب ألا ينشر النطاق إلا سطر SPF واحداً. وإذا كنت تستخدم خدمات إرسال عدة، فأضفها كلها في السجل نفسه بذكر «include» عدة مرات.
+أي سياسة DMARC تختار للبداية؟
«p=none» مع عنوان لتلقي التقارير. وهي الحد الأدنى الذي يطلبه Gmail وYahoo. انتقل إلى «p=quarantine» بعد أن تصبح جميع إرسالاتك المشروعة موثقة بشكل صحيح.
+كم يستغرق حتى يُعتمد تعديل DNS؟
غالباً بضع دقائق، وأحياناً بضع ساعات حسب مدة التخزين المؤقت (TTL) للسجلات. وإذا لم يتغير شيء بعد 24 ساعة، فالمرجح أن السجل أُدخل بشكل خاطئ.
+هل تكفي SPF وDKIM وDMARC لتجنب الرسائل غير المرغوب فيها؟
لا. هي ضرورية لكنها غير كافية. فسمعة النطاق، وحجم الإرسال، وجودة العناوين، ومحتوى الرسائل، كلها تلعب دوراً لا يقل أهمية.