انتقل للمحتوى
البريد والجدولة

ضبط SPF وDKIM وDMARC لبريد ووردبريس: تجربة توقيع وفحص

رسائل ووردبريس بتوصل spam او بتنرفض رغم ان SMTP بحكي sent؟ غالبا لازم تفصل بين ثلاث طبقات: مين مسموح يرسل باسم النطاق، هل الرسالة موقعة، وهل نطاق التوقيع او مسار الارجاع متوافق مع العنوان الظاهر للناس. هون بيجوا SPF وDKIM وDMARC.

ما غيرنا DNS الحقيقي لـ semsemm.com من جهاز محلي، وما رح ندعي ان Gmail فحصه. بدل هيك بنينا منطقة DNS تجريبية لنطاق smsm-mail.test، ولدنا مفتاح RSA بطول 2048 بت، وقعنا رسالة فعلية، ثم شغلنا مدققا محليا قبل السجلات وبعدها. التجربة بتثبت المنطق والتوقيع والمحاذاة، اما فحص الدومين الحقيقي لازم يتكرر بعد ربط مزود البريد على الاستضافة.

المشكلة نفسها تظهر في دعم ووردبريس عند مقارنة DNS وسجل الخادم وفي نقاش ريديت عن نجاح بريد Workspace وفشل بريد ووردبريس. متطلبات مرسلي Gmail الرسمية تشرح المصادقة والمحاذاة، ودليل Cloudflare يوضح مواقع السجلات ووظيفتها.

نتيجة تجربتنا

  • قبل السجلات: SPF none وDKIM none وDMARC fail.
  • SPF سمح فقط لعنوان الاختبار 192.0.2.44.
  • DKIM استخدم مفتاح RSA بطول 2048 بت وSHA-256.
  • التحقق من التوقيع بالمفتاح العام نجح.
  • نطاق From وReturn-Path ونطاق DKIM كانوا متوافقين.
  • بعد الاعداد: SPF pass وDKIM pass وDMARC pass داخل المدقق المحلي.

قبل الاعداد

الرسالة خرجت من عنوان اختبار ووصلت للمدقق من غير اي TXT في المنطقة. ما في سجل يصرح لعنوان IP، وما في توقيع، وما في سياسة DMARC. النتيجة كانت واضحة:

تقرير محلي يظهر SPF وDKIM بلا نتيجة وDMARC فاشل قبل اضافة سجلات المصادقة
ثلاث اشارات ناقصة قبل اضافة سجلات المصادقة.

سجلات DNS التي اضفناها

سجل SPF كان v=spf1 ip4:192.0.2.44 -all. هاي صيغة مختبر ضيقة، ومش نص تنسخه لموقعك. سجل DKIM انحط تحت lab2026._domainkey وحمل المفتاح العام. سجل DMARC انحط تحت _dmarc وبدأ بسياسة p=none للمراقبة.

منطقة DNS تجريبية تعرض سجل SPF المحدد ومضيف DKIM وسياسة DMARC للمراقبة
منطقة DNS التجريبية فيها سجل واحد لكل وظيفة، من غير دمج عشوائي.

توقيع DKIM كان حقيقيا

ولدنا مفتاحا خاصا وعاما، حسبنا بصمة SHA-256 لجسم الرسالة، ووقعنا From وTo وSubject وDate والبصمة بالمفتاح الخاص. المدقق اعاد بناء الحمولة واستخدم المفتاح العام المنشور في المنطقة. openssl_verify رجع نجاحا.

تقرير توقيع فعلي بمفتاح RSA 2048 بت والتحقق من التوقيع وربطه ببصمة جسم الرسالة
توقيع RSA 2048 بت تحقق بالمفتاح العام وربط الرسالة ببصمة المحتوى.

النتيجة بعد الاعداد

نتيجة المدقق المحلي تظهر pass لسجلات SPF وDKIM وDMARC مع محاذاة نطاق From
SPF وDKIM وDMARC انتقلوا إلى pass في نفس السيناريو المحلي.

DMARC نجح لان From كان من smsm-mail.test ومسار SPF وتوقيع DKIM من نفس النطاق. لو خلت النموذج يضع بريد الزائر في From، ممكن تشوف DKIM pass لمزودك لكن DMARC يفشل بسبب عدم المحاذاة.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

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

شو بعمل كل سجل؟

SPF

يفحص عنوان الخادم الذي سلم الرسالة مقابل المصادر المسموحة لنطاق envelope sender او Return-Path. ما بفحص From الظاهر لحاله. لا تنشئ اكثر من سجل SPF مستقل لنفس النطاق؛ اجمع مصادر الارسال حسب تعليمات مزوديك وانتبه لحد استعلامات DNS.

DKIM

المزود يوقع الرسالة بمفتاح خاص، والمستلم يجيب المفتاح العام من DNS. اذا تغير جزء موقع من الرسالة، التحقق يفشل. احتفظ بالمفتاح الخاص عند مزود الارسال ولا تضعه في DNS او ووردبريس بشكل مكشوف.

DMARC

يربط العنوان الظاهر From بنتيجة SPF او DKIM ويحدد سياسة التعامل مع الرسائل غير المتوافقة. ابدأ بالمراقبة واجمع التقارير، وبعد معرفة كل مصادر الارسال انتقل تدريجيا إلى quarantine او reject. القفز مباشرة إلى reject ممكن يمنع رسائل صحيحة نسيتها.

الطريقة الصحيحة على semsemm.com

  1. حدد مزودا واحدا واضحا لبريد ووردبريس ومعه عنوان From ثابت من الدومين.
  2. خذ سجلات SPF وDKIM من لوحة نفس المزود، مش من مقال عام.
  3. افحص SPF الحالي قبل التعديل حتى ما تحذف مزودا ثاني مثل Workspace.
  4. انشر مفتاح DKIM بالاسم والقيمة كما يعطيك المزود.
  5. ابدأ DMARC بسياسة مراقبة وعنوان تقارير تملكه.
  6. انتظر انتشار DNS حسب TTL، ثم افحص TXT من اكثر من محلل.
  7. ارسل رسائل اختبار إلى Gmail وOutlook وافتح Show original او View source.
  8. سجل Authentication-Results وMessage-ID وحالة مزود الارسال.

اخطاء شائعة

  • نسخ سجل SPF لمزود غير مستخدم.
  • وجود سجلين SPF بدل سجل واحد.
  • وضع اسم النطاق كاملا في لوحة تضيفه مرة ثانية.
  • نسيان تفعيل توقيع DKIM من لوحة مزود البريد بعد نشر المفتاح.
  • استخدام بريد الزائر كـ From بدل Reply-To.
  • اعتبار p=none حماية تمنع الانتحال؛ هي للمراقبة وجمع التقارير.
  • الخلط بين MX الخاص بالاستقبال وSMTP الخاص بالارسال.

هل pass يضمن Inbox؟

لا. المصادقة شرط مهم، لكنها مش ضمان. سمعة IP والنطاق، معدل الشكاوى، المحتوى، الروابط، حجم الارسال، PTR، TLS، والارتدادات كلها بتاثر. النجاح الحقيقي يجمع Authentication-Results مع حالة delivered ومكان الرسالة عند المستلم.

حدود المختبر

النطاق وعنوان IP المستخدمان محجوزان للتوثيق، والمدقق المحلي ما يطبق كل تفاصيل RFC التي يطبقها Gmail. لذلك النتائج تعلمنا كيف نضبط ونتحقق، لكنها ما توثق حالة semsemm.com الحالية. عند نقل الموقع للاستضافة لازم نكرر فحص DNS والرؤوس مع مزود حقيقي ونضيف لقطات جديدة اذا تغيرت النتيجة.

الخلاصة

قبل السجلات كان DMARC فاشلا وما في SPF او DKIM. بعد نشر منطقة مضبوطة وتوقيع الرسالة بمفتاح 2048 بت صار الثلاثة pass مع محاذاة صحيحة. لا تنسخ قيم المختبر؛ خذ القيم من مزودك وافحص رؤوس رسالة مستلمة فعليا.