أي شخص يستطيع إرسال بريد باسم نطاقك، حتى تنشر هذه السجلات

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

لماذا يستطيع أي شخص أن يرسل باسم نطاقك؟

لأن البروتوكول يفصل الادعاء عن الإثبات. العنوان الذي يُسلّم منه البريد، أي مرسل الظرف، قيمة يعلنها الخادم المرسل، وسطر «من» الذي يقرأه المستلم ترويسة يكتبها المرسل. ولا شيء في SMTP يفحص أيا منهما. لا يملك الخادم المستقبل إلا أن يسأل نطاقك، في نظام أسماء النطاقات (DNS)، عما يتوقعه وما يفعل بغيره. ولا جهة إصدار شهادات في هذا المسار.

ماذا يثبت SPF فعلا؟

يسرد إطار سياسة المرسل (SPF) الخوادم المسموح لها الإرسال عن النطاق، ويقارن المستقبل الخادم المتصل بتلك القائمة. سجل TXT واحد يبدأ بـ v=spf1، وفيه آليات مثل include: وip4:، وينتهي بـ -all أو ~all.

وهو يثبت المسار لا الرسالة: النجاح يعني أن هذا الخادم كان مسموحا، لا أن المحتوى سليم. وتترتب نتيجتان. ينهار SPF عند إعادة التوجيه، لأن معيد الإرسال يصبح المرسل وليس في قائمتك. وله ميزانية استعلامات في DNS، وتجاوزها يعيد خطأ يقرأه معظم المستقبلين كغياب لـ SPF.

لماذا يُسمح بسجل SPF واحد لكل اسم؟

لأن المواصفة تسمح بسجل واحد، والسجلان لا يندمجان بل يبطل كل منهما الآخر. سجلان يبدآن بـ v=spf1 لا يتركان للمستقبل قاعدة يختار بها، والنتيجة خطأ.

ويحدث هذا عادة في الترحيل: يبقى سجل المستضيف القديم ويضاف الجديد إلى جانبه. والإصلاح سجل واحد يحمل كل الآليات، وinclude تدخل في الميزانية نفسها. سجل واحد فيه أحد عشر include يفشل أيضا.

ماذا يضيف DKIM؟

التوقيع بالمفاتيح المنشورة (DKIM) يوقّع الرسالة. يبصم المرسل ترويسات مختارة ومتن الرسالة، ويوقّع البصمة بمفتاح خاص، ويضيف التوقيع، ويُنشر المفتاح العام في DNS تحت اسم محدد، فيتحقق المستقبل منه.

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

ماذا يفعل DMARC حين يفشل الاثنان؟

يربط المصادقة والتقارير والامتثال القائم على النطاق (DMARC) النتيجتين بالنطاق الذي يراه المستلم. ويشترط المطابقة: ما نجح من SPF أو DKIM يجب أن يطابق نطاق «من». رسالة تنجح في SPF لنطاق مزوّد بريدي وتحمل عنوانك في «من» غير مطابقة، وتُحسب فشلا.

ثم يعلن سياسة للبريد الذي يفشل في الاثنين، ويطلب تقارير. وRFC 7489 صريح في أن هذا طلب: يطبّق المستقبل تقديره، والسياسة المنشورة بيان نية تحترمه المستقبلات الكبرى عادة.

ويسري على النطاقات الفرعية ما لم يكن لها سجل خاص، ويستثنى منها ما يحدده sp=. ونطاق فرعي قديم يخدم نظاما داخليا لم يعد أحد يتذكره يكفي وحده لتعطيل سياسة الرفض.

ماذا يتغير فعلا بين p=none وp=reject؟

وسم السياسة هو الفرق الوحيد الذي يتصرف عليه المستقبل، وهو الفرق بين تقرير وحاجز.

السياسة	ما يُطلب من المستقبل	متى تُستخدم
p=none	التسليم كالمعتاد وإرسال التقارير	الاستكشاف: رؤية كل مرسل أولا
p=quarantine	معاملة البريد الفاشل كبريد مشبوه	المرحلة الانتقالية، بنسبة جزئية
p=reject	رفض البريد الفاشل	بعد نجاح كل مرسل في المصادقة

p=none لا يحمي شيئا: البريد المنتحل يصل، والقيمة كلها في تقارير التجميع التي تسرد الخوادم التي ترسل باسم نطاقك. وفي هذه المرحلة تجد نظام الفواتير على خادم لم يتذكره أحد. أما p=reject فهو الموضع الذي يتوقف فيه الانتحال، والموضع الذي يصير فيه مرسل منسي انقطاعا: فواتيرك وإعادة تعيين كلمات المرور تختفي، وأول تقرير يصل من عميل.

بأي ترتيب تنشرها دون تعطيل فواتيرك؟

1. احصر كل مرسل. نموذج الموقع، ونظام المحاسبة الذي يرسل الفواتير، والنشرة البريدية، ونظام علاقات العملاء، ونظام التذاكر، ومزوّد الدفع، والتنبيهات، وسكربت على خادم قديم. اسأل كل نظام عن العنوان الذي يرسل منه.
2. انشر سجل SPF واحدا يغطيها، وأحص استعلامات DNS التي يحتاجها. وقرب الحد انقل مرسلا إلى نطاق فرعي بسجله، بدل إضافة include آخر.
3. فعّل DKIM حيث يدعمه المرسل، وسجل اسم المحدد لكل نظام. التوقيع لكل نظام على حدة: من يوقّع نشرتك لا يوقّع فواتيرك.
4. انشر DMARC عند p=none مع صندوق بريد تفتحه فعلا، واتركه أسابيع. وأضف sp= إن كانت النطاقات الفرعية ترسل بريدا.
5. أصلح ما تظهره التقارير. المصدر المشروع الذي يفشل إما غائب من SPF، أو لا يوقّع، أو يرسل عبر مزوّد يعيد كتابة نطاق «من»؛ والثالث إعداد عند المزوّد لا عندك.
6. انتقل إلى الحجر ثم الرفض، واقرأ التقارير بعد كل خطوة. واستمر في قراءتها: أداة تُضاف بعد ستة أشهر تكسر المطابقة بهدوء.

أين ينكسر هذا؟

• سجلان لـ SPF بعد ترحيل. مضبوط في العين، خطأ عند المستقبل.
• سلسلة include تتجاوز حد الاستعلامات. الفشل صامت حتى يتوقف وصول البريد.
• DKIM على النطاق الرئيسي وحده، والفواتير تخرج من نطاق فرعي.
• p=reject في خطوة واحدة يوم خميس. التنفيذ قبل الاستكشاف يحوّل بريدك التشغيلي إلى طابور دعم.
• لا أحد يقرأ تقارير التجميع، وهي مرفقات XML، فتُنشر السياسة على غير بصيرة.
• الخلط بين هذا وبين النطاقات الشبيهة. DMARC يمنع انتحال نطاقك، ولا يقول شيئا عن نطاق بعيد بحرف، وهو الطريق الذي يصل منه احتيال الفواتير.
• افتراض أن صندوق البريد محمي. البريد من حساب مخترق فعلا ينجح في الثلاثة، لأنه صدر من نظامك.

ما الذي لا يغطيه هذا المقال؟

هذه مصادقة لا أمن محتوى: رسالة تنجح في الثلاثة وتبقى احتيالية في ما تطلبه. ولا تشفير هنا، ولا وقف لصندوق مخترق، ولا تغطية للنطاقات الشبيهة أو التلاعب باسم العرض. والتنفيذ تقدير المستقبل، والنشر يفترض السيطرة على DNS، وقد تكون بيد من بنى الموقع. نشرنا هذه السجلات على نطاقنا، ووجدت مرحلة الاستكشاف مرسلا نسيه الفريق. وهي تجعل الانتحال صعبا لا مستحيلا.

نبني مسار البريد وسجلاته معا، لأن نطاقا لا يستطيع أن يعلن من يرسل باسمه نطاق يستعيره أي أحد.