شرح SPF و DKIM و DMARC

بقلم فريق زمام · 29 May 2026

صُمّم البريد الإلكتروني في زمن كانت الثقة فيه هي الأصل، والبروتوكول الذي ما زال يحمله حتى اليوم¹ يسمح ببساطة لأي خادم أن يدّعي الإرسال من أي عنوان. لا شيء في التصميم الأصلي يمنع غريباً من أن يكتب اسمك في خانة “المُرسِل”. ولهذا فإن كل ما نسمّيه اليوم مصادقة البريد ليس سوى رقعٍ أُضيفت لاحقاً للإجابة عن سؤال لم يطرحه البروتوكول قط: هل هذه الرسالة فعلاً ممّن تدّعي أنها منه؟

تجيب عن هذا السؤال ثلاثة سجلات تعيش في نظام أسماء النطاقات² الخاص بك، حيث يقرؤها الجميع — بمن فيهم المهاجم الذي يقرّر هل يستحق نطاقك عناء الانتحال.

SPF: مَن يحقّ له التحدث باسمك

سجلّ سياسة المُرسِل³ قائمة عامة بالخوادم والخدمات المسموح لها بإرسال البريد باسم نطاقك. فما إن تصل رسالة حتى يبحث الخادم المستقبِل عن هذا السجلّ لديك ويتحقق هل الخادم المُرسِل ضمن القائمة. ويبدو السجلّ المعتاد على هذا النحو:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

تفوّض مدخلات include: الثقة إلى مُرسِلين آخرين، كمزوّد بريدك أو أداة نشراتك. أمّا -all في النهاية فهي موضع الخطأ الشائع: معناها “ارفض كل ما ليس في القائمة”. وحين تُنهي السجلّ بدلاً من ذلك بـ ~all (فشل ليّن) أو تحذفها أصلاً، فأنت تطلب من الخوادم أن تتساهل مع البريد غير المصرّح به.

ملاحظة دقّة. يصادق SPF على خوادم الإرسال في مسار الظرف (MAIL FROM / HELO)، وهو وحده لا يثبت النطاق الظاهر للمستخدم في خانة “المُرسِل”. المطابقة في DMARC هي ما يربط نجاح SPF أو DKIM بذلك النطاق الظاهر.

ولهذا السجلّ حدّ شهير: لا يجوز أن يُطلق أكثر من عشر عمليات بحث في DNS وهو يوسّع سلاسل include:، فإن تجاوزها انهار السجلّ كله إلى خطأ تعامله الخوادم معاملة الفشل. وبما أن include: يفوّض الثقة إلى نطاق لا تملكه، فإن مدخلاً منسيّاً يشير إلى نطاق منتهي الصلاحية يفتح باب الاستيلاء على مصراعيه — وهو بالضبط ما جرى في حملة SubdoMailing التي أرسلت ملايين الرسائل المزعجة يومياً، مصادَقةً بالكامل عبر هذا السجلّ، من علامات تجارية لم تفعل سوى أنها كفّت عن ترتيب سجلاتها.

DKIM: ختمٌ يكشف العبث

يحدّد سجلّ سياسة المُرسِل من أين يجوز أن يأتي البريد، لكنه لا يقول شيئاً عمّا إذا كانت الرسالة قد عُبث بها في الطريق. وهنا يأتي دور البريد المُعرَّف بمفاتيح النطاق⁴: يوقّع خادم بريدك كل رسالة صادرة بمفتاح تشفير خاص، بينما يجلس المفتاح العام المطابق له في DNS. وحين يتحقق المستقبِل من التوقيع يعرف أمرين معاً: أن الرسالة جاءت فعلاً من نطاقك، وأن محتواها الموقَّع لم يتبدّل في الطريق. وهذا التوقيع هو الجزء الذي ينجو من معظم عمليات إعادة التوجيه، ولهذا يتّكئ عليه السجلّ الثالث.

DMARC: السياسة التي تمنح السجلّين الآخرين قيمتهما

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

v=DMARC1; p=reject; rua=mailto:[email protected]

وتتصاعد السياسة على ثلاث درجات:

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

غير أن قوة هذه السياسة الحقيقية تكمن في المطابقة (alignment): إذ تشترط أن يتطابق النطاق الذي يراه الإنسان في خانة “المُرسِل” مع النطاق الذي صادق عليه أحد السجلّين الآخرين فعلاً. وبهذا تُهزم محاولات الانتحال المشابه، لأن المهاجم لا يملك أن يطابق نطاقاً ليس له.

لماذا لم يعد هذا اختيارياً

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

كيف يساعد زمام

حين يراجع زمام نطاقاً، يقرأ سجلاته الثلاثة العامة ويُبرز ما يهمّ من الإخفاقات: سياسة مفقودة، أو ~all كان الأولى أن تكون -all، أو سجلّ يتجاوز حدّ العشر عمليات بحث، أو سياسة لا تزال عند p=none بعد طول إعداد. وكل فحص يقرأ DNS العام وحده — لا يُرسَل شيء، ولا يُمسّ أي بريد.

ذات صلة

• كيف تتحقق من سجل SPF
• كيف تُعدّ DMARC خطوة بخطوة
• لماذا تنتهي رسائلك في صندوق الإزعاج؟
• من المدوّنة: بريدٌ مزعج من نطاقٍ لم يعد يملكه أحد

الهامش